Serialization and deserialization is a critical part of IoT applications, since data must be transferred over constrained networks to constrained end-nodes. Many efficient serialization methods have been developed with goals ranging from "hundreds of bytes is fine" to "every byte decreases battery life". The requirements for an efficient serialization and deserialization scheme include low processor resource consumption at the end-node, support for time-aggregated sensor readings and small-as-possible payload sizes.
Data serialization refers to turning object data into a binary format that can be either saved or transmitted. Deserialization means the opposite, constructing the original object representation from the binary format. The serialization can require a schema, where an externally defined structure is required to understand the data, or schema-less, where the object attempts to represents itself. The most critical aspect with regards to data serialization and LPWANs is the resulting payload size.
Examples of common schema-less serialization schemes are JSON [49], XML [50], CBOR [51] and MessagePack [52]. All of these allow for representation of com-mon programming objects such as arrays and key/value pairs, with JSON and XML being fully human-readable while CBOR and MessagePack are binary formats. Mes-sagePack and CBOR both encode information in a compact manner. MesMes-sagePack outperformed JSON, XML, CBOR and all the other tested serializers in speed and compactness in a study [53] by Bo Peterson et al., but this may depend on payload type.
As seen in listing 1, serializing an object containing the data of a humidity and
temperature sensor with JSON in results in a payload size of 145 bytes (whitespace removed), which is twelve times the allowed Sigfox uplink payload size. The example listing includes a channel value in order to seperately identify multiple sensors of the same type in one payload, for example indoor and outdoor temperature. Serializing the same data structure with MessagePack yields a payload size of 117 bytes for the same data. This is an improvement, but is still roughly ten times the size of the maximum allowed Sigfox payload, and double the maximum payload size of LoRaWAN with the slowest data rate.
{
Listing 1: Example of explicit end-node sensor data. Channel of data allows for multiple readings of the same type to be referenced.
A model of how to compress sensor measurement data has been defined by the IETF as Sensor Measurement Lists in the RFC 8428. SenML is a data model, and serializations of it are provided for JSON, CBOR, XML and Efficient XML Interchange (EXI). SenML compresses the data by reducing redundant data in lists of sensor measurements. It supports measurement lists for values at different relative and absolute times, different sensors and actuators, completely different devices. [54]
A simple example of a SenML-modeled JSON serialization is shown in listing 2.
A base name "bn" and base unit "bu" are used to reduce redundant data. The JSON serialization less whitespace requires 78 bytes, and a CBOR serialization of the same data requires 46 bytes – a decrease of 71 bytes in payload size compared to listing 1 MessagePacked. In the case of a single measurement SenML achieves this decrease mostly due to reducing key lengths to one or two characters. Where SenML shines is when data from multiple devices or timepoints are to be expressed in a
compact manner. For example historical measurements can be added without using a Real Time Clock by adding measurement instances with the"t" parameter set to a negative value. At of -5indicates "5 seconds before this moment". Measurements from other devices at different times can be added by adding a measurement defining a new base name.
[{
"bn": "Example",
"bu": "%RH"
}, {
"n": "1",
"u": "Cel",
"v": 20.50 }, {
"n": "3",
"v": 50.5 }]
Listing 2: A sensor measurement list using SenML of the same data as in listing1.
JSON, XML, and MessagePack all serialize data with mostly human-readable keys.
The keys allow the contents to be understood without knowledge of a schema, but this is also the main cause for the large payload sizes. NB-IoT’s unrestricted payload sizes allow sending data in these schema-less formats such as JSON, XML and MessagePack, but especially Sigfox can not transmit data in these formats due to the large payload size. For a 12-byte payload as in Sigfox, one must use a binary format together with a schema.
In the example of listing 1, much of the payload bytes are spent in ensuring that the data is deserializable without knowledge of the contained data. For example, if the use of Celsius degrees and percent as the units of temperature and humidity were known by both serializing and deserializing parties, the payload could be made smaller. This is the main approach used by Cayenne LPP, based on IPSO smart objects.
IPSO Smart Objects define a data model, consisting of the object representation, the data type used, operations one can perform on the object and more. The data model, specifically designed for IoT applications by OMA Specworks defines Object Type ID’s for digital input’s digital outputs, temperature sensors, accelerometers and more. An instance ID is also defined, allowing multiples of the same sensor to be referenced per end-node. [55]
Hex Stands for Result 0x01 Channel 01
0x67 Temperature sensor Temperature (Channel 1): 20.5 °C 0x00CD Value of 205
0x03 Channel 03
0x68 Humidity sensor Humidity (Channel 3): 50.5 % 0x65 Value of 101
Table 5: Explanation of Cayenne LPP packet 0x016700CD036865 containing the same data as in listing 1.
The IPSO Smart Objects specification was used to define the Cayenne LPP, which is a more simple model with emphasis on suitability for LPWANs with very constric-ted payload sizes, and reading sensors instead of executing commands on objects.
Cayenne LPP defines an object data type ID which mandates the data type (in-teger, float, boolean, etc), the length (No. of bytes), what the object representation (temperature reading, humidity reading) and the data format (0.1 °C, 0.5 %) of the following binary data. [5]
Using the pre-defined data types in Cayenne LPP, the previous data from listing 1 specifies the same functional data in 7 bytes. The only factor the Cayenne LPP is missing compared to the listing 1, is that the payload doesn’t specify the device’s identifying string. Sigfox and LoRaWAN payloads are always forwarded together with the device name or identifier. The SCEF would also be expected to report a name or identifier of an NB-IoT end-node. Only in the case of direct NB-IoT IP communication the end-node must specify it’s identity within the payload. The Cayenne LPP 2.0 specification draft also includes representations for historical data and device configuration commands such as sensor on/off, transmit period and sensor reading period [56].