 Thanks for the introduction, so today I'll be giving a brief presentation on the implementation of a standard interface for SMS and Zephyr. Before we get to that, though, let me give myself a brief introduction of myself. So, hi, my name is Jared Bowman. I work for T-Mobile in the US. I particularly, I've worked on the DevEdge IoT project, particularly our hardware platform, which runs on the Zephyr RTOS. And because of this, we have found many ways in which we can improve Zephyr, particularly both for our use cases and for everyone else's. One of these is, of course, adding SMS support to Zephyr. So, to start, let me just get into a little bit of background. What value does SMS provide? So, of course, SMS is a standardized communication protocol that exists and is supported by the majority of cellular networks. And it's useful for a couple of things, particularly notifications. Now, generally, when we think SMS, we think, oh, like a restaurant text you when your table is ready, but those notifications could be or anything and can be useful in an IoT situation as well. Of course, it lets you do transfer small segments of data. And in particular modem configurations with specific networks, it's even possible to do wake up for low power applications. But again, that's kind of dependent on network and modem. But let's go on to what already exists. So currently, of course, there is no standard interface in DevRTOS for SMS. Some modems, particularly the SIM7080G does have code for handling SMS. It is the only modem it does currently. There isn't anything really existing for anything else. Of course, the SIM7080G implementation, though, is even kind of limited, particularly that it only supports receive. It can only be polled for whether a message is available. And it's a very basic custom interface. So let's just talk why does this matter? Why the standardizing the SMS interface matter? Again, currently, only one modem sports SMS and see a custom interface. And while it is useful and can be utilized for a lot of purposes, it's not really generalized. Again, it is receive only. There's no ability to send messages. There's also just no ability to actually tell when a message comes in. You have to mainly poll and check. And even when you get that SMS message, it only provides minimal information about the message. Particularly, it only provides the message body, just the text of the message, as well as the timestamp. And by having custom interfaces for SMS on each modem, each modem would generally probably have a different approach to how it's done. And without a standard interface, generalized testing is completely impossible. So let's talk about a few slides there. So let's talk a little about the design. First, when we were designing this interface, we set up some really basic functional requirements. First and foremost, again, it must be able to support both send and receive of SMS. Particularly, we want to be able to send standard SMS using the SMS Alphabet GSM 0338. We also want to support UCS 2, but we thought that'd be more as an optional, more optional. At minimum, we want to also be able to block waiting for SMS receives. Preferably though, we wanted notifications to be possible so we know when a message is received without having to wait. And finally, we want to provide pretty much all the available information from SMS message, not just the timestamp. We also wanted to say the original address or phone number it came from, data header information, and of course timestamp as well. So here's what we kind of proposed a solution. We just designed a very basic interface with five user code functions for driver side functions. From the user's perspective, there is a function for send, receive, and setting up callbacks, enabling, disabling, registering, unregistering. As well as for driver side functions that need to be implemented in tandem so that the modem supports it. And particularly those are just the driver code for sending an SMS, receiving an SMS, notifying the callbacks of a receipt of a message, as well as the toggle for whether or not these notifications would be sent out or not. So let's start with some of the user code synchronous functions or send and receive the really basics things send is about kind of like how you send an SMS normally you provide a target number as well as your message. And you just say which modem you'd like to send the message out on. Receive, also relatively basic, and takes a pointer to somewhere to write the message that receives out to, as well as the timeout requested. And basically is a walking call, wait till either the timeout comes or that you have received a message, at which point it will write the buffer and will return a zero status indicating the successful receipt. The timeout of course just getting your nice negative be timed out. All the good stuff. Of course, then there's also the callbacks, which enable callbacks will be triggered asynchronously when the modem receives an SMS message. As soon as you have the message received it will let your application know and you can do what you want with that. So people provide useful information for each of the received SMS messages, including the body of the message of course, the originator address timestamp, the concatenation info as well as just telling you which modem received the message. So, for callbacks, we have a number of management functions again. There is, of course, callback enable which is used to enable and disable the message or message callback. We have a register function to register your callback for later use, as well as non-register to remove that callback if desired. Now, the other part of course is the driver's second. We want to make it very simple for this to implement the existing separate drivers for modems. For the drivers, all is needed, of course, is a send function, a receive function, a notification toggle, which simply just enables and enables the callback mode and as well as a code to call, notify when the message is received. So, of course, the send receive and notify enable are relatively self-explanatory. They're basically just the driver side counterparts to the user code. The only fundamental difference, of course, is that they don't provide a device pointer since this is going to be linked to the device so it's kind of implied. And they're relatively basic exactly what you'd expect there. The other function important to the driver side, though, is the notify function. This is a function provided by the subsystem slash modem interface we're providing. All it does is relays the received SMS information to the callbacks. It's simply just call this function with received SMS and all this information and the subsystem will automatically handle relaying that to the applications. So, let's talk a little bit about some other considerations of future work for this. Of course, RPR really just sets out to be the basic framework to be expanded upon. We really just want to get something out there to start with. I mean, certain details will need to be considered for a final version. Right now, again, alternative encodings is one big one. Currently, our implementation, we do release on our modem, which is the one SE, which is still in the process of getting upstream. We export UCS2 and we just convert that to UTF-8. But the validity of this is a little questionable as well, just the fact that variable encodings make properly cited buffers a little difficult. And there's a debate on whether that is the best solution. So again, we're just trying to determine what the most proper solution is, but even exploding UCS2, GSM, V38, characters, some of them also do fall outside of ASCII. So that adds some more complexity here. Of course, there's also dealing with handling of other headers. Currently, we really only handle concatenations. And in our usage, that was the most important header to consider since, again, it's very often you'll send an SMS that's more than 160 bytes of a single segment. So you want to deal with longer SMS, you have to consider that header. But there are also other headers that are part of SMS. We don't have any code to support that yet. However, we probably want to consider that. We may want to share that in the future. But yeah, for more details, of course, you can see our full proposed solution in RPR. It exists now, I think it's currently still a draft, but it's all ready for review and can comment and can be worked on. So let's get to the questions part. Any questions? As of I'm going to check virtual in the room, there are currently no questions. And we don't have any virtual, but please, if you could tell someone if someone is just starting out and looking for some more information and is new, where would you recommend that they go? Or where could they find more, you know, more details, materials, tools, that kind of thing. So I'm trying to figure it out. It kind of depends on what you're asking for understanding the SMS. Well, believe me, I'd love to tell you some nice easy to understand resources. But I'll be honest in my research, it's a lot of very dense technical documentation that's really just not fun to deal with. But as, but if you're asking more from the perspective of implementing this in Zephyr, we have actuals and documentation on this and I'm trying to collect my thoughts a little here. But yeah, we will again we also have the PR that has all the information currently for this code. Yeah, it's really just kind of what you're asking there. I'm, do you see that there is something in the Q&A? Yeah, and I was just actually going to say that they are asking, could you display the link to the PR again? Oh, no problem. Any further questions? Like I should have made this a little longer. So as of right now, there are no other questions, but if someone did want to reach you or contact you after this, how can they do that? Oh, I probably should have a contact information on this. Well, of course, they can always reach out to me at my work email, of course, that is in the PR. I also do have a personal email, which I think I may have put in the PR, but I may not have, but you can always reach out to me via email. I also do, I am also in the Zephyr Discord, of course, so I don't have, I can not tell you to use your hand well thought my head, but if you reach out in the modem channel, I should be able to respond to that and answer any questions that they may have. Okay, and some, and we just had another thing come in virtual too, which says what modem have you ported this to? Currently, we have ported this to the Murata 1SC modem, which unfortunately is still in the review process for his effort considering that was the modem on our dev edge hardware kit. But that's just where we had it implemented first. We do have a, or at least I'm currently working on a version of the Sim7080G driver that has this interface also implemented. However, unfortunately that was not ready before this presentation, so again, it's not there yet, but I'm hoping to get that in in the next week or two depending on if time permits. That could be next year. You can do a follow up session. Yeah. Okay. Well, I don't see anything. Oh, hold on. Is there a limit on the length of sent or received SMS messages? Yeah, that is controlled by a config option. We have a config, I'm not going to remember this off the top of my head, but in the PR we do have taken fig options for setting the maximum send size as well as maximum receive size. Again, there is a practical limit, but the full limit of cat name SMS you can have up to, I believe 255 segments so that can get quite large. We, instead of we just went for a configuration option, whatever someone particular application needs, they can just set in a config. So if they need to send, I don't know 1000 characters, they can set that as their output size, and a driver can handle that, presumably. Thank you. And I thank John for those questions. Anything else? I don't have a lot here. Yeah, any other questions? Nothing else is coming in yet, but I do just want to remind anyone who is watching or watches this after that they can reach you via the platform as well via direct message that will alert Jared immediately that someone is sent a question or note, as well as watching the session and again and putting questions right in there. So there are a couple of ways to get to him and also check out the PR in this. And Jared, I thank you so much for joining us today. Well, thank you as well. He's glad to present. And just thanks again for having me. Thank you. Have a great day and we will hopefully talk to you later. All right. Thank you. Bye.