What 12 Bytes Really Mean

Executive Summary

It is not very straightforward and simple to compare different IoT communication technologies in terms of data consumption. If such a comparison is made without a good research on the particulars of the radio technologies, very false conclusions can be made.

This article explains the differences of a Sigfox connected object versus an IP connected object in terms of data transfer and explains the technical details when it comes to what it means with “12 bytes of payload” within a Sigfox network concept.

It is concluded that the corresponding data consumption of a 12-byte Sigfox message compared with an IP connected object with same behavior is 8.2 KBytes. This is then converted to monthly and annual data consumption to help find the right pricing for the cellular connected objects. One final point is made about the fine prints in cellular data and how they apply to objects with infrequent data transfer sessions.

Introduction

There was an article on the internet where the data prices of various IoT communication subscriptions are compared, and an unfair conclusion is presented by making a calculation of “Euros per byte”. This is an unfair conclusion because it compares fundamentally different technologies without going into any details around how data is sent over the air and how it is presented to end customer.

The purpose of this article is to try to find a common ground for comparing Sigfox “12 byte” message versus an IP enabled IoT object with a similar behaviour. To be able to demonstrate the differences, an overview of Sigfox technology is presented and an attempt is made to calculate the data consumption of a counterpart IP enabled object, as IP connectivity is the most common implementation of IoT objects in cellular world. Finally, there is a section that talks a bit about the fine print conditions on M2M, IoT SIM plans and their effect on data consumption for object communications with low data exchanges.

 

How Sigfox Connection Works

The image below shows the message flow of a Sigfox connected object.

 

No alt text provided for this image

Sigfox radio is famous for being the simplest radio access technology to enable low-cost low-power IoT objects to connect wirelessly to the Internet. The simplicity comes from a few different design choices. For the purpose of this article, we will talk about the following:

Message Type = 0 (GPS Data Record)
In Trip = True
Last Fix Failed = False
Lat = 1.3401526
Long = 103.7762054
Heading = 304 degrees
Speed = 22km/h
Battery = 4.85V.

A Sigfox object simply sends the 12 byte data payload:

10b67dcc0006efda3d9816c2

and leaves it to the Customer Application Server to decode it properly, according to predefined and specific rules.

Below is an indication of how many bytes various types of sensor data need.

No alt text provided for this image

It is also worth mentioning that some optimization on these values can be made. For example, if a certain environment temperature is known to be between 0-40 degrees with a step size of 0.5 degrees, only 80 discrete values are needed and 1 byte instead of 2 bytes will be sufficient to represent this data.

Sequence ID: A transmission sequence identifier to avoid certain replay attacks and preserve authenticity. Also used for calculating message success rate.
Object ID: A 4-byte global sigfox ID to uniquely identify an object within Sigfox.
Object Authentication Code: HMAC signature used by Sigfox Cloud in authenticating the object.

For more details on Sigfox radio frame structure, please refer to this link.

POST {URL of the destination endpoint} HTTP/1.0
accept-encoding : gzip,deflate
connection : Keep-Alive
accept-charset : UTF-8;q=0.9,*;q=0.7
x-amz-security-token : {security token ~356 characters}
content-type :
authorization : {authorization credentials ~211 characters}
content-length : 203
host : {URL_host}
accept-language : fr
user-agent : SIGFOX
accept : */*
x-amz-date : 20200824T045545Z
{
"object" : "2C4A89",
"time" : 1598244944,
"data" : "10b67dcc0006efda3d9816c2",
"seqNumber" : 1262,
"lqi" : 3
}

Please note that the sensitive fields have been replaced with descriptions in curly brackets.

It is also worth mentioning that:

  1. Sigfox network also supports applications where a message back to the object (downlink communication) is required. This downlink communication has minimum to no effect for the purpose of this article and will be neglected. Please refer to this link for more information on downlink.
  2. Some level of decoding of the raw message can be done at Sigfox Cloud to send actual values rather than the raw data.
  3. Multiple callbacks can be configured to different destinations, with no additional cost.
  4. Sigfox Cloud tries to deliver the callback four times, at times T0, T0+1 minute, T0+2 minutes and T0+4 minutes. If all 4 attempts fail, Sigfox Cloud keeps the message for retrieval by a special API endpoint. This is also free of charge.

How IP Connection Works

The image below shows the message flow of an IP connected object over a cellular network.

No alt text provided for this image

 

In cellular-connected objects, it is common to implement IP connectivity directly on the object. Although in theory it is possible to do a no-IP communication with NB-IoT, it is currently not a very usual implementation. Data prices of cellular network operators are almost always advertised for IP connected objects. It is also not clear how pricing works for Non-Ip Data Delivery (NIDD) as the operator needs to provide an API interface for the customer to pull/push the data and this usually means and additional service with a cost.

If a similar object communicates over the IP, this is how the flow works:

  1. Object wakes up, establishes an RRC connection with the cellular network.
  2. Object gets an IP address and establishes an IP session with the application. All of the TCP, SSL and HTTP overheads between Sigfox Cloud and Customer Application Server as described in the previous section take place between the object and Customer Application Server and all these overheads are counted against the data consumption of the object.
  3. The usual TCP/IP packet losses and retransmissions due to the nature of the internet bursts happen between the object and the Application Server, and are counted against data consumption of the object.

Calculation of Data Consumption

Considering the information given above, a better estimation and comparison of data consumption of a Sigfox objects vs IP-connected object can be made.

Below are some assumptions made during this calculation:

Sigfox Object Assumptions:

  1. The Sigfox object sends 140 messages a day, with 12 bytes of payload.
  2. No decoding of data takes place in Sigfox Cloud. (i.e. the 12-byte payload is sent as-is to the application server)
  3. One callback is defined from Sigfox Cloud to Application Server.

Below is the data + metadata sent within the callback:

Timestamp in epoch time: 10 bytes
Object ID: 4 bytes
Payload: 12 bytes
Sequence number: 1 byte
Link quality indicator: 1 byte

Cellular Object with same behavior:

Timestamp in epoch time: 10 bytes
Object ID: 4 bytes
Payload: 12 bytes
Sequence number: 1 byte
Link quality indicator: 1 byte

Firstly, we show what the data looks like after it is “converted from 12 bytes to a HTTP POST format. Below is a figure depicting that evolution.

No alt text provided for this image

A 12-byte payload that contains sensor data is converted to json with the addition of a few metadata that is mandatory for analysis, and then this json data is converted into an http POST request with the proper authentication and other http parameters. The resulting POST request is 1040 bytes size.

Secondly, we figure out the total amount of traffic generated by securely sending the payload via an HTTP callback over TLS. To find out the total amount of traffic created for the exchange of data, postman was used to send https callbacks with all the proper headers and payload. Screenshots of the postman API callback request is shown below.

Screenshots of the postman API callback request
Screenshots of the postman API callback request

And the successful receipt of the callback can be seen below

Callback reception
Callback reception

While sending these requests, Wireshark dumps have been taken to analyze the traffic created by this exchange. Screenshot of the traffic can be seen below.

wireshark trace
wireshark trace

 

All this traffic exchange sums up to a total of 8202 bytes (8.2 KBytes) whose breakdown is given below.

Cellular Signaling in KBytes
Cellular Signaling in KBytes

Notes on Comparison

Please note that this comparison is an optimal case scenario where:

Monthly and Annual Data Consumption Calculations

With some simple maths, data consumption of an equivalent IP connected object can be easily calculated for 3 different subscription levels offered by Sigfox connectivity plans. Below is a breakdown of Sigfox subscription levels, and their corresponding monthly and annual data consumption amounts for corresponding IP connected counterparts.

Sigfox Vs cellular plans
Sigfox vs Cellular Plans

To give one examples from the table above, an IP connected object with a behaviour that is equivalent to a Sigfox connected object with Ultra Level subscription level (i.e. 140 Uplinks per day) will end up consuming around 413 Megabytes per year (~35 Megabytes per month), assuming ideal traffic conditions with no packet loss and no DNS requests.

Notes on Cellular Data Plans

Fine prints on data charges need to be carefully investigated to avoid any bill shock on an IP connected object. some of these fine prints that we could capture from public pages are as follows:

  • Charging on data is done for uplink and downlink communication combined.
  • Minimum charging block: The total data consumption within a session is usually rounded up to the closest 1 kbyte or 10 kbyte. For small data volumes such as our case, the amount of data sent during a session will be very small and be rounded up, which can make a significant difference in terms of billing. In our case, the object would be charged for 9 or 10 kbytes per session if the minimum charging block was 1 or 10 Kbytes respectively.
  • Minimum charging amount per session: Some operators have a minimum charging amount per session. This is also important for use cases where the object battery life is maximized by infrequent wake-ups and data transfer sessions. Imagine a data tariff where the minimum charging amount was even as low as 1 cent. This would result in a data cost of 1.4 Euros per day!

Conclusion

Contrary to what some believe, 12-bytes actually mean a lot. Not only 12 bytes can represent a significant amount of sensor information, the IP connected version of 12-byte data transmission could result in a traffic exchange of 10 Kbytes. Thanks to the simplicity centric design of Sigfox connectivity, processing and transmission of small amounts of data becomes very easy and much more efficient.

Tugberk B.

Tugberk B.

Customer Solutions EMEA Team Leader at SIGFOX

Link to Original Article in LinkedIn