LwM2M is a lightweight platform that works in the background to send messages to and receive messages from devices. It is designed to be a reliable and low-cost alternative to other networking technologies. There are three basic configurations that you can use with this technology. These are Binding mode, Objects governed, and Update process.
Objects governed
LWM2M is an emerging industry standard for IoT devices. It provides a simple REST service and uses CoAP protocol for communication. The architecture diagram below shows how it works.
Objects governed by LWM2M are grouped into resources, which describe the characteristics of each object. Objects are assigned unique resource IDs. They are then linked to one another. For example, the temperature sensor object has up to 10 sensors.
Objects are also grouped by functionality. This includes general device information, reporting states, and reporting states that are specific to the LWM2M protocol. Objects can be imported for custom implementations of standard objects.
Objects are also grouped into instance IDs. This is a key aspect of LWM2M. Each device has a unique number, referred to as an instance ID.
Some of these objects are mandatory and others are optional. In some cases, these objects may be read-only.
Using a LwM2M Object is not as simple as it seems. In order to write to a particular resource, the client must first add it to a Device Protocols. Other design decisions must be taken into account by the manufacturer of the device.
Generally, it is recommended to use the Write-Composite operation. However, clients should be careful to ensure that all objects are supported. If all values cannot be written, the Server will reject the request.
Alternatively, it is possible to use attribute-oriented commands to specify resources. These are useful for providing unique Resource IDs. OMNA can provide these.
A dimmer, for example, can have a variable that controls the brightness level. If the server can read this value, it can set the switch on and off.
Update process
The LWM2M protocol is a flexible protocol that supports over-the-air software updates. It has no restrictions on the format or number of images used.
There are several phases in the process of updating device software, including the software activation process, the package installation process, and the firmware update process. This article focuses on the update process.
The first thing that happens is the client attempts to apply firmware. When this fails, it automatically proceeds to the idle state.
The next thing that happens is the LWM2M server begins to interact with the device. The server may instruct the LwM2M client to download firmware image. If the client agrees to do so, it will then upload the firmware image to the server.
The LWM2M server can also initiate a firmware upgrade. The protocol can push the firmware to the client through a Package Resource.
The LwM2M protocol has a few other features, such as a microservice with a global setting. One such feature is a minimum and maximum period. A “pmin” defines the minimum time between two notifications and a “pmax” defines the maximum time.
Another notable feature is the LwM2M’s ability to perform a “write composite” operation. However, the most important feature is the protocol’s ability to support time series data.
The emqx-lwm2m document contains more details. But for the moment, here’s a quick look at the most important features of the LWM2M protocol.
Binding mode
In order to provide users with a set of standard objects, LwM2M 1.1 introduced a number of new features. These include new transport bindings, SenML serialization, optimized message exchanges, and efficient decoding. While these features are not enabled by default, they are available for users who wish to activate them. Moreover, the 1.1 standard provides a compact data format and performance improvements for updating multiple objects.
In addition to the standard structure of the LwM2M Client data model, users can create custom Objects. Custom objects are based on a set of XML definitions specified by the OMA.
Each LwM2M Client object is assigned a unique numerical identifier. This numerical identifier is called the Resource ID. It is a well-defined concept. The Resource ID may not be present in all Object Instances.
Using this concept, LwM2M Servers can access a subset of Resources for a single request. This is a good example of how non-IP devices can operate in lossy networks.
In addition, LwM2M 1.1 supports an external Identifier as a valid Client Endpoint. This can be used in coordination with other bindings, such as SMS. However, this identifier must be unique across all tenants.
In order to manage a large number of Object Resources, a new “Write-Composite” operation has been introduced. The Write-Composite operation targets a list of Object Instances, allowing the server to write to a subset of resources.
Similarly, operators can monitor and manage a large number of Objects using the Bootstrap Read operation. With Bootstrap Read, operators can monitor a device, or they can trigger a Trigger.
Comparison of LwM2M vs MQTT
LwM2M and MQTT are both lightweight protocols that are designed for IoT device management. Both are compliant with TLS 1.2+, which means they offer a high degree of network security, ensuring end-to-end application-layer security. However, when using a full TLS protocol, the trade-offs for speed are dramatic.
The key difference between LwM2M and MQTT is that LwM2M was built to address the device lifecycle. It supports software over-the-air updates (SOTA), rebooting, and activating. This is an essential feature in deploying a variety of IoT solutions. In addition, it offers a host of standard objects to simplify device management.
LwM2M has a simple architecture, but it offers a rich set of features for each platform. For example, it can control cellular connectivity, APNs, and firmware over-the-air. Additionally, it can provide headless device management and enable device activating.
MQTT was first developed in 1999, and it has a long history of use. Many industries, including agriculture and telemetry, have adopted it. But, it is also useful for IoT solutions that don’t need to focus on loose coupling. Compared to LwM2M, MQTT is faster and easier to deploy.
LwM2M is perfect for high-intensity IoT projects, especially those involving resource-constrained devices. Its efficient architecture minimizes bandwidth, making it a good choice for battery-powered or off-grid low-power sources. Also, it is more responsive than MQTT, enabling data reporting and monitoring.
MQTT is suitable for use cases requiring a clear-cut data management model, as well as those with a high payload of data. Although it is a popular choice, it has limitations. As such, LwM2M is better suited for enterprise applications.
Choosing the right technology protocol can help enterprises save costs. Especially when implementing IoT solutions, choosing the right protocol can mean the difference between getting a solution to market quickly and bringing it to the marketplace at a lower cost.
