FUOTA (Firmware Update Over The Air) with ChirpStack

The following steps describe the setup and execution of firmware updates (FUOTA) for LoRaWAN end devices using the ChirpStack Application Server.

Requirements

Before you begin, make sure the following requirements are met:

  • An installed and running ChirpStack v4 server.
  • The new firmware file as a .sbin-file.
  • The devices are connected to the ChirpStack server.
  • The Device Profile for your devices has the sleep time of your devices configured as the Expected uplink interval (secs). The default value would be 300s. More details about the Device Profile settings are provided below.
  • The devices have sufficient battery charge. We recommend performing FUOTA during the day in sunlight.
  • The devices are within good radio range. We recommend bringing the devices close to a gateway.

Setup

Device Profile

The following parameters are important for the Device Profile:

General

  • Region: EU868
  • MAC version: LoRaWAN 1.0.4
  • Regional parameters version: RP002-1.0.1
  • Expected uplink interval (secs): device sleep time - default 300s

Application layer

  • Clock sync version (TS003): v1.0.0
  • Clock sync fPort (TS003): 202
  • Fragmented data block transport (TS004): v1.0.0
  • Fragmented data block transport fPort (TS004): 201
  • Remote multicast setup version (TS005): v1.0.0
  • Remote multicast setup fPort (TS005): 200

1. Create a ChirpStack FUOTA deployment

First, a new FUOTA deployment must be created. This option can be found in the ChirpStack application containing your device. ChirpStack automatically creates the multicast group for FUOTA. ChirpStack FUOTA deployment settings The following settings are recommended:

  • Unicast retry count (max): 5
  • Multicast data rate: 4 (depending on the distance to the devices)
  • Fragmentation redundancy (%): 25%
  • Multicast timeout: 4096 s
  • Fragment size (multiple of 8): 192 bytes
  • Payload: the new firmware (.sbin)

2. Add devices to the deployment

All end devices that are to receive the same firmware can be updated simultaneously. In the application's Devices overview, selected devices can be added using the button Selected Device added to a FUOTA deployment.

3. Add gateways to the deployment

As with the end devices, the corresponding gateways must also be added to the FUOTA deployment.

4. Start FUOTA

Once FUOTA has been configured and all desired end devices and affected gateways have been added to the FUOTA deployment, FUOTA can be started.

Note: The complete FUOTA process takes approximately 2 hours, depending on the number of devices, the configured Unicast retry count, and the Fragmentation redundancy. The time the device remains in Class C mode (Always On – receiving the FUOTA packets) is approximately 30–60 minutes by default.

FUOTA process and status

The ChirpStack FUOTA process consists of the following steps, which are shown in the FUOTA deployment dashboard:

  1. Create multicast group
  2. Add devices to multicast group
  3. Add gateways to multicast group

Steps 1 to 3 take place almost immediately. They only document the internal setup in ChirpStack.

  1. Multicast group setup
  2. Fragmentation session setup
  3. Multicast session setup

Steps 4 to 6 concern device configuration. ChirpStack attempts to configure the devices via downlink. If this fails, the respective configuration downlink is repeated the number of times specified by Unicast retry count. During this time, the device operates normally. The status of the individual devices in the FUOTA deployment regarding these setup messages can be viewed in the "Devices" tab of the FUOTA deployment.

  1. Enqueue fragments: As part of this internal setup process, the firmware fragments are added to the multicast group's queue at the "Run at" time.
  2. Delete multicast group: The multicast group is deleted.
  3. Complete deployment

FUOTA takes place between steps 7 and 8. The devices remain in Class C mode and permanently awake for the duration of the Multicast timeout. During this time, they do not send normal messages but receive the individual firmware fragments. Accordingly, the devices' power consumption is also higher during this period. The Multicast timeout must be long enough for all firmware fragments to be transmitted in time. The FUOTA setting Calculate multicast-timeout calculates the required time based on the Fragment size and the firmware file in the Payload.

After the multicast-timeout has elapsed or all fragments have been received, the device restarts and, if FUOTA was successful, boots into the new firmware.

Optional

The FUOTA setting Fragmentation status request requests the fragmentation status at two selectable points in time. The result can be viewed in the "Devices" tab of the FUOTA deployment.