v3.25.2

Getting Started Devices Gateways The Things Stack Integrations Reference
Get The Things Stack

Reference

    Overview
  • Adaptive Data Rate
  • API
  • Application Packages
  • Billing with Stripe
  • Command-Line Interface
  • Components
  • Configuration
  • Data Retention and Privacy
  • Device Claiming Configuration
  • Email Templates
  • Federated Authentication
  • Frequency Plans
  • FUOTA
  • Gateway RTT
  • Glossary
  • ID and EUI Constraints
  • Last Activity
  • LoRa Basics Station Implementation Guide
  • LoRaWAN Join Server Configuration
  • Packet Broker Routing
  • Packet Forwarders
  • Rate Limiting
  • Resource Limiting
  • Root Certificates
  • The Things Network

FUOTA

This section contains information on using FUOTA with The Things Stack.

Firmware Update Over the Air (FUOTA) is a standard for distributing firmware updates using unicast or multicast. Its greatest benefit is delivering updates over the air to many devices at the same time in an efficient and secure manner.

The Things Stack containts the fundamental blocks for FUOTA support, though it is still in an early adoption phase.

Native FUOTA server is planned to be added to The Things Stack in the near future. We recommend to stay tuned for updates on this topic in our social media channels (YouTube, LinkedIn, etc.).

Note:
Remote Multicast Setup (RMS) and Fragmented Data Block Transport (FDBT) protocols are not supported by The Things Stack.

FUOTA Process

See the FUOTA Process Summary document from LoRa Alliance.

On a high level, a FUOTA process implies the following steps:

  • Server enables class C and joins a multicast group
  • Server signs the firmware update and splits it in chunks
  • Server schedules each update chunk as a downlink message to the multicast group
  • Server verifies that the device has received all chunks, synthesizes them and verifies the update signature
  • Device applies the firmware update
  • Device sends a firmware update complete uplink message
  • Server disables class C

Best Practices when Using FUOTA

File Size

There are two types of FUOTA - full firmware update and incremental firmware update. Incremental update is always preferred, but you first have to make sure that your end device supports it and that you know which firmware version your end device is running.

Fragment Size

The preferred fragment size depends on the available data rate, which depends on the selected group of end devices. A common practice is to allow the lowest common data rate denominator to reach all devices in a multicast group. However, if for example 80% of devices are nearby and are reachable with SF7 and large fragment sizes, transmitting all data in SF12 would quickly burn those devices’ batteries.

Duty Cycle

Using multiple gateways for updating firmware on the same group of end devices is recommended because of duty cycle restrictions and to avoid packet loss. It is also recommended to use class B, which takes longer to update but it is likely better for duty cycle distribution.

Useful Links

A test FUOTA server compatible with The Things Stack can be found here.

For a beginners guide on using multicast and FUOTA, check out this video.

Regarding devices that implement FUOTA, we recommend you to check out our Generic Node.

See this link for an example application that implements multicast FUOTA for MBed OS 5.

← Adding Frequency Plans Gateway RTT →

On this page

  • FUOTA Process
  • Best Practices when Using FUOTA
  • Useful Links

The Things Stack

Getting Started

Devices

Gateways

The Things Stack

Integrations

Reference

Contributing

GitHub

Forum

About Us

The Things Network

The Things Industries

About this page

Last changed by Nejra Selimović on 18 May 2022.
doc: Add FUOTA doc (#851)

Edit on Github