Working on Standards: A brief look at OMA SpecWorks

This is a guest blog post by Hannes Tschofenig, Senior Principal Engineer at Arm.

OMA SpecWorks: a new beginning

Several organizations are working on technical specifications to improve interoperability and security within Internet of Things (IoT), and Arm contributes to several of them. The end of March merger of the Open Mobile Alliance (OMA) with the IP Smart Object (IPSO) Alliance resulted in the establishment of a new organization - OMA SpecWorks. As a former board member of the IPSO Alliance, I have supported this development, particularly as it will lead to better integration of the smart object development into the IoT device management solution developed by the OMA.

What does this formation of OMA SpecWorks mean practically? One result is that it has simplified the processes in the organization: it is now easier than ever to get technical work done without being distracted by administrative overhead. The “Device Management and Service Enablement” working group, which I co-chair with Padmakumar (Padhu) Subramani from Nokia, has been using Github’s repository and its corresponding tools to manage the LwM2M specification maintenance, and the Markdown language for writing specifications. The IPSO assets have been transferred, and the IPSO smart objects, which have been utilized by a diverse set of companies (including many non-IPSO members), are incorporated into the object registry (see

While LwM2M has been developed as a solution for device management, the IPSO smart objects enhance the use of LwM2M for application data transfer. I expect to see more application-specific object registrations to the public object registry. IPSO also worked on whitepapers, and this work will be continued in OMA SpecWorks as part of a newly created working group. Finally, OMA SpecWorks now has a larger membership than each of the individual organizations before it.

Gathering of several key LwM2M contributors on the roof top of the Hilton Bangkok Hotel

Gathering of several key LwM2M contributors on the roof top of the Hilton Bangkok Hotel

More information about OMA SpecWorks can be found in this FAQ.

Running Code is great – testing is even better

The OMA has always been committed to systematically testing the interoperability of implementations prepared by different vendors. OMA SpecWorks is no different, and so it should come as no surprise that the next testfest is already scheduled: it will take place in Seoul, South Korea from July 9th through July 12th and is hosted by the Telecommunications Technology Association (TTA). More information about the event can be found at Registration is open at and the deadline for registration is June 7th. The test specification will be released on June 8th. A large number of companies will be attending this event, including Arm.

Meeting in Bangkok

Taxis in Bangkok are lightweight and fast; so is the LwM2M protocol

Taxis in Bangkok are lightweight and fast; so is the LwM2M protocol

The OMA SpecWorks members met for the first time in Bangkok from April 23rd to 27th to celebrate the launch of the new organization. This was my first trip to Thailand, and as an Austrian, who enjoys long distance running in the Alps, I was not prepared for the humidity. The weather in Bangkok took some getting used to, as even a short walk outside the meeting venue to the nearby market to taste the local cuisine could be exhausting for us in the heat. It was an adventure. Yet, I definitely think the long-distance travel was worth it. It gave me the opportunity to meet and interact with my OMA SpecWorks colleagues, and the location allowed for easier participation of smaller companies in that region. It was a busy week finalizing the latest version of LwM2M (i.e. version 1.1), and we took every opportunity for face-to-face meetings, including during breakfast, lunch and dinner. While the agenda was heavily packed, it was rewarding, and I enjoyed seeing a new place and experiencing a different culture.

Last year, I posted a blog article listing the timeline and the anticipated features of LwM2M v1.1 (see The feedback received from the testfests, the public Github issue tracker (see, and the requirements gathering process (documented at resulted in the decision to split the specification into two parts: core and transport. The core specification contains the LwM2M messaging functionality and the data model description (including a number of essential objects). The transport specification describes how LwM2M messaging is translated into CoAP and conveyed over a variety of protocols. In my opinion, the specification has reached a higher maturity level, in terms of readability, as many suggestions and clarifications have been incorporated by the group.

LwM2M v1.1 also contains a number of new features. I will focus on two items:

1) The ability to carry LwM2M messaging over TCP and TLS.

This feature has been requested by customers, due to challenges with the use of UDP-based transports in enterprise networks that are firewalled and contain Network Address Translators (NATs). Deployments that utilize this feature will encounter fewer problems with NATs and firewalls. Other deployments, where these middleboxes are not present or have been configured accordingly, may still decide to use the UDP-based transport instead, which leads to less overhead.


“The primary reason for introducing CoAP over TCP [RFC793] and TLS [RFC5246] is that some networks do not forward UDP packets. Complete blocking of UDP happens in between about 2% and 4% of terrestrial access networks, according to [EK2016]. UDP impairment is especially concentrated in enterprise networks and networks in geographic regions with otherwise challenged connectivity.” RFC 8323

The recent publication of RFC 8323 “CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets” ( by the Internet Engineering Task Force (IETF) laid the foundation for making this functionality usable for the upcoming version of LwM2M. Arm worked with Zebra Technologies and other IETF participants throughout the standardization process to complete this specification just in time for the v1.1 specification release.

2) TLS / DTLS Clarifications and Guidance

DTLS and TLS communication security is a main component of the LwM2M specification. LwM2M v1.1 will come with a number of new recommendations regarding the use of these widely employed security protocols. An important part of v1.1 is the alignment with RFC 7925 “TLS / DTLS Profiles for the Internet of Things”. RFC 7925 was published mid-2016, and its recommendations were explained in the Arm-organized webinar series on “Securing IoT applications with Mbed TLS” (see

Using TLS and DTLS for securing IoT communication has become popular and is now deployed by all major companies offering IoT device-to-cloud connectivity. By providing these recommendations and the open source code, we have made it easier to improve the security of IoT devices.

Mbed TLS can, of course, also be found in the recently-released code of our Mbed Cloud Client (see

What is next?

The Lw2M v1.1 specification will be published in the next few weeks, and companies will gather for the testfest in July. Since the July testfest event will focus on features of the v1.0.2 specification, new test cases focusing on v1.1 features will have to be written. We expect to receive feedback from the wider IoT community on the new specification. These review comments and the feedback from deployments will be taken into account for a future version. At Arm, we are particularly interested in the use of MQTT as a new transport for LwM2M.

If you share our interest in improving IoT security and the efficient deployment of IoT device management, then join us at OMA SpecWorks.


Hannes Tschofenig is a Senior Principal Engineer at Arm and our go-to LwM2M guru.

You need to log in to post a discussion