The message container at LPWAN limits the application in the number of possible bytes per transfer. In addition to the physical container, there is always a logical limit. In the European unlicensed band we have one percent duty cycle in the upload. Therefore, only 36 seconds per hour are available for the protocol header and the payload. In the download, the base station of the unlicensed LPWAN is limited to 10 % duty cycle.
NB-IoT & Sigfox comparsion – upload and download
Upload and download restrictions at Sigfox
With Sigfox you are very limited in upload and download. Only 12 bytes six times per hour are available in the upload. The radio module adds 14 bytes of protocol header to these twelve bytes of payload. 6 seconds per message (incl. repetitions) and six telegrams per hour result in the maximum transmission time of 36 seconds per hour. In the download Sigfox provides only 8 bytes limited to four messages per day.
A Sigfox base station works on half duplex. This means that the base station cannot receive anything at the moment where it is transmitting. In addition there is the duty cycle of 10 %. A base station may not transmit for longer than 360 seconds per hour. This means that the download capacity is heavily restricted.
Sigfox modules can only receive after transmission. To do this, it opens a reception window for 20 seconds after sending. So we have a high current for 20 seconds to receive just 8 bytes. The reception mode at Sigfox is therefore extremely energy-hungry.
No limitation in upload and download at NB-IoT
NB-IoT has nearly no limitation the physical message container has a size of 317 bytes in upload and download. Whether you want to transfer 2 bytes 12 bytes 120 bytes 1200 bytes or even 12,000 bytes does not matter with NB-IoT. The NB-IoT protocol then consists of several physical message containers.
Examples for applications and restrictions
M-Bus protocol
With the M-Bus protocol, it is quickly 200 bytes in UL. Many applications require more than 12 bytes. If binary data and compression have been used to store data in 12 bytes, Sigfox can only be used to acknowledge data four times a day.
Pizza with special requests and drinks
An order process for four pizzas with special requests and drinks is difficult to get into 12 bytes. If you manage it anyway, you can only confirm four orders per day. And four is only valid if no receipt is lost. The order of a taxi in the hotel at the push of a button would then only be limited to four taxis.
Agricultural technology with upload and download
The sensors on the farmland must transmit temperature humidity air pressure pH value and much more. The temperature is measured in the soil at two depths and at least once above the ground. In addition there is the multiple measurement of the humidity. You can see that 12 bytes are not enough. If it is too dry you have to switch on the pump. However, a Sigfox device can only receive if it has been sent before. The pump can therefore be switched on four times a day and only if the pump sends six times per hour and opens a reception window after sending. It can be seen that eight and 12 bytes are not the only limitation. The real time and acknowledgement mode are extremely limited. All these limitations do not exist with NB-IoT.
Gas meter with TCP/IP or pay terminal with TCP/IP
With TCP/IP, it is known to increase energy consumption with acknowledgement operation. Gas meters and payment terminals already approved on the protocol will continue to use TCP/IP even with the high energy consumption. A new approval is much too expensive. With payment terminals before certified protocol Stacks are used. NB-IoT supports the energy-hungry TCP/IP, the low-energy UDP/IP and the energy-optimized non-IP operation.
Summary of comparision of Sigfox and NB-IoT
Due to the extreme restrictions, the Sigfox protocol is primarily only suitable for sensors with upload without acknowledgement or with limited acknowledgement per day. Sigfox does not provide a constant receive mode like with NB-IoT. The receipt of receipts requires a lot of energy compared to NB-IoT.
NB-IoT has almost no restrictions in upload and download. The restriction for NB-IoT comes at the end from the network operator. To transfer large amounts of data in upload and download is not welcome. A base station with NB-IoT is supposed to administrate 50,000 participants. larger data quantities means also larger time demand. However, NB-IoT should serve many subscribers with small to medium data volumes in upload and download.
References
Sigfox website https://www.sigfox.com/en/sigfox-iot-radio-technology
Lightweight M2M 1.1 White Paper by Ericsson and T-Mobile https://www.omaspecworks.org/lightweight-m2m-1-1-white-paper-ericsson-and-t-mobile/
Does this article gain your interest? Do you have a wireless IoT idea? Do you plan an IoT device with embedded antennas? Do you have an IoT prototype and have a need for optimisation or price? If your answer to any of these qustions is “YES”. Then do not hesitate to drop an email to harald.naumann (at) lte-modem.com and to ask for an akorIoT radio adapter or some engineering services to make your IoT idea reality.