Multicasting and Firmware over the Air (FOTA)


#21

I really appriciate that FUOTA comes to this greate project!

Still, open questions for me are:
Think of a big deployment of heterogenous nodes, where heterogenous means different nodes from different vendors, as well as same nodes on different firmware versions.

The first scenario can easily be manage via applications: just put separate device types into different applications.

But, how would you manage the second scenario?
Would you move devices on different firmware versions between applications?
Would you manage versions in loraserver.io directly?
What if you do not know the firmware version a priori?
What if updating fails for some of the devices, e.g., due to a bad connection?

I know that some (if not all) of these questions have to be answered/handled within the application. But what will happen then? Will everyone implement its own update process? How will the management of those different processes be done? How will the LNS handle this ressouce consuming so that the network can still work?

To do this intelligently (things like prioritizing downlink capacity, gateway aware multicasting, …) the either the application of the LNS needed information of the other party which they currently do not have.

If it was up to me, I think I’d propose a new component (something like a update server) which would handle the firmware related things like versioning, prioritizing, etc. Maybe it would be tightly coupled to the LNS to do things intelligently, maybe it only uses the specified functionalities for multicast, fragmentation, …
I think for now, however, there is no specification on how the actual update process will take place, which makes such a component a thing of the future.
(I’m not even sure, if specification of an update process is even possible, if we consider the different requirements which arise from different deployments.)

As far as I know, the LoRaAlliance only specified how multicast groups are setup (LoRaWAN Remote Multicast Setup Specification v1.0.0.), how big data packets can be fragemented and sent via these groups (LoRaWAN Fragmented Data Block Transport Specification v1.0.0.), and how colock synch can be done, so that all devices can agree on the start of the multicast session.
There are proposals of how firmware files and update processes should look like (I’ve seen documents from mbed guys, as well as semtech; the latter one even tries to describe what specific tasks have to be done by which participant of the LoRaWAN infrastructur (interestingly, they propose a US (update server) as well, as they also seem to have undertood, that updating is not that trivial).

To make things short:
I think your porposal to upload files directly to (either device or application based) will only work for very simple deployments but it might be sufficient for the first shot.
To make this thing usable in real world environments, it takes a lot more -> a new update server component should be implemented, which handles this stuff.
To enable other parties to implement such server, the LSN should provide some APIs for the currently specified functionalities (Multicast, Fragmented Downlinks, …), so that these features can be used comfortably by a separate component and concerns can be separated cleanly.

Btw., are you aware of any resources or a specification which may cover (parts of) my questions?


#22

I agree that per device or application is a simple implementation. It is a first shot and I think we all need to see how the FUOTA is going to move forward. Please note, the whole FUOTA implementation is implemented in the application-layer, thus you could already create your own separate update server :slight_smile: I believe the only APIs you would need are the multicast-group and device-queue APIs which are already available.

I’ve already open-sourced the modules that you can use to create the multicast-setup / clocksync and fragmentation-session payloads: https://godoc.org/github.com/brocaar/lorawan/applayer.