When trying to implement IoT solutions, developers and solution architects face the dilemma of which IoT protocol to choose. Many protocols are available making the decision difficult, time-consuming, and prone to misjudgment. Although each technology has its merits and a place in the IoT ecosystem, few can claim the label of a device management protocol that allows the efficient connection and management of millions of constrained IoT devices in the field. This blog post explores the Lightweight M2M protocol (LwM2M) that is used as the foundation protocol of the Pelion Device Management Service of the Pelion IoT Platform and then walks through an example running the Pelion Client to demonstrate the LwM2M concepts “in action”. Then, we briefly describe the differences of LwM2M with MQTT, another popular IoT protocol used in the field and we present the merits on why we think LwM2M is a much more compelling protocol. Lastly, we describe the value-added services provided by the Pelion platform on top of the LwM2M foundation.
Let’s start first with the basics of device management.
A device management protocol should provide the following features:
- Secure Bootstrapping – The mechanisms to securely provision a device with the necessary cryptographic elements (keys/certificates) to securely connect to a device management server. Further, Access Controls Lists (ACLs) should limit the “allowed” interactions to predefined and strict areas.
- Remote Management – The mechanisms to configure the device with newly updated settings to reflect a new desired state required by the business application or as a response to an external stimulus that prompts a change to the device. Further, the ability to trigger actuators on the device to perform actions.
- Firmware Update – The mechanism to implement a secure and efficient firmware over the air update (FOTA) to update the application running on the device with new functionality or to fix vulnerabilities discovered after the device was shipped on the field.
- Fault Management – The mechanism for the device to report errors.
- Reporting – The mechanisms that allow the device to notify changes in its current status and allow it to be queried for specific parts of its configuration settings.
All these features should be designed with security in-mind as an integral part to protect your data and devices. Understandably, the scope of a device management protocol is wide and encompasses all the real-world issues IoT developers face when trying to efficiently and scalable manage their production devices in the field. OMA SpecWorks, a standardization body formed by several companies started a combined effort in 2013 to create a next-generation IoT device management protocol specifically targeted for M2M communication, which will serve the needs for the explosion of connected devices.
- You may not know but OMA SpecWorks are the original creators of the OMA-DM management protocol that allowed mobile operators to efficiently manage mobile phones, PDAs and tablets. If you use a mobile phone, it’s likely that you are already using the work the standardization body has done.
In February 2017, the first version of the specification was released, followed by three more revisions, with latest being LwM2M v1.2 released on December 2020. Throughout the years, the specification has incorporated many technological advances and improved a number of areas as part of the feedback gathered by the increasing number of companies deploying LwM2M in production. At the moment, LwM2M stands as a mature device management protocol, ready to be deployed in the field.
Let’s have a high-level look at how LwM2M works starting with the “interfaces” concept.
- If the word specification scares you, fear not! The LightweightM2M specifications are easy-to-follow and well-written documents and you can easily follow along and understand the internals of how LwM2M protocol works if that interests you!
Architecturally, LwM2M is a client-server protocol. The IoT device plays the role of the client while the server is the Device Management server where devices register, making them available to be managed. The communication between the two is bidirectional; a device reports back information either as a response to a request the server initiates or on a predefined time interval.
Traditionally, LwM2M relies on the IETF standardized CoAP protocol to provide the semantics and structure of how the different parties should communicate. CoAP itself is a specialized protocol, where the efficiency of the communication (to allow it to run on lossy networks) and of the runtime (to allow it to run on low-power constrained devices) played a vital role in its development. You may think of CoAP as analogous to the HTTP protocol (in fact it is modelled very closely), which defines the structure of the communication, and LwM2M as the Web browser that builds on top of it to provide value-added services (or whatever the application is that is based on HTTP).
The diagrams below depict the protocol stack of LwM2M:
First are “Objects”, described in detail later, which are the managed properties the device exposes to the outside world. Because LwM2M is based on CoAP, it inherits its properties, such as UDP as the transport protocol and DTLS for securing the path. SMS may feel strange to you, but LwM2M was designed to operate on that transport, too. (The OMA-DM protocol, a precursor to LwM2M, might played a role here!).
In more recent revisions of the specifications (v1.1 and v1.2), the protocol introduced support for TCP as an alternative transport protocol to UDP (following the advancements of CoAP), added HTTP and MQTT transports (refer to transport bindings spec), catering for Low-Power Wide-Area Networks (LPWAN) such as NB-IOT, LTE-M and much more.
- If you are in the market looking for solutions on how to best connect your devices using LPWAN technologies, Pelion Connectivity Management can be a great starting point. We’ll love to hear from you and your specific use cases and problems you are facing!
The specification defines “four interfaces” that match the device management concepts described previously:
One important characteristic of LwM2M is that it opted to use a standardized format to describe the “Objects” a device supports based on the work done by the IPSO Smart Objects working group (now part of OMA SpecWorks). This was done deliberately to allow maximum interoperability between devices from different vendors. As long as vendors supported this common format, their devices can be easily plugged in and communicate with other devices that supported it.
- You can find a list of current registered IPSO Smart Objects here.
Let’s see what an “Object” looks like when extracted from the OMA SpecWorks Registry. Below is a description of the “Temperature“ Object, used to report measurements of a temperature sensor:
Each “Object” is globally assigned an ID, and it can contain one or more “Resources” describing its properties (which themselves are assigned an ID).
Each “Resource” can:
- Be either readable/writable or executable (‘Operations’ field).
- Be single or have multiple instances (‘Instances’ field).
- Be mandatory or optional (‘Mandatory’ field).
- Have a specific data type associated with it (‘Type’ field).
During the ‘Registration’ phase with the LwM2M server, the device indicates the list of Objects it supports:
You can use the IDs for Objects and Resources to construct a URI targeting a specific resource or Object you would like to access with the management interface:
- Notice the similarities with web addressing. As we described earlier, LwM2M relies on COAP protocol, so it adheres the REST paradigm to access the properties of a device.
The specification predefined eight standard Objects that every LwM2M implementation must adhere to, so the IPSO Smart Objects working group and external vendors can step in and provide additional Objects to suit their specific needs. Below is a list of those standard objects defined by the specification:
Pelion Client Example
Now that we’ve looked at the basic concepts behind the LwM2M protocol, let’s use an example to see how those concepts are implemented in the Pelion IoT Platform Pelion IoT Platform. The official reference example, provided by the platform, connects to Pelion Device Management Service and interacts with the device’s Objects and Resources. This tutorial uses the Pelion Device Management Portal to interact with the service, but you can also choose to use the exposed API’s provided, in case you need to develop custom integration points or web applications on top of the service.
- For an example web application build on top of the Device Management Service, check our web application tutorial.
This demonstration uses an ST Discovery-L475E-IOT01A board but you can use the provided example to connect and manage any device, ranging from low-constrained devices (such as Mbed Enabled or Amazon FreeRTOS compatible boards) to mid-range devices (such as Raspberry Pis and generic Linux boxes). See our documentation for instructions on how to get started on each platform and our Pelion Ready page for a list of supported hardware boards. Further, if you don’t have access to a real board, you can also use our Pelion Virtual Demo simulator to connect and experience the platform. Check our blog for more information on how to get started.
When the example is executed the device bootstraps and connects to Device Management service. Click on the Device Directory section in the Portal to see its status as Connected:
Clicking on the device reveals a right pane with various device details and metadata, including the Object and Resources this device exposes:
We can use the ‘Information Reporting’ interface of LwM2M to subscribe to a specific Resource. This notifies you when the value of that Resource changes on the device. The example code is set to periodically change the value of /3200/0/5501 – Digital Input Counter.
- In LwM2M terms, this operation is called creating an Observation for an Object Instance or Resource.
Click on the Resource. The service sends an LwM2M Observation request for that specific Resource on the device to start receiving the new values as they change. Notice in the console that the device echoes the initial observation request received from the server (‘subscribed’), the periodic emission, as well as the delivery of the notifications with the new values.
It’s time to exercise the ‘Device Management & Service Enablement interface’ of LwM2M. Although this tutorial uses a subset of the operations of this interface, mainly Read/Write and Execute, it should give you an idea of how this interface works.
Start with the Execute action. The example exposes a blinking action on resource (/3201/0/5850 – Digital Output On/Off). When invoked, the LED of the device blinks with a specific pattern (which we’ll adjust later) and for a predefined interval.
- NOTE: If you browse the definition of the Object /3201 in the Object Registry, you’ll notice that the ‘/5850 – On/Off’ Resource is missing. That is because this specific resource is called a ‘Reusable Resource’ and is defined outside an Object definition. Many Objects, particularly those targeting similar domain, may need similar resources so instead of replicating those in each Object definition, a ‘Reusable Resource’ allows itself to be embedded to multiple Objects.
Click on the /3201/0/5850 resource to invoke the blinking operation. The operation requires no-params, so click the Send button using empty params. When the device receives the request, it starts blinking the internal LED.
Click on the /3201/0/5853 Resource to read and write on it. This resource indicates the number of milliseconds the LED stays active on each blink. Lowering it makes the LED blink faster. When clicked, the Portal displays the current value of the Resource. Edit the value and click ‘Send’. This causes the service to issue a write request on the device to update it. If you try to invoke the blinking operation again, you’ll notice the device blinks faster.
- NOTE: Similar to /5850 we discussed previously, the /5853 Resource is itself a Reusable Resource
This tutorial demonstrated the most basic operations of LwM2M, mainly to Read/Write and Execute an action on a Resource. Please see our documentation for more detailed information regarding managing resources.
LwM2M and MQTT
We couldn’t end our walkthrough of LwM2M without comparing it with another popular IoT protocol used in the field, MQTT. In fact, this comparison always comes up when we talk with our customers and partners where we are asked to share our views on the matter. First let’s start with the similarities. Both MQTT and LwM2M are standardized protocols with open specifications defined and continuously advanced by standards body responsible for their development. This openness and standardization allow a) multiple implementations (commercially or open-source) of the same core specification from different vendors to healthy coexist and compete in the “extra-mile” services, thus eliminating expensive vendor lock-in situations in the long-term, b) a continuously feedback loop to improve and enhance the specification from companies utilizing the protocol standard in the “real-world”. Another similarity of both protocols is that due to their ‘lightweight’ nature, they can be deployed in resource constrained devices (e.g., Cortex-M0) and continue to operate even in unreliable networks, common in the IoT world.
The major difference between MQTT and LwM2M can be in fact be traced in their acronym names. Message Queuing Telemetry Transport (MQTT) is what is states, a mechanism to transport telemetry messages over a transport protocol. In contrast, LwM2M is a fully featured protocol supporting all five pillars of Device Management we described earlier:
- Secure Bootstrapping
- Remote Management
- Firmware Update
- Fault Management
To accomplish similar functionality with MQTT, your development team are forced either to implement device management features (expensive and prohibited option in smaller scale teams) or worse, rely on proprietary solutions who have done some of this work for you and consequently face vendor lock-in for your entire IoT journey.
LwM2M provides an extensible and well-defined Object data model which further enforces interoperability between devices of different vendors. In contrast, the MQTT specification neither dictates what the data model of these telemetry messages is, nor the payload encoding. The payload in LwM2M is defined in the form of the efficient TLV and CBOR encoding, making perfectly suit for transport across LPWAN and Cellular networks where the network transmission is costly and limited. For both issues though, we need to mention the recently introduced MQTT SparkPlug specification which tries to provide a solution but remains to be seen if there is widely adoption from the industry.
Lastly, as we mentioned previously, in the most recent version of the LwM2M specification (v1.2), the protocol introduced support for MQTT transport thus opening possibilities to be used to even more use cases and environments. This enforces its flexible nature and ability to adopt to future requirements.
Below is a summary comparison table of LwM2M and MQTT highlighting their differences:
Building on top of LwM2M
Having LwM2M as its foundation protocol allows the Pelion IoT platform to enjoy the benefits of a mature and open standard device management protocol developed in cooperation with many companies already deploying it in the production field. On top of that, Pelion IoT Platform introduces value-added services that solve issues our customers are facing when trying to deploy real-world IoT solutions.
- Trusted Device onboarding and service provisioning of the device before it leaves the factory.
- Device Grouping and filtering for flexible and efficient targeting of operations to a subset of devices.
- A scalable update process able to handle firmware updates for millions of devices. This includes delta updates for cutting network transmission costs to the minimum required.
- Operational Monitoring of the devices (e.g. memory use, CPU behavior) to proactively detect incorrect behavior (e.g. after a software update).
- Handle long-sleeping devices with ‘last-reported-state’ and ‘desired-state’ giving the ability of business applications to continue to operate even when the device is offline.
- Handle efficiently different network types with variable transmission latency characteristics.
- and much more.
Upcoming blogs posts will cover in detail the different value-added services provided by the platform and how each one helps solve real-world IoT deployment issues. In the meantime, we provide free-tier access to Pelion IoT platform, so you can easily get started. Why not give it a try?