Sigfox Monarch service is a free global service allowing to determine the zone where a device is located.

By zone location I mean RC (Radio Configuration zone). It basically defines the European Zone (RC1) or the North American Zone (RC2)…

Thank to this technology a world-wide device, having no GPS to get its location, is able to determine its radio configuration and the associated frequencies to use for transmissions.

This service is covering most of the airports and ports around the world to support the existing customer use-cases like Louis-Vuiton tracker and Safecube container tracking.

It would be great if this service could, in the future, be also used to broadcast/multicast information to devices. It could be used to get time from the network and later be also used to transport custom data to the group of devices. But currently it does not transport any data.

In this post I propose to detail the Monarch technology and then, in a second post to see how to use it with the first released devkit from Unabiz supporting Sigfox Monarch.

Monarch service

The Monarch service has been opened 2 years ago to support the Louis-Vuitton project. For this reason the main airports are covered. Now the service as been extended to ports and different cities where goods are transiting. It means you will not have a Monarch service anywhere.

In terms of use-case, Monarch allows an object to know in which zone it is to setup its radio configuration correctly. It means the use-case around Monarch are supply-chain & logistics across zone. Monarch is usually implemented in conjunction with Atlas localization or WiFi localization. These solutions do not permit the device to position itself compared to GPS based system.

The use of Monarch to automatically discover the radio zone for a static device (like smart home, as an example) is not a good idea due to the limited coverage. In a such situation a static configuration, as part of the logistic chain is more efficient.

The Monarch coverage map is accessible in the Sigfox backend. Below you can see a partial view of the coverage for EU and North America.

The coverage is extended by Sigfox based on customer projects and it can also be extended with micro-base-station on customer facilities. As you will see below, it’s not a technical big deal to simulate Monarch from an OOK transceiver if your need to make local device test.

The service is free to use. You need a specific certification of your device if you want to be Monarch labeled. Apparently, regarding the 6-10 month we had to wait between the Monarch module announcement and the end of the certification process, this step is complex. The use of pre-certified modules for getting started with Monarch is really something to consider.

Monarch technical details

Monarch modulation technique

The Sigfox Monarch technical specification gives all the details of this technology. Basically the Monarch signal is a specific beacon transmitted on regular basis by Sigfox gateways.

The Monarch signal is generated by cumulating 12 different carriers signals. Each of them is transmitted with a pre-defined frequency difference (dF). As en example, for a central frequency of 869,505,000Hz and (dF) at 1KHz we are going to have the two first carriers at 869,506,000Hz, 869,504,000Hz (+/-1Khz). This is going up to 869,511,000Hz and 869,499,000Hz (+/-6Khz).

When summed, this type of multi-carrier transmission, is going to create high pics of energy on the central frequency, spaced by the period corresponding to the (dF).

Here, we see the monarch signal received: multiple pics of energy spaced by 1/(dF) period.

During all the transmission, the signal is continuously the same. The high pic of energy allows to have a higher resistance to noise and long range transmission. This allows to achieve a better sensitivity to reach the Sigfox uplink / downlink sensitivity. You obtain, with Monarch, the same coverage as for Sigfox BPSK with something simpler to demodulate.

This signal is really easy to decode. A Monarch receiver is simply using an OOK (On-Off Keying) circuit for de-modulation.

An OOK demodulator is basically an envelop detector: it simply rises to 1 when energy is detected and goes back to 0 when no more energy is detected.

The OOK will return 1 when the previously seen pic of power will be received. 0 otherwise.

This binary signal is really easy to process with a MCU gpio. By searching for a periodic bit stream with a period corresponding to one of the predefined (dF), we can easily detect a Monarch signal.

OOK sensitivity is limited to -126dBm, the specific way described above to generate the signal allows to reach the Sigfox usual sensitivity.

Monarch RC decoding

The Sigfox Monarch frame is composed by 2 signals created that ways. The first signal duration is 362ms. The second signal is 38ms. The total duration of the Monarch pattern is 400ms.

Each of the pattern have a different (dF) value. The first pattern on the left of the following picture id (dF1), the second pattern on the right is (dF2). The combination of (dF1) and (dF2) plus the reception frequency encodes the RC.

The (dF) values have been chosen to be easy to detect with a standard RTC clock synchronized on 16,384Hz or any multiple. There are 3 different possible (dF) values : 1024Hz, 1260.3Hz, 1489.4Hz. The RC encoding is:

RC	Monarch Rx Frequency	dF1	dF2
RC1	869,505,000	1024Hz	1260,3Hz
RC2	905,180,000	1024Hz	1260,3Hz
RC3	922,250,000	1024Hz	1260,3Hz
RC4	922,250,000	1260,3Hz	1489,4Hz
RC5	922,250,000	1024Hz	1489,4Hz
RC6	866,250,000	1024Hz	1489,4Hz

Monarch beacon periodicity

Every Monarch enabled base-station sends a beacon every 5 minutes. There is a 10 second random time around the 5 minutes to reduce collision risk between the multiple base-station emitting the beacon around.

All the Sigfox base-station are in sync world-wide. As a consequence, once a device has received a beacon it can wake up shortly before the Monarch emission to update it’s location.

On this diagram, we can see the 5min transmission from 1 gateway, sent in the 10s random slot. The device can see multiple Monarch beacon during this 10s slots coming from different base-station around.

All the base-station around will not transmit the Monarch beacon to reduce the collision risk.

The Video above is a Sigfox Monarch beacon capture. You can see 3 beacons coming from 3 different antennas around, all sent within the 10s time slot. On each of the beacon you can also see the 12 different frequencies used to encode the RC (dF1). You can notice a frequency shift at the end of the transmission corresponding to the second frequency (dF2).

Monarch on the device side

Scan different frequencies

On the device side, you need to take the frequency dimension in consideration. As the device do not know in what RC it is, the beacon can be received on one of the 4 different frequencies seen previously. Monarch allows to scan up-to 6 different frequencies to support later coming RC. The device will perform frequency hoping during the beacon listening phase. The number of scan frequencies depends on your wish to support some or all the different zones, from 2 to 6.

The device is scanning the frequencies all over the different bands during 38ms each time ; it can be less if your design is able to detect the signal quickly. There are different scan mode depending on the number of band you want to scan. You can refer to the documentation attached at the beginning of this post.

There is also different way to confirm the reception and avoid false positive detections.

When looking at a Sigfox Monarch power consumption we clearly see the 38ms channel hoping.

In my experience with some of the first Monarch devices, I learned firmware design is a key point. Monarch can become the first factor of your power consumption if not correctly implemented. A Monarch full scan, 5 minutes, is 4,7mWh power on the tested hardware.

Optimise your code for power consumption

In this exemple, the radio scanning is always activated, we see no sleep time. But as only 4 frequencies are actually defined, the implementation could have implemented short deep sleep sequence and save 33% of the consumed energy.

So my first recommendations to implement Monarch in a device are:

• When you failed 2 times getting a Monarch beacon, do not try again before any interesting movement.
• When you get a Monarch signal, use your local clock to reduce the next Monarch beacon scan windows.
• Only scan for Monarch when you really have good reason to consider a zone change.
• Why not making quick scan just to refresh the clock sync on regular basis.
• A downlink cost may be lower than a Monarch scan when clock is out-of-sync.

You need to always have is mind Monarch coverage is limited by the number of base-station where it is activated. As a consequence, most of the time the search will fail. Then, your device may not boot the first time in a covered zone, you need to take it into consideration.

Conclusion

Monarch is a really great Sigfox feature and what I love with it is its openness. This technology can be used by other LPWAn like LoRaWan for the same exact purpose.

We have seen, the way the signal is encoded and the simple way the signal is decoded and process to determine the radio configuration. This is the Sigfox touch: managing the complexity on the network side with asymmetric technology to make the device the simplest as possible.

However, simple hardware do not means software engineers will have a peaceful job: the Monarch complexity is on the way you manage the beacon non reception in the large uncovered zones. Dedicated algorithms, your secret sauce, will make the difference.