In our earlier blog, we discussed about the suitability of OMA’s LWM2M protocol for IoT applications, including how the Light Weight M2M protocol defines the Object model, basic communication methodologies and the opportunities and challenges it presents.

While in M2M context, LWM2M devices can community with machines locally using CoAP, in IoT context, it can be used for communication with a gateway or aggregator from where it can be taken to the cloud platform using with the CoAP or customized REST/HTTP packets

It is expected to see large deployments of LWM2M protocol for usage in IoT/M2M applications and hence brought several solutions based on the same. In this article, we will discuss some of these offerings as well as other solutions available for integrating the protocol on different technologies.

LWM2M on Android/Java

Without doubt, Android is going to play a major role in industrial scenarios with growing usage in the HMI segments. Standardized APIs, Rich UI, improving performance, powerful processors and growing RAM storage, ease of use and more importantly familiarity of users are some of the key factors for this trend.

Another important reason of gaining acceptance amount the developers is the need for support in Eclipse IDE. It must be possible to create servers and clients in Eclipse based development environment before/during deployment in the device. Eclipse foundation has launched a dedicated initiative to facilitate IoT developments under iot.eclipse.org.

Requirements in Android/Eclipse necessitates the need for a Java based protocol stack. This is available in form of the WAKAAMA project.

The project uses the Californium server as the underlying CoAP implementation.

This server internally uses the Californium stack. It supports LWM2M clients connect to it over CoAP/UDP over WiFi (or Ethernet if available in the Android device). It supports configuration of server port number, start/stop options along with features like observe notifications etc. Currently only basic communication is supported. Security and Bootstrapping will be supported in upcoming releases.

A customized Bluetooth transport is also available for use with low power devices.

LWM2M Stack for embedded

The reference for the LWM2M protocol is provided in form of a library named LIBLWM2M. This should form a basis for developing your own LWM2M client and server implementation.

Another option is the availability of the open source LWM2M client stack from Embien. Since majority of the device is going to be only clients, this should serve purpose for those cases. Again a minimal stack without many advanced features, it is optimized for resource constrained embedded applications. The stack can be run with or without using an OS/RTOS.

The code is available at LWM2M Client Github repository in a BSD license.

The implementation supports two transports

  • CoAP/UDP – for communicating with LWM2M servers
  • REST/TCP – for communicating with SkyCase server

The transports can be chosen in the configuration file and used easily in a minimal time. LWM2M Objects are also supported with callback functions enabling quick integration of custom logic with the main stack

Cloud based Solutions

For an IoT scenario, soon there will be a need for a cloud platform to manage these connected devices. As of now, only solution available for LWM2M model is SkyCase – IoT application platform. This platform currently supports REST interface for communication and uses LWM2M object model internally.

SkyCase provides the JAVA API library to develop cloud applications with LWM2M/IPSO standard objects.

Soon it can be expected to support CoAP transport directly enabling direct LWM2M communication.

This blog should have given an idea of LWM2M related developments with a consolidated list of LWM2M stacks for IoT/M2M devices available. We hope there will be more implementations of the stack available in the near future as adaptation of the technology increases.

About Embien Technologies: Embien Technologies is a leading provider of embedded design services for the Semi-conductor, Industrial, Consumer and Health Care segments. With track record of working with cutting edge technologies, Embien is an adopter of OMA LWM2M standard in its designs as well as in its flagship SkyCase IoT application platform. Feel free to contact us or email us for any queries regarding LWM2M stack or SkyCase or any other requirements on IoT/embedded developments.

Saravana Pandian Annamalai
21. July 2014 · Write a comment · Categories: Internet of Things, Technology · Tags: , , ,

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 Device Instances

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.

Instance ID mapping for M2M vs IoT

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 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.