# Device Management with Lightweight M2M (LwM2M) and Pelion Client

When trying to implement IoT solutions, developers and solution architects face the dilemma of which IoT protocol to choose. Many protocols are available (such as MQTT, CoAP, DDS, AMQP and so on), making the decision difficult, time-consuming and prone to misjudgement. Although each technology has its merits and a place in the IoT ecosystem, few can claim the label of a device management protocol that allows the efficient connection and management of millions of constrained IoT devices in the field. This blog post explores the Lightweight M2M protocol (LwM2M) that is used as the foundation protocol of the [Pelion Device Management Service](https://www.pelion.com/iot-device-management/) of the [Pelion IoT Platform](https://www.pelion.com/) and then walks through an example running the Pelion Client to demonstrate the LwM2M concepts “in action”. Then, this post describes the value-added services provided by the platform on top of the LwM2M foundation.

Let's start first with the basics of device management.

## Five pillars of Device Management

A device management protocol should provide the following:

1. **Secure Bootstrapping**
The mechanisms to securely provision a device with the necessary PKI cryptographic elements (keys/certificates) to successfully connect to a device management server. Further, Access Controls Lists (ACLs) should limit the “allowed” interactions to predefined and strict areas.
2. **Remote Management**
The mechanisms to configure the device with newly updated settings to reflect a new desired state required by the business application or as a response to an external stimulus that prompts a change to the device. Further, the ability to trigger actuators on the device to perform actions.
3. **Firmware Update**
The mechanism to implement a secure and efficient firmware over the air update (FOTA) to update the application running on the device with new functionality or to fix vulnerabilities discovered after the device was shipped on the field.
4. **Fault Management**
The mechanism for the device to report errors.
5. **Reporting**
The mechanisms that allow the device to notify changes in its current status and allow it to be queried for specific parts of its configuration settings.

**Read Also:**
Whether you're a business looking to enhance your customer communication, a developer interested in the technical aspects, or simply curious about the future of messaging, this article is your gateway to understanding the power and versatility of **[sending messages as SMS via server](https://www.techtually.com/sent-as-sms-via-server/).**

The scope of a device management protocol is wide and encompasses all the real-world” issues IoT developers face when trying to efficiently and scalably manage their production devices in the field. [OMA SpecWorks](https://www.omaspecworks.org/), a standardization body formed by a number of companies ([including Arm](https://omaspecworks.org/membership/current-members/)) started a combined effort in 2013 to create a next-generation IoT device management protocol specifically targeted for M2M communication, which will serve the needs for the explosion of connected devices.

> You may not know but [OMA SpecWorks](https://www.omaspecworks.org/) are the original creators of the [OMA-DM management protocol](https://en.wikipedia.org/wiki/OMA_Device_Management) that allowed mobile operators to efficiently manage mobile phones, PDAs and tablets. If you use a mobile phone, it's likely that you are already using the work the standardization body has done.

In February 2017, the [first version](http://www.openmobilealliance.org/release/LightweightM2M/V1_0-20170208-A/OMA-TS-LightweightM2M-V1_0-20170208-A.pdf) of the specification was released, followed by three more revisions. A fourth is currently in the ‘candidate’ phase. Throughout the years, the specification has incorporated many technological advances and improved a number of areas as part of the feedback gathered by the increasing number of companies deploying LwM2M in production. At the moment, LwM2M stands as a mature device management protocol, ready to be deployed in the field.

Let's have a high-level look at how LwM2M works starting with the "interfaces" concept.

> If the word specification scares you, fear not! The LightweightM2M specifications are easy-to-follow and well-written documents and if you have a basic technical savity you can easily follow along and understand the internals of how LwM2M protocol works if that interests you!

## LwM2M walkthrough

Architecturally, LwM2M is a client-server protocol. The IOT device plays the role of the client while the server is the Device Management server where devices register, making them available to be managed. The communication between the two is bidirectional; a device reports back information either as a response to a request the server initiates or on a predefined time interval.


Underneath, LwM2M relies on the IETF standardized [CoAP protocol](https://tools.ietf.org/html/rfc7252) to provide the semantics and structure of how the different parties should communicate. CoAP itself is a specialized protocol, where the efficiency of the communication (to allow it to run on lossy networks) and of the runtime (to allow it to run on low-power constrained devices) played a vital role in its development. You may think of CoAP as analogous to the HTTP protocol (in fact it is modelled very closely), which defines the structure of the communication, and LwM2M as the Web browser that builds on top of it to provide value-added services (or whatever the application is that is based on HTTP).

The diagrams below depict the protocol stack of LwM2M:


First are “Objects”, described in detail later, which are the managed properties the device exposes to the outside world. Because LwM2M is based on CoAP, it inherits its properties, such as UDP as the transport protocol and DTLS for securing the path. SMS may feel strange to you, but LwM2M was designed to operate on that transport, too. (The OMA-DM protocol, a precursor to LwM2M, might played a role here!). In more recent versions of LwM2M (v1.1), the protocol introduced support for TCP as the communication protocol (following the [advancements of CoAP](https://tools.ietf.org/html/rfc8323)), as well as catering to the Low-Power Wide-Area Networks (LPWAN) that are starting to appear around us (such as NB-IOT, LoRA and so on).

> If you are in the market looking for solutions on how to best connect your devices using LPWAN technologies, [Pelion Connectivity Management](https://www.pelion.com/iot-connectivity-management/) can be a great starting point. We'll love to hear from you and your specific use cases and problems you are facing!
>

The specification defines “four interfaces” that match the device management concepts described previously:


### Object Model

One important characteristic of LwM2M is that it opted to use a standardized format to describe the “Objects” a device supports based on the work done by the [IPSO Smart Objects](https://omaspecworks.org/about/the-oma-specworks-work-program/ipso-smart-objects-working-group/) working group (now part of OMA SpecWorks). This was done deliberately to allow maximum interoperability between devices from different vendors. As long as vendors supported this common format, their devices can be easily plugged in and communicate with other devices that supported it.

> You can find a list of current registered IPSO Smart Objects [here.](http://www.openmobilealliance.org/wp/omna/lwm2m/lwm2mregistry.html)
>

Let’s see what an “Object” looks like when extracted from the [OMA SpecWorks Registry](http://www.openmobilealliance.org/wp/omna/lwm2m/lwm2mregistry.html). Below is a description of the “Temperature“ Object, used to report measurements of a temperature sensor:


Each “Object” is globally assigned an ID, and it can contain one or more “Resources” describing its properties (which themselves are assigned an ID).

Each “Resource” can:

- Be either readable/writable or executable (‘Operations’).
- Be single or have multiple instances (‘Instances’).
- Be mandatory or optional (‘Mandatory’).
- Have a specific data type associated with it (‘Type’).

During the ‘Registration’ phase with the LwM2M server, the device indicates the list of Objects it supports:


You can use the IDs for Objects and Resources to construct a URI targeting a specific resource or Object you would like to access with the management interface.


> Notice the similarities with web addressing. As we described earlier, LwM2M relies on COAP protocol, so it adheres the REST paradigm to access the properties of a device.

The specification predefined eight standard Objects that every LwM2M implementation must adhere to, so the [IPSO Smart Objects](https://omaspecworks.org/about/the-oma-specworks-work-program/ipso-smart-objects-working-group/) working group and external vendors can step in and provide additional Objects to suit their specific needs. Below is a list of those standard objects defined by the specification:


### Pelion Client Example

Now that this post has discussed the basic concepts behind LwM2M protocol, it will show through an example how those concepts translate in action using the [Pelion IoT Platform](https://www.pelion.com/). The official [reference example](https://github.com/ARMmbed/mbed-cloud-client-example), provided by the platform, connects to [Pelion Device Management Service](https://www.pelion.com/iot-device-management/) and interacts with the device’s Objects and Resources. This tutorial uses the [Pelion Device Management Portal](https://portal.mbedcloud.com/) to interact with the service, but you can also choose to use the [exposed API's](https://www.pelion.com/docs/device-management/current/service-api-references/index.html) provided, in case you need to develop custom integration points or web applications on top of the service.

> For an example integration with the [Device Management Service](https://www.pelion.com/iot-device-management/), check the Arduino use case published in our [blog.](https://blog.pelion.com/post/arduino-pelion)

> For an example web application build on top of the [Device Management Service](https://www.pelion.com/iot-device-management/), check our [web application tutorial.](https://www.pelion.com/docs/device-management/current/integrate-web-app/building-and-deploying-a-web-application-using-the-connect-apis.html)

This demonstration uses an [ST Discovery-L475E-IOT01A](https://os.mbed.com/platforms/ST-Discovery-L475E-IOT01A/) board, but you can use the provided example to connect and manage any device, ranging from low-constrained devices (such as [_Mbed Enabled_](https://os.mbed.com/platforms/?q=&Mbed+Enabled=Pelion+Device+Ready) or [Amazon FreeRTOS](https://www.pelion.com/docs/device-management/current/connecting/nxp-mcuxpresso.html) compatible boards) to mid-range devices (such as [Raspberry Pis](https://www.pelion.com/docs/device-management/current/connecting/linux-on-raspberry-pi-3.html) and generic [Linux boxes](https://www.pelion.com/docs/device-management/current/connecting/linux-on-pc.html)). See our [documentation](https://www.pelion.com/docs/device-management/current/connecting/device-management-client-tutorials.html) for instructions on how to get started on each platform.

1. Flash the example on the board. The device bootstraps and connects to Device Management service. Click on the Device Directory section in the Portal to see its status as _Connected_:
2. Clicking on the device reveals a right pane with various device details and metadata, including the _Object and Resources_ this device exposes:
3. Exercise the _‘Information Reporting’_ interface of LwM2M to subscribe to a specific _Resource_. This notifies you when the value of that _Resource_ changes on the device. The example code is set to periodically change the value of _[/3200/0/5501 - Digital Input Counter](http://www.openmobilealliance.org/tech/profiles/lwm2m/3200.xml)_ every 5s.

> In LwM2M terms, this operation is called creating an _Observation_ for an Object Instance or Resource.
>

Click on the Resource. The service sends an LwM2M _Observation_ request for that specific Resource on the device to start receiving the new values as they change. Notice in the console that the device echoes the initial _observation request_ received from the server (_'subscribed'_), the periodic emission, as well as the delivery of the notifications with the new values.


4. It's time to exercise the _‘Device Management & Service Enablement interface’_ of LwM2M. Although this tutorial uses a subset of the operations of this interface, mainly _Read/Write and Execute_, it should give you an idea of how this interface works.

a. Start with the Execute action. The example exposes a blinking action on resource (_[/3201/0/5850 - Digital Output On/Off](http://www.openmobilealliance.org/tech/profiles/lwm2m/3201.xml)_). When invoked, the LED of the device blinks with a specific pattern (which we’ll adjust later) and for a predefined interval.

> NOTE: If you browse the definition of the Object _[/3201](http://www.openmobilealliance.org/tech/profiles/lwm2m/3201.xml)_ in the [Object Registry](http://www.openmobilealliance.org/wp/omna/lwm2m/lwm2mregistry.html), you'll notice that the _/5850 - On/Off_ Resource is missing. That is because this specific resource is called a _'Reusable Resource'_ and is defined outside an Object definition. Many Objects, particularly those targetting similar domain, may need similar resources so instead of replicating those in each Object definition, a _'Reusable Resource'_ allows itself to be embedded to multiple Objects.

b. Click on the _/3201/0/5850_ resource to invoke the blinking operation. The operation requires no-params, so click the Send button using empty params. When the device receives the request, it starts blinking the internal LED.


c. Click on the _/3201/0/5853_ Resource to read and write on it. This resource indicates the number of milliseconds the LED stays active on each blink. Lowering it makes the LED blink faster. When clicked, the Portal displays the current value of the Resource. Edit the value, and click ‘Send’. This causes the service to issue a write request on the device to update it. If you try to invoke the blinking operation again, you’ll notice the device blinks faster.

> NOTE: Similar to _/5850_ we discussed previously, the _/5853_ Resource is itself a _Reusable Resource_


This tutorial demonstrated the most basic operations of LwM2M, mainly to _Read/Write_ and _Execute_ an action on a _Resource_. Please see our documentation for more detailed information regarding [managing resources](https://www.pelion.com/docs/device-management/current/resources/index.html).

### Building on top of LwM2M

Having LwM2M as its foundation protocol allows the [Pelion IoT platform](https://www.pelion.com) to enjoy the benefits of a mature and open standard device management protocol developed in cooperation with many companies already deploying it in the production field. On top of that, Pelion IoT Platform introduces value-added services that solve issues our customers are facing when trying to deploy real-world IoT solutions.

In particular:

- Trusted Device onboarding and service provisioning of the device before it leaves the factory.
- Device Grouping and filtering for flexible and efficient targetting of operations to a subset of devices.
- A scalable update process able to handle firmware updates for millions of devices. This includes delta updates for cutting network transmission costs to the minimum required.
- Operational Monitoring of the devices (e.g. memory use, CPU behaviour) to proactively detect incorrect behaviour (e.g after a software update).
- Handle long-sleeping devices with _‘last-reported-state’_ and _‘desired-state’_ giving the ability of business applications to continue to operate even when the device is offline.
- Handle efficiently different network types with variable transmission latency characteristics.
- [and much more.](https://www.pelion.com/docs/)

Upcoming blogs posts will cover in detail the different value-added services provided by the platform and how each one helps solve real-world IoT deployment issues. In the meantime, we provide [free-tier access](https://os.mbed.com/pelion-free-tier/) to [Pelion IoT platform](https://www.pelion.com), so you can easily [get started](https://www.pelion.com/guides/connect-device-to-pelion/). Why not give it a try?