 So my name is Julien. I'm an architect at a company called H IQ where we build product management platform for Managing operating fleet of connected devices and Today I'm going to talk to you about a device management communication standard called the light with M2M and And the related open source project for implementing it So The first part of my presentation is an introduction to light with M2M I don't know many of you are familiar with light with M2M and co-op I don't know if you are familiar with light with M2M Okay, yes quite some people who don't know it. So it's okay. So I'm going to talk about light with M2M then discuss a bit about the Eclipse lesion project, which is a more server-side implementation of that or you can use that with the Zephyr clients and Yes, and then the last part is more about When to use light with M2M and a bit of on a bit of feedback on the standard that it's thought to be quite old now So first, yes light with M2M is built On top of the constrain it application protocol and it's mainly why light with M2M is called lightweight Because co-op was built in a way to be a light protocol replacing TCP and HTTP in a single protocol Basically you have the same Semantic as HTTP you call URLs With paths with methods you get a response code Theorically you have a transparent mapping with with HTTP Which is not the case for light with M2M due to the way light with M2M is using co-op But the way co-op was designed was ready to build this HTTP Replacement but for lightweight IoT devices plus some extra features which are not available on HTTP like Observation for streaming data Back from a single request You issue a get and every time the value change you get multiple answer to that and the blockwise transfer which is a way for Constrainted devices to Negotiate the size of the message exchange with with the server Mainly yeah, maybe it's something you apply to only for IoT devices on HTTP You have chunk encoding, but it's different. I would say and Then yeah co-op is very compact From a high-level point of view, it's basically a Small eater defining what kind of message it is. It is a get is it an answer to to something etc A token for correlating multiple messages between them for creating a transaction and The equivalent of HTTP either which which are called options for For example defining the content type of the payload, but in place of using Text-based either like you do in HTTP 1.1 Here you use numbers a Code for the header as an option you want to set and a code for for setting the value like one code to say Content type and one code to say its text basically Yes, and then you can push a payload with the co-op message So if for example, if it's a response to a get you can have a payload But if it's a get you just have the description of the get but you don't have a payload So later attempt to M So the ice the first the first release 1.0 was published in 2017 it's It was started way before I see I work at on the prototype of an implementation in 2014 so it was based on some draft and It's a standard managed by the open mobile alliance, which is a Standard body focus on cellular technology, so it's not like the 3GPP which is focused more on the Wireless protocol open mobile alliance is more focused on the application layer. I would say And it was started to be a replacement to for all medium So medium was or still probably still used a device management protocol for mainly cellular phones Where you are using HTTP and XML a binary version of XML To manage the the phone or it was also used for machine to machine communication and When we started to see a new wireless technology like LTM and NB IOT We know that all medium will not be very efficient on that. So that's why so may start at the work on the on the lightweight M2M protocol so the Physically in late right M2M you have multiple Protocol in one. It's a bit like co-op which is replacing You'd TCP and HTTP in single protocol in light with M2M. You have multiple parts Which are basically the replacement for I would say three or four protocols The first part is the bootstrap phase Which is mainly a way for Provisioning devices so you provision your device at the factory with some key material and some URL for reaching what we call a bootstrap server and then when the device come online it's reaching the bootstrap server and then the bootstrap server is in charge of giving the connected device The URL and the credential for connecting to the management server Most of the time with lightweight M2M you use one management server But there is some use case where you can have maybe two. I never seen more than two but But yeah, the idea is to use this bootstrap server to redirect the device or configure the device to go in some places. So for example to manage Win on which server you are going to put your devices Could be based on the regions or application or whatever and also you can use it as a way for distributing the key the certificate or the pre-short key for security authentication and Yeah, and if the device at some point is not able to reach its device management server The protocol mandate the client to go back and redo the bootstrap phase. So it could be also used as a Fallback mechanism Then you have something which is looking more like a presence protocol, which is a registration phase and It's where it's interesting to see how co-op is used because it's where you can see that co-op is not really used as you will do is HTTP client and server So the device start want to register with the device issue post on the device on the server Providing it some information and then Server answer with some token and the device now needs to refresh this token to show that it's still online and still Remember its state for example if the device reboot Losses token this registration token then it's forced to do a new registration and then the server knows that the device lost his state and it's useful for some Management operation I will discuss about later Yes on the device Issue a post for registration or for updating then the server can also issue get post Put to interact with the device. So it's where it's a bit strange It's not like when you use a HTTP and an HTTP API is you have the two side the server and the and the device Sending methods to each other So yeah, so it's used to be it's used for Showing the presence of the device but also what is important to note is that since we are using UDP and If you are using UDP with a private network Behind a public network in the middle you have a not get away which is in charge of rewriting the IP address and What is particular with UDP and is the Default session time for those middle box for those not router. Usually it's more like 180 seconds For UDP where for TCP it could be hours Most of the time 23 minutes. It's safe. I will say so if you don't refresh every 100 second or so in this Kind of configuration, which is quite common Your your ability from the server to reach the device will be lost or you will need to wait for the device to refresh its Registration to be able to send a command. So So yeah, so it's important. Sometimes you think, okay, I'm using UDP. I'm lightweight I'm going to send less messages for example for over a cellular communication But in fact if you need to be online 100% of the time Maybe with UDP you will send more packets than with TCP Also, yeah, so there is the registration and there is a special mode for the registration called QMode for device Which don't want to stay online all the time typically battery Battery constraint devices for example a smart meter a smart meter Maybe you need to connect on Sunday to push to say hello to the server and the server to retrieve the Metering information, but Probably you don't want to send a message every 100 seconds to Keep online. So the QMode is that you are going to say this device is saying I'm going to go offline after some time Which is most of the time 80 seconds if the server don't send instruction to the device In this given time frame after the registration of the registration update The device is expected to go offline and then come back later with the registration update Okay, so we have these two first pieces the bootstrap So registration and now we have the object model It's what is most important in lightweight M2M is what you use for managing the device for reading values writing values and Like what M2M is using this object model based on URL but each pieces of URL are numbers and Numbers or the first numbers represent what we call the object ID and The object ID so there is a bunch of Object defined by the standard and it's what provide the Interoperability on the at the device management level so You have a device object for example Representing all the device information like the manufacturer the model the serial number And each device are supposed to implement the object in the same way and present the data in the same way So you need to fit in the object model to become interoperable Yes, so the standard define a bunch of object plus there is more object than that And then you have this concept of multiple Instances or single instances objects for example the device object or the location object It's a single instance device because it's you have a single device So you don't need to have multiple instance of that But for example or object which are a bit more Software abstract like the light weight M2M server, which is the information For the values server the device need to connect to or for example the software object, which is An object for installing Software on the device they can be multiple instances Because you can manage multiple instances of different software or multiple instances of the server Information for the device There is also a bunch of new well new of Object define for sensor which was merged into the lightweight M2M standard for Managing Sensor and actuator. So it's interesting if you want to Expose some very simple value like a humidity Value a sensor value which are maybe not core to your application Because probably for your application you have those very specific needs and probably you will design your custom object But for example you are building a machine with a very complex System, but on the side you have Temperature monitoring and you say okay, maybe it's good to add it to my system and In case in the future someone operating the system want to know the temperature of the system to detect some Problems they will be able to look at this at this value. So the object model is Mainly something you want to publish Or at least you need to define it There is a central repository managed by the OMEI You need to define your object using some XML definition language defining all the values you have in your in your object and And package that and Maybe you can publish that publicly and the OMEI will give you a number an official number and it will be your object and Anybody will be able to Understand and use what your object is exposing Or you can do a private object and not publish it if it doesn't make sense So we have this object model where we can read write Values on the on the device and now how to push values and create a telemetry pipeline from the device to our application to our server It's why you have two mechanism one the first one the first historical one which is observation. It's some a Server driven Mechanism so the server issue get on the values object or resources It's interesting to it's interested into monitoring with the observation option on the on the query And then the device will send a first Answer and then if any value change in the observer to resource or object the device will send back Updates of the content Now since one dot one. I think yes, there is a new new system which is more Device initiated which is called the send operation Which is basically posting some content with pass and values to the server At the the device initiative so this is not controlled by some configuration It's really device application dependent If you want to control it you need to provide to build something an object or something else to to configure it Okay, so now Talking about the open source implementation. So first eclipse lesion. So eclipse lesion is a really on Java library For implementing lightweight M2M server and clients Clients, I will say it's more it was developed more for testing the server pieces You can build a device using this Java library, but it's a Regular Java library. It's not something very it's not embedded friendly at all It's a Library with no With little dependencies and no framework usage. So I don't know if you If you like to use a spring boot, which I don't like but if you want to use that you can totally take Lesion and wrap it into spring boot the spring boot framework if you like it's very We try to keep it very Java friendly plain Java There is a web demo UI for testing the protocol Which it could be useful for people developing clients and devices for testing the capabilities of the device But it's really not something you want to deploy on the cloud and because it's not scalable or not secure It's based on California the Java library for implementing co-app and DTLS but since recently a Layer of abstraction between the co-app implementation and the lightweight into implementation was Introduced so probably in the future lesion will provide Like to attempt when based on some other Java library like the So open co-op one Which is an interesting one because it's simpler and lighter than the eclipse californium one and yeah There is a sandbox if you want to test the device It's always deployed with the latest commit and there is two version of lesion one is v1, which is stable Sometimes there is really is for bug fixes or security problem, but there is no feature development It's targeting like to attempt to m1.0 And it's stable the API is stable And there is a v2 which is under development, which is targeting 1.1 So API is not stable But it's something you can use in production if you are not afraid of fixing some API When you upgrade your library, it's basically what I'm using in in production for hIQ and it's working. Well and And the lesion maintainer is doing a great job to document the roadmap or everything which is Currently under under work or or in target for the next releases and And who is working on what? So you can reach the people if you need Clarification or help on some features And yeah Yeah, I'm going to skip this part, but basically yeah, it's a Java library you configure it use You say, okay. I want to bind on this interface this port You could provide the models You want to customize for example and you start it and when it started then the server is ready to accept registration from the devices It's very different when you Use a client because on the client. It's a bit different what you need to do is Define of the all the objects you want to do for example for the Zeffield item 2m client You need to define all the objects you need And set the values for example for the device object you need to set the manufacturer for example and Yes, and since a lot of like to item 2m is controlled and configurable through object by the protocol then the client often it's configured by setting values in the object and Yeah, as a number the developer something which is important is that This object model of like to item 2m means that each time you create a new object You need to consume memory for exposing the structure behind the behind the object So the more features or more objects you create the more memory you will need Yes, yes, well it's the Zeffield item 2m client is supporting some of the Standard sensor object. It's very simple to wire the sensor object of like to item 2m and the same so Facilities in Zeffield and with some worker push the value in the in the light to item 2m object and expose that on the on the on the communication layer Okay, so now Yeah, a bit of discussion about greater light to item 2m So light to item 2m is lightweight because it's using co-op. So that's what make it friendly for using wireless communication But that doesn't mean it's simple. You have this object model. You have this key Bootstrapping management protocol you have these registration pieces And yes, and over time you add more and more feature on the on the protocol And also the standard body they try to keep Backward compatibilities So every time there is a new release, you know what it is when you want to keep backward compatibility and for example when you read Optimization in the real is not of lightweight to item 2m. What does that mean? That means they are not Reworking what was done before they were they are introducing a new feature a new flag for having the feature behaving differently so More release often mean more complexity and and supporting more and more more objects Yes, and also something to know that if So the interoperability comes from the way object are built and people are supporting Try to to implement the same object so then from one server to another server Two devices are supposed to be able to manage the same way But that means for example for firmware update there is 20 way to do a firmware update in IOT so Sometimes yeah, you could find that a bit complicated the way it was Created in the in the standard for example for firmware update in lightweight M2M You have multiple step is not you send a firmware and you wait for a result. You need to send Write a packaging line using co-op or send a URL Pull the status from the server to know if the device is downloading correctly if it's downloaded correctly fine, you can go to the next Next phase or you need to look at the error code and the error code that are fixed in the standard so you need to Categorize your error in the error code of the standard and then yeah, it's On the and then that you go to the next phase you ask from the server point of view You ask the device to execute the installation And same you pull for status back, etc. Etc. So it can be a bit complicated and you need to fit in the what was decided in the standard So that's a bit the drawback to try to be Interoperable I would say and also there is sometimes strange complexity like when they created this software update object It's looking like but it's not like the firmware objects They have different states have different values for error code, etc. So Yeah, since it's a standard organization and you have multiple contributors sometimes you find things like that like pieces where which were frightened by two different people and they not very well or harmonized What is also a bit yeah a side effect of that of this standard Our Committee approach is the content type and I Don't know you you would expect that for representing all such a model like where you have Key and values and values being string or integer or float or Boolean or binary array You don't need to have a lot of different way to do that, but you have From a device point of view, it's not so important because I think most of them are optional so you can implement Only one two or three But from a server point of view, you need to be able to implement You must implement all the different media type and some are just the same in just a different language like json and sebo sebo is really just a Binary version of json. So yeah, so there is quite a lot of complexity by this accumulation of feature on more positive notes and What is interesting is that? I think it's today is one of the few There is really little option if you want to be interoperable in the IOT device management world There is quite a lot of people using eclipsation so here it's just a list of people who agree to put their logo on the eclipsation website, but there is more than that and And from the later item to end point of view the the standard is quite popular in cellular IOT for example if you are using a modem and for connecting, I don't know the LTM or BIOT and Your device is carrier certified You probably already have a lighter item to end client in the cellular modem because it's mandatory for having the certification so maybe you have a way for hooking your application to this system and Reuse something that it's already there There is now a large ecosystem of vendors I seen some in the in the conference and Yes, and They're proposed nice solution for scaling your deployment either from client point of view or server point of view Exactly what we do at H IQ like providing a nice device management Connected device operation platform and for our low-level light-weight M2M implementation we use Eclipsation And that's it for me if you have questions there's been a question in from the online virtual from Romain Pelotot and sorry if I've said that name wrong anyhow. He says thank you for the presentation is Lushan Ready for production as an LWM2M broker even with customization Okay, so Yeah, as a As a light-weight M2M server, I don't think we talk about broker for light-weight M2M, but Lushan, yeah, it's production ready in sense. It's a Java library then you need to create your server And if you want to scale to million of devices, then you need to create a cluster and put a load balancer in front of that Etc. But yeah, I know that today it's used for deployment of More than one million devices You need to know how to scale your Java server, but it's totally production ready. I would say okay He's got another question With bootstrap x509 certificate is transferred from the server to the device on the wire Do you advise that the security? Do you advise that security mode anyway? Yeah, and then EST enrollment over secure transport is preferred question mark Yeah, so when you are bootstrapping you can exchange pressure key or use certificate, but when you use certificate You are not supposed to send the Well, I think in the protocol you can do it sending the private key Over the year, but also yeah, you it's possible to use a bootstrap protocol for Certificate with EST to enroll the device With your public key infrastructure without exposing the private key I think it was clarified in the 1.2 What the two release of the of the of the standard Does anyone else have any questions there's a mic over there people want to stand and go and ask any questions not seeing any Okay, okay. Well, thank you very much. Thank you very much