Low Power Wide Area Networks (LPWANs), like Sigfox and LoRaWAN, are uplink optimized for a reason. They are fundamentally data mining operations. Updating firmware on low-power devices connecting to these networks requires a lot of downlink traffic that will congest the network. And multiple solution vendors operating on the same network can't tolerate a congested network. So what are these problems?
1. Channel Capacity
LPWAN gateways - whether on residential rooftops or central towers - must accept data from potentially 1000's of devices on the same channel. Occupancy of this channel by any one device will have a negative impact on the gateway's capacity, so devices are designed to minimize channel occupancy with short, infrequent messages. Similarly, the gateway or central tower must also keep its transmissions on this channel to a minimum to keep capacity levels acceptably up. Remember, this is primarily a data mining operating, not a device management service.
When the gateway is transmitting, it is guaranteed that not one single device will get its message through. Devices must get their data through, hence, gateways must not transmit. Really, they should not. A little feedback is good; I think gateways should come up with a protocol for "broadcast acknowledgement" - some sort of bitfield that all devices can reference to determine if they are getting their messages through or not. Currently LoRaWAN specifies a downlink transmission feature for individual nodes that occurs in one of two time slots following an uplink transmission. For each transmission by the gateway to one node, not one single node can send successfully, and they will not know it.
2. Vendor Independence
This is actually the bigger problem. A business problem, not a technical one. On a given LoRaWAN network deployment, there will be devices from multiple vendors. All they have to work with, in common, is a protocol specification by the LoRa Alliance. This specification does not contain a firmware update protocol, let alone what kind or size of payload is to be sent. Any two vendors will invariably come up with their own in-house firmware update system, that will transfer some or all of the firmware image bytes that need to reside on the device. This system will have to comprise some sort of cloud management solution outside the scope of any LoRaWAN network operation. The cloud management solution will need to track each device, offering the vendor the option to update one, some or all of them. Listen closely. Vendor A's potential update of all of their devices will need to work simultaneously with vendor B's and C's regular device operation. In fact, vendor B and C would be highly agitated if Vendor A's firmware update operation affected their value proposition in any way. So much so that I believe Vendor B and C would not tolerate a single transmission from a gateway intended solely for Vendor A's device firmware update, because this single transmission will likely cause at least one of their own device's transmissions to be lost.
Device and solution developers want maximum uplink capacity for their devices. Their solutions depend on it. Firmware updates will be a challenge over LPWAN's because they are data mining operations first and we must treat them that way. We will have to come up with clever out-of-band device management schemes that don't impair the uplink performance of the LPWAN network.
That said, the LoRaWAN Alliance and innovative member companies are working on ways to perform firmware updates, primarily useful on closed networks due to the issues described above.
I have previously blogged about The Things Network FOTA approach for LoRaWAN networks. This firmware update system is based on open source work by ARM for the mbed platform. And TrackNet has announced it will soon open source its FOTA update system for LoRaWAN devices, likely based on this prior work by ARM.
Firmware Modules is evaluating these systems and will continue to make improvements to its leading IoT firmware deployment system in the IoT Firmware Core product line. Firmware Modules' IoT firmware deployment system embeds a stream of tokens in the firmware update image that allows for on-board regeneration of relocatable firmware images so that an external flash part is not required for robust dual-section application updates. In other words, the firmware is put down in flash where it will be executed, all without disturbing a running, good firmware image. No verified image transfer from one flash area to another is required by a bootloader, greatly simplifying the bootloader design and entirely eliminating the risky act of erasing known good firmware.