Every bit counts!

In a previous article on march 30th 2017 I wrote about the # of IoT devices deployed in the field. An important number of these IoT devices will be using one of the new IoT networks based on LoRaWAN, Sigfox, NB-IOT or any similar LPWAN technology.

According to Machina Research, connected objects will account for more than 25 billion connections by 2024. 14% of connections in 2024 will use Low Power Wide Area Networks (LPWAN) connections such as Sigfox, LoRa and LTE-NB1 or 2.75 billion in total.

‘LPWAN’ networks serve use cases which need long range communication to reach sensors that require  low power consumption  in order to operate several years remotely on a single battery pack. Examples of such sensors are street lights, parking sensors, sensors to monitor pipelines, energy meters and other infrastructure.

These are typically use cases where ‘main powered’ sensors are economically not feasible. It costs about €700 per meter to place an energy cable in the ground to power a street light, without even mentioning the time loss and disturbance  caused for the public.

Another potential for LPWAN are M2M and IoT devices that use 2G cellular networks. Telecom operators  phasing out these networks see LPWAN as a a good alternative for those end-devices.

A first challenge for product manufacturers who develop LPWAN devices; is the battery life. Technical sheets from those product manufacturers claim up to 5 or sometimes even 10 years of battery life, while in practice some last only 6 months on a ful charge.

A good practice is to design the product from it’s most important role, which is… sleeping. Consecutively, the power consumption during transmission can be optimised. Important  here is to limit the ‘time-on-air’. Depending on the type of technology used, this  varies with the distance between the sensor and the base station as well as with other factors like the density of the network. A good practice is to keep the payload generated on the edge-device as short as possible.

In the beginning of the information technology era, developers were well aware of the importance of using every bit available, as the cost of storage or communication was high per byte transmitted (during my first job back in 1990 our company drive, used by 8 engineers was a total of 10MB!). Today we are spoiled with the amount of storage and broadband communication capabilities in such a way that we do not think anymore about how many bytes are being used by the data format of our choice to send a message. For example JSON is a popular data format to exchange information between a browser and web services and it can also be used to exchange information between a physical (IoT) object and a web service, but is not necessarily the most optimal for the latter. JSON as XML contains besides the actual data also metadata to define the schema, so systems can interpret the data correctly.

A second challenge that product manufacturers and Application developers face is the size of the required footprint to encode and decode these messages. Typically LPWAN technologies define the physical and network layer but they do not specify the application layer, which means there is no standard defined for it. In practice this means that every product developer encodes his own payload with his own convention. Application builders have to know these conventions, before they can read the messages produced by the end-devices and act upon them. On top of that, each product manufacturer uses his own convention! This is not only a labor intensive task but also, could impact the scalability on the cloud side, as these different conventions will impact the footprint of decoding all those different conventions.

SenML & CBOR

JSON bridges the gap between human readable and machine parsable data formats via a more compact syntax than SGML and XML, but it is still ultimately ASCII.  A first natural step when you need to optimize for space, is to use a binary encoding and then put a compression algorithm on top.

A promising solution can be found within the new IOT data model and data formatting standards SenML and CBOR to tackle both challenges; the battery life of battery powered LPWAN end-devices and the footprint needed to encode and decode the message .

While SenML and CBOR aim the same 2 goals - The first goal is to provide an extremely small code size (< 1K) and the second one is to provide a fairly small message size - each of them contribute a specific approach.

SenML stands for Sensor markup language and provides a data model for representing simple sensor measurements and device parameters. In short it improves the encoding efficiency of JSON based representations by minimising the length of the attribute label strings through the use of abbreviations. The example below of a SenML JSON serialization shows a temperature reading taken approximately “now” by a 1-wire sensor device that was assigned the unique 1-wire address of “10e2073a01080063”.

[{ "n": "urn:dev:ow:10e2073a01080063", "v":23.1, "u":"Cel" }]

Where the single character string "v" in the above example represents the numerical value attribute (21.1) and the single character string "u" represents the unit (Cel = degrees Celcius).

Although SenML approaches the realistic limits of encoding efficiency for a JSON based format, the fact that JSON uses a text based encoding means that it is still much less efficient than a dedicated binary representation.

This is where CBOR comes in. CBOR (Concise Binary Object Representation) is a concise binary object payload representation (http://cbor.io) Just like JSON, the CBOR schema is embedded, eliminating the need to communicate separate schemas. Furthermore, CBOR  fully automates encoding & decoding and is also extensible, eliminating the need for version negotiation.

All of this makes SenML and CBOR  very good candidates to solve the 2 main challenges described above. Besides the small messages based on binary payloads, SenML and CBOR allows a small footprint and very scalable encoding and decoding, which is important for the constrained end-devices at the edge of IoT and the centralized IoT platforms that need to support large deployments of such constrained LPWAN devices.

Sources :

https://tools.ietf.org/html/draft-jennings-senml-10

https://machinaresearch.com/news/press-release-global-internet-of-things-market-to-grow-to-27-billion-devices-generating-usd3-trillion-revenue-in-2025/