The Internet of Things promised us a new era. One with ubiquitous connectivity that would lead to an abundance of data, allowing us to make smarter decisions. Today, reality caught up with this promise. Wireless networks are widely available, connectivity is relatively cheap to use, and off-the-shelf hardware is available. However, instead of focusing on gaining meaningful insights from rich data, we’re trapped in never-ending discussions about what wireless technology to use, which communication protocol to utilize, or what security standard to implement.
This often results in companies implementing different devices from different vendors, each using a different wireless technology and a different messaging protocol and data format. Once the data ends up in the cloud, it’s unstructured and hard to make sense of. Device management is challenging as different devices adhere to different standards which need to be addressed differently, and the firmware update process needs to be redesigned for each device. Managing a heterogeneous fleet of devices and integrating the data into one platform is a heavy burden.
Finding Our Way Out Of a Labyrinth of Wireless Technologies
As of 2017, a group of engineers promised an easy way out of this labyrinth of wireless technologies, messaging protocols, and data formats. They proposed a simplified communication and device management standard to be implemented industry-wide. A new application-layer protocol for resource-constrained devices was launched called Lightweight Machine to Machine, or LwM2M. This novel protocol dictates a standardized way of formatting application data and orchestrates device management and firmware update mechanisms which should forever end the need for reinventing the wheel.
LwM2M is the response to the ever-growing need for faster, easier and more power-efficient communication. The standardized message semantics enable embedded developers to focus on functionality rather than reinventing communication protocols. The efficient data format makes this standard well-suited for resource-constrained IoT devices. Ideal for microcontrollers using expensive cellular connections or running low-power applications which require devices to optimize their communication.
LwM2M simplifies the design and development of IoT solutions by standardizing the data format and taking care of the complicated processes of secure device authentication. The standard also defines the process of sensor data collection, connectivity monitoring, and firmware updates.
The architecture of an LwM2M application comprises 3 components: the LwM2M client running on the end device, the LwM2M Server which manages the device, its data, and firmware in the cloud, and the LwM2M Bootstrap Server a cloud service to authenticate and provision the LwM2M Client.
The LwM2M Client communicates with the LwM2M Server and LwM2M Bootstrap Server. It ensures a secure (i.e., authenticated and encrypted) connection with these servers, and sends the data in the right format as dictated by the standard.
Several open-source clients are available and ready to be used with your hardware platform of choice. Including:
- Anjay – maintained by AVSystem
- Zephyr LwM2M Client – maintained by the Zephyr Project
- Leshan – maintained by the Eclipse Foundation
- Wakaama – maintained by the Eclipse Foundation
- IOWA – maintained by Ioterop (limited open-source version available)
The LwM2M Server maintains the connections with the clients. Servers often come with a user interface allowing the end user to monitor the devices, send commands to one or multiple devices and schedule firmware updates.
Specific operations, comparable to RESTful API methods, are defined in the LwM2M protocol. Operations for device management sent by the LwM2M server are DISCOVER, CREATE, READ, WRITE, DELETE and EXECUTE. The operations to manage sensor data collection are OBSERVE and CANCEL OBSERVATION. On the client side, a device sends data using the NOTIFY and SEND operations.
From the LwM2M Server, data integrations to third-party platforms can be initiated. As the data integrations are not defined in the LwM2M protocol, LwM2M Servers implement their data connector differently. Depending on the server implementation, APIs can be used to retrieve sensor data. Some pre-built connectors may be used to send data to popular IoT platforms such as AWS IoT Core or Azure IoT Hub.
Popular LwM2M Servers are:
- Coiote IoT Device Management – from AVSystem
- ALASKA – from Ioterop
- Leshan LwM2M server – from Eclipse (Open Source, evaluation purposes only)
- Cumulocity – from SoftwareAG
The LwM2M Bootstrap Server is a cloud service that the LwM2M Client can connect to and often runs on the same instance as the LwM2M Server. LwM2M Clients usually connect to the Bootstrap Server during their very first boot-up, after an explicit command from the LwM2M Server, or after a factory reset.
The Bootstrap Server provides the clients with credentials that are required to connect to an LwM2M Server. In addition, it initializes the data model and writes new configurations to the device. Once the device is provisioned using commands sent from the Bootstrap server, the Client is ready to start communicating with the LwM2M Server.
The usage of the Bootstrap Server is optional, all necessary information can also be hard coded into the device. This is, however, not recommended as it poses complications with updating configurations over time such as renewing security credentials or migrating to different LwM2M servers.
LwM2M Data Model
Each data message is sent using a data format that identifies standardized objects, object instances, and resources, all defined by the OMA in the LwM2M Registry.
Devices contain different building blocks, each of these blocks is represented by an Object and identified by an Object ID. An object describes a particular part of a device. For example, the Firmware Update Objects are used to invoke and track the status of the firmware update process. Objects can also describe the connectivity technology (e.g. cellular or WiFi), device information (serial number, manufacturer, firmware version), sensors (temperature, air quality), or peripherals (GPS, LEDs, buzzers). All Objects combined can be used to construct a digital twin; a virtual representation of the end device.
Each Object may have different Instances, e.g. multiple temperature sensors embedded in one device.
Object Instances have one or multiple Resources. For example, the “device” object has multiple resources such as the manufacturer, serial number, and firmware version. The “location” object has the resource’s latitude and longitude.
The data sent using the LwM2M standard follows the format:
<object id>/<object instance id>/<resource id> = <data>
As an example, to send the temperature data of 23.5, the data format becomes:
3303/0/5700 = 23.5
Getting Started with LwM2M
This article gave you an understanding of the need for the LwM2M standard. In my opinion, the best way to really learn how LwM2M works is through hands-on experience.