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.

 

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:

• Object wakes up, broadcasts its message and gets back to sleep.
• Object sends 12 bytes of payload as part of the message. These 12 bytes is to be used by the application, usually in an encoded way to make the best use of it. A good example of such encoding can be found at one of Sigfox Ecosystem Partner’s object named Oyster. As can be seen here, instead of sending a structured 174 byte message such as:

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.

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.

• The object also sends a 14-byte frame for radio overhead, which consists of some radio parameters, CRC check field and also the following fields:

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.

•  The data from objects are captured by Sigfox base stations and forwarded to the Sigfox Cloud. During this phase, some metadata including timestamp, object ID, Sequence Number and link Quality indicator can be added to the object message.
• Sigfox Cloud authenticates the message and forwards it to the customer premises via an HTTPS callback. A typical HTTPS data callback is as follows.

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.

 

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:

• The Cellular object in comparison establishes 140 sessions a day to the Customer Application Server directly and sends the exact same payload and metadata in an https callback. Below is the data sent

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

• The data in https callback is in json format.
• This communication is over TCP/IP.
• DNS requests to resolve the URL are neglected.
• Application server responds to the successful receipt of callback with an http 204 message.
• 100% TCP success rate (no retransmissions)

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.

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.

And the successful receipt of the callback can be seen below

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.

 

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

Notes on Comparison

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

• Ideal TCP/IP conditions are assumed, i.e. no re-transmission of data is considered. If a retransmission occurs, which is likely to happen at a rate of 1.5% in IP world, that will mean additional data consumption of an IP connected object, however, Sigfox equivalent bears no additional cost, as all TCP/IP communication including retransmissions is handled by the Sigfox Cloud.
• No decoding on object is assumed. If the object sends decoded data in text format, that results in additional data consumption on IP connected object. Sigfox equivalent can do decoding at Sigfox Cloud level with no additional cost.

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.