Sigfox Network Operators are rolling out the first global 0G network to listen to billions of objects broadcasting data, without the need to establish and maintain always-on network connections.
This is a unique approach in the world of wireless connectivity, where there is no signalling overhead, a compact and optimized protocol, and where object is not attached to the network.
The Sigfox technology offers a software based communications solution, where all the network and computing complexity is managed in the Cloud (Sigfox Backend), rather than on the devices. All that together, it drastically reduces energy consumption and costs of connected devices.
An uplink message has up to 12-bytes payload and takes an average 2s over the air to reach the base stations which monitors the spectrum looking for UNB signals to demodulate. For a 12-byte data payload, a Sigfox frame will use 26 bytes in total. The payload allowance in downlink messages is 8 bytes.
Using the Ultra Narrow Band modulation, Sigfox operate in the 200 kHz of the publicly available band to exchange radio messages over the air. Each message is 100 Hz wide and transferred at 100 or 600 bits per second a data rate, depending on the region. Hence, long distances can be achieved while being very robust against the noise.
The Sigfox protocol stack is the software used by connected devices modem to generate radio frames and thus transmit messages over the Sigfox global network. The Sigfox protocol stack is provided free of charge to modem manufacturers. It is embedded in millions of chipsets, system on chips or modules. No royalties are charged.
Sigfox uses 200 kHz of the publicly available and unlicensed bands to exchange radio messages over the air (868 to 869 MHz and 902 to 928 MHz depending on regions). Sigfox uses Ultra Narrow Band (UNB) technology combined with DBPSK and GFSK modulation. Each message is 100 Hz wide and transferred at 100 or 600 bits per second data rate, depending on the region.
The small footprint of UNB enables more simultaneous signals within the operation band, in addition Sigfox protocol cuts down the radio frames size. Those two features combined with the use of cognitive radio technology enables the Sigfox network to reach a very a high capacity.
A device is not attached to a specific base station. Its broadcasted messages are received by any base station in the range, which is 3 on average, and there is no need for message acknowledgement. Spatial diversity coupled with time and frequency diversity of radio frame repetitions lead to high quality of service of the Sigfox network.
Security comes with devices first. Security is also supported by radio technology. The communication between the base stations and the Sigfox Cloud, as well as the Sigfox cloud itself are secure, robust, trusted and scalable. At the chain end, IT platforms of customers are connected to the Sigfox Cloud using HTTPS encrypted interfaces.
The downlink process of Sigfox brings additional security robustness. When objects have their ears closed they can’t listen to anything that might be sent by a hacker. The fact that the objects choose when to communicate and at which frequency is protecting them from a hacker sending them a misplaced, unattended command.
The Sigfox backend uses an architecture based on Groups/ Sub Groups – Device Types – Devices. Every device has a unique ID which stays with the device for life. A PAC code is also required to register a device on the Sigfox Backend. The PAC code changes with a change in ownership. Once you have a live Sigfox Contract associated with your backend account, you are ready to begin using the completely self-managed service.
The first step is to create a ‘Device Type’. Each Device Type can be attributed to a "family" of devices. After the Device Type is created you can now add devices one by one, or as a series. Once added successfully, you will now see any messages that are transmitted from the device. No other steps are required.
Callbacks are the mechanisms used to deliver device data and information from the Sigfox Backend to your platform, where the messages can be decoded and visualised. Callbacks are linked to Device Type’s, and they will be triggered every time any device of a Device Type sends a message. Every device in a Device Type will have the same Callback behaviour. From a technical perspective: Callback queries are HTTP requests which are notification messages (one-way only). For more detailed documentation click here.
The Sigfox REST API is designed for device management rather than a mechanism for delivering device data. REST API queries are HTTP requests which are bi-directional and work at the Group level: your server can request and receive data from Sigfox Cloud through the API. The REST API allows you to automatically register and manage all your devices on the Sigfox Cloud, including their subscription lifecycles. This way, you don't have to connect to the Sigfox Backend website to perform recurring device management operations. For more detailed documentation click here.
