Multicasting and Firmware over the Air (FOTA)


#1

Hi:

Does anyone know about the latest efforts by the Alliance to standardize FOTA and Multicasting? We have heard that both are being actively discussed and may even be released in the next few months.
We are currently using the Lora Server for all our experimental setups and have been very happy with the results so far. However, our applications (AMI) requires FOTA for LoRa to be a viable alternative to existing technologies.
Hopefully this is an area the Project can take up sometime in the near future. Maybe it is already on the way :slight_smile:

Sameh


#2

As soon as this has been standardized, I do agree that this would be beneficial to support as part of the LoRa Server project :slight_smile:


#3

Hi brocaar,

is there an update since the last post?
Or can you estimate when a FOTA will be possible with the loraserver project?

HasiFlo


#4

I’ve just merged multicast support into the master branch of LoRa Server. Support for multicast support for LoRa App Server will be merged later today or tomorrow into the master branch :slight_smile:

This will be the first “building block” to also work on support FUOTA. If one of you is interested in testing multicast support, please let me know.


#5

Multicast support has also been merged into the lora-app-server master branch :slight_smile:


#6

Hi, is this included in the last docker images release or I need to run it from sources? I am currently using your docker-compose install method.
I have xDot and mDot modules which has a FOTA firmware example but waiting for the required external SPI Flash memory chips “AT45DB161E-SSHD-T” to start testing.


#7

Yes, multicast this has been released, also as a Docker image. Please share your experience with FUOTA @lgarellivates!


#8

Hi brocaar,
I’m working on a work project that would benefit from multicast (rather than peer-peer).
Is it possible to use/send multicast from a node (mDot) to other mDots? I’m guessing this would not work with channel hopping, unless a multi-channel gateway was used?
I think the only way for nodes to multicast is to have multi-channel gateways all connected through some network/backbone?
Looking forward to hearing back :wink:


#9

Multicast is from network-server to multiple devices. Device to devices is not standardized. Or you could send from a device to the end-application (uplink) and then let the application schedule a multicast downlink.


#10

Do you believe that the code could be modified to allow node -> node multicast?
Do you think (there is any chance) the above could be done without scheduling (instant/real-time)?

I tried to compile the example using mbed-os 5.7 (5.7.7), but ‘timeSinceLastFrag’ was not defined, so I commented-out the conditional definition:
//#ifdef FOTA
int32_t timeSinceLastFrag();
//#endif
and it worked.


#11

Now that MultiCast is supported does anyone know if anyone has successfully created a firmware upgrade implementation using LoRa server IO?

Also probably a question for mBed forum but does anyone know if mBed OS supports delta upgrades and if a decent algorithm is implemented?


#12

We (Arm) have published the latest version of the firmware update client for Mbed OS, which is on-spec with the now ratified LoRa Alliance specs. In addition I’ve added a script that uses loraserver for an actual update: https://github.com/armmbed/mbed-os-example-lorawan-fuota

(Although only now I see that @brocaar already implemented the multicast spec, so someone should fix my script :wink: ).


#13

This video (by @janjongboom) demonstrates the FUOTA example using LoRa Server:


#14

Since the first time I’ve seen this, I’ve had to wonder how this is feasible on lorawan, considering the duty cycle restrictions that exist. It just would take a long time with large delta changes of the binary.

I had a thought of doing this by just entering a plain lora mode and simply broadcasting segments.


#15

@txf, Let’s take SF9, 125 KHz on EU868. Delta update size of 8K, 5% packet loss. Max payload size is 110 bytes with 595 ms. Tpacket. This gives 82 packets required (10% redundancy packets used) for a total of 48 seconds transmission. Duty cycle at 869.525 MHz is 10%, measured per hour, so well within the 6 minute limit. Add some prioritization in the mix for the downlink queue to not avoid missing RX2 windows, and you’re maybe looking at 2 minutes for sending the update. During this time there’s no transmission from the end-devices that are updated, so no duty cycle limitations in place there. Other bands (US915) have even less issues, can use dedicated update band, and only need to adhere to 400 ms. dwell time between packets.

I had a thought of doing this by just entering a plain lora mode and simply broadcasting segments.

Which is very similar to what we’re doing. We’re also broadcasting, and as fast as possible, but with additional security features and forward error correction in place. Also in a standardized manner, which is important if you want to deploy this on other networks.


#16

Hmm.

When you put like that, then that does seem feasible.


#17

Now that ARM has implemented this feature in their Mbed stack, I’m looking forward to finally integrate FUOTA into LoRa App Server. I’m looking forward to feedback on how you think you would use this feature.

So far, I’m thinking of adding support for the following options:

  • Upgrade an individual device. E.g. you would click on the device within the web-interface and upload the new firmware which would trigger a FUOTA process for this device only.

  • Upgrade all devices within an application. E.g. you would click on an application and upload the new firmware. This would then trigger a FUOTA profess for all devices within the given application.

Feedback is welcome :slight_smile:


#18

Awesome, I’m trying to use multicast to update groups of end devices, but I need delta update due to my large firmware. Could delta updates be considered in the LoraServer FUOTA? Like, one way to send all the firmware in case of critical failure, and another way to send only the patch.


#19

I believe LoRa App Server should not be aware of what it is sending, e.g. a full update, delta update, … This is application specific and also depends on what the application and / or bootloader of the device supports. So in short, yes, you would be able to use the FUOTA to do delta updates, given that your device supports this :slight_smile:


#20

Any news? How are you proceeding with FUOTA implementation?
Keep up the good work!