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

#News(IoTStack) [ via IoTForIndiaGroup ]

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.

1. 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.

1. 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. 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.

Read More..