Crash course in LwM2M

Lightweight M2M (LwM2M) is a standard created by OMA SpecWorks that specifies device management, telemetry and service enablement mechanisms designed initially for devices that have limited processing and storage capabilities (commonly referred to as resource constrained devices). The technology functions very well over potentially unstable and low bandwidth networks such as cellular networks as well as LPWA radio networks.

In LwM2M, the information exchange occurs between the LwM2M Client (e.g. IoT device) and the LwM2M Server (e.g. IoT platform) or the LwM2M Bootstrap Server. There are four interfaces governing the communication:

• Bootstrap

• Client Registration

• Device Management and Service Enablement

• Information Reporting

The Bootstrap Interface defines the tools for the LwM2M Bootstrap Server to provision the LwM2M Client with initial information needed to “register” with the LwM2M Server. Once the Client has been provisioned, it can inform the LwM2M Server about its presence and perform the registration via the second interface (Client Registration). After a successful client registration, the remaining two interfaces can be used.

The Device Management & Service Enablement Interface is where the actual device management occurs. By using operations defined in the protocol such as “Read”, “Write”, “Execute”, you can access the data stored in LwM2M Client resources.
Finally, Information Reporting – the last interface, which enables the LwM2M Server to automatically receive periodic updates about selected LwM2M Client resources. This can be used to proactively monitor the values of certain parameters and adjust the thresholds to fit each specific use case, per device and in bulk.

The data model for LwM2M is organized in a three-level tree: Objects, Object Instances and Resources. Objects consist of Object Instances and Object Instances consist of Resources.
Each level has its own numerical identifier which forms a path. For example, a path /0/1/2 refers to Resource ID=2 in Object Instance ID=1 of Object ID=1. The path may also end on the whole Object Instance (/0/1) or even the whole Object (/0).

Resources can be represented as certain data types, such as string, integer, Boolean,or float. This very well defined data model ensures interoperability even in complex IoT environments, where different types of devices communicate over many different protocols.

As mentioned before, LwM2M is designed to consume as little bandwidth as it can. To make this possible, it uses the Constrained Application Protocol (CoAP), (which works in a similar way as the HTTP protocol but is especially designed for resource constrained devices) that helps LwM2M devices to easily communicate with LwM2M Server as well as each other.

CoAP makes it possible to transmit messages with low overhead – the minimal header size is just 4 bytes, which makes it possible to send meaningful content within single, non-fragmented UDP datagrams, even over links with low MTU, such as SMS.

Although LwM2M comes with a few already defined objects and resources, it is not enough to provide structured data models which would allow efficient communication over protocols such as CoAP. Responding to these needs is the IPSO Smart Objects project (now also part of OMA SpecWorks) that aims to ensure the interoperability on the application layer by creating and providing a common design pattern of objects based on LwM2M. The key feature of IPSO Smart Objects that distinguishes them within the LwM2M data model is that they are designed to be reused and easily adjusted to new use cases.

Furthermore, there is also a possibility of defining your own objects with a special editor provided by OMA and registering them with OMNA (Open Mobile Naming Authority). The objects will then be reviewed by individual members of OMA and added to the registry (if they pass the evaluation).

The protocol in its current version (1.1) supports various transport bindings, including UDP, TCP as well as SMS and LoRaWAN. Most importantly, however, Lightweight M2M defines a Queue Mode – a special mode of operation in which the device is not required to actively listen for incoming packets. Queue Mode can be set in Register and Update commands, which means that, for example, after the Update command, the LwM2M Client is only required to listen for incoming packets for a limited period of time. The mode is particularly useful when a device is not reachable at all times (be it due to lossy network or just to minimize the power consumption).

Yes, it is.

The security is based on CoAP and utilizes DTLS (Datagram Transport Layer Security) or TLS (Transport Layer Security) as its main security mechanisms. DTLS/TLS implements authentication, confidentiality and data integrity between the LwM2M Server and the LwM2M Client along with three security modes:

• certificates,

• raw public keys,

• pre-shared keys.

The LwM2M Client needs to have credentials and the configuration information obtained during the bootstrapping process. Once the bootstrap is done, the LwM2M Server authenticates the LwM2M Client enabling the LwM2M Client to use all the security features supported by LwM2M.

The Lightweight Machine-to-Machine standard is truly lightweight. It allows to manage devices that have very little power over really low bandwidth networks, while being itself a standard with a very simple and not confusing stack of technology. The devices that LwM2M is designed to manage include sensors, microcontrollers, actuators etc. which can sometimes be installed in a place that is hard to reach. It does not change the fact that such devices are actually on the web and do need to be managed, secured, updated, monitored etc.

To sum it up, LwM2M responds to these needs by offering:

• a simple but well-thought-out and well-designed stack of technology

• ability to manage devices with very little power over really low bandwidth networks

• very little bandwidth consumption with very light payloads

• great security based on DTLS and TLS

• enhanced interoperability thanks to a clearly defined data model

• device and network flexibility and applicability to rapidly changing needs of the IoT market

• possibility for the IoT market to move into sectors where devices need to be of low cost, low power, limited network or battery lifetime etc.

• time-to-market improvement – LwM2M is ready to use as a plug-and-play solution

• open-source LwM2M clients and SDKs are available – free to download and use

Composite operations such as READ-COMPOSITE, WRITE-COMPOSITE and others.

In the early specification, LwM2M utilizing CoAP used simple operations such as READ, WRITE, EXECUTE, CREATE (and others) based on basic methods used for example in HTTP (GET, POST, PUT, DELETE). In the latest LwM2M 1.1 specification however, there are new operations added on top of the already existing ones. These include composite operations such as READ-COMPOSITE or WRITE-COMPOSITE. The idea behind this was to extend the basic READ, WRITE and other commands to allow aggregation of operations on many different objects and send all the acquired parameters in one payload.

SEND operation in Information Reporting interface.

As far as operations are concerned, SEND is another one that significantly improves LwM2M’s telemetry capabilities. In the previous specification, in order for the LwM2M Client to be notified about any changes in a given resource, the LwM2M Server had to first issue OBSERVE operation on that resource and only then could the LwM2M Client issue a NOTIFY operation to receive the desired information. SEND on the other hand, gives similar results to NOTIFY operation, with the difference that it does not require OBSERVE operation to be active to send notifications. Thus, it makes the communication between the client and the server not only easier but also more reliable.

Transport bindings such as CoAP over TCP and Non-IP Data Delivery.

LwM2M gives you a plethora of transport bindings to choose from. If your project requires minimum power drain and maximum speed, UDP is a way to go. However, if you need reliability, you can use the TCP protocol thanks to its NAT/firewall traversal capabilities. Furthermore, you can also make use of Non-IP Data Delivery – another transport binding, which is particularly attractive for the IoT, because it further minimizes power consumption for IoT-specific resource-constrained devices.