IoT Device Management Using LwM2M

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

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

"When devices use the LwM2M standard, IoT integrators can be assured that each device similarly reports its data."

-AVSystem

LwM2M Data Format

Welvolver

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

Wevolver

#1: Objects

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

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

Next to 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 the signal strength and network type.
• Object ID 5: Firmware Update: Allows for remote firmware updates to be performed.
• Object ID 6: Location: Provides information about the device's geographic location, such as its latitude and longitude.
• Object ID 11: LwM2M APN Connection Profile: Enables 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 may have multiple object instances. Examples of such objects include the object that manages connections to LwM2M Servers as multiple LwM2M Servers can be configured or devices that contain multiple SIMs with different APN profiles. When devices contain multiple identical sensors, object instances are used to distinguish the different sensors.

#3: Resources

Resources represent specific properties of an object which can be read, written, or executed. Each resource is identified by a unique resource ID. For example, a temperature object has the resource current temperature, a unit of measurement, and a timestamp. Similarly, the device object has resources like manufacturer name, serial number, and firmware version. The location object has the resource's latitude, longitude, and altitude. All details of the objects and resources are defined in the OMA Registry. There is also a 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, int, opaque), and allowed server operations (such as READ, WRITE or EXECUTE). Let's take a look at a few examples.

Examples

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

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

When sending data, each message is formatted as: <object id>/<object instance id>/<resource id> = <data>

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

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

Resource Instances

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

0: DC power
1: Internal Battery
2: External Battery
3: Fuel Cell
4: Power over Ethernet
5: USB
6: AC (Mains) power
7: Solar

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

LwM2M Architecture: Client & Server

The LwM2M architecture comprises the LwM2M Client and the LwM2M Server. The communication works independently of the (wireless) technology used and can run on top of both 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, by running a thread over Bluetooth. 

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

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

The LwM2M Client runs on the end device and communicates with the LwM2M server using a secure connection. The client informs the server about the supported objects and resources during its first connection as well as during periodic status updates. Throughout the lifetime of the device, the client sends a notification to the server with telemetry data formatted as defined by the LwM2M standard. All data is captured and stored by the LwM2M Server where it can be further processed or forwarded to specific databases of platforms such as 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 the state of the devices. Server operations are used to read or write data, or to remotely update device configurations or firmware over time. Two interfaces can be distinguished: The Information Reporting Interface, and the Device Management Interface.

#1: Information Reporting Interface

Wevolver

The LwM2M Client can inform the server about telemetry data or state changes in real-time, initiated by the Client. The Server can also define the device’s behavior by requesting the device to send data at periodic intervals, or when values exceed a certain threshold (e.g. when the temperature rises above 30 degrees). This can be accomplished using the operations: OBSERVE, SEND, and NOTIFY.

• OBSERVE: When the Observe operation is invoked, the Client will start sending NOTIFY messages to the Server about its data or state at configurable intervals. The OBSERVE operation can also be canceled when sending CANCEL OBSERVE.
  
  
• SEND: The SEND message is used by the Client to send data to the server without explicit request. Depending on the application firmware it can be used to report new measurements, or inform the server about a change in telemetry data or state.
  
  
• 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. E.g. 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 configuration, software, security, etc. The interface comes with a set of standardized operations, all of which are initiated by the Server.

• DISCOVER: Retrieving the list of objects and resources supported by the Client.
• READ: Retrieving the current value of a specific resource or an object as a whole.
• WRITE: Modifying the value of a specific resource, or an object as a whole.
• EXECUTE: Invoking an action or operation on a resource. For example instructing a device to reset, reboot or upgrade its firmware.
• CREATE: Creating a new object instance.
• DELETE: Deleting an object instance.

Simplify With LwM2M

The IoT landscape is fragmented and it's easy to get lost when digging through wireless technologies, messaging protocols, and data formats. LwM2M promises to simplify the connected world through standardization and interoperability. This is accomplished as a result of the IPSO Smart Objects with predefined identifiers, allowing for 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 the end devices and the web. Lastly, the pre-defined operations enable devices to send data and be reconfigured over time.