Open Standards to Open up the IoT

As the IoT expands, the need to remotely manage devices on a variety of networks— to provide reliable smart homes, offices, smart metering and medical devices—requires a common set of standards that can unite the industry.

Developing standards is a complex process. The Institute of Electrical and Electronics Engineers (IEEE), Internet Engineering Task Force (IETF) and World Wide Web Consortium (W3C), have joined forces with the Internet Architecture Board (IAB) and the Internet Society as Open Stand and have jointly compiled a set of principles for the development of open standards.

The core principles are respectful co-operation between standards organizations, adherence to the fundamental parameters of standards development and collective empowerment to strive to develop standards that are chosen and defined, based on technical merit, availability of standards specifications, and voluntary adoption by the standards market (Figure 1).

The Open Mobile Alliance (OMA), which drives the development of service enabler specifications and supports the creation of interoperable end-to-end mobile services, architectures and open enabler interfaces, follows these principles in its standardization process.


Figure 1: An explanation of the five core principles for open standards development.

The LWM2M Specification

Lightweight Machine to Machine (LWM2M) is a technical specification that allows IoT operators to manage their IoT devices remotely, to retrieve sensor data, to push messages to actuators on IoT devices, to provision security credentials, and to update firmware.

The specification was developed by the OMA, with companies such as ARM, Alcatel Lucent (now Nokia), Gemalto, Microsoft, Sierra Wireless and Vodafone actively contributing.

To implement a product based on the LWM2M specification, developers can download snapshots of the specifications from the OMA website. There is no requirement to be a member of the OMA.

Work on OMA LWM2M version 1.0 is fairly mature. The Candidate Enabler release is currently available for download and takes into account implementer feedback. These interoperability test events ensure that the specification is interpreted unambiguously. Work on version 1.1 started early this year, for further feature enhancements.

Software Updates

The LWM2M specification supports the distribution of firmware updates. Updating the software and firmware of IoT devices is an important functionality, as devices have a long lifetime and are often installed in inaccessible or remote locations, which can make installing software updates by field engineers prohibitively expensive. Not installing software updates is not an option, as without them there are huge security and interoperability risks.

The LWM2M specification re-uses other standards, particularly from the IEFT, such as IPv4 and IPv6, User Datagram Protocol (UDP), Datagram Transport Layer Security (DTLS), Constrained Application Protocol (CoAP), Resource Directory and Link Format, amongst others. Re-use of well-established Internet specifications allows companies to utilize the expertise, available code and tools. It also shortens the standardization process by the OMA when developing the LWM2M specification.

IoT Security

Performance investigations presented at the NIST workshop on lightweight cryptography ( indicate that ARM® Cortex®-M series MCUs are able to perform advanced cryptographic operations in software without any hardware acceleration. Hardware support for cryptographic algorithms, such as encryption and hash functions, may result in lower energy consumption, which is a critical part of IoT efficiency.


Figure 2: The low power, efficient ARM Cortex-M MCUs can support software implementation of critical security functions.

For the design of the LWM2M standard, engineers took the earlier OMA Device Management (DM) specification into account and put the protocol “on a diet.” The result is a protocol that requires less bandwidth, RAM and flash memory, and offers better performance.

In particular, the use of CoAP and an efficient encoding of payloads substantially reduces the communication overhead. This is helpful whenever low power radio technologies, such as IEEE 802.15.4 or cellular radio technologies, are used.

Despite these optimizations at the application layer, ironclad communication security protection with DTLS has been maintained.

The OMA specification defines a number of objects to be provisioned to, and retrieved from, devices. These can be found in the LWM2M specification, or in the online repository.

Objects are not only specified by OMA members. The IPSO Alliance, a non-profit organization promoting the use of IP for the networking of smart objects, for example, also used the OMA LWM2M specified object models.

LWM2M Version 1.1

CoAP is a highly efficient protocol design specifically for use in IoT deployments. When CoAP was designed, HTTP/2, the revised network protocol for Hypertext Transfer Protocol (HTTP) did not exist. The web community developed HTTP/2 to lower bandwidth consumption. In some circumstances the use of HTTP/2 may be preferred over CoAP. Version 1.0 of the LWM2M specification supports CoAP as well as CoAP over DTLS, SMS and DTLS over SMS. The LWM2M version 1.1 will add support for HTTP/2 (and for the messaging protocol, MQ Telemetry Transport Protocol, or MQTT).

Other functionality to be added in version 1.1 is firewall traversal using CoAP over TCP (based on; CoAP Resource Directory (based on ), CoAP publish/subscribe functionality (based on, security enhancements (based on, support for low power wide area networking standards, such as Narrowband IoT (NB-IoT), and enhanced gateway functionality. Additionally, there are plans to simplify the specification by removing less-used features.

Device Management

Another initiative for M2M communications and the IoT, is OneM2M. This group develops agreed, access-independent, end-to-end specification for M2M communications and management systems that can be embedded within hardware and software. Technical specifications address the need for a common M2M service layer to connect devices with M2M application servers worldwide.

OneM2M aims to serve as an umbrella standard for a number of device management solutions and extend those to standardize data sharing in the back-end.

Sharing Data with REST APIs

There has not been a great amount of success in standardizing Representational State Transfer Application Program Interfaces (REST APIs) for sharing data, as many companies prefer to react quickly to market needs, develop their own REST APIs and make them freely available.

ARM’s mbed Device Connector provides a REST API to access the data of IoT devices ( This API is used by partners, such as IBM with its Bluemix open standards cloud platform, to offer machine learning, or persistent data storage.

What has been standardized are security technologies that deal with secure and privacy friendly data sharing. OAuth 2.0 is an example (

The main use case for LWM2M today is offering device management, for example, OEMs offering a software update service for devices to ensure that security fixes are applied as quickly as possible. Another use-case is for a company to collect data reported from deployed IoT devices for fault diagnosis or machine learning purposes.

Other bodies, the Open Connectivity Foundation and the Open Interconnect Consortium, started their work with a focus on the home automation use-case, where devices are talking to each other independently of a cloud service provider. This is similar to devices using Bluetooth Low Energy or Universal Plug and Play (UPnP) protocols that are “paired” to just talk to each other directly.

The LWM2M specification does not require the server-side functionality to be located in the cloud. It may be located in any device, such as a server in an enterprise network, or in a home gateway. Which deployment works best needs to be decided on a case-by-case basis.

An implementation of the LWM2M version 1.0 specification may be hosted on a gateway to serve nodes in the local network. However, functionality for the gateway to act on behalf of devices behind the gateway will only be standardized as part of the LWM2M version 1.1 specification.

One of the advantages of OMA LWM2M standardization is that it started years ago, when other standardization organizations had not recognized the need for device management, or were focused on more powerful devices.

With the increase in deployment of Cortex-M based microcontroller and low power radio technologies, it became clear that the existing device management protocols, such as OMA DM or TR69, are not suited for such environments. This started the development of a lightweight device management that re-used emerging standards developed in the IETF, such as CoAP.

Today, LWM2M has matured, with feedback from implementers helping to improve the quality of the specification. Maintaining its goal of being lightweight fits the Cortex-M microcontroller market.

This article was sponsored by ARM.


For a more detailed description of the enabler concept and the published OMA enablers, visit:

A description of the different features of DTLS for the use in Internet of Things environment can be found at:

To contribute to the OMA LWM2M specification you need to become an OMA member. Please consult the OMA membership pages at:


Figure 2 is from

Share and Enjoy:
  • Digg
  • Sphinn
  • Facebook
  • Mixx
  • Google
  • TwitThis