Efficient Transport of Telemetry Data in IoT with LwM2M Protocol

When you think about the Internet of Things, you may imagine many very different scenarios:

• automated farms that start irrigation process in perfect moment,
• smart buildings with precise cooling and heating systems,
• connected cars sending information to traffic management systems, optimizing transport in real time.

All cases require us to gather data like temperature, humidity, location and speed from numerous sensors deployed in our vehicles, buildings and city streets. Those devices must be energy-efficient to operate on batteries and cheap, because we need a lot of them. Such devices, called constrained, have very little processing power and communicate over low bandwidth, high latency radio interface like Narrowband IoT (NB-IoT). On the other side, we deploy powerful servers, that must process and store data from millions of sensors. Both sides have completely different requirements and architecture, but need to communicate using one protocol that’s simple to implement for IoT devices, compact to transport and easy to process in large amounts.

This issue caught IETF attention and new data representation format was created. Sensor Measurements Lists (SenML) defined in RFC 8428 describes a format easy to encode without putting much stress on constrained device CPU. On the other hand, format takes into account parsing of huge amounts of measurements by data consumers, enabling large scale deployments. SenML is meant to be carried in HTTP and CoAP protocols, and especially the latter is interesting with regard to IoT applications and limited bandwidth offered by radio interfaces like LoRaWAN, SigFox, LTE Cat-M or NB-IoT.

Let’s consider an electricity meter that sends measurements in regular intervals to enable pricing based on demand or time of the day. Also, electricity producers need historical data to plan grid upgrades and plan electricity production.

The meter makes first measurements each full hour and sends it to the cloud in a form of JSON payload:

[

{“n”:”urn:dev:ops:561133-ElectricMeter-CL17999”,”u”:”kWh”,”t”:1.5513408e+09,”v”:65141}

{“n”:”urn:dev:ops:561133-ElectricMeter-CL17999”,”u”:”kWh”,”t”:1.5513444e+09,”v”:65190}

{“n”:”urn:dev:ops:561133-ElectricMeter-CL17999”,”u”:”kWh”,”t”:1.551348e+09,”v”:65230}

]

Each measurement contains the following fields:

• n – name, unique device (meter) identifier, in our example we use URN as proposed in Uniform Resource Names for Device Identifiers draft
• u – unit, measurements unit – kWh
• t – time of measurements, for values lower than 2^28 (268 435 456) represents time in relation to current time, zero being now. For values higher than or equal 2^28, time is specified as absolute time in POSIX time.
• v – measurements value

There is quite a lot of repetitive data in meter message, for example device URN is sent in each record. To make it more efficient, SenML defines so-called base fields, that are sent only in the first record prepended (for strings) or added (for numbers) to values in the next records. An example of such base field is Base Name (bn), that is prepended to names. In our example, usage of Base Name will result in this message:

[

{“bn”:”urn:dev:ops:561133-ElectricMeter-CL17999”,”u”:”kWh”,”t”:1.5513408e+09,”v”:65141}

{”u”:”kWh”,”t”:1.5513444e+09,”v”:65190}

{”u”:”kWh”,”t”:1.551348e+09,”v”:65230}

]

Name field would contain an empty string, so it has been omitted. If we use more base fields our message will be even smaller:

[

{“bn”:”urn:dev:ops:561133-ElectricMeter-CL17999”,”bu”:”kWh”,”bt”:1.5513408e+09,”bv”:65141}

{”t”:3600,”v”:49}

{”t”:7200,”v”:89}

]

SenML also supports messages from devices that do not have time source and can only send information about relative time. In such a case, message sent from our meter would look like that:

[

{“bn”:”urn:dev:ops:561133-ElectricMeter-CL17999”,”bu”:”kWh”,”t”:-7200,”bv”:65141}

{”t”:-3600,”v”:49}

{”t”:0,”v”:89}

]

The system which receives a message with zero in time field must be able to determine when exactly that measurement occured, for example considering typical transmission delay.

SenML could also be used in other direction, to send instruction from a server to a smart device. Imagine a connected thermostat that needs to be set on different levels depending on time of the day. The example below will create several entries in device memory:

[

{“bn”:”urn:dev:ops:123577-Thermostat-CL17999”,”bu”:”Cel”,”bt”:1.5513408e+09,”bv”:22.5}

{”t”:10800,”v”:-2}

{”t”:21600,”v”:-3}

{”t”:32400,”v”:-2}

{”t”:43200,”v”:0}

]

All presented examples use JSON representation, but SenML also supports CBOR, XML and EXI.

To further strengthen SenML interoperability, Internet Assigned Numbers Authority (IANA) has created registry of SenML labels and units. This enables telemetry collection systems to understand measurements sent by any sensor, without prior integration.

First full version of RFC got introduced fairly recently (August 2018) but SenML has been developed for a long time and it has been recognized as a preferred way of transporting measurements data in several applications. Current version of LwM2M 1.1 defines two additional media types:

LwM2M 1.1 also introduces new “Send” operation, that works as an upgrade for the previous “Notify” operation and together with SenML creates perfect setup for telemetry services. “Notify” required more complex server and client implementations, where a server has to subscribe to resource measurements with certain settings and a client has to handle subscription fulfillment, taking those settings into account. Also, both client and server have to store subscription ID in case of the restart of a device. “Send” operation enables unsolicited notifications without explicit server request, simplifying the whole process.

AVSystem’s Coiote IoT Device Management platform provides a lot of mechanisms that allow easy access to data collected from sensors as well as management of the sensors involved in the whole process of an IoT deployment.