Lightweight M2M (LwM2M) is a standard created by OMA SpecWorks that specifies device management and service enablement mechanisms designed mainly for devices that have limited processing and storage capabilities (commonly referred to as resource constrained devices). The technology functions very well over potentially unstable and low bandwidth networks such as cellular or sensor networks as well as low link consumption and LPWA radio networks.
In LwM2M, the information exchange occurs between the Server and the Client (which is located on a device).
There are 4 interfaces governing the communication:
The Bootstrap interface is used to provision the Client with information needed to “register” with the Server. Once the Client has been provisioned, it can then perform the registration via the second interface (Client Registration). Once the Client is registered, the last two interfaces can be used. The Device Management & Service Enablement Interface is used to access Client’s resources with simple operations such as “Write”, “Delete”, “Execute” and the like.
Finally the last interface – Information Reporting is used by a Server to receive notifications when the value of a specified resource has been changed. This can be used to pro-actively monitor the values of certain parameters, adjusting the thresholds to fit each specific use case, per device and in bulk.
Using simple resource constrained devices (which could even be 8-bit systems with very few kilobytes of ROM and RAM) requires also a simple data model. The data model for LwM2M consists of resources which can be grouped into objects. To be more specific, an LwM2M device supports one or more object types. An object can have object instances, and every object type has its own list of resources. Resources can be defined to be certain data types, for instance string, integer, Boolean, float. Thanks to the data model in LwM2M being very well defined, interoperability is ensured, even in multi-protocol and multi-vendor, complex IoT environments.
As mentioned before, LwM2M is designed to consume as little bandwidth as it can. To make this possible, it uses the Constrained Application Protocol (CoAP), (which works in a similar way as the HTTP protocol but is especially designed for resource constrained devices) that helps LwM2M devices to easily communicate with the web. One of its biggest merits that makes it especially suitable for LwM2M is the fact that it supports UDP (User Datagram Protocol) as a transport layer protocol which ensures effective battery consumption for devices. UDP has a big advantage over TCP (used in other M2M protocols) in regards to the speed of packet transmission. This is especially useful for any use cases involving mobile terminals and wireless access.
Although LwM2M comes with a few already defined objects and resources, it is not enough to provide structured data models which would allow efficient communication over protocols such as CoAP. Responding to these needs is the IPSO Smart Objects project (now also part of OMA SpecWorks) that aims to ensure the interoperability on the application layer by creating and providing a common design pattern of objects based on LwM2M. The difference between the object model proposed by LwM2M Enabler is that IPSO Smart Objects are designed to be reused and easily adjusted to new use cases.
Furthermore, there is also a possibility of defining your own objects with a special editor provided by OMA and register them with OMNA (Open Mobile Naming Authority). The objects will then be reviewed by individual members of OMA and added to the registry (if they pass the evaluation).
Apart from UDP, LwM2M also supports SMS binding. There are several modes including modes when the Client is reachable only via UDP, only via SMS, or both UDP and SMS. The flow of the communication is pretty straightforward: if the Server sends request via UDP the Client responds via UDP, if the Server sends request via SMS the Client responds via SMS. What is also worth mentioning is the Queue Mode. This mode is particularly useful when the Client (device) is not reachable at all times (be it due to lossy network or just to minimize the power consumption). When the Queue Mode is supported, the Server is obligated to queue all requests, and send them only when the Client is reachable.
Yes, it is.
The security is based on CoAP and utilizes DTLS (Datagram Transport Layer Security) as its main security mechanism. Along with UDP and SMS transport channel bindings, DTLS implements authentication, confidentiality and data integrity between the Server and the Client.
There are 3 security modes:
The Client needs to have credentials and the configuration information obtained during the bootstrapping process. Once the bootstrap is done, the server authenticates the Client, and thus the Client can make use of all the security features supported by LwM2M.
The distinction lies in the protocol level. In the layering scheme of the protocol stack, the MQTT ranks lower than LwM2M. Therefore, the comparison should be made between CoAP (rather than LwM2M) and MQTT.
As far as these two are concerned, the difference is found in communication methods: CoAP provides communication based on requests and responses, whereas MQTT relies on publish/subscribe messaging system. It is worth noting that CoAP requires less link consumption compared to MQTT, the reason being that MQTT uses TCP as a transport binding, while CoAP uses UDP.
The Lightweight Machine-to-Machine standard is truly lightweight. It allows to manage devices that have very little power over really low bandwidth networks, while being itself a standard with a very simple and not confusing stack of technology. The devices that LwM2M is designed to manage include sensors, microcontrollers, actuators etc. which can sometimes be installed in a place that is hard to reach. It does not change the fact that such devices are actually on the web and DO need to be managed, secured, updated, monitored etc.
To sum it up, LwM2M responds to these needs by offering:
Some of the most important features include:
Composite operations such as READ-COMPOSITE, WRITE-COMPOSITE and others.
In the early specification, LwM2M utilizing CoAP used simple operations such as READ, WRITE, EXECUTE, CREATE (and others) based on basic methods used for example in HTTP (GET, POST, PUT, DELETE). In the latest LwM2M 1.1 specification however, there are new operations added on top of the already existing ones. New operations introduced in LwM2M 1.1 include composite operations such as READ-COMPOSITE or WRITE-COMPOSITE. The idea behind this was to extend the basic READ, WRITE and other commands to allow aggregation of operations on many different objects and send all the acquired parameters in one payload.
SEND operation in Information Reporting interface.
As far as operations are concerned, SEND is another one that contributed to improved functionality of the LwM2M standard. In the previous specification, in order for LwM2M Client to be notified about any changes in a given resource, LwM2M Server had to first issue OBSERVE operation on that resource and only then could LwM2M Client issue a NOTIFY operation to receive the desired information. SEND on the other hand, gives similar results to NOTIFY operation, with the difference that it does not require OBSERVE operation to be active, to send notifications. Thus, it makes the communication between the client and the server not only easier but also more reliable.
New transport bindings such as CoAP over TCP and Non-IP Data Delivery.
Last but not least are new transport bindings. To this moment we only had CoAP
utilizing UDP, which – as mentioned before – is a faster transport protocol than
TCP. However, TCP generally is more reliable than UDP
especially concerning its
traversal capabilities. In other words, TCP is more effective
when it comes to
restrictions imposed by NAT or firewall. This was the reason why in LwM2M 1.1
CoAP over TCP functionality has been implemented.
Furthermore, we can also enjoy Non-IP Data Delivery – another
transport binding
– which is particularly attractive for the IoT, because it further minimizes
power consumption for IoT specific resource constrained devices.