Further to our discussion on Internet of Things, we will have a look in to one of the most promising standards proposed for IoT – LWM2M from OMA.
This post will provide a quick overview of the standards followed by a discussion on the opportunities it presents and challenges faced primarily in the object model more than the underlying communication protocols.
Light Weight M2M – LWM2M for IoT
Internet of Things presents challenges so far not seen in usual environment with known or well predicted communication and computing requirements. IoT brings in necessity to support few thousand types of devices with billions of actual devices. Further it needs even computationally less powered systems with limited network connectivity to be managed.
For these challenges, OMA (Open Mobile Alliance) a consortium of industry leaders proposed a new standard – LWM2M – Light Weight Machine-to-Machine. It is a Client-Server model and in the words used in the technical paper.
The LWM2M protocol, to be used for remote management of M2M devices and related service enablement, has at least four outstanding characteristics:
1) it features a modern architectural design based on REST appealing to software developers,
2) it defines a resource and data model that is extensible,
3) it has been designed with performance and the constraints of M2M devices in mind, and
4) it reuses and builds on an efficient secure data transfer standard called the Constrained Application Protocol (CoAP) that has been standardised by the Internet Engineering Taskforce (IETF) as a variation of the Internet’s HTTP protocol (appropriate for data transfer to and from low-cost connected IoT devices).
These words truly describe everything about LWM2M. LWM2M for IoT offers simple REST services for data logging and retrieval. It defines an Object/Instance/Resource model for data management and uses CoAP (a low-bandwidth protocol) for communication. The architecture diagram is given below.
Currently data transfer over UDP and SMS are defined with security using DTLS. There are numerous documentations and links available to describe the communication aspects of the standard and is not the scope for this discussion. Rather we will describe the data management layer.
LWM2M Object Model
LWM2M considers every device being connected to it having a set of parameters each mapped to an aspect of its functionality. Some may be Read-write that needs configuration and control and some may only be Read/Only used for observing status information.
An example might be a simple dimmer that controls the brightness of the light. The dimmer may have a variable to switch it on or off and another to set the brightness level.
LWM2M assigns a unique resource ID for each of these parameters and groups them in to something called an Object identified by a unique Object ID. For each actual device present, an instance ID is allocated which contains the actual resource values. The instance ID management is done by the LWM2M Client and typically starts from 0. There may be any number of instances based on the actual number of devices.
The example object description of a Light Control Object (object ID = 3311) will look like as follows
|
S.No |
Resource ID |
Description |
Type |
Access |
| 1 | 5851 | Dimmer | Integer 0 -100 | R,W |
| 2 | 5850 | On/Off | Boolean | R,W |
Considering a LWM2M Client connected to 3 Light Control objects, the client will present itself like this:
LWM2M Object Instances for Dimmers
The object model and resource ID definitions may be complex depending on the complexity of the device it represents.
In terms of object/instance/resource philosophy, it resembles the CIP standard from ODVA that is employed in DeviceNet & Ethernet/IP and other protocols being used in industrial automation.
LWM2M Model – Opportunities
Now about the opportunities it presents to the IoT segment, the salient points are.
New Standard
Since being a new standard being drafted in very recent time, LWM2M is designed with IoT and M2M requirements in consideration. Backed by the expertise of OMA, it should be very easy for the LWM2M to map and accommodate the changing needs of the industry. It should be possible to create object models for the new devices being supported under IoT.
Simplicity
The underlying communication technology and data model is very simple and robust unlike the OMA-DM. The devices implementing this technology could even be an 8-bit system with very few kilobytes of ROM and few bytes of RAM. Further the legacy systems could be easily accommodated using simple LWM2M gateways.
Acceptability
With IoT industry beginning to take shape and leaders in industry like ARM, Vodafone, etc backing it, it should be very easy for the industry to accept LWM2M for IoT. With a little aggressive push, the LwM2M can find far more deployments. With reference implementations available for C and Java, developer community need not sweat it out to bring a new LWM2M device.
LWM2M Model – Challenges
Some of the opportunities we believe LWM2M have to look out in terms of its object model are as follows.
Limited defined Objects
The virtue of being a new standards is a vice here. Very few objects are currently defined. At the time of this writing, only around 18 Object IDs and 42 resource IDs are defined excluding the basic ones. A far more definitions will help in faster adoption of the standard.
On the positive side, OMA provides users an interface to request for new object definitions, which should quickly bring many devices under this standard.
Dynamic IoT Instances
Probably true to its name, LWM2M might be designed with a higher preference on M2M devices. The main difference between an industrial and say a consumer ecosystem is the relative stability and identification of devices. In an industrial setup, when a device is set up and assigned an instance, it is highly unlikely to change over time. While it might be online or off-line, the instance ID can safely assumed to be same. Whereas in a typical consumer environment, the whole system constituent may change completely. Further it is very dynamic that the order of adding a device and removing them will be chaotic. An example could be a set of Bluetooth devices deployed spread across a large area and a mobile phone acting as a LWM2M Client. With LWM2M server in the cloud, the instance orders will drastically change depending up on the range of the Bluetooth coverage. With more smart-phone clients, things will be even more complex. The following diagram depicts the difference.
To overcome this, a UUID – Universally Unique ID resource ID might be assigned for each device. This should be a simple version 4 UUID based on Random numbers without dependency on any governing bodies. This will provide a totally unique reference at the server and reduces dependency and complexity on the gateways.
LWM2M Objects connected with gateways
Further it has an added advantage of consolidating the device view. For example, in the above diagram, multiple IoT devices are connected to the main LWM2M server via multiple gateways. Ultimately the last gateway will show the devices in completely different instance ID mapping. With a UUID being used, the LWM2M can correctly select the per-registered device for control. Also it can choose use that as an endpoint to control bypassing the instance ID’s.
Conclusion
LWM2M is going to be a major player in IoT and we expect a lot of deployments based on LWM2M soon. When UUID is available for individual device identification and more underlying physical communication layers defined, LWM2M is sure to be here for a very long time managing the ‘Internet of Things’.
Embien, with its rich expertise in IoT and allied segments, has launched its SkyCase – IoT solution for enabling IoT for devices across industry. Combing the best in class technologies – REST, LWM2M and Java, it offers a cloud system that enables LWM2M devices to be connected and controlled. Please visit our SkyCase product page more details of the same.