Case Study: LoRaWAN FUOTA

Posted by Vijaykumar, Uma.k, Sekar.n | Mon, 07 Aug 2023 | Tagged: wireless, case-study, firmware

LoRaWAN on the other hand, is a wireless communication protocol, built on top of LoRa physical layer and designed for long-range, low-power applications such as Internet of Things (IoT) devices. LoRaWAN support 3 different operating modes: Class A, Class B, and Class C. ] The operating modes determines the communication behavior and power consumption characteristics of LoRaWAN devices.

Background

LoRa is a physical layer that employs Chirp Spread Spectrum modulation, which makes it resilient to channel noise. Its distinguishing features include the ability to transmit data over long distances while consuming minimal power.

LoRaWAN (Long Range Wide Area Network), on the other hand, is a wireless communication protocol, built on top of LoRa physical layer and designed for long-range, low-power applications such as Internet of Things (IoT) devices. LoRaWAN support 3 different operating modes: Class A, Class B, and Class C. The operating modes determines the communication behavior and power consumption characteristics of LoRaWAN devices.

In LoRaWAN, devices often use a power-saving mechanism called cyclic sleep to conserve battery life. The device’s time is split into sleep and activity intervals. The active period is when the device wakes up to perform its intended tasks, such as sending or receiving data. During sleep period, the device remains disconnected from the LoRaWAN network and turns off its radio and other power-consuming components to minimize energy usage.

The characteristics of each of the operating modes is provided below.

Class A: It is the simplest and most energy-efficient communication model in LoRaWAN and consists of two basic windows. Once a device sends an uplink message to the network server, it opens two receive windows at specific time slots to listen for downlink responses. The first receive window opens shortly after the uplink transmission, while the second window opens at a predetermined delay. Class A devices operate in a cyclic sleep mode and can only receive data from the network after transmitting a packet. Due to their constrained listening windows and inability to rapidly receive downlink data, they may experience delays in receiving directives or updates.
Class B: In addition to the Class A behavior, Class B devices periodically open new receive windows, resulting it more predictable downlink communication. Due to the extra receiving windows, Class B devices use a little bit more power than Class A devices.
Class C: Class C devices maintain their receivers open at all times. As a result, they have low-latency communication capabilities and can always receive downlink signals. This continuous listening consumes more power compared to Class A and Class B, which can significantly impact battery life.

Problem Definition

The customer wanted to implement FUOTA update for their devices, which were operating in Class A.
Update time should be significantly reduced by downloading the delta instead of the complete image.

Solution

Combining Class A, and Class C modes

LoRa has a FUOTA specification that combines Class A and Class C operation. During normal operation, devices can utilize the power-saving Class A mode to conserve energy. But during FUOTA download devices switch to Class C mode for continuous listening and immediate response to downlink commands. Combining the Class A and Class C modes facilitates efficient firmware updates using FUOTA mechanisms. By leveraging the strengths of both Class A and Class C modes, LoRaWAN networks can optimize power consumption, achieve real-time responsiveness when needed, and efficiently manage firmware updates.

LoRaWAN Multicast Download

LoRaWAN supports unicast communication, by default, where a device communicates directly with a network server. LoRaWAN also supports multicast, where a single transmission can reach multiple devices simultaneously, reducing the overall energy consumption and update time compared to individual unicast transmissions.

LoRaWAN FUOTA is done through multicast download. Unicast messages are sent to individual devices to invite them to a class C multicast download session. The multicast address, keys, and window (start and end time) is sent as part of the invite. Devices acknowledge the invite and then switch to class C mode, during the specified window. The server then sends out the firmware update messages to the multicast group, which is stored by the devices into the download partition in their flash memory. After the successful reception of the firmware update messages, the devices replace the application image with the downloaded application image, and then boot into the new application image.

FUOTA Client and Server Implementation

The LoRaWAN FUTOA server from Chirpstack https://github.com/chirpstack/chirpstack-fuota-server was used for testing the FUOTA implementation.

The microcontroller was based on STM32WL series, which has the on-chip LoRa Radio. The LoRaWAN FUTOA implementation from ST was used for implementing the client. A bootloader was implemented to update application firmware image after a successful download of the firmware.

Firmware Update using Binary Diff

Instead of downloading the complete firmware update, the binary diff between the current firmware image and the new firmware image can be downloaded.

Downloading the binary diff significantly reduces the download size of firmware updates, optimizing bandwidth utilization in the LoRaWAN network. By transmitting only the differential changes, the energy consumption during firmware updates is reduced, leading to extended battery life for LoRaWAN devices.

In our implementation, the JojoDiff tool from https://jojodiff.sourceforge.net/ was used to generate the binary difference. The JANPatch module from https://github.com/janjongboom/janpatch was integrated into the firmware to apply the diff and recreate the original firmware.

Conclusion

Using a combination of Multicast FUOTA download and Binary Diffing, an efficient download mechanism was implemented, as part of this project. A bootloader that switch to the new downloaded application was also implemented and delivered. The FUOTA software developed was then integrated, tested and demonstratd with a Chirpstack server.