- Posted by Rafal Chabowski
- On 16 May 2018
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.
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.
- 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
- 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).
- Object #5 – “Firmware” – urn:oma:lwm2m:oma:5
- Instance #0
- Resource #3 – “State”
|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.|
- 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