If you went these days to ‘google’ for LWM2M, you would find something that is called a new technical protocol specification.  It is abbreviated LWM2M which stands for Lightweight M2M – Machine to Machine the lighter way. What’s that all about? Why does it show up here and there already on Google?

What is LWM2M – LWM2M is a new, still on-going effort to create a new technical standard for remote management of machine-to-machine devices and a bit of service enablement and application management.  In essence, LWM2M is a new communications protocol running between LWM2M software clients embedded on all sorts of M2M devices and their M2M management platforms [1].

Why is that of potentially good use? Well, various sources forecast a significant growth of connected M2M devices in the next 7 years or so, up to hundreds of millions reaching into the few billions. Such devices will range from connected consumer gadgets (e.g. a wireless scale, or wireless fridge) to commercial and industrial “things” that make up the growing “Internet of Things”: smart meters, smart street lights, intelligent sensors of all kinds as used for the Smart Grid and for environment management in Smart Cities, location tracking devices for containers and smaller goods. The list is indeed very long. Many of those Internet of Things appliances require some caretaking: They need to be remotely switched on and off, woken up and put to sleep (or made to shut up), reminded to transmit sensor data to the Cloud to feed control processes and the Big Data analytics engines; they want to be monitored, maintained, upgraded with new software; they need to be configured and services need to be provisioned on them. In short: These devices call for device management, service enablement and application management.

Why to create a new remote management protocol?  Good question. Device management is not a new subject per se. Other non-M2M devices have been around for a while and they also require remote configuration and management: e.g. ADSL broadband routers, set-top boxes, VoIP phones or our beloved smartphones. Technical standards have been created to manage those kinds of devices, like TR-069 from the Broadband Forum for remote management of end user devices (customer premises equipment) [2] or OMA DM 1.2.1, 1.3 (and 2.0) from Open Mobile Alliance for smartphones [3]. Now, the design goal of LWM2M was to create a mechanism that is not only suitable for rather powerful computing devices (like an Android-based smartphone or a home router), but also caters for the need of more constrained M2M devices: those that run a lifetime on a single battery, those that need to be very low cost (e.g. CPU, memory space RAM and ROM), or “Things of the Internet”, that are in themselves not complex devices (e.g. one would expect a controller for a street light to be less complex and also less costly than a smartphone, with fewer aspects to be remotely managed).
Given that the industry expects the number of connected M2M devices to grow into billions over the next 10 years, it’s a laudable approach to keep the number of bits transferred between those devices and their management platforms as small as possible and to design the mechanism to work robustly over any sort of shaky (unreliable) connection. A deliberate reduction in protocol complexity compared to other approaches has inspired the term LWM2M.

What’s new about this protocol? The LWM2M protocol is a client server protocol running between M2M LWM2M software clients (on those many millions of connected devices) and their management platforms operated by M2M service providers. To go with times and make the protocol appealing and easily understandable, the idea was to apply shades of a RESTful architectural style to it. This means that items to be managed on a remote device are considered resources. Those resources are addressed by uniform resource identifiers URIs (like the URLs or Web addresses we all know). For convenience, related resources are grouped together into objects. The client-server interaction is modelled along the lines of how the Internet works, of course with a few major differences as well. Instead of using HTTP as the data transfer protocol (that ships most of our Internet web pages to browsers), a ‘variation of HTTP’ is used, a protocol called CoAP (standing for Constrained Application Protocol) [4]. CoAP works similarly to HTTP, however it has been optimised for communication with performance-constrained devices over constrained networks. Ergo, fewer bits are transmitted over the wide area network interface. For a tutorial see [5].

As one would imagine, LWM2M works with a kind of data model that is largely made up by the definition of resources and collection of such resources (into Objects). This helps to cut down on processing overhead as M2M client and server on the platform side have a common understanding of what a certain resource actually means (e.g. the manufacturer’s name of the device, the current type of network the device is connected to, the signal strengths of the cellular connection it uses etc.). Though the new specification comes with a set of predefined objects and resources, the set of objects is extensible, i.e. other organisations can define new ones that are most suitable for particular corners of the M2M universe.

Who has been defining LWM2M? The new specification is being developed by a team of experts from various companies (e.g. system and software vendors, service providers) in the Open Mobile Alliance.

When is it ready? A look into the public documents folder of the expert team in OMA [1] reveals that the specification is still work in progress, however, I suggest it may well get finished still in H2 2013.

What about the business benefits? There would be little purpose in creating a new industry specification unless there were a number of anticipated benefits to the industry. Here we go with a shortlist:

• LWM2M is supposed to open up a partially closed market. Historically, a large part of the M2M market was developed by manufacturers creating M2M modules, terminals and devices with little or limited remote management capability. Soon the commercial need for remote management arose and many companies expanded their product offerings by including remote management capabilities and services. This required them to implement some remote management mechanisms. Sometimes, in the absence of any suitable standards, those management protocols soon included lots of vendor-proprietary flavours. As a result, we end up with vertical, proprietary solutions. Any open remote management standard offers the opportunity to render the market more open, more plug and play, such that M2M device from vendor X can be remotely managed by a software system from vendor Y. That’s the interoperability argument.
• The decoupling of M2M devices from their management systems through open interfaces should theoretically also permit greater independent innovation on the device and on the server side.
• A fit-for-purpose remote management standard has the potential to decrease fragmentation in some parts of the M2M market.
• From a M2M customer point of view, an open specification like LWM2M helps to reduce the problem of vendor lock-in (being locked into a solution where your M2M device can only speak to the M2M management software of the same vendor, also when the price for ‘management as a service’ is increased by the vendor).
• Finally, the solution space for M2M customers and M2M system integrators is expected to become bigger: hopefully a greater choice of M2M devices and connected appliances emerges (as the developers of those wouldn’t have to worry about creating their own bespoke remote management solution from scratch). Equally a greater choice of M2M device management and service enablement platforms to pick and choose from would be possible, once they speak a remote management ‘language’ common with many more devices.
• Implementers of M2M devices and application management platforms may count on greater reach in terms of M2M devices to be able to connect to without the need to create bespoke protocol adapters for those devices. That would positively reduce time to market for M2M solutions, uplift margins and make business models more sustainable.

Any challenges left for the success of LWM2M? Yes, always. First, there are the existing vertical solutions, which will keep growing for some while and will leverage their speed advantage related to new feature rollout (only one party to consult with itself compared to reaching consensus in a diverse group of corporate members in a standards organisation). Second, there are the existing device management solutions, in particular those built around TR-069 and also OMA DM. Some of those will serve the purpose also in an M2M context, though possibly adjusted for particular needs or implemented only with partial scope. Third, once you know all the components and possible configuration parameters of the device you have created or built yourself, the urge is high to be able to manage each individual parameter or feature remotely through your own, wonderfully powerful remote management mechanism. Where it’s needed for the successful operation of a M2M solution, such a bespoke solution is great and will possibly outperform one that’s based on a standard industry interface.  Where it’s not needed it will be overkill and represent costs the M2M customer may have to write off further down the road.

The real proof of the pudding comes when the Internet of Things really takes off, with lots of M2M devices chatting away with their management platforms. Then, elegant, efficient and flexible remote management mechanisms should pay off for multiple parties. LWM2M is one to watch out for.
For a summary of LWM2M, see also a nice presentation on slideshare.net [6].

—— For the more curious, technically interested mind

Here a flavour of how things work. Let’s assume we have a wireless M2M device controlling some infrastructure equipment in the wider Smart Grid (e.g. monitoring your green energy power plant in your backyard to ensure it behaves nicely. And we want to read the value of a parameter from that device, e.g. its latest current firmware version, because we just realised some of the older control devices with older firmware versions would benefit from a bug fix. How would we do that?
We would have to address a resource called “Firmware version” on the device. That resource is part of a group of resources which all have to do with the device in question. So it is part of a resource group called Device Object.

Before we look further, it’s important to consider a typical protocol stack for LWM2M:

• LWM2M logical operations layer
• CoAP protocol with two layers in it: a REST-style request/response layer and a messaging layer below it.
• UDP/IP

From the M2M management platform side, we send a READ operation to the remote device with the intent to read the value from the Firmware resource on that device. (By the way, if we wanted to reboot our remote device, we would send an EXECUTE operation from the management platform to the device.) Thus, on the LWM2M logical operations layer, we can READ resources on an M2M device, WRITE a new value into a resource, CREATE a whole new object instance in a device, EXECUTE an action on some resource and do other really useful stuff.

Thus, technically all LWM2M logical operations (call them commands) are sent over a protocol stack that includes the CoAP protocol (like CoAP over UDP over IP).

The READ operation (with its semantic to read the value of some resource like the firmware version or say a temperature) together with the address of that resource (its URI) is then mapped to the GET method of the CoAP protocol. The resource identifier is a path name like /{Object ID}/{Object Instance ID}/{Resource ID}.

E.g. the ‘mega-short’ path /3/0/3 means the object ID of the object Device is ‘3’, there is only one instance of that object (there is no cloned M2M device sitting in your backyard indicated by ‘0’) and the identity of the resource ‘Firmware version’ happens to be ‘3’ (within its Object).

Thus, on CoAP protocol level a GET method request is shipped to the M2M device, and a response is shipped from the device to the M2M server: e.g. with the response code 2.05 followed by some content (namely the value of the resource ‘Firmware version’, say version 1.1.8).

So, in essence the CoAP GET method is comparable to an HTTP GET request. The CoAP GET method is shipped as a Confirmable request (expecting some kind of acknowledgement to ensure reliable transfer). Whilst in HTTP the response content would be shipped as part of the HTTP 200 OK message, in CoAP it can be shipped e.g. as part of an Acknowledgement message with response code 2.05. (The response content is sort of piggy-backed to the acknowledge message where the latter is needed for the prime reason to confirm the Confirmable request).

CoAP is thus used as a transfer protocol similarly to HTTP.
Thus, LWM2M operations on device resources (like get me the firmware version or reboot the device) are mapped to REST-style requests for resource representations and responses which are shipped as part of CoAP messages.

As mentioned already, CoAP has two layers in itself: A request/response layer using method codes and response codes and underneath it a messaging layer with messages. All information about messages, method codes and response codes is placed into a single CoAP message header, which precedes any payload. URI and payload content type are carried as CoAP options (options are similar to HTTP header fields). The whole lot then goes over UDP.

Looking at the LWM2M level, we would see something like:

LWM2M Client <—-READ logical operation to resource Firmware version —- LWM2M Server

Looking at the CoAP protocol level, we would see something like:

LWM2M server side CoAP Client request:
CON + GET coap://IPv4 address of the M2M device/3/0/3
CON stands for Confirmable message.

LWM2M client side CoAP Server response:
ACK, 2.05 Content, ct=text/plain, payload: “1.1.8”
ACK stands for Acknowledgement message, ct for content type.

By now you may have also noticed that there is a delicate use of the terms client and server.

On the management application level, the LWM2M client sits on the M2M device, terminal or module and the LWM2M server sits on the side of the M2M management platform.

On CoAP level, you find a CoAP client both on the M2M device and on the M2M platform and the same holds for a CoAP origin server.

In our ‘READ the firmware version’-example above, the M2M device management server submits the CoAP GET request as a CoAP client, whilst the M2M backyard-energy-plant controller submits the response to the GET request as a CoAP origin server.

That’s it, roughly.

References
[1] Document pool for LWM2M (beware, experts only!): http://member.openmobilealliance.org/ftp/public_documents/dm/LightweightM2M/Permanent_documents/
[2] TR-069: http://www.broadband-forum.org/technical/download/TR-069_Amendment-4.pdf
[3] OMA standards, including for Device Management: http://technical.openmobilealliance.org/Technical/current_releases.aspx
[4] CoAP specification from IETF:  http://datatracker.ietf.org/doc/draft-ietf-core-coap/
[5] CoAP tutorial: http://www.slideshare.net/zdshelby/coap-tutorial
[6] LWM2M tutorial: http://www.slideshare.net/zdshelby/oma-lightweightm2-mtutorial