In the connected world, firmware updates are necessary to secure and prolong the life of IoT edge nodes. This blog demonstrates the firmware updates for LoRa nodes over LoRaWAN protocol. At asvin BeeHive, we have incorporated the LoRaWAN FUOTA feature in our IoT update platform. The network architecture devised for firmware updates is depicted in the diagram below.
LoRa Node
The L-Tek-FF1705 LoRa device was used as LoRa node for the proof of concept of our end-to-end solution. The board contains MultiConnect xDot module which consists of STM32L151CCU6 microcontroller, SX1272 LoRa module and an external flash memory of 256KB for storing the firmware fragments. The device runs the Mbed OS enabled applications. The applications implement multicast firmware IoT updates over LoRaWAN for Mbed OS 5. More details about the firmware and software stack are given in the lorawan-fuota-mbed-os-example repo.
LoRa Gateway
For deploying a LoRaWAN network infrastructure, we have created a LoRaWAN Gateway using Raspberry Pi and IMST iC880a concentrator board. The gateway uses the Semtech Packet Forwarder to send the data from end node to the Network server.
Network Server
It is a LoRaWAN Network Server, responsible for managing the state of the network. It has knowledge of device activations on the network and is able to handle join-requests when devices want to join the network.
IoT Agent
IoT Agent forwards the device requests to the asvin platform. It does it over HTTPs using REST API end-points. The IoT Agent acts as a bridge between the Network Server and the asvin Platform. The communication between Network Server and IoT Agent is performed over MQTT protocol.
asvin BeeHive IoT update distribution Platform
The End-Node will be logged into the respective customer account in the asvin BeeHive IoT update management platform when it sends an uplink packet to register for the first time with appropriate credentials such as device key and customer key. The customers can then allocate the device to the appropriate group on the dashboard. The device groups are used to manage the devices on the dashboard.
One can create rollout on the dashboard to start firmware update. A delta patch file is required for this task. The file is saved on an IPFS Server in a secure manner. Below figure shows the rollout creation step on the dashboard.
Delta Update
The delta update strategy is employed for updating a firmware on a LoRa node. This strategy reduces data transmitted to the end node. The process is carried out in steps as mentioned in the figure below. The lorawan-fota-signing-tool was used to create the authentication certificates and signed delta files.
FUOTA Process
During the FUOTA process, the asvin BeeHive IoT update distribution platform sends a request to IoT Agent to create a FUOTA deployment. The IoT Agent then securely fetches the respective firmware file from the IPFS server and creates a FUOTA job on the Network Server. This process is carried out using the API endpoints provided by the Network Server.
The Network Server first sends the multicast session creation request to the end device as shown below. This downlink data contains multicast mac address, network session key, and application session key which are utilized by LoRa node for further communication in class C mode.
Then, the Network Server sends a downlink to the device with Fragmentation session setup details. The end node uses this information to create a fragmentation block in the external flash provided in the development board.
In the next step, the Network Server sends a downlink to start the class C multicast session. This packet contains the time to start the class C mode, timeout, downlink frequency and data-rate to be used in the class C mode. The details are depicted in the figure below.
Consequently, the End-Node switches to Class C using the multicast session and class C setup information. During this, it receives the firmware fragments sent by the Network Server. Upon receiving all of the fragments (including some redundant frames), the device starts the patch process.
If the hash of the received file is as expected and the ECDSA signature is verified, then the device accepts it and updates the Bootloader header to point to the updated application memory slot. Only after that the LoRa node reboots to start the application with new firmware. An example is shown below.
As the End-Device starts running the updated firmware, it sends the successful update status to Network Server which is internally forwarded to the Version Controller. It changes the status of the updated IoT devices in the Asvin IoT update distribution platform accordingly as presented in the next figure.
With a quick primer to configure LoRa end devices and an intuitive dashboard, the asvin platform makes it simple to upgrade LoRa end devices securely. Furthermore, the delta upgrades optimizes firmware distribution, reduces network consumption and saves the device battery, consequently extending its lifetime.
