Issue link: https://read.uberflip.com/i/1428347
FUOTA Process Summary Technical Recommendation ©2019 LoRa Alliance™ Page 8 of 11 The authors reserve the right to change documents without notice. compression mechanism used by the image, etc.) and a digital signature using a private/public key scheme (used to authenticate the image). The image is signed using the FUS private key. Create the list of fragments (the fragment file). 3 FDS- NS Negotiate with the NS a Class C or Class B distribution window. Parameters include the list of end-devices, the size of the fragment file to send, time criticality, coding redundancy, etc. 4 FDS If necessary, configure the multicast group using applicative unicast downlink for all end-devices to be updated. (multicast address to use, key material) [McGroupSetupReq/Ans] 5 FDS Configure Class C or Class B rendezvous using applicative unicast downlink for all end-devices to be updated. [McClassCSessionReq/Ans]. In the background the end-device MUST synchronize its clock to the network's clock because absolute time is used to define the session start. 6 FDS Setup the fragmentation session for all end-devices to be updated. The fragmentation session setup command contains a freely assigned descriptor such that end-devices, in case of a FUOTA broadcast, can autonomously check that the image is applicable to them and knows where to store it. [FragSessionSetupReq/Ans] 7 FDS- NS Send fragmented file to the NS. 8 NS- Dev NS broadcasts (or unicasts) the fragment file to end-devices to be updated. 9 Dev As soon as an end-device has received enough fragments, it reconstructs the binary image (BLOB). 10 Dev End-device checks the digital signature of the image and authenticates the sender using the FUS public key stored in all end-devices. This step also serves as an integrity test of the firmware upgrade image. 11 Dev End-device checks the image header: 1. Is the image compatible with the end-device's hardware? 2. Is the image compatible with the firmware version currently running on the end-device (the firmware version may be a CRC of the code)? 12 Dev The end-device's application marks the firmware image as "ready". This means that the image will be installed by the bootloader at the next reset. The application may decide to reboot immediately, or may differ the reboot to a later time, or wait for a firmware management command to reboot. 13 Dev The end-device reboots. 14 Dev Bootloader checks the availability of a firmware upgrade image and founds one. Bootloader checks again the CRC of the image, un-compresses the image or delta-image if required. This decompression might happen directly in-place, meaning the decompressed image overwrites the previous firmware image. Or the decompression might happen in a currently unused memory space for end-devices supporting dual-firmware image. If the bootloader overwrites the firmware code memory space, then this update is performed transactionally. ("transactionally" means that flash memory is updated page per page, at each step the content of the page written is verified and the address of the next page to update is written to NVM. This process guarantees that even if the end-device crashes or power is interrupted during the update process, the process will resume where it was left at the next reset). Bootloader marks the firmware upgrade image as installed.