Hybrid & multi-cloud infrastructure
Lightweight M2M (LWM2M)
Definition of Lightweight M2M (LWM2M)
OMA LightweightM2M (LwM2M) is a protocol standard that allows IoT devices to securely connect to one or more LwM2M servers. IoT devices and servers exchange application data such as temperature, perform software & firmware updates, monitor connectivity, etc. LwM2M is an application layer protocol and defines payload format and a related metadata file format.
In the LwM2M specification, an IoT device exposes a number of objects. These objects can be accessed by the server using create, read, update, delete, execute and discover operations. Additionally the IoT device can send “notifications” to the server, assuming the server registered itself with an “observe” operation.
The LwM2M payload can be formatted as TLV, JSON, opaque or Plain Text format. LwM2M Version 1.1 added additional formats CoRE Link, CBOR, SenML JSON, and SenML CBOR. A LwM2M server must support all formats. A LwM2M client must support a standard-defined subset.
An object, its internal resource structure and associated metadata (identifiers, names, cardinality, access) are defined in an XML file. This XML file follows an LwM2M defined XML schema.
The LwM2M specification comes with predefined objects which cover mainly device management. Objects from other standard organizations like IPSO or from companies are available at the OMA LwM2M Registry. Refer to the following diagram for an illustration of the retrieval of the Device Object resource values. The used identifiers are defined in the LwM2M Device Object.
LwM2M runs on top of the CoAP protocol, a lightweight HTTP alternative. CoAP itself typically runs on DTLS/UDP. Additional protocols have been introduced in LwM2M 1.1. Transport Bindings, including TLS/TCP and usage over mobile network protocols like narrow band IoT (see also Technology Radar on NIDD&SCEF).
Optionally, OSCORE can be used to encrypt the CoAP message payload, see [8] for details.
TECHNOLOGY EVALUATION
Benefits
LwM2M provides full plug-and-play capabilities and thus helps the dream of IoT come true: connect a LwM2M device to your IoT Platform and retrieve business data from it or manage the device’s software, hardware and configuration. LwM2M makes this possible because it is a full-stack standard, defining a standard payload format, standard metadata, and a central registry for metadata files. Additionally, an IoT platform can use runtime discovery to learn about the supported objects when a new device is connected. LwM2M does include domain models for device management, for example, and thus no additional software development in that area is needed when using supporting IoT platforms. For specific use cases (e.g. smart cities), more standard objects are needed to reach the same plug-and-play user experience.
The LwM2M specification has been optimized for mobile networks, which means it works also if only low bandwidth is available. This applies for e.g. narrow-band IoT and LoRaWAN. This is enabled by compact message payloads and avoidance of metadata transmission.
LwM2M comes with rich out-of-the-box functionality, including protocol functionality like CRUD operations. In protocols like MQTT, this needs to be designed in a bespoke approach.
Drawbacks
While there are various open-source client and server libraries available, there is no official open-source reference implementation. This makes it more difficult for the open-source developer community to grow and bears the risk of incompatible implementations.
Securing LWM2M communication remains a challenge. Currently, there are two alternative approaches without a clear winner: The first approach is using DTLS to secure communication on the transport layer. The second approach is the usage of OSCORE that provides an application layer encryption.
In addition, LwM2M as a UDP based system is more difficult to scale to a large implementation with millions of devices, given that most cloud systems rely on TCP for horizontal scaling. However, this is changing and in the last years many environments (including hyperscaler load balancers and Kubernetes) have added UDP support.The LwM2M feature-rich protocol causes a complex implementation for simple sensor use cases: If a sensor just wants to send measurements to a server, LwM2M v1.0 causes more complexity than using the MQTT protocol. This applies to both the protocol complexity and the device implementation complexity. This is less of a concern for linux based devices due to the availability of LwM2M client libraries. However, for embedded systems with smaller software ecosystems this leads to a high implementation effort.
MARKET - CURRENT ADOPTION
Markets using LwM2M
The LwM2M specification is used especially in the telecommunication market, which is not surprising as the standard was driven by many telecommunication players participating in the OMA. Additionally LwM2M also gains traction in the modem space, with vendors like u*blox Telit and Sierra Wirelss to include LwM2M clients in their modems. Note that traction in the telecommunication space is weakened by existing, well-established device management standards like TR-069.
Compared to MQTT, usage of LwM2M is less by at least one dimension:
- Google Trends: 80 vs. 1 (Search)
- Stackoverflow: 6000 vs. 30 (MQTT vs. LwM2M)
- GitHub projects: 46.000 vs. 360 ( MQTT vs. LwM2M)
LwM2M Software
Server applications with end-user LwM2M support include:
- Software AG Cumulocity IoT provides a full LwM2M implementation with a user interface for notification configuration and object mapping.
- AV Systems Coiote Device Management
- IoTerop ALASKA Device Management
- ARM Pelion Device Management
Server developer libraries available include:
Client developer libraries available include:
- Mbed Cloud Client
- Eclipse Wakaama
- AVSystem Anjay
- Zephyr LwM2M
See also OMA LwM2M Github pages for additional tooling.
MARKET – OUTLOOK
Most IoT platforms do not support LwM2M as a first-class protocol (one exception being Software AG's Cumulocity IoT). Instead nearly all IoT platforms support MQTT. This makes it unrealistic that LwM2M would become the dominant IoT protocol in the future.
As LwM2M provides many unique features, it will be an important challenger in the area of IoT protocols.
Adoption of the LwM2M specification might increase with the MQTT binding that was specified with LwM2M 1.2.
Further Information and Links
References
[2] OMA LwM2M Release 1.1 Slides
[3] Machine Research compares MQTT and LWM2M for bandwidth efficiency.
[4] Networkworld on LwM2M vs. MQTT
[5] Teserakt AG Blog does a security review of LwM2M.
[6] embedded software engineering States that UDP is not great for IoT cloud usage.
[7] OSCore Introduction by Ericsson.
Notes
LwM2M uses the terms “server” and “client”, but in contrast to classical client-server architectures and other native internet-of-things standards like MQTT (where the client initiates all communications with the server), the LwM2M server (= IoT platform) actually polls the LwM2M client (= device) for data and the client “answers” the server’s requests.
Updates
August 2021 - updated metrics, added AVSystems Anjay, removed historic discussions on queue mode.