We are no longer used to saving data. Bandwidths are constantly increasing, which is why hardly any attention is paid to clean HTML source code or pure text messages today. However, there is enormous market potential in limiting the new public 0G networks to just a few bytes. Fewer bytes mean less energy for data transmission and less payload also costs less money and also creates space in the communication channel for additional subscribers. This in turn saves costs for the infrastructure so that services can be offered more cheaply. It is precisely in this low-end, high-volume market that Sigfox's ultra-narrowband 0G network is positioned in order to connect all those things to the Internet that could not be connected until now because 3G/4G/5G broadband is too expensive, requires too much energy and cannot be used globally without roaming charges.

Strong in widely distributed infrastructures

Whether Microsoft Azure Cloud for Predictive Maintenance, Siemens Mindsphere Cloud or Cumulocity, they all support Sigfox's 0G network and connect to the Sigfox Cloud, which is hosted in Europe by Thales and is one of the most secure clouds in the world.

© Sigfox Germany

There is therefore a large market for the new 0G network in things and infrastructures that are often distributed across borders - from container and load carrier monitoring solutions to smart metering and monitoring the operation of pumping stations in the water supply. The charm of 0G logic for smart sensors and actuators of all kinds in such distributed systems lies, among other things, in the maintenance-free network connection, as there is no need to change batteries. Ultimately, for OEMs, they are nothing more than globally distributed devices that need to be monitored and managed centrally for better customer service.

Small messages, big benefits

12 bytes or 96 bits are only part of the overall communication stack. There is also a Length Indicator (LI), a Bidirectional Flag (BF), Repeated Flag (RF), a Message Counter (MC) and an Identifier (ID).

© Sigfox Germany

Sigfox can send up to 140 messages a day from devices of all kinds to IoT clouds (uplink) and four back to the device (downlink) for setting commands, parameterizations or function activations. However, the payload of the messages must not exceed 12 bytes. This is not a lot, which is why the network connection is also very energy-saving and inexpensive. With 12 bytes, however, 2 to the power of 96 different values can be represented. That is 79 quadrillions of different states. To clarify: a quadrillion is a number with 27 zeros before the decimal point! With this diversity, it should be possible to describe any system state with sufficient precision. Even complex global GPS coordinates only need around 6 bytes, so that the monitored objects can be localized precisely if required. But what solutions are there for transmitting various measured values, for example, if these add up to more than 12 bytes in purely mathematical terms?

Dos and don'ts when packing data

The data compression methods currently available are not very useful, as they hardly achieve any savings with the already very small data packets. The overhead of these algorithms is often greater than the savings that can be achieved with 12 bytes.

It also makes no sense, for example, to transmit only the small changes in relation to the previous position for geodata, because if the message with the first complete geoinformation is lost, the subsequent data string can no longer be reconstructed. For systems that would then allow alternative fallback access to the source data, this would not be the end of the world, but it is certainly better to design the system from the outset in such a way that it is not necessary to fall back on alternatives. For this reason, stateless communication, i.e. communication without reference to previous packets, has become established in message processing for 0G networks. No session information is exchanged and/or managed either.

However, it makes sense to split messages that are larger into several data transmissions using splitting procedures and to reassemble them in the cloud. If the existing data does not correspond to the 12-byte structure, it can be expanded using suitable bit and byte sequences.

Avoid redundancies

It also makes sense to reduce redundancies and optimize entropy, for example by no longer programming into the message that it is sensor x or machine y that is currently reporting here. It also makes no sense to send the type of value being transmitted, for example temperature or speed. This is because the devices already receive a unique identification in the cloud via the Sigfox ID, in which the assignment can be defined.

Unlike with Ethernet data packets, another tried and tested method is not to use a fixed data width. Instead, only the bit depth required by the measured values is used. For example, 7 bits (27 = 128) are sufficient for temperature values from -20 to 100 °C. This allows the payload of the Sigfox signal to be optimally utilized. This principle can also be used for yes/no values. If only the on/off information for six inputs has to be transmitted, this does not have to be coded in one byte, but only requires 6 bits with the appropriate set of rules. This means that this information can be transmitted together with only 13 bits. This saves 3 bits compared to pure byte values, which can be used for other data. In addition, the possible measured values can also be segmented into ranges, allowing the data to be communicated in a few message clusters instead of large numerical values with endless decimal places.

Not always explaining the whole world

It is also advisable not to transfer the geodata 1:1, but to reduce it logically in blocks, which saves bits as the area to be displayed is reduced. This can be useful for devices that do not leave countries or continents, for example. Because future GNSS chips will enable increased accuracy by evaluating the E5/L5 signals, these savings can then be used there. It also makes sense to create a specific table of states - ideally sorted by expected frequency - in order to assign shorter bit sequences to them. This procedure is called Huffman coding.

Set priorities!

If all these measures are not sufficient, messages can also be prioritized so that only the most important data is transmitted immediately if a threshold value is exceeded and other data is sent later. For example, data that is less critical can only be transmitted weekly or monthly, which, with 140 messages per day, leaves plenty of scope to transmit even the most exotic values to the cloud in order to collect all the necessary information over a slightly longer period of time. An "I am active" message can also be omitted entirely if other status information is transmitted regularly.

For complex predictive maintenance applications, it is also necessary to implement edge analytics anyway, for example to correctly interpret machine vibrations. Streaming such complex, sometimes gigabyte-sized data live in real time to central clouds rarely makes sense, at least for predictive maintenance, and is generally only of interest if the AI algorithm of the inference system is to be trained further in deep learning clouds. The message: The axis is now warped to such an extent that the CNC machine is no longer working within the tolerance range, but fits easily into 12 bytes.

Use memory on the Edge

Some customers also use local storage space for their data, which they read out via the BLE interface during maintenance work in order to then collect the complete data records via such complementary channels. For the simplest mobile IoT devices, such as charge trackers, it is often necessary to clarify how much flash memory the microcontroller used should have to store the data, as this is comparatively expensive for MCUs. For more complex embedded systems that are operated with larger ARM or x86 processors anyway, however, this memory issue is generally negligible, meaning that walk-by solutions consisting of a BLE interface and Sigfox as the primary reporting channel for the most important usage and predictive maintenance messages are an excellent combination, even for more complex devices.