Definition
Sigfox is an Ultra Narrow Band (UNB) LPWAN technology launched by the French company Sigfox, operating in unlicensed ISM bands (e.g., 868MHz in Europe, 902MHz in North America). It uses DBPSK for uplink and GFSK for downlink, with a single frame payload of only 12 bytes and a limited daily transmission (typically 140 messages/day), achieving ultra-low power consumption and ultra-long range (several tens of kilometers in suburban areas). Along with LoRa and NB-IoT, it is a mainstream LPWAN technology suitable for sensor scenarios that require extremely low data rates, massive connectivity, and predominantly uplink.
Technical Features
- Ultra-narrow band modulation: 100Hz-level bandwidth, strong anti-interference and penetration capability, high reception sensitivity
- Operator-level RC network: A global network operated by Sigfox, terminals do not need to build gateways and can use immediately
- Predominantly uplink, limited downlink: Only 4 downlink messages per day, about 8 bytes each, suitable for one-way telemetry
- Ultra-low power consumption: Short transmission time, no connection establishment needed, battery life can last for several years
Comparison with LoRa and NB-IoT
Sigfox uses a proprietary protocol with carrier-grade networks, complementing LoRa (which allows building private networks). Compared with NB-IoT, Sigfox has no mobility, no voice, and no IP connectivity, but it has low deployment and terminal costs, making it suitable for pure sensor reporting scenarios. When choosing among the three, one must balance coverage, speed, power consumption, cost, and whether cellular roaming is needed.
SimtoLink focuses on cellular IoT (NB-IoT, Cat.1, 4G) and provides a differentiated solution compared to non-cellular LPWANs like Sigfox. For scenarios requiring domestic roaming, mobility, two-way communication, or integration with carrier private networks, SimtoLink recommends a cellular solution; for pure sensor, extremely low-cost, fixed deployment scenarios without roaming needs, Sigfox and similar solutions can be considered as complementary. The SimtoLink cloud platform supports multi-protocol access, facilitating unified management of heterogeneous devices.
Ultra-Narrowband Squeezes a Frame into the Order of a Hundred Hertz
The core of Sigfox is an extremely narrow bandwidth. The uplink uses differential phase-shift keying and occupies about a hundred hertz, concentrating energy in a very narrow slice of spectrum in exchange for receive sensitivity and a longer distance. One frame can carry only twelve bytes of application payload. The message format is fixed by the protocol. It is not an IP packet that can be extended at will. When the device transmits, it usually sends several times, with the frequency slightly offset, and uses time diversity against fading and collisions instead of setting up a connection that is acknowledged. Downlink uses GFSK. Both the window and the count are limited by the protocol. A common allowance is only a few messages a day, about eight bytes each. So this is an uplink-first telemetry link, not a symmetric two-way network.
On the network side, the operator deploys base stations and delivers messages to a cloud callback. The device does not form its own network, and it does not hold a routable IP address. That is different from a spread-spectrum network that can build its own gateways, and different from a cellular bearer. With no local base station, a module that is otherwise fine still cannot deliver into the platform.
Only Sparse Uplink Fits Inside the Daily Allowance
The conditions of use are narrow. One report has to fit in twelve bytes, the number of messages per day has to stay under the contract and the regulatory allowance, and downlink is at most an occasional acknowledgement or a switch. Meter readings, alarm bits, and simple counts fit. A device that needs firmware delivery, frequent remote parameter changes, voice, or any TCP session does not. Duty cycle on the unlicensed band and regional certification also have to match the country of deployment. European and North American frequencies and certifications cannot be mixed.
Because there is no IP, platform integration hands the payload to the application by callback, and the application parses the twelve bytes itself. Delay depends on when a base station receives the repeated frames and on whether the callback is open. It cannot be held to a cellular bearer delay. Downlink can be delivered only while the device has a receive window open, and that window follows an uplink. The platform cannot wake the device at an arbitrary second. If the service later needs IP, choose cellular or LoRaWAN. Do not split a long message into fragments spread over many days at the application layer.
Treating a Confirmed Downlink as an On-Demand Recall
A common mistake is to use up the allowance at “more than a hundred uplinks a day” and then have too few downlinks left for one parameter change. When the device fails it cannot be recalled. It can only wait for the next report it sends on its own. Another mistake is to ignore the repeated transmissions. Several copies of the same reading arrive in the cloud, and an application that does not deduplicate counts them as several measurements. If variable-length text is also stuffed into twelve bytes, the extra is truncated. The platform sees incomplete data and gets none of the error indication TCP would have given.
Coverage contracts are also often written from open-air distance. Where base-station density in a city is not enough, three repetitions still do not all arrive. First confirm that the network really exists in the target area, then measure the actual arrival rate and the deduplication of repeated frames. Do not look only at the module’s transmit current. Treating this link as a cheap substitute for cellular IoT, while still requiring commands at any time and over-the-air upgrades, means the whole batch is reworked after the pilot.
When several repeats of the same reading arrive in the cloud, the application has to deduplicate by device and sequence number, or a counting service is inflated. Put variable-length text into twelve bytes and the overflow has no transport error to return. The platform only sees the truncated content. After daytime debug commands use up the downlink allowance, an emergency shutdown in the evening has no window. Monitor daily uplink count, repetition count, and remaining downlink allowance together. With no local base station, a normal module current only shows that it is transmitting. It does not show that any server received the payload. Count callback outages and air-interface failures separately, or a platform fault is recorded as insufficient coverage. Count repeated frames only after the platform has deduplicated them, or the same reading is counted more than once.