 Hello, everyone, and welcome to my session. My name is Frédéric Débiens, or Fred, if you prefer. I'm with the Eclipse Foundation, and it is my pleasure today to speak about remote management for Zephyr-based devices with the lightweight M2M protocol. So our agenda for today is fairly straightforward. And happy Canada Day, by the way, since this is July 1. So if there are any Canadians listening or rewatching, well, I hope you have a fantastic national day. So our agenda for today is quite simple. First, I will give some context about lightweight M2M, because not necessarily everyone in the IoT or even embedded space is aware of what the protocol is. Then we will discuss how Zephyr specifically supports lightweight M2M. And finally, we'll have a demo. But this being completely virtual, and I wanted to avoid the complications, so to speak. So instead of being a completely live demo, we'll see the various steps of the demo alongside with the screen caps of the results. But I won't be actually running the code right now. Well, to keep things a bit simpler. And I will keep a close look on the Q&A. So there's a Q&A section in the platform. And at the end, it will be my pleasure to answer any question that you would have. And after the session, if you didn't have the time to ask your question or simply want to chat, I will be probably hanging around the IoT channel in the Slack for the conference. OK, so what is lightweight M2M? Well, essentially, lightweight M2M is a device management protocol that has been built from the ground up for scenarios where you have sensor networks and machine-to-machine environments and really focuses on constrained devices. Devices that have very weak CPUs, very little memory, and that need to operate in a low-power environment. Imagine, let's say, a connected building. You put sensors over, replace in the walls, and the batteries are supposed to last for five years. So you need to manage those devices, a protocol that will really, really be low-power. Otherwise, well, you certainly won't like the experience, or you will have to hire a full team of battery change people. And you don't want that. I mean, it's not economically feasible. So really, lightweight M2M has been built for the ground up to take into account the constraints of IoT. And this is why it's, in that context, probably a much better alternative than, let's say, use SNMP or any other data center-centric protocol in order to manage the devices. The nice thing about lightweight M2M is that the people who invented the protocol didn't reinvent the wheel. They built lightweight M2M on the top of another IoT centric protocol that's called co-app, the constraint application protocol, which means that the basic architecture for both co-app and lightweight M2M is really very, very close to the one for rest. So you have verbs, you send requests, you get responses, that kind of stuff. The third quality or the third characteristic of lightweight M2M is that it defines a very extensible resource and data model. So by default, you get a number of properties. But it's built in a way where you can extend it and still fit into the specification because, essentially, there's a formal specification for lightweight M2M that's owed by OMA spec works. And so they do the spec work at that organization. And you can be a member of that. And on the other hand, you have multiple implementations vying in the market, some of them commercial, some of them open source. All right. Now, before we dig a bit deeper into lightweight M2M, it's really, really important to understand what co-app is about because, well, as I mentioned, lightweight M2M builds open co-app. So co-app is a specialized protocol defined in an RFC. So that's RFC 7252. And, essentially, the greatest characteristic of co-app is that it's really got a minimal overhead. Essentially, any device that supports UDP or something equivalent to UDP-like, you could run it over SMS, for example, will be able to support co-app. The typical header for a co-app frame is around 100 bytes. So that's very, very small compared to many other protocols that you can find in the typical data center. And the nice thing about co-app is that it can be used on a unique or centralized constraint network, so low power network in the field. Let's say you have a bunch of sensors in a factory that can have stuff. But it can be connected over the general internet as well. And you can even join separate constraint networks together in order to provide a connected distributed environment. So co-app by design is very close to HTTP. As I mentioned, it uses the REST model with the get, put, post, and delete verbs. It's got URIs, response codes, MIME types. But one important thing in co-app is really that it leverages a lot multicast. For example, if you have to do device discovery, you will send the multicast packet, and then you will see whatever device on the network will respond to that packet. So co-app is really important in the context of lightweight M2M. And so when we look at the protocol stack for co-app, obviously you have some sort of physical channel. It can be internet, it can be wireless, whatever. And then on the top of that, the typical protocols, so Bluetooth, low energy, or a personal area network so that the 802.15.4 family of protocols there, which includes a ZigBee, which includes a six-low pan. In this case, we see it in the stack. So there are various flavors of that, but all of them tie back to the 802.15.4 specification. And then on the top of that, you have IPv4, IPv6 that are supported, UDP with optional DTLS, which is an adaptation of TLS to the embedded space. And after that, while co-app is message oriented, so you've got messages, requests, responses, and your applications on the top. And all of that is really and fairly, in a programmer's perspective, really, really simple to use. Now, how does that fit in the typical lightweight M2M environment? Well, this is the official diagram that they put in the various documents at OMA Specworks to describe the lightweight M2M protocol stack. And you see the central place of co-app in that diagram. The interesting thing in this diagram is that it really highlights the flexibility of lightweight M2M. Yes, running over UDP, running using IPv6, using a six-low pan, and stuff like that, is a typical use case. But you can run this using SMS. You can obviously run this over attended protocols, such as Laura 1. So there are many, many possibilities there. And I think that's certainly one of the strengths of lightweight M2M, the fact that it lends itself to a variety of deployments without losing any feature, whatever deployment topology or configuration you would choose. OK. Now, what are the features of lightweight M2M? What does it give to you? The first one is bootstrapping. And that one is really critical if you're thinking about mass-producing devices in the sense that, or not even mass-producing, but even mass-deploying devices inside an organization if you design and build the devices yourself. Why is that? The bootstrapping mechanism means you can have a bootstrap server on the network, where essentially, at the factory or when you are building the device, you will put by default some PKI, some security certificates for DTLS, that kind of stuff. But those are the factory-provided ones. They are just a transient artifact that will enable the device to connect to a bootstrap server that will recognize the credentials. And once this bootstrapping process is over, the bootstrap server essentially will assign a proper IP address, proper digital certificate, et cetera, to the device. And then it will be actually be configured and connect to the real production network, so to speak. And that's a very, very well-defined area in the protocol. And that's really useful, because if you build something from the ground up using an attorney protocol, you won't necessarily have those bootstrapping mechanisms. And well, believe me, rotating credentials by hand or devising your own method to do that when you are designing a turnkey IoT solution is really a pain. So the fact that Lightweight M2M provides that, it's certainly a big advantage. Then Lightweight M2M takes care of device configuration. So essentially, it provides the primitives for you to retrieve and modify devices configuration. And certainly, once again, the fact that this is standardized is a big productivity gain for developers when leveraging the protocol. Another intriguing feature in Lightweight M2M is the fact that it will support firmware updates. So essentially, the way this will work, let's say, in a Zephyr context. So you build your executable, you put it on an HTTP server somewhere, or maybe you use some software update management platform like we've got a nice one at the Eclipse Foundation that's called Eclipse Hockbit. So you could use Hockbit to perform that. But essentially, once the new firmware binary is available over HTTP somewhere, then you can initiate a software or firmware update on the device using Lightweight M2M. So essentially, you flag the device for update and provide the URL to the new firmware file on your HTTP server. And then you start the update. So this means that the device will obviously download the new firmware, replace it in persistent memory, and then reboot, et cetera, et cetera. All of that is taken care of at the protocol level. So once again, this is really, really handy. Obviously, you still need to plan accordingly. I mean, if you want to support firmware updates like that, please ensure that you have enough persistent storage on the device to be able to do this. So if you calculate things too tight, you won't unfortunately be able to do that. And then Lightweight M2M has everything you need in order to manage faults or manage errors, manage the configuration control of not only the device but the applications running underneath. And it's got reporting features as well in the sense that you can easily query any of the properties defined by the device or even use the observe mechanism. That's a part of co-app and Lightweight M2M exposes that where essentially some server can be an observer, so to speak, of the device. And when I say of the device, it's a writer of a specific property on the device. Let's say you have a temperature sensor and you expose that, then the server can register to watch that specific temperature value. And then when the value changes, the device will send to observers a message with the new value. This is really handy. And this enables you to tweak your code to your use case because maybe, well, if you are monitoring temperature in rooms, for example, inside the digital building, maybe it's not meaningful for you if the temperature just goes up by one tenth of a degree. Maybe you want the change to be reported if it's five tenths. You are at 23 Celsius, and then you go up to 23.5, for example. So in the way you write the code, you can manage when those notifications are sent, which means you can really optimize the code for your application to the power profile of your device, to the power profile of your application. And lightweight M2M means it's really easy to tailor your application to scenarios like that. All right. So now we have a fairly good idea at a high level what lightweight M2M can do. Let's now focus on how it's implemented in the Zephyr RTOS. So this is a bit small on the slide. So I already updated the deck to the conferencing tool, so you can retrieve the PDF from there. But essentially, if you look a bit, if you squint a bit, you will see that there are two little circles, red circles on the diagram that I took in the Zephyr documentation. And one is the six low-pan larger lighter blue rectangle. So you see 15.4 support, BLE, and on the top, you see six low-pan. So six low-pan is a way to, it's a Bluetooth profile, essentially, that you can use in order to run IPv6 offer Bluetooth low energy. And then you see lightweight M2M at the top in the application services right besides MQTT and Co-App. So obviously the diagram there cannot show the relationship between Co-App and lightweight M2M. But in Zephyr, like in everything else, lightweight M2M leverages the Co-App protocol, the Co-App implementation. And they are in the Github for Zephyr. There are two very relevant samples for the general use of a six low-pan and then the lightweight M2M client. So the IPSP sample really focuses on just running six low-pan. So it's a good way to troubleshoot an environment, troubleshoot your hardware, that kind of stuff, just to ensure that you can establish an IPv6 connection over Bluetooth low energy. So I always recommend people to try that one out first and ensure that everything works at that level. And after that, there's a pure lightweight M2M client. You can run that using QMU, using emulation. Or you can use an actual board. In my case, my demo is relying on the real board. And so I will give the details of the hardware a bit later. And obviously, if you want to really test this, you need not only the lightweight M2M sample client application on the Zephyr side, but also lightweight M2M server. And fortunately, we've got a free and open-source one to offer there. All right. And that server is Eclipse Leshen. So Leshen as its core is really a Java library for implementing lightweight M2M clients and servers. So it's not a full-blown server, but it provides a demo server for lightweight M2M and also a demo bootstrap server implementings. You know, the various primitives related to that. So you can very easily take advantage of those demo servers in Leshen to get started with lightweight M2M on the server side. And obviously, there are many implementations like Leshen is used by Bosch and other members of Eclipse IoT in commercial products. And well, I must say that even the Zephyr documentation points you to Leshen when the time comes to leverage a lightweight M2M server. So it's certainly widely used and well appreciated in the community. Leshen is very simple. It's not using any third-party frameworks. It has few dependencies. And it provides nifty web UIs. And you will see a few screenshots later for device discovery testing, that kind of stuff. And even, let's say, the firmware update scenario I described you, you can totally that using the web UI in Leshen, granted that you have access to some HTTP server to deploy the new firmware file somewhere. You build it using Maven installs. So it's really, really easy to deploy in that perspective if you start from the source code. And it's leveraging our co-app implementation at the Eclipse Foundation that's called Eclipse Californium. And Californium is a very mature, well-supported. It comes from Bosch implementation of co-app. And so, well, plenty of good stuff as you can see going on at Eclipse. OK, now I will give you some code. The only warning I would give you, I took code out of the Zephyr demo there. And to fit it on the slides, I made some cuts. I removed some of the ips. I removed the comments. I removed everything so that you can have a view. So please refer to the full sample. And I put the link earlier in the deck if you want to have a look at this. But for registration proposals, you've got some code in this presentation. So first, the includes. You will see that the includes for typical lightweight N2M application are fairly standard. Obviously, you've got the base Zephyr.h. And in this case, the sample reads hardware information. It configures stuff over GPIO. It relies on some sensors. So it's using the includes for that. But lightweight N2M itself is very simple, just a plain header file in net slash lightweight N2M. And nothing more than that. And that speaks to the great simplicity and great design in Zephyr that it's so simple to just add support for the protocol by adding so few includes, so few headers. Looking at the typical main for sample application, we'll see here there's a struct that's defined that contains client information. And essentially, you have to do some setup and put values in a structured way for future use. And then after some initialization, you call the lightweight N2M RD Client Start function by passing this client structure and then some other information to get the actual lightweight N2M stack initialized and start. It's as simple as that. Now, one important thing is that as I mentioned before, this main is really streamlined. I removed some of the code. So please have a look at the full sample for the full code. A typical initialization function here, so lightweight N2M setup here. So that's the one that we were calling at the very top of the main here. And essentially what it does, you see, it assigns values to a number of lightweight N2M resources. And all of that, the fact that it's 3, 0, 0, 3, 0, 1, et cetera, all of those standard values are defined in the lightweight N2M specification. So you're not inventing that. But obviously, since the data model is extensible, you can add your own in a structured way as defined in the spec. The other thing that you do in a typical setup function will be not only to register those values, but to register some callbacks as well. So when you have specific heavens happening, you want to process them so you register the callbacks. And then the callbacks will execute whatever logic you want to at runtime. This is an example of one of those callbacks. So this is a general callback for client heavens that has been registered in a previous method. And in this case, in the sample app, it's just one giant switch. And all it does is to log the fact that, let's say, we have a registration failure for us as a lightweight N2M client, or we have a registration success and that kind of stuff. But obviously, you could put some business logic there in order to do specific things when registration works or anything like that. So once again, the protocol is very clear and clean there in the sense that it's really about defining values, defining callbacks, and decide what you want to do at runtime. All right, now about the little demo that I built to support this specification. Essentially, what I did is on one side to run my Zephyr application, I used an Adafruit Federer. And this is the RF-52 model. So essentially, it's got a small cortex M4 at 64 megahertz, some storage, but not too much. And it's got a built-in USB serial converter, so you just plug it in and then you can observe whatever is happening on the console. And then it's got Bluetooth low energy radio built in. And on the other side, I just used a random Raspberry Pi I had lying around. In this case, a model B+. You could use probably any model there, really. It was running Raspbian, the latest version. And once again, we've got Bluetooth support in there. So essentially, what we had to do essentially was to compile the demo code, deploy that on our little Adafruit Federer. And then on the other side, just ensure that 6-Lopin, IPv6, all of that was configured properly on the Raspberry Pi. And then we are running Lession on the Raspberry Pi. So we need to bring that up. And that's what I will illustrate in the next few slides. So all of the code here, if you download the PDF, should be cut and you should be able to cut and paste it without any problems. And I put little screenshots there of the output so you have an idea of what's happening when you type those comments. So to deploy the Zephyr Lightweight M2M demo is really straightforward. It's just if you want to use it over Bluetooth, you have to ensure that you've got the proper configuration overlay. The sample comes with overlays for several things. But in this case, there's one specifically for Bluetooth and another one for DTLS. So in this case, I just using the Bluetooth one. And then we do West Flash in order to deploy. So my other fruit fatter needed a little flasher. So I'm using the Jailing from Segerd in this case. And then we use Minicom in order to connect to our board to see whatever is happening. So when you do that, you have the output that you see on the right. And you see that the application is starting. And the last message, waiting interface to be up. So the network is getting up. And unless we assign an IP address to the device, it won't go further than that. So that's what we do as a second step, essentially. Establish the Bluetooth connection. And then, essentially, ensure that we associate, in this case, a static IP, IPv6 address to it. So in order to do that, the first step of instructions, you need to ensure that 6-LowPan is active in your Linux kernel. So you do a mod probe on Bluetooth 6-LowPan in order to activate that. And then Echo 1 6-LowPan enable. So with that, everything kernel-wise is OK. The next step, you need to retrieve the Bluetooth or the Bluetooth ID of the device. So HCI2 is what you use for that. So when you type that command, you will get the output in the first screenshot at the top here. And you see that, OK, there are many unknown devices. So that's my phones and random stuff. I mean, so much Bluetooth stuff in my home. It's a testament to the fact that I work in IT, I guess. So I retrieved, we see there's only one lightweight M2M IPSP node. So that's the identifier that has been allocated to my device. So I retrieved that identifier. And then I run the Echo Connect command that you see here in the second part of the slide. So we pass that. We do that Echo 2 6-LowPan control. And we use IP to assign a specific static IP address. And that becomes the BT0 interface when you type IFCONFIG, for example. And when you do ping 6 on that specific address, you will see, as you see in the second screenshot, that you can ping the device. So with that, we have the instruments that we have established properly the connection over 6-LowPan and assign a proper IP address. All right, now at this point, we just have the lightweight M2M sample running on our board. So the next step is to start our lightweight M2M server. And by the way, I added additional screenshots. When you assign the IPv6 address to the board, you will see additional output coming up. And you will see that there will be registration timeout. So that's the screenshot on the right of the slide. So you see it in bold registration timeout. This is because we don't have a lightweight M2M server running at that point. So we need to bring Leshen up in order to do that. And that's our step number three. So you can get the latest nightly build of the Leshen demo server by just doing this little W get. And it's just a few megabytes, so it should be over fairly quickly. And then you just start the jar you just downloaded. So if you have JDK version 8 and up, this would work perfectly fine. Just ensure that you set the configuration parameter to prefer IPv6 addresses since Sixlopan uses IPv6. So this will ensure that Leshen won't waste its time listening on IPv4. And you get once Leshen is running, you get the output that you see in the screenshot. When this happens, you can connect to the Leshen demo server. So you just use the IP address and port. And those things, by the way, when you start Leshen are configurable. So by default, it will use ATAT. If that port is already used in your environment, then obviously, this will, I would say that, you can reassign Leshen to use Analyte Report without any problem. And if you have multiple network cards in your environment that's the same, you can assign it to a specific network interface or that kind of stuff. So it's really flexible. And it's got a whole slew of options you can pass to it in order to configure it the proper way. But in this case, I use the defaults. So I connected to my Leshen Raspberry Pi on port ATAT. And I've got the screenshot on the left. So this is the list of devices that are registered on the Lightweight M2M server. So you see my little add a fruit feather there. And when you click on it, you get the screenshot on the right. So it will enumerate the various things that are available on the device. And you see that most of those values, you can do an observe. You can do a read. You can do a write. So you can dynamically modify the values for those configuration parameters or device parameters. And depending on what hardware support you have on the board, you can obviously expose those sensors and those hardware features through Lightweight M2M. So in the sample that's provided with Zephyr, you have support for some lights, temperature sensor that can stuff built in. So if the board exposes that, then you can manipulate them straight from the interface. And the interface on the left is also the one used to deploy firmware updates. So once again, this is something that we could have done. So that's what Leshen looks like. And at that point, you have a working environment. And you can start fine-tuning your Lightweight M2M application, implement support for whatever hardware you want to support, that kind of stuff. And Leshen will pick up whatever you code in your Zephyr application and expose and register properly in the Lightweight M2M stack. So it's that easy to work with. Now, Leshen is only part of what we have in Eclipse IoT. So I already spoke about Eclipse Californium, our co-app implementation, and I also evoked Eclipse Hubbit, which is an enterprise-grade solution to deploy software updates. So in this case, when you consider everything that we've got in Eclipse IoT at this point in time, but those numbers are always outdated, but at least they were good as of last week, so end of June 2020. We've got more than 8 million lines of code in the 45 projects that we host specifically in Eclipse IoT, more than 350 contributors, 42 member organizations, and in fact, 43. We had a new member last week, so we are growing all the time there. And that's just the Eclipse IoT community, the Eclipse Foundation as a whole as 375 or even 400 projects at this point in time. So just in the IoT space, we've got 45. And then when you look at the membership we've got in our IoT working group, you see our strategic members, Bosch, Rotec, and Red Hat. And you see who's who of the names in IT. Really, we have all sorts of layers, little startups, huge multinationals, and we've got the Linux Foundation. And this is something I would like to emphasize here today, the fact that the Linux Foundation is a member of the Eclipse Foundation. The Eclipse Foundation is a member of the Linux Foundation, and specifically of the Zephyr project. We don't have an artist of our own, and we are proud to draw support behind Zephyr and other open source RTOSs. But I must say Zephyr is certainly one of the best, if not the best. So we work very closely with the Linux Foundation, and we are happy to be a part of this ecosystem. Now, my call to action at the end of this presentation would be for you to really become an Eclipse member, to join our IoT working group, and help us build the future of open source IoT. And to contribute to the various IoT projects that we have, or even if you have technology that you want to open source, obviously we are open to that as well. OK, now, if you have questions, and there are some questions, I will look at them. Please continue to add them to the Q&A, and I will get through them as they come. If you want to keep in touch, I'm on Twitter as Blueberry Coder, and you can visit our website on ioteclipse.org. So thank you so much for listening, and now I will have a look at whatever questions are in the pipeline. So Pulkit is asking, does lightweight M2M have mesh support available? This is not something that I tested personally. I can be wrong there, but to my knowledge, I would expect this to work properly. I mean, as long as whatever mesh you are using is able to assign IPv6 addresses, the little scenario that I just described should be able to work. Obviously, mesh environments may mean that you will consume a bit more power, so you need to be careful about that. Then Robert is asking, are there other ways to connect the six-slope pan device over Bluetooth besides writing to the CIS kernel debug file? Do regular Bluetooth tools support it? I would expect this to work, but I must say I'm no Bluetooth specialist, but this is something I would try to dig a bit in. So maybe I will put something somewhere in the Slack channel if I get a more definitive answer there. Obviously, what I did in my demo was just to illustrate how things work at the basic level, but I would expect whatever typical Bluetooth tool you use to be absolutely working, as long as your kernel has the six-slope pan support baked in and that you activate, obviously, that module either explicitly or by default by putting that in the proper configuration file. The third question in the Q&A is from Andreas, and Andreas is asking, assuming I'm building a product for an on-premise solution, how does the client discover the server? Well, that's the thing, the client doesn't discover the server. What the client will do is to broadcast its presence, because essentially, as I mentioned earlier, co-app and lightweight M2M are big on broadcast, so essentially you send a broadcast packet and whatever server is there will accept the registration packet or the registration message, and then we'll process that. So if I go a bit earlier in my slides, so we see that process happening in the screenshot on the right. You see a registration timeout, registration failure, and then the lightweight M2M client is simply sending those registration messages all the time until a server will pick up the registration and send an acknowledgement message in return. So when essentially my relation server came up, we can see lower in the output that the registration message has been received, and the acknowledgement has been sent, and we see about in the middle of the output that registration is complete. So that's how it works, and that's one of the strengths of lightweight M2M. You don't need to know in advance the IP address for the server. You just start the client. If there's a bootstrap, if you want to use bootstrap, you need the bootstrap server to be available. So the client will send a bootstrap message until a bootstrap server picks up. The bootstrap server, when it picks up, will send back all the required information, and then after that, the device will register against the proper lightweight M2M server. So it's really great lightweight M2M as a solution for environments where the environment is unpredictable because you don't have in advance to know the IP addresses for the servers and all of that, and using DTLS, you can make sure using standard encryption that the data flows will be saved from man in the middle attacks and stuff like that. All right. I don't see any further questions in the Q&A. So if you have further questions, please add them now, and I will try to answer them, or otherwise, as I say, I will probably hang out in the Slack for the conference after this session ends. So the last thing I would like to say is thank you so much for attending my presentation today. I really appreciate your presence. I appreciate the questions that you asked. I hope this was useful, and please visit us at ioteclabs.org and leverage the open source components that we've got there. Many of them are server-side implementations that you can deploy in any cloud or on Kubernetes or on Promises. You do whatever you want to do. And we've got some tools that are useful, obviously, in embedded development, such as, well, in this case, lightweight M2M. I've got additional questions there. One is, I missed how to install it on the device feather. Could you repeat? Yes, I can repeat that. So it's fairly straightforward. So essentially, suppose that you have a Linux machine, you install the lightweight M2M, not lightweight M2M, but the Zephyr SDK. So that's really the simplest way to set up the tool chain and all of that. So once the Zephyr SDK is there, you have to clone the GitHub repo for the Zephyr code base. And going to the root folder of that, you type the command here, West build, you have to specify your board. The code is in samples, net, lightweight M2M client, and you pass the fact that you use the Bluetooth overlay to configure Bluetooth. After that, once the combination is over, you just flash your board using West. And then you can use Minicom or any other terminal application to connect over the virtual terminal over USB that you get in order to access the output. And that's about it. So it's very, very simple to deploy the application on the device. Okay. If there are no further questions, once again, thank you so much. Once again, happy Canada Day. And I'm looking forward to interact with you during the rest of the conference over Slack. If not, there's always Twitter. I'm Blueberry Quarter over there, as you can see on the last of my slides. So don't hesitate to reach out, always happy to strike a conversation. So once again, thank you. And I wish you a nice rest of the conference to everyone.