Essential Technical guide of Sigfox protocol: Network architecture, interfaces, protocol stack

Essential Technical guide of Sigfox protocol and how it works from a technological point of view. Discover the network architecture and the protocol stack

Learn about Sigfox and its topology in this guest post by Perry Lea, an IoT and fog compute expert.

Sigfox protocol is a narrowband LPWAN (like NB-IOT) protocol developed in 2009 in Toulouse, France. The founding company goes by the same name. It is an LPWAN technology using the unlicensed ISM bands for a proprietary protocol. Sigfox has some traits that significantly narrow its utility:

• Up to 140 messages per device daily on uplink (duty cycle of 1%, 6 messages/hour).
• A payload size of 12 bytes for each message (uplink) and 8 bytes (downlink).
• A throughput of up to 100 bps uplink and 600 bps downlink.

Originally, Sigfox was unidirectional and intended as a pure sensor network, which implies that only the communication from the sensor uplink was supported. Since then, a downlink channel has become available.

Sigfox protocol is a patented and closed technology. While their hardware is open, the network, however, isn’t and must be subscribed to. Sigfox hardware partners include Atmel, TI, Silicon Labs, and others. Sigfox builds and operates its network infrastructure similar to the arrangement of LTE carriers.

This is a very different model from LoRaWAN. LoRaWAN requires a proprietary hardware, PHY, to be used on their network whereas Sigfox technology uses several hardware vendors and a single managed network infrastructure. Sigfox calculates rates by the number of devices that are connected to a customer’s network subscription, the traffic profile per device, and the duration of the contract.

Note that while there are strict limitations of Sigfox in terms of throughput and utilization, it is intended for systems sending small and infrequent bursts of data. IoT devices like alarm systems, simple power meters, and environmental sensors would be candidates. Data for various sensors can typically fit within the constraints (such as temperature/humidity data of 2 bytes at 0.004 degree precision).

You must be careful with the degree of precision the sensor provides and the amount of data that can be transmitted. One trick to use is state data—a state or event can simply be the message without any payload. In such a case, it consumes 0 bytes. While this doesn’t eliminate the restrictions in broadcasting, it can be used to optimize for power.

Sigfox protocol: Physical layer

Sigfox technology is an Ultra Narrow Band (UNB), implying that the transmission uses a very narrow channel for communication. Rather than spreading the energy across a wide channel, a narrow slice of that energy is confined to these bands:

• 868 MHz: Europe (ETSI 300-200 regulations)
• 902 MHz: North America (FCC part 15 regulations)

Note: Some regions such as Japan have strict spectral density limitations currently, making UNB difficult to deploy.

The band is 100 Hz in width and uses Orthoganol Sequence Spread Spectrum (OSSS) for the uplink signal and 600 Hz using Gaussian Frequency Shift Keying (GFSK) for the downlink. Sigfox will send a short packet on a random channel at a random time delay (500 to 525 ms). This type of encoding is called Random Frequency and Time Division Multiple Access (RFTDMA). Sigfox, as stated, has strict parameters of use, notably data size limitations. The following table highlights these parameters for the uplink and downlink channels:

Bidirectional communication is an important characteristic of Sigfox versus other protocols. However, bidirectional communication in Sigfox does require some explanation. There is no passive reception mode, meaning a base station cannot simply send a message to an endpoint device at any time. A receive window opens up for communication only after the transmission windows complete. The receive window will open only after a 20 second period after the first message was sent by an endpoint node. The window will remain open for 25 seconds allowing reception of a short (4 byte) message from a base station.

333 channels, 100 Hz in width each, are used in Sigfox. The receiver sensitivity is -120 dBm/-142 dBm. Frequency hopping is supported using a pseudo-random method of 3 out of the 333 channels. Finally, the transmission power is specified to be +14 dBm and +22 dBm in North America:

Three copies of the payload are transmitted on three unique random frequencies with various time delays. A window of downlink transmission opens only after the last uplink.

Sigfox technology: MAC layer

Each device in a Sigfox network has a unique Sigfox ID. The ID is used for the routing and signing of messages. The ID is used to authenticate the Sigfox device. Another characteristic of Sigfox communication is that it uses fire and forget. Messages are not acknowledged by the receiver. Rather, a message is sent three times on three different frequencies at three different times by the node. This ensures the integrity of transmission of a message. The fire and forget model has no way of ensuring that the message was actually received, so it’s up to the transmitter to do as much as possible to ensure accurate transmission:

The frames contain a preamble of predefined symbols used for synchronization in transmission. The frame sync fields specify the types of frames being transmitted. The FCS is a Frame Check Sequence (FCS) used for error detection.

No packet contains a destination address or other node. All data will be sent by the various gateways to the Sigfox cloud service.

The data limit can be understood and modeled from the MAC layer packet format:

Given that each packet is transmitted three times and that European regulations (ETSI) limit transmissions to a 1% duty cycle, you can calculate the number of messages per hour using a maximum payload size of 12 bytes:

Even though twelve bytes is the limit of a payload, the message may take over 1 second to transmit. Early versions of Sigfox were unidirectional but the protocol now supports bi-directional communication.

Sigfox protocol stack

The protocol stack is similar to other stacks following the OSI model. There are three levels:

• PHY Layer: This synthesizes and modules signals using DBPSK in the uplink direction and GFSK in the downlink direction.
• MAC Layer: This adds fields for device identification/authentication (HMAC) and error correcting code (CRC). The Sigfox MAC does not provide any signaling. This implies that devices are not synchronized with the network.
• Frame Layer: Generates the radio frame from application data and also systematically attaches a sequence number to the frame:

With regards to security, messages are not encrypted anywhere in the Sigfox protocol stack. It is up to the customer to provide an encryption scheme to the payload data. No keys are exchanged over a Sigfox network; however, each message is signed with a key unique to the device for identification.

Sigfox topology

A Sigfox network can be as dense as 1 million nodes per base station. The density is a function of the number of messages sent by the network fabric. All nodes that attach to a base station will form a star network.

All data is managed through the Sigfox backend network. All messages from a Sigfox Base Station must arrive at the backend server through IP connectivity. The Sigfox backend cloud service is the only destination for a packet. The backend will store and send a message to the client after authenticating it and verifying that there are no duplicates. If data needs to be transmitted to an endpoint node, the backend server will select a gateway with the best connectivity to the endpoint and forward the message on the downlink.

The backend has already identified the device by packet ID and prior provisioning will force the data to be sent to a final destination. In Sigfox architecture, a device cannot be directly accessed. Neither the backend nor the base station will directly connect to an endpoint device.

The Sigfox cloud routes data to the chosen destination. The cloud service offers APIs via a pull model to integrate Sigfox cloud functions with a third-party platform. Devices can be registered through another cloud service. Sigfox also offers callbacks to other cloud services. This is the preferred method to retrieve data:

Sigfox protocol utilizes its proprietary non-IP protocol and converges the data to a Sigfox network backend as IP data.

To ensure data integrity of the fire and forget communication model, multiple gateways may receive a transmission from a node; all the subsequent messages will be forwarded to the Sigfox backend and duplicates will be removed. This adds a level of redundancy to the reception of data. Attaching a Sigfox endpoint node is intended to ease installation. There is no pairing or signalization.

If you found this article interesting and want to learn more about Internet of Things, you can refer to the book, Internet of Things for Architects, by Perry Lea. The book explores IoT in minute detail, taking you through the entire spectrum of IoT solutions—from sensors to the cloud. So, if you are an architect, system designer, technologist, or a technology manager, this book is a must-have in your bookshelf.