Internet of Things Wireless Connectivity Option Analysis: Sigfox
PROS and CONS
Sigfox intends to deploy a managed network, much like a cellular network, dedicated to the IoT. Sigfox uses sub-GHz frequency bands and claims that it achieves long-range communication by relying on a very low data rate of 100 bps, approximately 100 to 1,000 times less than the other IoT technologies discussed so far. Such a low data rate results in great sensitivity, which allows for long-range communication of multiple kilometers, provided there is no interference at all. Like LORA, Sigfox faces constant criticism regarding its theoretical vs actual range performance. Its actual performance substantially worse than the theoretical marketing numbers use to attract LPWAN enthusiasts. Although a managed IoT network is a viable approach to a number of IoT applications, the current Sigfox technology has several shortcomings that make it not suitable for the widespread IoT applications.
Sigfox does not employ any collision-avoidance techniques. Consequently, Sigfox technology is put under stringent transmit power, and in Europe duty cycle, limitations by not being able to transmit more than 1% of the time. Stricter regulation in Japan enforces power spectral density limitations, essentially making ultra-narrowband inapplicable.
Sigfox’s 100 bps data rate is not practical for regular GMSK modulation. This translates into a 2 seconds transmission time for a mere 12 bytes of payload. Because of the ultra-narrowband requirement, it also mandates the use of a very precise crystal, like Temperature-Compensated TCXOs, which are more expensive than regular 20ppm crystals. Besides, such narrowband transmission is the worst type of interferer for other systems. A single Sigfox device could already interfere with any wideband system. If you consider thousands of Sigfox devices, which do not implement any fair use, collision avoidance and Listen Before Talk mechanisms.
The narrow band also makes it difficult to recover the data from the base station as the result of frequency error. Current Sigfox deployments are only one-way. Enabling two-way communication is quite challenging if possible at all. One-way communication means no acknowledgement. This means that an application can only achieve reliability by retransmitting the same data many times in case the applications did not receive it in the first place. Always transmitting 3 times, for instance, directly translates in a 3x power consumption increase, which is very inefficient for resource-constrained devices.
Relying on high sensitivity, i.e., low received power, to achieve communication in a shared frequency band is most likely bound to cause reliability issues. Although Sigfox system can theoretically achieve km range, in practice any legal and regulation-compliant system using the same spectrum and that are deployed nearby a Sigfox device, or even worse a Sigfox base station, may be enough to jam the Sigfox network.
Sigfox’s data rate is so low that even sending the smallest of data, for instance 10 bytes of information, requires a transmission time of about 10 seconds. This means the probability of collision with other devices is increased. In addition, the power consumption is high as the transmitter consumes roughly the same whether it operates at 10 bps or 100 kbps, but it has to be on for 1,000x longer, resulting in 1,000x higher energy consumed.
Such a low data rate and long packet duration, several seconds compared to typically milliseconds, make Sigfox extremely sensitive to frequency inaccuracy and interference. In particular, mobility is almost impossible, and experiments have shown that communication is unreliable over 6 km/h pedestrian speed, and may have issues with the speeds of cycling or running.
In short, Sigfox would not be a feasible IoT protocol for fast-moving and resource-constrained IoT devices that need to communicate at high data rates.