Sigfox downlink in details

The downlink process is the way a sensor can receive data from the network. This process is really useful if you need the device to execute an action or if you want to change the sensor behavior.

This post is as some other of my LpWan series a video post in French completed by this text post in english.

 

The donwlink process is a way a sensor can receive a data coming from the network / from the end user application. As the IoT is energy sensitive a device is not able to receive data at anytime otherwise the reception would consume all the battery energy really quickly. For this reason the application backend will have to store its message for the device until this one will initiate a communication with an uplink.

The backend will only be able to transfer the downlink message when the uplink will include a ack flag corresponding to a downlink request.

 

Sigfox downlink conditions

When the device add this flag to its communication, it will switch in reception mode for the next 30 seconds.

Downlink and service callback

During this time  the sigfox network will decode the uplink message, execute the callback to the applicative backend. This one will have to return the downlink message to the sigfox backend. Sigfox will assign the message to the best base-station to proceed to transmission.

The transmission of the downlink message is executed on the 869Mhz band where the duty-cycle is 10% and the transmission power can reach +25dBm to let your device the maximal chance to get the message even if its environment is less favorable than the network antenna for receiving radio signal.

The reception requires a good antenna and also an environment with an acceptable level of noise on 869MHz. In fact, the reception sensitivity of your device is generally lower than the one of the network, something about -126dBm instead of -146dbM for the uplink. The network will choose the best antenna as possible but is depends of its duty-cycle capability. On another hand your device can be exposed to local noise and when this noise is higher than the signal noise it will be hard to capture the message.

Sigfox downlink & ack

The sigfox backend will then confirm the transmission to the device by firing a service callback to the applicative backend. This callback doesn’t mean the device received the downlink, it just means it has been transmitted.

The device, will confirm the reception of the downlink with and OOB message. This is a technical ack to the sigfox network containing the rssi. This message is unfortunately not reported by the sigfox backend. It just consume some of your duty cycle. It sounds it is not considered as reliable as the repetition is set to 0. By-the-way, even if not reliable it is nice to get it when it has been fired.

This message is incrementing the Sigfox sequence number so a way to know if the downlink has been received is to identify a Sigfox sequence rupture during the next transmission.

Because this solution is not fully reliable I think the best way is to add a functional ack in your firmware to confirm reception and downlink execution:

Downlink confirmation

This applicative ack is developed in your firmware and generate a callback you can directly manage in your application to give a feedback to the end-user.

 

 

 

 

6 thoughts on “Sigfox downlink in details

  1. Hello,
    Si finalement c’est le device pour qui s’est important de connaître le changement d’état (et pas forcément l’utilisateur du front end applicatif), le flag spécial au moment de l’uplink pour prévenir de porteur du produit du changement d’état est suffisant, non ?
    L’applicative ACK est une bonne solution dans le cas où c’est l’utilisateur du front end applicatif qui a besoin d’être informé d’un changement d’état.
    Je me trompe ? 🙂

    • Not only in this case, the problem is to be sure that the device has apply the downlink. As you will never be sure a message has been transmitted or not you will never be sure the downlink has been proceeded. You have different way to do that functionnal ack is one of these. You can base this on siqseq number as the tech-ack will increment it, you can add a counter in your frame to check in later communication if it has been incremented by downlink process or not … many ways.

  2. Pingback: 35C3: Hacker zeigt Schwachstellen in IoT-Netzwerk Sigfox auf » LinTeum Computertechnik uvm.

  3. Pingback: No ! Sigfox is not removing duplicates - disk91.com - technology blogdisk91.com – technology blog

  4. Pingback: Stop telling me Sigfox is clear payload, for real you're just lazy ;) - disk91.com - technology blogdisk91.com – technology blog

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.