 Hello, welcome to the presentation on Lora and Lora Van and Zuffer. My name is Manu and Sadasivam. I work as a colon engineer at the Qualcomm learning team of Linaur. So I contribute to various open source projects such as Linux, kernel, UBOO, Zuffer, MRA, library, et cetera. And I do maintain few steps here and there. So today, I'm going to talk about Lora and Lora Van and Zuffer. And this presentation is not about deep dive into Lora and Lora Van technologies. But instead, I'll be focusing on the addition of the Lora and Lora Van wireless technologies into the Zuffer autos. And I'll give a quick introduction on what is Zuffer, Lora and Lora Van. And I'll share some thoughts on why Zuffer needs Lora and Lora Van technologies. And then I'll talk a little bit about the history of adding this support into Zuffer with various pull requests. And then I'm going to talk about the community which is growing around this effort. And then of course, the future plans. All right, let's get started. So, okay, what is Zuffer? So Zuffer is this scalable, small footprint real-time operating system for the resource constrained systems with devices like microcontrollers. And it is highly configurable in the sense that we can shift on most of the features. But in these days, Zuffer is extending its scope, which means that for instance, there is a 64-bit architecture support in Zuffer, like it can run on the Cortex-A53 processor from Aham. So there are talks going on around making Zuffer as the future hypervisor and boot order for the next. So clearly, Zuffer is not constrained onto the MCUs, but its scope is getting extended. And of course, Zuffer supports multiple architectures. Not only Aham, it supports x86 from the beginning. And then more recently, it started supporting RISC-5 and then extensor. And one of the nice features about Zuffer is that it offers rich functionality. For instance, in networking, it offers BLE. Zuffer has its own BLE networking stack. And then it supports Wi-Fi, open trade. And the other peripherals like USB, display, modem, it's already that in Zuffer. So it's a cluster of functionalities, I would say. And Zuffer is truly open source in the sense that it offers the most permissible license, which is Apache 2.0. Of course, it's often loud by everyone in the community. So let's look into LoRa. So LoRa is an acronym of long range. So it is an LP wireless technology based on the chip spectrum modulation technique. So it was invented by Cycleo, a French company. And then it was later acquired by Centek. And then Centek started selling the LoRa videos based on this modulation technique. So LoRa operates in a license-free, sub-gurus frequency band, which varies with locations. For instance, it operates in the 865 Mahals in India, and then 868 Mahals in Europe, et cetera. And not only frequency, the data rate and also the spreading factor also varies with locations. And we have restrictions based on the countries. And Zuffer is a perfect candidate for low data rate and then long range applications like the smart city and then industrial applications, where we don't need to send high amount of data in a short period of time, but we do need to cover long range distances. And the data rate is actually low. And what is LoRaVan? So LoRaVan is the MAC layer. It sits on top of the LoRa. So in terms of the OSI model, we can say that LoRaVan is the MAC layer and LoRa is the PHI layer. So LoRa protocol is closed in the sense it is proprietary to Centek. On the other hand, LoRaVan specification is open to the public and then there is also a reference implementation available in the data repository so that everyone can just use in their end product straight away. And LoRaVan works in a star-based topology. So the end nodes transmit data to the centralized gateway over here and then the gateway will relay the messages to the network server. So I have simplified the network server part because usually there are three components here. One is the network server and there is join server and there is application server. But in a typical system, these three can be contained in a single piece of server. That's why it's just over simplified. And the communication between the end node and gateway happens through the LoRa technology and then the communication between gateway and the network server in cloud happens through the TCP IP mechanism. And then I should note that the LoRaVan is actually a software implementation not the hardware one as like LoRa. I haven't seen any, or I should say that there isn't any hardware implementation of LoRaVan. It's all running as a software stack in a dedicated MCU and then which in turn communicates with the LoRa, because you are using the communication protocol like SPI. And the LoRaVan specification is governed by LoRaAllens, which is a nonprofit association of more than 500 companies invested in the LoRa technology. So it takes care of the specification and make sure it gets evolved to meet the future needs. Okay, so here comes the question. Why Zephyr needs LoRa and LoRaVan? So far, Zephyr is mostly used as the autos for IoT applications. But in order to make Zephyr as an autos for industrial-grade applications, there are certain parameters needs to be considered. And first on is multitasking. And Zephyr is already excellent in that because it has the support for preemptible and then the cooperative threads. So it can handle multitasking really well like this guy. And then it has the support for MISTRAC guidelines. I mean, Zephyr is not fully MISTRAC compliant, but the process already started. And then there were several pull requests merged in order to make Zephyr the MISTRAC compliant. And I hope that in the future we can see that Zephyr is fully MISTRAC compliant. And that's one of the requirements in order to meet the industrial-grade certification. And for security, Zephyr is already pretty good in terms of security when you compare with the other open source autos available in the market. So Zephyr has its own security technical steering committee which governs the security processes. And then there is a security guideline available for the companies and the individuals who are willing to make secure applications using Zephyr. And of course, there are support aids available for cryptographic algorithms using the external trusted repositories like Ember DLS. But what is really missing today is the communication medium which is used for transferring the data for the industrial applications. As I said before, Zephyr is primarily focused on IoT applications. So it has support for networking protocols such as BLE Wi-Fi which operates in the 2.4-bit range. But unfortunately, that frequency range can be used for industrial applications as it is overly polluted because all of our consumer devices are already operating in the same frequency range and it may cause interference. So what we really need is a communication protocol which can operate in a less polluted space and that's where Lora comes into picture. Since Lora operates in the sub-gearage frequency range, it is less polluted interference and it can cover long-range distances. And in the industries, we don't need N number of 100 sensors sitting in the single industry and then talking to each other using a machine network. We don't need that kind of setup. What we really need is a device per compartment which sends low data often for NR or so and then it should be able to cover the entire building or the entire industry and the same requirement often satisfies for the smart city applications also. And this makes Lora an ideal candidate for making Zephyr as the industrial-grade autos. That's the whole motivation for adding Lora and Lora when supporting Zephyr. Okay, so here comes the history. As like most of the features in Zephyr, the Lora support was started by opening a GitHub issue in the Zephyr repository by a community user and after some time, Kate Stewart from Linux Foundation opened a feature request in order to make Lora in the official plans for Zephyr. And a couple of months later, Dingtao, a community member, opened the first RFC pull request into the Zephyr repository for making the Lora support into Zephyr. But that is on catch. That pull request was incomplete in the sense that it had no API and board support and the author made it clear that he didn't want the pull request to be merged into mainline but he just wanted to share what he was working on so that others can also benefit from that. So in that PR, he just reused the Lora man reference repository by Sentech which is called Lora Mac node and then he added support for a couple of Lora radios like SX1272 and then SX1276. So in that PR, there were discussions going on around the basic API design how the Lora man code should exist in Zephyr, etc. But unfortunately, the PR was closed by the author since he made it clear that he had no intentions on merging it to Zephyr. But clearly, it made as a starting point for the Lora support in Zephyr. So I took it forward and then I submitted a RFC pull request after some time addressing all the review comments given in the initial PR. So in that PR, I proposed a basic API and then the code design for Lora and I should note that I haven't added the Lora man support in that PR because I wanted to start small and then build it big. If I add Lora man support then I thought that it would make the process more complex so the best way to get something into Zephyr is to make it small so that other people can also review the code easily and get it merged. And for the PR, I used 96 Boards Vistrio as the target platform. That is one golden tool in Zephyr is that we need to have a target platform for any feature we are adding to Zephyr in order to make sure that it is validated properly, it's working properly and others can also test it. So that's why I used 96 Boards Vistrio which is IoT based for 96 Boards designed by Rack Wireless and then it had the Lora radio embedded on it. So I added Boards support for it in the pull request and then I also I also wrote the SX1276 driver from scratch. So I hadn't reused the existing Lora man reference implementation by SEM type. The reason was like I wanted to host the native Lora drivers in Zephyr and only depend on the SEM type repo for Lora man stack. But unfortunately that idea was turned on by the community and then the PR was snagged. So the suggestion was given to me to reuse the existing Lora man repository because it had support for various Lora drivers. So the reason was not to reinvent the wheel again in Zephyr and it offers more code maintenance also and I agree with that. So I went back to the drawing board and then I reworked my PR and then I came up with the next version of the PR and this time I reused the reference repository by SEM tech but still I haven't added Lora man support and I still stick to the point of start small and then build it big but I added the SEM tech Lora man repository as a Zephyr module. So the way it works is in order to make Zephyr depend on any other external repositories like this one we need to make it as a Zephyr module. We need to clone the upstream repository into the Zephyr organization and then the guy who owns this repository need to make sure that whatever the change which happens in the upstream is getting in sync with the clone repository in Zephyr. So this is the proper way of adding a module in Zephyr. So this time I got positive reviews from the community so I just printed the board specific parts from the pull request and then I merged it separately. So roughly after three months of time going through the reviews the PR got merged. So it was a moment for celebration but I didn't stop and then I straight away started working on the Lora value presentation. All right. So right now that is a basic API in Zephyr which provides the Lora point-to-point support between two end nodes. So we have the config API which does the configuration of the Lora radio based on the modem config structure. So this structure will have all the parameters required for the stack to configure the device and then we have the API for send. So it takes a buffer and then a buffer length so it will just transmit the buffer to the end device and then we have separate API for receiving the data from the end node also. So I have also added on sample application in the pull request which requires two Lora nodes. One will be sending the data and another one will be receiving the data just to exercise the basic functionalities of the API. All right. So this is the radio configuration structure which is used for configuring the modem. So we have the frequency parameter. It defines the frequency range in which the device is operating and then we have parameters for configuring the bandwidth, data rate, coding rate, preamble length and then the TX power. So that is on final parameter which is called TX and it is used to configure the modem for transmission or receive. So right now that is on limitation in the LoraVent code for configuring the modem each time for sending and receiving. If we want to send continuously we can configure one time and then start sending the data but if we want to switch to receive then we need to reconfigure the device and then start receiving the data. I hope that this limitation will be addressed in future days. All right. So here comes the next PR for adding the LoraVent support in Zephyr. So this time I had some experience of handling the pull request and then I used the comments which were given for the Lora pull request and then I tried to avoid as much as the mistakes I did in the first PR in this LoraVent PR. So this time I placed the code LoraVent code into the subsystem directory and then the API and the intro directory. So in the LoraVent PR I reused the existing Lora drivers which were already present in the Zephyr repository not through a direct way like calling the config and sending the API but indirectly through the Semtech repo which has the callbacks into the Zephyr Lora API. So for this PR there was no modification required in the Lora Mac node repo but I just need to enable a few drivers like the cryptographic ones for adding the LoraVent but other than that it was very straightforward. But I should stress the fact that designing the API for LoraVent is somewhat hard compared to LoraVent. The reason is because of the synchronous and asynchronous nature of the LoraVent specification. For instance LoraVent send or the uplink is a synchronous operation but LoraVent receive or the downlink is an asynchronous operation. And we also have the blocking and non-blocking states like the send cam block for N number top time, etc. So this makes somewhat tricky for the API design. So again I wanted to make things simpler so I just went with only uplink nor the downlink. And then there's one more challenge for storing the keys and states in the N node. Since the keys are stored in the network server and also in the N node we need some kind of secure mechanism to store the keys safely in the N node so that it won't get tampered but for the initial PR I didn't consider that. And the initial PR supported both OTAA and the ABP join methods. So OTAA is a dynamic way of joining the LoraVent server. And ABP is a static way of joining the LoraVent server. And I had only added support for class A device class and there was still support needed for class B and class C. And the region static is static which means that before running the application we need to make the LoraVent stack know what kind of region it is operating the device is getting operated which means it can be India or it can be Europe etc. And of course there is no support for downlink as of now and after posting the PR the reviewer has gone for 8 months of time mostly because of me working in a spare time on this project and also the delays in getting the reviewers finding this PR and hopefully after 8 months of time this PR got worse just couple of weeks before. Yeah it took a lot of time. So here is the basic API for providing the uplink support in the LoraVent. So we have the join API which is used to join the network server using the LoraVent join config and as like Lora it has the parameters contained the whole structure and we need to call this API with the join method whether we are joining using OTA or APP and then it will return 0 if the network join is successful or the native errant code if failure and then we need to start the LoraVent stack in order to send or receive the data but right now we just have the send API which is used for sending the data to the network server. So again we are passing the buffer and then we are passing the buffer then and then there are flags which determines the type of behavior of the message whether it can be confirmed or it can be unconfirmed. Confirmed means we should be waiting for getting the confirmed message from the network server. If unconfirmed means it will just return all right. So these are the parameters used for joining the network and then sending or receiving the data in the LoraVent so we have two structures for OTA and then ABP and both are declared as union because you will be using one at the point of time and then we will have the join UI network key APP key so for OTA the session keys are derived using this APP key but in the case of ABP the session keys are stored statically in the device itself so every time when the session keys get changed in the network it needs to get changed in the device also if you are using ABP so the keys needs to be stored statically in the device we can't actually modify the keys dynamically that's not it's supported and then all these joining parameters are based on the LoraVent version one point on specification and there are plans on going in order to store these keys in a secure element of the device just to make the keys don't get tampered using an external factor all right so while looking on the LoraVent support developers from various part of the region reached out to me willing to collaborate in this effort so for that purpose I created a Slack channel which is called Zephyr LoraVent and then I invited all the members who are willing to collaborate and then I mentioned this Slack channel in the LoraVent PR itself so that people who are all willing to try out the PR will notice this Slack channel and then join so that's what's the whole idea and then as like I expected more members started join in this Slack channel and then they started contributing to the existing LoraVent and then LoraCode so they submitted several PRs and then they started improving the Lora support so as like any true open source project this started getting traction all right so we are in we came to an end of the presentation and then let's see the future plans on the todo list so we need to add the class B and then the class C device classes and then we need to add the secure element support for storing the keys and states this is pretty important because if you want to deploy the Zephyr LoraVent in any product we need to have the secure element in place for storing the keys so this will take the top priority for us to work on and then we need to add the support also and then that is an interesting feature which needs to be added so a lot of the LoraVent vendors they have a customized firmware running on their module which exposes 80 commands that are communicated using the UART protocol but what we really have as of now in Zephyr is we will talk to the Lora radio directly using the spy protocol from the target MCU running Zephyr but we need to support the 80 command set feature also because there are times where we cannot customize the end device firmware and then we have to relay on the 80 command set for achieving the LoraVent networking so that support needs to be added as well and then of course we need to add more Lora modems also right so that is it for this presentation I hope everyone really enjoyed and then I am expecting everyone who are willing to try out this feature to actively collaborate, join the Slack channel and then contribute to this project thanks a lot