Device Management with Lightweight M2M (LwM2M) and a note on MQTT

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.

Five pillars of Device Management

A device management protocol should provide the following features:

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.

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.

LwM2M walkthrough

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.

LwM2M architecture

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.

The specification defines “four interfaces” that match the device management concepts described previously:

Object Model

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.

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:

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:

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.

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.

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.

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.

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:

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.

In particular:

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?