Last week, we hosted the "Device Management with the OMA LWM2M protocol" webinar, led by Hannes Tschofenig, in ARM's Meet the Experts webinar series. If you missed the event, get the webinar recording to find out how LWM2M can solve a variety of IoT deployment issues by enabling secure device management.

Thanks to all of our fantastic attendees for their interest! We hope that you enjoyed the in-depth dive into LwM2M, where Hannes introduces the LWM2M version 1.0, explains how to ensure IoT device security, and how this standard maps to the ARM implementation to facilitate the creation an interoperable solution for IoT device management.

You can view the webinar recording by registering your details. You can also access the presentation slides.

Pete Aldworth has also published a summary of how ARM mbed is utilizing LwM2M to help break down the inevitable silos created when organizations scale out their IoT deployments which you may be interested in reading.

Q & A Followup

As promised during the webinar, Hannes wanted to follow up with comprehensive responses to the attendee questions he received. Due to the large number of questions, he wasn’t able to answer all of them during the webinar itself.

Can I use LwM2M in parallel to an implementation of an MNO?

LwM2M is a technical specification and does not impose a particular business model. An implementation on an IoT device (in form of the LwM2M client) can connect to a LwM2M server operated by a MNO, by a cloud provider, by an enterprise network, or by anyone else. What the best possible deployment model is depends on the requirements by those developing the IoT device. A company selling a wearable to end users may, for example, have different deployment needs than a company selling sensors for use in a factory. LwM2M will, however, offer a device management solution for both example deployments.

Are there already commercial server implementations available?

Yes, there are a number of commercial server implementations available. ARM, for example, offers one such commercial server with mbed Cloud (see https://cloud.mbed.com).

Will mbed OS be suitable for an LwM2M deployment?

mbed OS is an operating system for IoT devices running ARM Cortex M-class devices, see https://www.mbed.com/en/development/mbed-os/. It is open source, see https://github.com/ARMmbed/mbed-os, and ARM has developed an implementation of the LwM2M client. It is also available as open source, see https://www.mbed.com/en/platform/mbed-client/.

Hence, an implementation of the LwM2M specification can be run on mbed OS. There are, of course, other implementations of the LwM2M protocol that run on other IoT and non-IoT operating systems as well.

For ARM's own mbed server, what does the "northbound" API look like? (i.e. the interface out to other services in the cloud, including the application). Does it look like a vanilla LWM2M server, or something different? Are there any efforts to standardise this northbound API?

The “northbound” API ARM uses for communicating between a LwM2M server and application servers is described at https://docs.mbed.com/docs/mbed-device-connector-web-interfaces/en/latest/. It uses an HTTPS-based RESTful API. The OMA device management group does not plan to standardize the northbound API. In general, the standardization of such Web APIs has not been very successful in the past, i.e., standardization has been too slow and the market has been innovating too fast. We were told that there are standardization efforts in the oneM2M organization around these northbound APIs but we are neither active in oneM2M nor have we seen demand for those APIs.

What is the difference between MQTT and the LwM2M protocol? What are the advantages of LWM2M over MQTT?

MQTT and LwM2M cannot easily be compared as they provide different features. LwM2M sits at a different level of the protocol stack than MQTT and a more reasonable comparison would be between MQTT and CoAP (+extensions).

LwM2M offers a full device management solution, which includes an object model, access control concepts, security credential provisioning, etc. All these features are missing in MQTT.

With the LwM2M version 1.0 specification, CoAP (and SMS) is used as a transport but in context of future standardization work on the LwM2M specification, other transports have been under discussion. This includes HTTP/2 and MQTT as well. Additional transports will be added to LwM2M in a future version as decided as part of the standardization process in the Open Mobile Alliance (OMA) and every company is invited to participate in such a debate. More information about the OMA standardization process and membership rules can be found at http://openmobilealliance.org/membership/

Did any cloud provider apply your LwM2M model?

The communication model offered by LwM2M, where IoT devices connect to servers in the Cloud or on premise, is the result of the standardization effort within the OMA with the help of many other companies participating in this process. As such, it is not an ARM model but rather an industry developed model. All the companies participating in the standardization process in the OMA device management working group on LwM2M are endorsing this model. There are additional companies, who have not participated in the standardization process, who are offering products based on LwM2M. They also follow the same model.

Furthermore, the approach of connecting IoT devices to server-side infrastructure for device management is a generic IoT communication pattern, as described in this https://www.internetsociety.org/doc/iot-overview publication by the Internet Society.

There are, however, differences in the product offerings for the LwM2M server infrastructure. Some companies focus purely on device management while others offer additional functionality, such as machine learning and analytics services.

Based on your experiences so far, have you seen any issues related to firewall traversal or reliability when using a UDP based transport as opposed to using a TCP based transport?

IoT deployments come in many different types and in some situations there are problems with firewalls. We encountered problems in enterprise deployments where network administrators are unwilling to change the settings of firewalls to allow UDP-based CoAP traffic to traverse the firewall. In other environments this is not a problem, particularly not in greenfield deployments. To mitigate these problems, ARM has joined forces with other companies to develop a specification that allows CoAP messages to be carried over TCP and TLS. This technical specification is currently being finalized in the IETF and can be found at https://tools.ietf.org/html/draft-ietf-core-coap-tcp-tls. We have also implemented CoAP over TCP and TLS and it is currently being used by a number of customers even though it is not officially part of the LwM2M version 1.0 specification. It is very likely that support for CoAP over TCP and TLS will be made available in the upcoming version of LwM2M.

Note, however, that using CoAP over UDP is more efficient and leads to a smaller code size on IoT devices. It is therefore the preferred communication mechanism.

On an IoT device what are the minimum ROM and RAM requirements for LwM2M? Is 64KB RAM enough?

The LwM2M specification offers a number of different options to make the protocol usable in different deployment environments and different IoT verticals. For example, the specification allows different types of credentials to be utilized ranging from pre-shared secrets to certificates. Depending on the selected features the implementation will be larger or smaller.

Some companies are also spending more time in optimizing their implementations for code size, RAM usage, and performance. My co-workers have written several articles about this topic on our public mbed blog, see for example https://developer.mbed.org/blog/entry/Optimizing-memory-usage-in-mbed-OS-52/.

In a nutshell, the answer to the question is unfortunately not a single yes or no answer since it will depend heavily on the requirements. In general it can, however, be said that LwM2M is among the most lightweight protocols in the industry. This is not only true for the communication overhead but also for code size and RAM requirements. The security functionality is the most demanding component from the entire stack.

How do you plan to handle access control lists (ACL) in case the device is bootstrapped?

Access control lists is a feature of the LwM2M specification that is used when IoT devices communicate with multiple LwM2M servers. It allows an OEM to specify which LwM2M server has access to which resources on the IoT device. If an IoT device only talks to a single LwM2M server then no access control lists are necessary. Our implementation of the LwM2M currently supports only a single LwM2M server and hence access control lists are not implemented. This allows us to keep the implementation of the LwM2M client for use with IoT devices simple.

Is it possible to load some kind of configuration in the device, like a measurement profile?

The LwM2M specification defines interfaces and an object model that allows information reporting, fault management, and remote management of IoT devices. A number of objects for use with IoT devices have been defined already and their definition can be downloaded from http://www.openmobilealliance.org/wp/OMNA/LwM2M/LwM2MRegistry.html. If the existing object definitions are insufficient to cover the envisioned use case then the further objects can be defined or existing objects extended.

Is LwM2M open source and can be used licence free?

LwM2M is a technical specification and can be downloaded for free from the OMA webpages (see http://openmobilealliance.org/release/LightweightM2M/V1_0-20170208-A/). There are various implementations of the LwM2M specification available and some of them are available as open source. Please check the license policy of each of the relevant open source projects. Our LwM2M client implementation, for example, is available with an Apache 2.0 license.

From device management point of view, have you done a comparison between LwM2M and TR069 / SNMP?

TR069 is a protocol initially developed by the DSL Forum (which is now called Broadband Forum) for use with network gateways and home routers. It is a fairly heavyweight protocol that uses HTTPS and SOAP for exchanging messages. Since home routers are typically well-connected the additional bandwidth overhead by XML encoding and HTTP communication has not been seen as a huge obstacle. Re-using TR069 for use with IoT devices that are battery powered and connected using low power radio technology is, however, a challenge. For this reason the Broadband Forum has started an effort to re-design their protocol suite for use with IoT environments. While TR069 has been quite successful in the home router market, the success of their not-yet-published IoT device management solution in markets that are outside the typical telco sector remains to be seen.

SNMP has been used as a management solution for networking equipment, typically routers and offers a subset of the functionality of device management solutions offered by TR069 or LwM2M. Since it has not been designed for use with IoT environments there have recently been effort to change the underlying protocols and encodings to make the protocol more suitable for the IoT sector. These efforts are ongoing in the IETF CORE working group under the name of CoAP Management Interface (COMI). Since the work is still in an early stage, it is premature to judge whether the attempt to re-purpose SNMP to the IoT environment will be successful.

As a general observation, we have seen very few standardized solutions for device management that are tailored to the needs of IoT deployments offering a complete set of features.

Various companies use PSK-based credentials with DTLS to secure the communication with LwM2M servers. Are other companies using other credential types as well?

There are other credential types in use in implementations as well. For example, ARM mbed Cloud uses certificate-based credentials and mbed Client can use certificates as well as pre-shared secrets. Leshan, as another example, uses pre-shared secrets and raw public keys.