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.