LoRaWAN FUOTA: Firmware Updates Over the Air for Battery-Powered Meters

LoRaWAN FUOTA: Firmware Updates Over the Air for Battery-Powered Meters

Deploying tens of thousands of battery-powered water, gas, or heat meters across a city is a significant capital investment. When a firmware defect surfaces — or when a new regulatory tariff structure requires application-layer changes — the cost of physical truck rolls to reprogram each device can easily exceed the original hardware cost. Firmware Update Over the Air (FUOTA) for LoRaWAN solves this operationally, but the physics of sub-GHz radio and the electrochemistry of lithium thionyl chloride cells impose hard constraints that make LoRaWAN FUOTA considerably more complex than its cellular or Wi-Fi counterparts.

This article dissects the full FUOTA stack as standardized by the LoRa Alliance, examines the fragmentation and timing mechanics in detail, and provides practical guidance for metering product managers and firmware engineers who need to ship reliable, battery-safe updates at scale.

Why LoRaWAN FUOTA Is Not Trivial

LoRaWAN Class A devices — the dominant end-device class in utility metering deployments — open a receive window only immediately after an uplink transmission. A typical metering device transmits one frame every 15 minutes or every hour, yielding an average downlink opportunity rate that makes a naive sequential-block delivery approach completely impractical. A 128 KB firmware image at a payload of 48 bytes per fragment requires roughly 2,730 fragments. At one uplink per hour, sequential delivery alone would take over 113 days — clearly unacceptable.

The LoRa Alliance addressed this through a suite of complementary specifications that together constitute the FUOTA framework:

• TS006 — Remote Multicast Setup: provisions multicast security contexts and session parameters.
• TS007 — Fragmentation Layer: defines the block fragmentation and forward error correction (FEC) scheme.
• TS008 — Firmware Management Protocol (FMP): orchestrates the full lifecycle — announcement, scheduling, apply, and reboot.

These specifications operate above the LoRaWAN MAC layer and are transport-agnostic in the sense that the application server uses standard LoRaWAN port numbers (typically FPort 200–225 range, allocated by the Alliance) to carry FUOTA control messages.

The Multicast Architecture

Unicast delivery to each device individually would generate unacceptable air-time collisions and battery drain. LoRaWAN FUOTA relies on Class B or Class C multicast sessions to broadcast firmware fragments simultaneously to a group of devices.

Class B Multicast

Class B devices synchronize to a network beacon, enabling the network server to schedule downlinks into predictable ping slots. For FUOTA, the server provisions a multicast group with a shared 128-bit network session key (McNetSKey) and application session key (McAppSKey), a multicast address (McAddr), and a frame counter. During the multicast session window, all devices in the group listen to the same channel and spreading factor at the agreed ping slot.

From an energy perspective, Class B is preferred over Class C for battery-operated meters because Class C requires continuous receive mode — a power draw of roughly 10–15 mA versus the microampere-level standby current of a lithium primary cell system. Even Class B ping slots must be carefully budgeted: a device operating at SF9/125 kHz consumes approximately 6–8 mA during reception, and a 3.6 V / 8.5 Ah LiSOCl₂ cell can tolerate only a finite number of additional active periods before the 10-year design life is compromised.

Temporary Class C Elevation

An alternative approach — used when Class B beacon infrastructure is unavailable — is temporary Class C elevation: the device switches from Class A to Class C for the duration of the multicast window only, then reverts. TS006 includes the McClassCSessionReq command for exactly this purpose, specifying a session start time (GPS epoch), timeout, and the channel parameters. The device must receive this command via unicast before the session begins.

The Fragmentation Layer in Detail (TS007)

The fragmentation layer is responsible for splitting the binary firmware image into fixed-size fragments and applying a systematic Raptor-like linear block code to generate redundancy fragments. The scheme is not strict erasure coding (it is not a full fountain code), but it provides sufficient protection for the lossy LoRaWAN channel.

Fragment Structure

Each fragment carries:

• A 2-byte fragment index (1-based)
• A payload of up to 48 bytes (configurable, but 48 is the practical maximum for DR2/SF10 in EU868)

The total number of fragments N and the number of redundancy fragments M are announced in the FragSessionSetupReq command. A typical deployment uses M ≈ 10–15% of N, meaning a 2,730-fragment image might carry an additional 300–400 redundancy fragments.

Fragment Recovery

If a device misses fragment i, it can reconstruct it from the redundancy fragments using the known generator matrix — a XOR-based linear combination. The device maintains a binary matrix in RAM; each redundancy fragment received reduces the rank of the missing-fragment system by one. Full recovery is possible as long as the number of received redundancy fragments ≥ the number of missed data fragments, subject to the matrix rank condition.

This has a critical RAM implication: the decoding matrix can require up to (M × ceil(N/8)) bytes. For N=2730, M=300, this is approximately 300 × 342 bytes = ~100 KB of RAM — more than many Cortex-M0+ metering SoCs provide. Vendors must either constrain image size, increase fragment size, or implement a compressed matrix representation.

Firmware Management Protocol (TS008)

TS008 adds the lifecycle management layer. Key commands include:

• DevVersionReq/Ans: queries hardware version and current firmware version (aligned with the LoRaWAN DeviceInfo model).
• DevUpgradeImageReq/Ans: announces a firmware image: its 32-bit CRC, version, and the expected fragmentation session identifier.
• DevDeleteImageReq/Ans: instructs the device to discard a staged image.
• DevRebootTimeReq/Ans: schedules the apply-and-reboot event at a GPS-epoch timestamp, enabling coordinated fleet-wide cutover.

The device validates the staged image against the announced CRC-32 before acknowledging DevRebootTimeReq. If validation fails, the device reports the failure and retains the previous firmware — a crucial safety net that prevents a corrupted OTA from bricking a field device.

Energy Budget Analysis

The energy cost of a FUOTA campaign is the dominant engineering constraint for battery-powered meters. The following table illustrates a representative budget for a 128 KB image on EU868 at DR2 (SF10/125 kHz):

A single FUOTA campaign consuming 0.1–0.15% of cell capacity is acceptable. However, failed and retried campaigns, poorly scheduled multicast windows with low delivery ratios, or excessively high spreading factors can multiply this cost by 3–5×. Metering firmware should implement a campaign abort threshold: if fragment delivery ratio falls below a configurable floor (e.g., 60%) midway through the session, the device should exit Class C/B early and wait for rescheduling.

Flash Memory Architecture for Safe FUOTA

A robust FUOTA implementation requires a dual-bank or ping-pong flash layout:

1. Bank A (active): running firmware, protected against write during normal operation.
2. Bank B (staging): receives incoming fragments, validated before bootloader swap.
3. Bootloader: resides in a protected sector; performs CRC validation and bank swap atomically (using hardware-assisted dual-bank swap where available, e.g., STM32WL series).

Without dual-bank support, a power interruption during the flash copy phase can render the device non-functional. Some metering SoCs mitigate this with an execute-in-place (XIP) secondary flash or an external SPI NOR flash for staging. The bootloader must be hardened against all failure modes — including a corrupted new image — and must always be able to fall back to the known-good firmware in Bank A.

Network Server and Application Server Considerations

The FUOTA campaign is orchestrated from the application server (AS), which communicates with the LoRaWAN Network Server (LNS) via the standard backend interfaces. Key operational requirements include:

• GPS epoch time synchronization: Both TS006 session scheduling and TS008 reboot scheduling use GPS epoch timestamps. Devices must maintain clock accuracy of ±1 ping slot period (minimum 128 ms at ping periodicity 0). The DeviceTimeReq/Ans MAC command (LoRaWAN 1.0.3+) is the standard synchronization mechanism.
• Multicast group management: Large deployments segment devices into geographic multicast groups aligned with gateway coverage areas to maximize delivery ratio. A device at the cell edge receiving SF12 should not be in the same multicast group as a device at SF7 — fragment timing becomes mismatched.
• Delivery ratio monitoring: The fragmentation layer includes a FragSessionStatusReq command that devices respond to with their received-fragment bitmap. The AS should poll this before the redundancy fragment window to estimate FEC requirements dynamically.

Security Considerations

FUOTA introduces a significant attack surface. The LoRa Alliance framework addresses this at multiple layers:

• The multicast session keys (McNetSKey, McAppSKey) are derived from a multicast root key provisioned at join time, separate from the unicast session keys. Compromise of a multicast key does not expose unicast traffic.
• Firmware image integrity is protected by the 32-bit CRC announced in DevUpgradeImageReq, but this alone is insufficient for security. Implementations should additionally verify a digital signature (e.g., ECDSA-P256 or Ed25519) stored in the image header before the bootloader performs the bank swap.
• Anti-rollback counters in the bootloader prevent downgrade attacks to vulnerable firmware versions.
• The LoRa Alliance TS006/TS007/TS008 stack does not mandate a specific image signing scheme — this is left to the implementer, and most commercial implementations align with the SUIT (Software Updates for Internet of Things) manifest format described in IETF RFC 9019 and RFC 9124.

Practical Deployment Recommendations

• Segment campaigns by DR class: Never mix SF7 and SF12 devices in the same multicast group. The fragment transmission rate must match the slowest device’s receive capability.
• Schedule outside meter reading windows: Prevent Class A uplinks from colliding with Class B ping slots during FUOTA. Configure a maintenance window in the application layer.
• Use DR stepping for large deployments: Start with DR5 (SF7) for near-gateway devices; run separate sessions for DR2 (SF10) devices. This halves total airtime for the majority of the fleet.
• Validate on a canary group first: Deploy to 1–2% of devices, verify CRC success rate and battery impact, then roll out fleet-wide. TS008’s per-device version query makes this straightforward.
• Implement watchdog recovery: If the device reboots into the new firmware and the application fails to post a health-check uplink within a configurable timeout, the bootloader should automatically revert to Bank A.

Key Standards and Further Reading

• LoRa Alliance TS006 — LoRaWAN Remote Multicast Setup Specification
• LoRa Alliance TS007 — LoRaW
  

  Frequently Asked Questions

  What is the primary challenge with sequential firmware delivery to LoRaWAN Class A meters?

  Class A devices only open receive windows immediately after uplink transmissions (typically every 15-60 minutes), making sequential block delivery impractical; a 128 KB firmware image requiring 2,730 fragments would take over 113 days to deliver sequentially at one uplink per hour.

  Which LoRa Alliance specifications comprise the complete FUOTA framework?

  TS006 (Remote Multicast Setup), TS007 (Fragmentation Layer with FEC), and TS008 (Firmware Management Protocol) work together above the LoRaWAN MAC layer using standardized FPort 200-225 ranges to orchestrate multicast provisioning, fragmentation, and update lifecycle management.

  Why is Class B multicast preferred over Class C for battery-powered meter FUOTA deployments?

  Class B operates in scheduled ping slots consuming 6-8 mA during reception versus Class C’s continuous receive mode drawing 10-15 mA, preserving the 10-year design life of lithium thionyl chloride cells that operate at microampere standby currents.

  What is temporary Class C elevation and when should it be used?

  Temporary Class C elevation switches a device from Class A to Class C for only the multicast window duration via the TS006 McClassCSessionReq command (specifying GPS epoch start time and timeout), then reverts to Class A when beacon infrastructure is unavailable.

  How do multicast security keys (McNetSKey and McAppSKey) enable efficient group firmware delivery?

  The network server provisions a single shared 128-bit network session key and application session key for each multicast group, allowing all devices in the group to simultaneously decrypt and receive the same firmware fragments on a common channel and spreading factor.

  Was this article helpful?
  👍 Yes
  👎 No