Management of IoT devices through LwM2M

In today’s market, IoT devices come in all different shapes and forms. Each device has a unique communication stack that comes with a particular data packet structure and a carefully designed device management layer. Now imagine the struggles of an energy distributor that has deployed various brands of smart meters over the years to measure electricity usage in thousands of buildings. Each meter comes with a different data structure that needs to be formatted. Specific processes must be implemented to remotely manage the different devices, and particular mechanisms must be implemented to update the firmware of the devices.

When devices use the LwM2M standard, IoT integrators can be sure that each device reports its data similarly. Configurations and firmware can be updated using similar server commands, regardless of the hardware, firmware version, or sensors used. Let’s explore the three fundamental components of LwM2M that ensure interoperability: the standardized data format, the LwM2M architecture, and the LwM2M operations.

“When devices use the LwM2M standard, IoT integrators can be sure that each device reports its data in a similar way.”

-AV system

LwM2M data format

LwM2M is an application layer communication protocol developed by OMA SpecWorks to simplify messaging and management of IoT devices. The protocol defines communication semantics, device management mechanisms, over-the-air updates (FOTA), and telemetry data collection, and is suitable for resource-constrained devices. The LwM2M standard uses so-called IPSO smart objects to represent configurations, functionalities and sensors to achieve data interoperability. By structuring IPSO Smart Objects in a specific way, a language is created that both the LwM2M Client and the LwM2M Server can understand. This language contains objects, object instances, and resources.

#1: Items

Objects represent a physical component (a sensor, LED, or actuator) or a logical entity (such as preferred radio technology, firmware update configuration, or security implementation). All objects are defined by an object ID. The LwM2M standard defines three mandatory objects that are considered essential for the device to connect and communicate with an LwM2M server. The required objects are:

1. Object ID 0: LwM2M Security: Contains confidential information about the connections to the LwM2M Servers configured in the Client.
2. Object ID 1: LwM2M server: Contains non-confidential information about the connections to the LwM2M Servers configured on the Client.
3. Object ID 3: Device: Contains basic information about the device, such as the serial number and firmware version.

Alongside the mandatory objects, additional objects can be implemented. Examples of non-mandatory objects are:

• Object ID 4: Connectivity Monitoring: Provides information about the device’s connectivity status, such as signal strength and network type.
• Object ID 5: Firmware update: Allows you to perform remote firmware upgrades.
• Object ID 6: Location: Provides information about the geographic location of the device, such as its latitude and longitude.
• Object ID 11: APN LwM2M connection profile: Allows a device to connect to an APN.
• Object ID 3303: Temperature: reports temperature measurements.
• Object ID 3313: Accelerometer: Represents a 1-3 axis accelerometer.

#2: Object Instances

Some objects can have multiple object instances. Examples of such objects include the object that manages connections to LwM2M servers, since multiple LwM2M servers or devices containing multiple SIMs with different APN profiles can be configured. When devices contain multiple identical sensors, object instances are used to distinguish the different sensors.

#3: Resources

Resources represent specific properties of an object that can be read, written, or executed. Each resource is identified by a unique resource ID. For example, a temperature object has the current temperature of the resource, a unit of measure, and a timestamp. Similarly, the device object has resources such as manufacturer name, serial number, and firmware version. The location object has the latitude, longitude, and altitude of the resource. All the details of the objects and resources are defined in the OMA Registry. There is also the possibility to define your custom object if a specific feature or sensor is not listed in the OMA Registry.

Each resource contains an identifier, a type (float, string, integer, opaque), and allowed server operations (such as READ, WRITE, or EXECUTE). Let’s take a look at some examples.

examples

The device object is represented by the identifier 3 and the resources include:

The temperature object is represented by the identifier 3303and resources include:

When sending data, each message is formatted as: // =

To send the latest temperature data, it could be something like: 3303/0/5700 = 23.5

To optimize bandwidth, the data is typically encoded into a space-efficient binary payload. Although the data can be sent with plain JSON, the most common is to use CBOR or SenML to reduce the size of the payload.

Sending latitude and longitude using the LwM2M data format

resource instances

In some cases, resources have multiple resource instances. For example, the Device 3 object includes resource 6: Available Power Sources. The different instances describe the different energy sources:

0: DC power
1: internal battery
2: external battery
3: Fuel cell
4: Power over Ethernet
5:USB
6: AC power (mains)
7: solar

To describe the availability of solar power, the message format becomes: 3/0/6/7.

LwM2M Architecture: Client and Server

The LwM2M architecture comprises the LwM2M Client and the LwM2M Server. Communication works regardless of the (wireless) technology used and can run over IP and non-IP networks. Popular IP technologies include WiFi and cellular. Non-IP includes Bluetooth, LoRaWAN, or Wirepas. Non-IP networks can be addressed using IEEE 802.15.4 (6LoWPAN) networks. For example, running a thread over Bluetooth.

The LwM2M standard uses the CoAP protocol to allow devices to easily communicate with the cloud. Think of CoAP like the HTTP protocol, but designed for devices with limited resources. CoAP is often compared to MQTT, as both protocols are commonly used in IoT applications. One key difference is that CoAP uses UDP by default, while MQTT is based on TCP. The small overhead of UDP is often seen as an advantage over TCP. Although CoAP can be used with TCP, UDP is often the preferred option when efficient use of network resources is a priority.

Popular LwM2M clients include Anjay (maintained by AVSystem) and Zephyr LwM2M Client (maintained by Zephyr Project). The LwM2M server provided by AVSystem is called Coiote and can be used to process device data, settings and firmware updates.

The LwM2M client runs on the end device and communicates with the LwM2M server via a secure connection. The client informs the server about supported objects and resources during its first connection, as well as during periodic status updates. Throughout the life of the device, the client sends a notification to the server with telemetry data formatted as defined by the LwM2M standard. The LwM2M server captures and stores all the data, where it can be processed or forwarded to platform-specific databases like Azure IoT Hub or AWS IoT Core.

LwM2M Operations

The third core feature of the LwM2M protocol is operations that can be initiated from both the client and the server. Client operations are used to inform the server about telemetry data or device status. Server operations are used to read or write data, or to remotely update device firmware or configurations over time. Two interfaces can be distinguished: the information reporting interface and the device management interface.

#1: Information reporting interface

The LwM2M Client can inform the server about telemetry data or real-time status changes, initiated by the Client. The Server can also define the behavior of the device by requesting it to send data at periodic intervals, or when the values ​​exceed a certain threshold (for example, when the temperature rises above 30 degrees). This can be accomplished using the operations: WATCH, SEND, and NOTIFY.

• NOTICE: When the Watch operation is invoked, the Client will start sending NOTIFY messages to the Server about its data or status at configurable intervals. The OBSERVE operation can also be canceled by sending CANCEL OBSERVE.
• SEND: The client uses the SEND message to send data to the server without an explicit request. Depending on the application firmware, it can be used to report new measurements or inform the server of a change in data or telemetry status.
• NOTIFY: In response to the OBSERVE operation initiated from the server, the client sends NOTIFY operations with data. Usually, the server provides a bandwidth in which the client needs to send its data. For example, at least every 1 hour, but no more than once every 15 minutes.

#2: Device Management Interface

The device management interface allows the server to remotely connect with the LwM2M client and manage its settings, software, security, etc. The interface comes with a set of standardized operations, all of which are initiated by the server.

• DISCOVER: Retrieval of the list of objects and resources supported by the Client.
• READ: Retrieve the current value of a specific resource or an object as a whole.
• WRITE: Modify the value of a specific resource, or of an object as a whole.
• EXECUTE: Invoke an action or operation on a resource. For example, instructing a device to reset, reboot, or update its firmware.
• CREATE: Creation of a new object instance.
• DELETE: Delete an object instance.

Simplify with LwM2M

The IoT landscape is fragmented, and it’s easy to get lost exploring wireless technologies, messaging protocols, and data formats. LwM2M promises to simplify the connected world through standardization and interoperability. This is achieved by using IPSO Smart Objects with predefined identifiers, allowing the creation of a digital representation of the device. The standardized data format allows any LwM2M server to easily interpret the data. The client-server architecture specifies how data flows between end devices and the web. Finally, predefined operations allow devices to send data and reconfigure over time.