Until recently, there was no industry standard for the remote management of M2M or IoT devices. This contrasts with the established industry standards that cater for the remote management requirements of fixed network broadband DSL routers (TR-69), enterprise IP networks (SNMP) and mobile phones (OMA DM).
The Open Mobile Association (OMA) have published a new industry open standard, OMA Lightweight M2M (LWM2M), for ‘constrained’ M2M & IoT devices. By ‘constrained’ we mean those devices (like sensor platforms) that are limited by network bandwidth, computing power and memory, those depending on a limited battery lifetime and those viable only at very low production costs.
OMA LWM2M is a good fit for ‘Over-The-Air’ (OTA) management of IoT wireless sensor platforms because it utilises a simpler protocol and COAP over UDP with a very small overhead (10s of bytes) and the device client is a lot smaller.
The LWM2M architecture is illustrated below.
© 2015 Open Mobile Alliance Ltd
OMA LWM2M defines the application layer communication protocol between a server and a client. The LWM2M Server is typically located in a private or public data centre and can be hosted by the M2M Service Provider, Network Service Provider or Application Service Provider. The LWM2M Client resides on the device and is typically integrated as a software library or a built-in function of a module or device. Four logical interfaces are defined between server and client namely:
The LWM2M protocol stack utilizes the IETF Constrained Application Protocol (CoAP) as the underlying transfer protocol over UDP and SMS bearers. CoAP defines the message header, request/response codes, message options, and retransmission mechanisms. The CoAP protocol was defined by the IETF Constrained RESTful Environment (CoRE) working group.
CoAP creates an alternative to HTTP for RESTful APIs on resource-constrained devices and supports the basic methods of GET, POST, PUT, DELETE (as with HTTP), which are easily mapped to those of HTTP. Unlike HTTP, CoAP messages are exchanged asynchronously between CoAP end-points over a datagram-oriented transport such as UDP. A subset of response codes is supported for LWM2M response message mapping. Built-in resource discovery is supported using the CoRE Link Format standard. CoAP messages are encoded in a simple binary format, allowing this functionality starting with just a 4-byte overhead. LWM2M defines the UDP Binding with CoAP as mandatory whereas the SMS Binding with CoAP is optional. This means, that LWM2M client-server interaction can happen both via SMS and UDP
LWM2M includes security to secure communications between client and server using Datagram Transport Layer Security (DTLS). DTLS is used to provide a secure channel between the LWM2M Server and the LWM2M Client for all the messages interchanged. DTLS security modes include both pre-shared key and public key technology to support both very limited and more capable embedded devices. The LWM2M standard defines provisioning and bootstrapping functionality that allows a LWM2M Bootstrap Server to manage the keying, access control and configuration of a device to enroll with a LWM2M Server. The security identifiers, endpoint identifiers and keys are used uniformly throughout the LWM2M system to provide a complete security lifecycle solution.
The LWM2M defines a simple resource model where each piece of information made available by the LWM2M Client is a Resource. Resources are logically organized into Objects. The Figure below illustrates this structure, and the relationship between Resources, Objects, and the LWM2M Client. The LWM2M Client may have any number of Resources, each of which belongs to an Object. Resources and Objects have the capability to have multiple instances of the Resource or Object.
LWM2M Object Resource Model
© 2015 Open Mobile Alliance Ltd
Resource is defined to have one or more operations that it supports. A Resource MAY consist of multiple instances called a Resource Instance as defined in the Object specification. The LWM2M Server can send “Write” operation with JSON or TLV format to Resource to instantiate a Resource Instance. The LWM2M Client also has the capability to instantiate a Resource Instance.
An Object defines a grouping of Resources, for example the Firmware Update Object contains all the Resources used for firmware update purposes. Each Object is assigned a unique OMA Management Object identifier and corresponding index which identifies an Object defined for the LWM2M Enabler. The LWM2M Enabler defines standard Objects and Resources. Further Objects may be added by OMA or other organizations to enable additional M2M Services.
An Object MUST be instantiated either by the LWM2M Server or the LWM2M Client, which is called Object Instance before using the functionality of an Object. After an Object Instance is created, the LWM2M Server can access that Object Instance and Resources which belong to that Object Instance.
As an example, the device object allows remote retrieval of device information such as manufacturer, model, power information, free memory, and error information. Furthermore, the device object provides a resource for initiation of a remote reboot or factory reset. Another example is the firmware object, which provides all resources needed to enable firmware updates.