IoT Expansion
According to most of the forecasts presented by Forbes, IoT market is going to develop rapidly in the coming years. Some forecasts say that it will grow from $157B in 2016 to $457B in 2020. Such a rapid technology development requires huge work targeted at the unification of the ways we manage the billions of devices connected to the global network.
Easy communication between all these devices is a requirement to keep the market and entire IoT industry growing at even higher rates. Therefore since many years, there is a huge amount of work put into standardization on the field of device management systems.
Device Management
In 2002 Open Mobile Alliance (OMA) was founded in order to streamline the device communication protocols of that time like WAP, SyncML, etc. In case of device management field, a special standard has been announced, called OMA DM. Currently, it is already at the second generation (2.0) and, since it has been evolving for many years it is now considered partly bloated. There are users complaining that from the IoT point-of-view some parts of the protocol are superfluous.
Additionally, OMA DM has its origins in the SyncML technology that uses XML to format a message and protocols that are considered heavy for the message transfer (HTTP, OBEX, WSP, etc.). Initially, OMA DM has been targeted for mobile terminals, but devices used to build an IoT network, such as tire pressure sensors, light bulbs, digital street signs are usually more constrained resource wise, mainly because they are expected to consume as less energy as possible and be cheap.
Parsing XML along with all accompanying meta-data and negotiating TCP connections are tasks that are often beyond the capabilities of such constrained devices. Even the latest version of OMA DM that allows replacing XML with JSON doesn’t solve the problem, although helps a bit. Reduced payload still needs to be transformed through resource consuming TCP.
LWM2M
Because of the aforementioned reasons in the year, 2012 OMA started working on the lighter protocol that would fit well into the environment of constrained devices. The first draft of the proposal for Lightweight Machine-2-Machine (LWM2M) specification surfaced soon. Its main assumptions are:
Low demand for device resources in terms of memory, networking system and computing power
Open and extensible object model available for the entire industry
Security and reliability even in spotty, constrained network connections
The same communication channel used for data and control plane
Devices that communicate via LWM2M no longer need to provide support for TCP based HTTP protocol, because all information could be transferred via a lightweight protocol called CoAP (Constrained Application Protocol) which is based on connectionless UDP. By design, UDP is generally much less complicated than TCP and puts less pressure on the devices that use it.
Designers of the LWM2M protocol have also taken care of the bloated message format and reduced the meta-data accompanying the messages to the minimum. Data that is transferred very closely resembles the pure byte stream instead of bloated messages based on XML or JSON. This approach greatly reduces the processing power required to transfer and serialize/deserialize messages. LWM2M users no longer need to pay the square- or angle-bracket tax, however, when one feels that he has enough processing power, he can still use JSON or TLV (tag-length-value) as this is not forbidden by the protocol.
Security in LWM2M is primarily based on the DTLS protocol (Data Transport Layer Security), whose security guarantees are very similar to the widely used in the Internet TLS protocol. LWM2M support credentials based on pre-shared secrets, raw public keys or certificates. LWM2M protocol stack and architecture
The resource model of LWM2M is also more simple compared to that of OMA DM. The protocol allows to define:
objects (O), for example, “temperature sensor”
instances (I) of objects, for example, “sensor #1”, “sensor #2”
resources (R), for example, “current temperature”
Such model directly maps to the CoAP Universal Resource Locators (URLs).
Currently, there are several standard LWM2M objects defined by OMA, therefore if one is requesting a resource from the “/5/0/3” he will be presented the state of the device firmware update:
Object #5 – “Firmware” – urn:oma:lwm2m:oma:5
Instance #0
Resource #3 – “State”
The protocol specification clearly defines what values could be stored in the resources and under which circumstances. Below please find an official definition of the “Location” object taken directly from Open Mobile Alliance webpage. Entire object registry in its current state could be accessed via this site.
Location
Description
This LwM2M Objects provide a range of device related information which can be queried by the LwM2M Server, and a device reboot and factory reset function.
Object definition
Name Object ID Object Version LWM2M Version
Location 6
Object URN Instances Mandatory
urn:oma:lwm2m:oma:6 Single Optional
Resource definitions
ID Name Operations Instances Mandatory Type Range or Enumeration Units Description
0 Latitude R Single Mandatory Float Deg The decimal notation of latitude, e.g., -43.5723 [World Geodetic System 1984].
1 Longitude R Single Mandatory Float Deg The decimal notation of longitude, e.g., 153.21760 [World Geodetic System 1984].
2 Altitude R Single Optional Float m The decimal notation of altitude in meters above sea level.
3 Radius R Single Optional Float m The value in the Radius Resource indicates the size in meters of a circular area around a point of geometry.
4 Velocity R Single Optional Opaque The velocity in the LwM2M Client is defined in [3GPP-TS_23.032].
5 Timestamp R Single Mandatory Time The timestamp of when the location measurement was performed.
6 Speed R Single Optional Float Meters per second Speed is the time rate of change in position of a LwM2M Client without regard for direction: the scalar component of velocity.
Summary
Even though LWM2M is still relatively young it already proved its value and is currently used by lots of key players in IoT like Microsoft (Azure), Ericsson (DDI) or Huawei (OceanConnect). The protocol is constantly developed and there is an ongoing discussion about it next features. This makes is the good candidate to become a fundamental protocol used in IoT industry.
Among the features for future development are:
transfer object meta-data in order to reduce the vendor’s dependence on the availability of the public object register
method of providing the LWM2M server with information about the availability of the optional object resources or possible values that could be written to the resource
Thaumatec will definitely keep an eye on the further development of the LWM2M protocol. If you also want to play with LWM2M a good starting point would be to use some open-source libraries like Leshan (server) or Anjay (client library).
