Firmware-over-the-Air (FOTA) with LoRa

It would be nearly impossible to update device firmware over-the-air (FOTA) using LoRaWAN^TM.

The LoRa Alliance does state that such an operation is possible, though this is referring to multicast frames available in class B and C devices.

Those in the user forums disagree:

The Things Network Forum.

Libelium Forum

Symphony Link^TM, the Link Labs protocol for LoRa was designed with FOTA in mind. More on Symphony Link FOTA below.

• See also: Key Business Benefits of Firmware-over-the-Air

The reason that firmware-over-the-air with LoRaWAN is difficult stem from a few factors:

1. Gateway transmissions are uncoordinated. This means that whatever time the gateway spends transmitting firmware downlink messages, it is not listening to the network. Nodes on a LoRaWAN network don’t know that the gateway isn’t listening, so any message that they try to send during the time the gateway is transmitting will be lost.
2. There is no MAC layer concept to place a Class A node into a mode where it can receive multicast frames. Multicast was added in LoRaWAN to class B/C nodes to enable things like street light control, not really for firmware transfers. What this means is that FOTA for battery powered LoRaWAN devices is not possible, as they cannot receive multicast frames.
3. LoRaWAN gateways are duty cycle limited. LoRaWAN gateways can only transmit 1% of the time (ETSI), and thus probably need all of that downlink resource for acknowledgements and MAC control messages. Very, very little would be left over for FOTA multicast. In the US scheme, where 1% duty cycle limit is not required, the network basically stops functioning for uplink due to #1.

Firmware-over-the-Air using Symphony Link

Symphony provides a mechanism to downlink a file up to 256 KB from an access point to an end node or groups of nodes.  The access point sets the Infrastructure Beacon (IB) period to a large value, providing more downlink capacity for the file transfer. This allows the network to still function for uplink during FOTA operations. Once the transfer is complete, the access point returns to its previously programmed IB period.

Figure 1. OTA file transfer. Initialization to first complete transmission of all file segments

OTA File Transfer Initialization

An example of an OTA file transfer initialization can be seen in Figure 1.  An access point notifies its associated end nodes that it has a new file to downlink.  The access point then pauses and waits for end nodes to respond.  Once user-specified criteria are met (e.g. number or percentage of nodes able to participate, timeout) the access point begins to downlink the file in segments.  

Figure 2. OTA file transfer. Example of file segment retransmission. ARQ to end of transfer.

OTA File Transfer

To increase throughput for the file transfer, an access point downlinks multiple file segments per frame.  This contrasts with other downlink packets, where an access point only downlinks either only one message per node per frame, or one broadcast message per frame.  The end node receives and aggregates all of the file segments received in a given frame.Once an access point is ready to downlink its file, it sends all file segments sequentially and then pauses.  

In Figure 1, the time sequence ends after all of the file segments are transmitted once.  At this time, each end node participating in the file transfer sends a list of file segments not received successfully by that end node.  The access point then assembles a file segment retransmission list based on the requests of its end nodes.  An end node may also request the access point to retransmit all of the file segments.  The access point retransmits the file segments, and the process repeats until all participating nodes notify the access point of a successful transmission or a failure criterion is met.  

Figure 2 shows an example of file segment retransmission and a node reporting a successful file reception.The access point sends file segments as unacknowledged downlink messages.  The ARQ scheme is achieved as nodes report their retransmission requests.

OTA File Transfer Termination

Once a node reports it has successfully received the file to its access point, it stays awake until receiving a command from the access point to apply the file.  In Figure 2, the final event is the access point terminating the file transfer with the “Apply File” command.

Conclusion

The OTA file transfer method can be used to transfer application software, scripts, setting, encryption keys, databases, or Symphony Link module firmware updates. It is a powerful addition to Symphony Link that makes many industrial and enterprise use cases possible.