Sigfox is an ultra-narrowband communications system designed for low data rates and ranges of up to 20 km [7]. The Sigfox network operates in the EU 868 MHz / US 915 MHz ISM bands. An end-node in the LPWAN is connected to an enterprises application servers via Sigfox’s own cloud backend. The gateway network used to communicate with end-nodes in the system is maintained by Sigfox, and the communication modules are registered to and billed by Sigfox (the company), leading to a business model similar to cellular operators.
2.4.1 Architecture
Data sent by Sigfox end-nodes is broadcast to all base stations within range, which process and forward the message to the Sigfox backend, triggering user-set callbacks in the Sigfox backend [7]. These callbacks forward the data to any of a number of systems. These systems include IoT platforms by Amazon, Microsoft and IBM, e-mail, and any other REST API. The architecture supports downlink data transfer, but it is much secondary to uplink data transfer in link frequency.
2.4.2 Transmission Specifics
Technical limitations of the Sigfox system are payload size, messages per day and downlinks per day. The up- and downlink payload limits of Sigfox are 12 bytes and 8 bytes, respectively. Sigfox utilizes a pricing model in which there are four levels of communication volume per day, presented in 1
The Platinum uplink limitation is a consequence of ETSI regulations used in Europe, citing a 1 % duty cycle limitation leading to 144 12-byte-payload Sigfox messages per day [9]. As the pricing model shows, the Sigfox LPWAN is designed for higher uplink
Subscription level Uplink / 24 h Downlink / 24h
One 1-2 0
Silver 3-50 1
Gold 51-100 2
Platinum 101-140 4
Table 1: Sigfox subscription tiers [8].
frequency than downlink, and for transmitting small payloads, such as infrequent sensor data. Downlink transmissions to many end-nodes must be sent by the same gateway, which itself must stay within the same ETSI duty cycle limitations as the end-node. Transmitting high-bandwidth data such as images, audio or video is not possible over the Sigfox network.
The Sigfox downlink transmission scheme [10] is as follows:
1. The end-node requests a downlink message by adding a downlink request flag to an uplink. The sequence is always initiated by the end-node.
2. The Sigfox Cloud runs a callback to the customer’s application server and gathers any downlink data available for the end-node.
3. In a few seconds, the downlink message is transmitted to the end-node.
With such a scheme, the end-node can not be activated remotely to perform an action with low latency. The application must allow waiting until the next uplink connection to transmit data downlink to the end-node. The downlink HTTP re-sponse must be received by the Sigfox backend in under 20 seconds [9]. Also, with a maximum downlink data rate of 24 bytes per day, it is not possible to perform firmware Over-The-Air (FOTA) updates. This amount of data may, however be enough for example adjusting certain parameters of a device remotely.
2.4.3 Security
According to Sigfox’s paper on their approach to security [11], the Sigfox network relies heavily on their non-IP connection and limited bandwidth. The paper ar-gues that Sigfox devices are expected to only use their data link for implementing their default behaviour, and don’t allow for radically changing device behaviour.
As the end-node can only ever contact Sigfox’s backend, the company has control
over where to forward the resulting IP traffic. Sigfox assures that data being sent over the air in both directions is error-checked, authenticated and protected against replay attacks, but is not encrypted and can thus be decoded by third parties. Au-thentication guarantees the proper origin of the message, either the end-node or the Sigfox network.
Each Sigfox message received contains a sequence number identifying the message.
A newly received sequence number is then compared to the ones last received by the Sigfox network, and action is taken according to the gap’s severity. A warning is issued if there is any gap in the sequence number, and an error message along with interruption of message delivery if the gap is larger than the error limit of a subscription level. After 4096 messages the sequence number wraps around to 0.
[12]
The Sigfox error limits for different subscription levels are presented in table2. The error limits for all but the "One" subscription level translate to roughly three days of continuous loss of coverage, assuming maximum subscription uplink throughput.
The "One" subscription level will issue an error after 10 days under the same con-ditions.
Subscription level Error Limit
One 20
Silver 150
Gold 300
Platinum 420
Table 2: Maximum difference in received Sigfox sequence numbers before messages are not forwarded. [12]
2.4.4 Managing Power Consumption
Sigfox end-nodes initiate uplinks completely asynchronously, and do not implement listening before transmitting [13]. This means that an end-node does not need to use radio power listening to the network before transmitting, may transmit imme-diately once it has ceased operating in a low-power state, and should receive any queued downlinks directly following the uplink transmission. The sequence allows for extremely low power consumption, as the end-node may fully turn off power to their radios during a low-power state, effectively making the connectivity option not use any power.
2.4.5 Configuration
The user interface for the backend system of the Sigfox network is displayed in figure 2. Sigfox provides an abstracted link between end nodes and the Sigfox backend, so all settings wth regards to data transfer have to do with either the end-node or the uplink callbacks. So-called custom callbacks can modify the data in a limited way, add more information like date, time, location and SNR, and forward this data to a HTTP API or e-mail.
Figure 2: A screen capture of the device callback editor in Sigfox Backend.
The callback editor provides settings for at least:
• Type: Data/Service/Error – What to react to
• Type (continued): Uplink / BiDir – Is a downlink expected?
• Channel: Url / Batch-Url / E-mail – Where to forward data?
• Custom payload config – How to decode received bytes to variables for message editor
• Url pattern: Url to invoke, may include variables such as device name
• HTTP Method: POST / GET / PUT
• Headers: User-defined headers such as authorization
• Content-type
• Body: A field in which to write the message body, may include variables The Sigfox Custom Format is a way to encode and decode data in few bytes, while specifying the data types used. It can decode a pre-determined sequence of bytes to signed, unsigned integers, floats, character sequences and booleans. These variables are then referenced according to pre-determined names.