Demystifying LwM2M

Understanding the Lightweight M2M (LwM2M) Protocol

The LwM2M protocol, developed by Open Mobile Alliance SpecWorks (OMA), has become a cornerstone for managing and gathering data from Internet of Things (IoT) devices. Research on this bandwidth-efficient but powerful protocol originally was started in 2012 by the Open Mobile Alliance.

First some history:

The Purpose of LwM2M

There are many IoT protocols. Why did OMA feel another protocol was needed?

IoT is a world full of diverse devices that require efficient management. LwM2M’s goal was to provide a network protocol and device schema which could span as many types of IoT devices as possible. Everything from tiny sensors to devices with full-fledged CPUs such as smartphones. By the early 2010s it was becoming clear that the vision of an “Internet of Things” would come to fruition in the next decade. It was also clear, that many (if not the majority) of these “things” would be tiny, relatively inexpensive and have lower power requirements being battery-powered.

Sophisticated protocols are powerful. For instance, look at HTTP/2 or AMPQ. These protocols are sophisticated and provide their clients many features. The flip side of this is they are complicated. Complicated in terms of software, means more code. More code means more power usage, larger RAM requirements and more flash / storage requirements.

A second issue is most IoT protocols, for instance, MQTT, which is older than LwM2M - don’t provide significant features beyond moving data in a certain manner between a device and another device or the Internet. There are many ancillary issues to think about which are necessary when you ship an IoT device:

• Firmware update. Devices will need to be updated in the field. These are referred to as FOTA - firmware over the air updates or sometimes just OTA - over the air updates.
• Onboarding and provisioning. When devices first arrive on a network, there must be some kind of provisioning process. In LwM2M we refer to this as bootstrapping and registration
• Configuring common features and getting common data. For instance, many devices will need an IP address, many will have a reset mechanism, and some will have a primary temperature sensor. Example: if you can ask all devices to report their temperature, despite their differences, it will make management easier. This capability may be referred to as device management or IoT device management and configuration management.
• Security. Underlying all of this there needs to be security. This does not just mean TLS. Encryption does no good if you can not ensure that a device is really the device it claims to be. LwM2M provides certain mechanisms and standards to provide this. Here at Izuma Networks we provide additional capabilities for added security (such as hardware root-of-trust support).

Leveraging its lightweight nature, LwM2M helps to optimize power usage while ensuring secure communication while provide these capabilities. Whether you’re tracking temperature on an industrial freezer or monitoring air quality in smart cities - these small yet important tasks are made possible thanks to LwM2M’s robust capabilities.

Not only does LwM2M allow telemetry within the realm of IoT but also extends into more traditional Machine-to-Machine applications (aka M-anything).

The Role of OMA SpecWorks in Developing LwM2M

From 2012 to 2018 OMA focused on developing the underlying protocol and network roles in LwM2M. This included the client-server protocol, using CoAP as the transport for LwM2M. CoAP (Constrained Application Protocol) rides on UDP. We will cover more on CoAP in a later article. This also included the general, abstract object model of LwM2M, which has a read, write, observer style pattern.

In 2018 the IPSO Alliance merged with Open Mobile Alliance. The ISPO Alliance was formed in 2008 with the primary goal of defining “smart objects.” While the smart object term has lost some vogue recently, the concept is fundamental to the way we interact with IoT devices today. For instance, when you think of say a basic, consumer thermostat, it has some data which is read-only - such as an indoor temperature and the current mode which is running (heat, cool, off). And then it is some things you can set, such as desired temperature. These different values are the fields in a smart object. Some are read, some read / write, and so forth. Smart objects are basically a defined schema for certain devices.

The merger of OMA and the IPSO Alliance was a natural fit, since LwM2M could be the protocol to work with different fields in smart objects. The merged organization formed OMASpecWorks, which is who maintains LwM2M today as well as the LwM2M registry (schema database) where common Smart Objects are defined.

LwM2M vs the LwM2M Registry

The history of LwM2M is informative for a few reasons.

First, as you can see the well-defined specs for different devices are really separate from the protocol. This is a common question we get: Do we have to follow the guidelines of the LwM2M registry to use LwM2M?

No. You do not. (Although, if you can we would recommend it.)

If you like the various other features of LwM2M such as the OTA updates or the bootstrap features, but have your own ideas for data paths, this is fine. LwM2M does not really force you to use specific data paths.

Control Path vs Data Path

Another factor to consider: You don’t have to use LwM2M to move your data at all, if that’s your design angle. If, for instance, the bootstrap, identity / security and OTA features of LwM2M are appealing, but for your own engineering reasons moving data with MQTT or DDS is necessary, this can be done. LwM2m does not specify anything that requires sole use of LwM2M for a specific use case. While LwM2M specifies many aspects of how a device can communicate, there is no inherent requirement, at least with Izuma Networks implementation, that you must use LwM2M for everything. If you plan on deploying devices in a network where another LwM2M service is present and plan on interacting with it - you should of course check that provider’s requirements.

Often times designers separate the control path (bootstrap, identity, OTA, config management) from the data path (specifics of whatever sensor / control / device) for many reasons. This separation also naturally falls into the thinking and design between OT (Operational Technology) needs and IT (Information Technology) needs. We have seen customers go down this path successfully.

In the end, you should think of LwM2M, the LwM2M paths in the registry and our LwM2M client solution - Izuma Connect, as tools you can use to build your own product. Use the tools the way you want to build your product efficiently and while being performant.

Advanatges of LwM2M for IoT Devices

As mentioned above, LwM2M was designed after many other popular IoT protocols, based on capabilities that OMA felt were missing. Many of OMA’s members are the major wireless carriers themselves. These carriers directly understand the impact of IoT devices on their networks, and understand the problem their users can have deploying IoT devices at scale.

Purpose Built

In contrast, many of other popular IoT protocols are in fact protocols designed for different purposes that have been modified and repurposed for IoT over the years. Three popular examples are MQTT, AMPQ and XMPP. For an overview of these and others check out our blog article on popular IoT protocols.

Regardless of which protocol is already your favorite, consider the things you must do in creating an IoT product:

• You must ship with a way to securely and reliably upgrade firmware.
• You must be able to configure some basic low level settings. These settings may be required to even get your own stacks running.
• Devices you ship need secure identity and secure onboarding to the network (bootstrapping).
• You need to uniquely build and ship each product so that the above identity can be trusted.
• You need basic telemetry of a device. When is it on / off? How long has it been off, etc.

The LwM2M standard can help you with these fundamental items. If you are in the conception or design phase, we encourage you to at least look into what is really required to do these things well. And then ask yourself and your team: Is it really worth us reinventing the way these things are done? Or is it better to go with open standards?

And as we have said before, using LwM2M does not lock you into only using LwM2M in your product, or require all data to use an LwM2M transport.

Power and Scale

We briefly touched on the power topic. A bit more detail:

LwM2M was designed as a protocol to be lightweight (it’s even in the name!). So what is exactly so light-weight about it?

• Simple negotiation and transmission. LwM2M over CoAP uses a stateless, datagram-based communication. This makes it very quick and very robust.
• Built on existing, simple standards. LwM2M runs on top of CoAP (new features also allow it to be carried over HTTP and MQTT). CoAP is itself very efficient: it runs over UDP and can even run over very small frame layer-2 networks (for instance IEEE 802.15.4 as with 6LoWPAN). By being small and nimble, LwM2M and CoAP provide the ability to transmit over many network types, and over networks where bandwidth may be limited or connectivity may be inconsistent.
• Power advantages: Being simple and datagram-based helps not just bandwidth needs but also power requirements. Transmission times are short, where a long held stream connection (for instance something using TCP) would require longer times with the radio running (i.e. eating power) and reuires more traffic round trips: TCP requires ACKs between windows of transmission and ACKs on connection setup and tear down. All of that eats power and eats time.
• Network load efficiency: The more ACKs needed, the longer connections are held, the longer the entire network is busy, and the less time other devices have available to talk. Simple fact: protocols that scale to many, many devices and need to move lots of data to / from many devices, often use datagram based, connection-less communications. Think about BitTorrent, RTSP, VPNs, and the most modern version of HTTP (HTTP/3 - QUIC).
• Network nimble: LwM2m over CoAP / UDP (or CoAP on TCP) can easily traverse firewalls and NAT. Devices do not need to reference their own public IP in the protocol nor be NAT aware. The same can be said of the HTTP variation of the protocol.
• Data Consumption: Last, but certainly not least from a budget standpoint. If you are building a product that will have a large footprint, on carrier networks around the world, decreasing bandwidth usage will directly or at least indirectly decrease your cost. LwM2M is very bandwidth efficient, and devices don’t by default consume gobs of data when just idly sitting on the network (in contrast to some protocols).

Standardization and Interoperability with LwM2M

Since 2018, OMASpecWorks has defined 3 major versions of LwM2M. The standards are additive, meaning they do not significantly supplant the previous one, and if implemented well vendor LwM2M stacks should be backward compatible. The three are:

LwM2M 1.0   Published in February 2017.

Core features:

• Smart object resource model
• Set / get / delete. From an actual protocol, these look like POST and DELETE commands to a specific REST path in CoAP.
• Discovery and bootstrap capabilities
• DTLS encryption
• UDP (CoAP) and SMS transports for LwM2M
• Queue Mode for offline clients.
• Core objects in what is now the LwM2M Registry

LwM2M 1.1   Published in June 2018.

Introduced these new features:

• Enhancements to LwM2M bootstrapping which allow incremental updates
• Better PKI features
• Support for CoAP on TCP
• LwM2M support on LTE-M, NB-IoT and LoRaWAN
• New data types including Sensor Measurement Lists (SenML - RFC 8428) with a CBOR encoding

LwM2M 1.2   Published in November 2020.

Introduced these new features:

• New client to server transports for LwM2M: MQTT and HTTP support
• Support for TLS / DTLS 1.3
• LwM2M gateway device support. This means non LwM2M devices can be published to the LwM2M server through a gateway.
• LwM2M CBOR encoding
• Enhanced “Observe” capability for watching specific LwM2M resources
• New notification attributes such as “edge” notifications and features assiting with historical data
• General optimizations around performance in bootstrapping and registration

Silicon Independence

A variety of implementations of LwM2M are specific to certain silicon vendors. These are generally stacks available from specific silicon vendors.

While these stacks may be tempting and will be well marketed, bear in mind that using a silicon-independent stack allows multiple generations of product you design to use the same software stack, without dedicating yourself to a silicon vendor for multiple generations of hardware. With the recent advances in AI-capable microcontroller hardware, with some vendors making big leaps before others, and the significant churn and consolidation in the silicon industry we think this advice remains more true than ever.

Gateways and LwM2M

As discussed in the 1.2 specifications, as of 2020, LwM2M now officially supports gateway devices and non-LwM2M (non-native) devices being published to the LwM2M server via a gateway proxy.

Izuma Networks Cloud has in fact had support for gateway devices for quite some time now, and long before the official standard. Izuma Connect and Izuma both incorporate our open-source Apache 2.0 LwM2M client. Izuma Edge is our gateway class software, and it makes publishing data to LwM2M from a non-LwM2M device incredibly easy. Code running on the gateway merely has to locally (process to process) send JSON-RPC requests to Izuma Edge about about the connected device. In doing so the client will update the server, as well as associate the new device as an attached device to the gateway in your LwM2M Device Directory.

This means that LwM2M can support many additional devices very easily, such as: Bluetooth sensors and presence tags, 802.15.4 devices, LorA devices, and even older wire protocols such Modbus and BACnet. Our team has significant experience with many of these protocols and can help get you up and running quickly to support them.

For more advanced needs, especially as gateways become more powerful and applications more sophisticated, Izuma Edge includes an application orchestration engine, powered by Kubernetes. Using Izuma Edge and Izuma Cloud you can deploy AI and other workloads at the edge to directly interact with your LwM2M devices.

About Izuma Networks and OMA LwM2M

Izuma Networks has a rich history in LwM2M and CoAP.

Izuma Networks was formed in 2022, when Softbank decided to spin off Arm’s IoT software business as Pelion. Izuma Networks was formed by previous Arm employees, who saw the need to further develop the IoT software business. Arm’s (and consequently Pelion’s) IoT software business was immediately acquired by Izuma Networks under a mutual agreement. We are happy to support both existing customers of Arm and Pelion, as well as our new customers at Izuma Networks.

You will find Arm has had a rich history in the development of many of the underlying technologies in LwM2M, including CoAP, Smart Objects, and many core features in the most modern versions of LwM2M, including as authors of various RFCs.