Getting Started Concepts The Things Stack Cloud The Things Stack Enterprise Integrations API Hardware
Get The Things Stack

Concepts

    Overview
  • Architecture
  • Features
    • Console
    • Command-line Interface
    • Multi-tenancy
    • Gaining insights using Events
    • LoRaWAN
      • Adaptive Data Rate
      • Frequency Plans
      • FUOTA
      • LoRaWAN Version Support
    • Single Sign-On
    • Alerting
    • Network Operations Center
  • Networking
  • Migrate to The Things Stack
  • Packet Broker
  • Server Addresses
  • Advanced Topics
  • Troubleshooting
  • The Things Stack Sandbox

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

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 LoRaWAN Version Support →

On this page

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

Sections

Getting Started

Concepts

The Things Stack Cloud

The Things Stack Enterprise

Integrations

API

Hardware

Sitemap

View our Sitemap

Contributing

GitHub

About Us

The Things Industries