FUOTA FAQ

1. What is FUOTA?
FUOTA is an acronym for Firmware Update Over-The-Air.
FUOTA is also the name of a LoRa Alliance Technical Committee Working Group, the FUOTA Working Group
(WG).

2. Why should I care about firmware updates?

LoRaWAN end-devices are often designed with a very long lifecycle; many devices are deployed with a life
expectancy of several years. During that time, factors can arise that affect the device, such as changing
regulatory rules, varying software requirements, issues that need to be fixed, or improvements in the protocol
stack.
Firmware updates are often needed to address these factors. However, without over-the-air firmware updates,
some of the changes would require physical access to each affected end-device. This is not always possible,
as devices can be installed in unreachable locations, making physical access too time-consuming and costly.
Over-the-air firmware updates enable a zero-touch path to tackle such device evolutions, making LoRaWAN
end-devices future-proof.

3. What are the specifications produced by the FUOTA WG?

The FUOTA Working Group has produced five specifications:

• TS003 - Application Layer Clock Synchronization v2.0.0

• TS004 - Fragmented Data Block Transport v2.0.0
• TS005 - Remote Multicast Setup v2.0.0
• TS006 - Firmware Management Protocol v1.0.0
• TS007 - Multi-Package Access Protocol v1.0.0

These specifications are the building blocks that enable over-the-air firmware updates for LoRaWAN end-
devices.
In addition, the FUOTA WG has produced a technical recommendation document describing the firmware
update process:

• FUOTA Process Summary Technical Recommendation TR002 v1.0.0

4. Are FUOTA specifications LIMITED to firmware updates?

5177 Brandin Court, Fremont, CA94538 | Tel: +1 510 -492-4044 | Fax: +1 510 -492-4001 | www.lora-alliance.org

FUOTA FAQ
 No. All FUOTA WG specifications are independent and can be used for other purposes. For example,
the Application Layer Clock Synchronization protocol can be used to set the correct clock time into end-
devices, independent of a firmware upgrade.

You can also use a combination of specifications, like Remote Multicast Setup and Fragmented Data
Block Transport, to send any large file to a fleet of end-devices.

5. Is there an open-source implementation of FUOTA specifications?

Yes, the LoRaMac-node project, for example, proposes an implementation of the FUOTA building block
specifications on the end-device side.

6. What is the maximum size of a firmware update?

There is no strict limitation on the firmware size that the FUOTA protocols can transport. The
Fragmented Data Block Transport protocol has been designed for data blocks of a few hundred
kilobytes. Missing fragment reconstruction becomes more complex when the data block size
increases.

The actual limit will mostly depend on the capabilities of the end-device, in terms of memory for
storage and reconstruction, and on the network capacity to broadcast large amounts of data over
the air.

There are techniques to lighten broadcasted data size. Refer to question 29, How can I improe the
efficiency of FUOTA? for more information.

7. I heard LoRaWAN payload sizes are limited. How can I send a large file to my
end-device?

Yes, LoRaWAN payload sizes are limited, depending on the region of the world and on the selected
data rate. However, the FUOTA WG specification Fragmented Data Block Transport describes a
fragmentation protocol to split a larger data block into fragments.

8. How do FUOTA protocols handle packet loss?

When broadcasting a firmware update to many end-devices, it is not efficient nor recommended to
ask each end-device if it has received all of the fragments. The FUOTA WG specification

5177 Brandin Court, Fremont, CA94538 | Tel: +1 510 -492-4044 | Fax: +1 510 -492-4001 | www.lora-alliance.org

FUOTA FAQ
Fragmented Data Block Transport proposes Forward Error Correction code (FEC) to enable
reconstruction of lost fragments by sending extra redundancy packets.

9. How many fragments can be missed by an end-device whereby it will still be

able to reconstruct the data block?

There is no exact number as the reconstruction capability depends on multiple factors, including
memory usage and network quality. The fragmentation session can be configured to send a given
number of redundancy fragments. However, the end-device requires memory to reconstruct the
missing fragments. More fragment recovery capability means more memory usage. That
configuration must be adapted based on the overall network quality.

10. Can an end-device request a missed fragment?

No, there is no means for an end-device to request a missing fragment with the proposed protocols.
This was done on purpose to avoid massive uplinks from a fleet of end-devices requesting lost
fragments.

Fragmentation Forward Error Correction code (FEC) has been designed for that issue, so that end-
devices with missing fragments continue to listen to the multicast session for recovery fragments,
which will enable lost fragment reconstruction.

The FUOTA server can request the status of the fragmentation session from the end-device,
including the number of missed fragments and reconstruction errors.

11. Can fragments be received out-of-order?

Yes, fragments can be received out-of-order. Since each fragment is numbered, an end-device will
be able to receive out-of-order fragments and recovery fragments, which enable the reconstruction
of lost fragments.

12. Is there an open-source implementation of FUOTA specifications?

FUOTA WG specifications do not provide a generic uplink fragmentation method. Other standards,
such as IETF SCHC RFC 8724, propose such methods. Static Context Header Compression
(SCHC) fragmentation has been designed to work with LoRaWAN, as specified in RFC 9011.

5177 Brandin Court, Fremont, CA94538 | Tel: +1 510 -492-4044 | Fax: +1 510 -492-4001 | www.lora-alliance.org

FUOTA FAQ
 13. Can I update several end-devices at once?

Yes! FUOTA WG specifications include multicast support, involving the Remote Multicast Setup
Protocol, which permits the definition of a temporary LoRaWAN Class B or Class C multicast group
on several end-devices, in order to update them all at once.

14. Why should I use a temporary multicast session?

When using multicast, the number of downlinks used to transport a file is far less than if unicast is
used to transport a file to each device individually. With multicast, a file is transmitted based on the
number of gateways required to communicate with all of the devices. Unicast would require a one-
to-one relationship with each device; if unicast is used to transfer the fragments to Class A end-
devices, the transfer would be dependent on receiving a Class A uplink for every downlink fragment
that needs to be sent.

By setting up a temporary Multicast Class B or Class C session, you can send fragments at regular
intervals, independent of device uplinks, for the duration of the transfer. After the transfer is
complete, the multicast session can be terminated, eliminating the extra battery drain from listening
in Class B/C.

15. When should I use Class B or Class C multicast sessions?

Class B multicast sessions should be used when:

• The devices can keep time for the duration of a firmware transfer.
• The devices are in a region with a duty cycle*.

Class C multicast sessions should be used when:

• The devices are unable to maintain clock synchronization for the duration needed to complete the FUOTA
transfer.
• The devices have a continuous power supply.

The advantage of Class B over Class C is power consumption. In regions with a duty cycle, there will be larger
periods of time in between downlinks. If a Class C multicast session is used in these regions, the radio will
need to be listening continuously even though downlinks may be spaced out by minutes. This equates to
wasted battery life for a device.

5177 Brandin Court, Fremont, CA94538 | Tel: +1 510 -492-4044 | Fax: +1 510 -492-4001 | www.lora-alliance.org

FUOTA FAQ
*Note: There are some cases where, when the transferred file is small enough, Class C can be used.

16. Can messages still be sent during a multicast session?

Yes, during a multicast session, an end-device can always transmit a message. Note that LoRaWAN end-
devices are half-duplex, so when transmitting a packet, the device will not be able to receive the multicast
downstream at the same time. This can be recovered using fragmentation session forward error correction.
During a FUOTA session, the network can also send data to the end-devices. If the end-device is using Class
C for multicast, it will not be able to receive unicast downlink on that stream. However, if the end-device is
communicating using Class A, the RX1 and RX2 receive windows will be available for downlinks.

17. When a FUOTA session is in progress, what happens to regular

transmissions?

In Class C mode, data fragments will be sent in the continuous receive window (RXC). The downlink RXC
frequency and data rate for the multicast session are transmitted to the end-device during the setup of the
Multicast Class C session thanks to the McClassCSessionReq/ McClassCSessionAns messages. When an
end-device is running in unicast Class C mode, the multicast session overrides the unicast parameters. The
device will not be able to receive Class C unicast downlink during a FUOTA session if those parameters are
different.
In Class B mode, data fragments will be sent in a ping slot window. The ping slot window periodicity for the
multicast session is transmitted to the end-device during the setup of the Multicast Class B session thanks to
the McClassBSessionReq/McClassBSessionAns messages, which will be defined to respect the regulation
with or without a duty cycle. When a device is running in unicast Class B mode, the unicast and multicast
session can interoperate. The multicast has priority over unicast by default, in case of ping-slot collision, but
the network server can control the priority.
In Class A mode, Class A receive windows (RX1/RX2) have priority against any of the multicast Class B or
Class C receive windows. If an end-device transmits or schedules a receive window during FUOTA session, it
may miss a broadcasted fragment.

18. Can I configure a multicast session with different radio parameters?

5177 Brandin Court, Fremont, CA94538 | Tel: +1 510 -492-4044 | Fax: +1 510 -492-4001 | www.lora-alliance.org

FUOTA FAQ
Data rate and downlink frequency are configured during multicast session setup. Only a single set of radio
parameters can be set for a multicast session, as it is using physical broadcast.
It is possible to use different parameters by setting up different multicast sessions for the group of end-devices.
This will require different streams of broadcast from the gateway or broadcasting each session from a different
gateway.

19. How can I avoid interference when multiple gateways broadcast the same
FUOTA session?

When multiple gateways broadcast the same FUOTA session at the same time, the signals might interfere at
end-device receiver. This requires good network planning to avoid the interference; you will need to choose the
correct set of gateways and network parameters to broadcast the data block.

20. How can I make sure my end-devices will join the multicast session at the
right time?

The FUOTA WG specification Application Layer Clock Synchronization defines a protocol to set the correct
time on end-devices that have no other means to get wall-clock time.

21. Can another time source (e.g., NTP) be used instead of GPS?

Yes, an end-device can be synchronized with another time source; there is no requirement to use the time
synchronization protocol if another method is used.
Note, however, that the time base used in LoRaWAN is the GPS epoch time. There are considerations about
leap second and start of the epoch that must be addressed.

22. How I check the currently running firmware on my end-device?

Yes, the Firmware Management Protocol specification has commands to check the current and the new
firmware version waiting to be installed on the end-device. In addition, this specification also permits rebooting
the end-device at a certain time.

5177 Brandin Court, Fremont, CA94538 | Tel: +1 510 -492-4044 | Fax: +1 510 -492-4001 | www.lora-alliance.org

FUOTA FAQ
As with all the other specifications, those commands can be used outside of firmware updates. For example,
one can simply monitor the current version of the firmware installed in their fleet of end-devices.

23. There are multiple protocols involved to start a FUOTA session. Isn’t that
inefficient?

Although there are multiple protocols involved to start a FUOTA session, the FUOTA WG also defines the
Multi-Package Access Protocol, which allows the ability to “pack” multiple commands into a single message.
This makes the FUOTA session setup efficient without losing the genericity of the standalone protocols.
Moreover, the Multi-Package Access Protocol has been designed to be re-used by other application layer
packages defined by the LoRa Alliance.

24. Which LoRaWAN link layer version supports FUOTA?

All. The FUOTA WG specifications were designed to be LoRaWAN link layer version agnostic. This means that
any version of the LoRaWAN link layer protocol can transport FUOTA messages.

25. What do I need to add to my end-device software to support FUOTA?

FUOTA WG specifications rely on the LoRaWAN link layer with multicast enabled, optionally. Selected FUOTA
protocols need to be implemented at the application layer. In addition, you must implement firmware
verification and installation.

26. How long does a FUOTA session last? How much power is required?

Duration of a FUOTA session and power usage depend on several factors. We will look at examples of three
broadcast use cases (Class C, Class B single ping slot, and Class B maximum ping slots) with two different
firmware images (90K and 120K) in two different regions (US and EU).
Firmware size

5177 Brandin Court, Fremont, CA94538 | Tel: +1 510 -492-4044 | Fax: +1 510 -492-4001 | www.lora-alliance.org

FUOTA FAQ
We will consider two firmware images, which are split into 239B fragments. We will take into consideration 25%
redundancy fragments.

FIRMWARE SIZE # FRAGMENTS # REDUNDANCY # TOTAL

NAME FRAGMENTS FRAGMENTS
90K 90KiB 386 97 483
120K 120KiB 515 129 644

Each fragment transports 239B of file data due to FUOTA fragmentation session overhead (3B) and a
LoRaWAN maximum payload size of 242B at the considered data rate.
Region
We will consider two region settings to demonstrate different fragment duration and duty cycle restrictions.

REGION LORAWAN DATARATE FRAGMENT BEACON DUTY

SETTINGS REGION TIME-ON-AIR TIME-ON-AIR CYCLE
US915-DR10 US915 DR10 563.712ms 305.152ms 100% (No
SF10, BW duty cycle)
500kHz
EU868-DR4 EU868 DR4 696.832ms 152.58ms 10%
SF8, BW
125kHz
This table contains fragment time-on-air and beacon time-on-air calculations based on Semtech’s SX1261
datasheet and LoRa™ Calculator [1].
[1] https://www.semtech.com/products/wireless-rf/lora-core/sx1261#download-resources

Broadcast use cases

The three broadcast cases below comprise each region and each firmware. For each case, the following
parameters are computed:

• Time elapsed is the total time from the moment the sensor starts receiving the data fragments to the end
of reception.
• Active time is the duration for which the sensor is actively receiving and, therefore, consuming power.
• Power is the electrical power necessary for the reception of the file, including redundancy fragments and
considering a 5mA current draw in reception mode. Data is presented in mAh (milliampere-hour) and in
percentage of a CR2450 coin-cell battery (600mAh).

Class C
The first use case is LoRaWAN Multicast Class C, where end-devices listen continuously to the broadcast.

FIRMWARE NAME REGION SETTINGS TIME ELAPSED ACTIVE TIME POWER

90K US915-DR10 4m 32s 4m 32s 0.378mAh (<0.1%)
120K US915-DR10 6m 03s 6m 03s 0.504mAh (<0.1%)
90K EU868-DR4 5m 37s 5m 37s 0.466mAh (<0.1%)
120K EU868-DR4 1h 01m 1h 01m 5.12mAh (<1%)

5177 Brandin Court, Fremont, CA94538 | Tel: +1 510 -492-4044 | Fax: +1 510 -492-4001 | www.lora-alliance.org

FUOTA FAQ
This case shows that the duration of a FUOTA session, for the first three scenarios, is a handful of minutes,
and that battery usage is kept low (< 0.1%).
The scenario on the last line highlights that Class C Multicast in a duty cycle-restricted region, where only 10%
of the time can be used to broadcast, may be inefficient for large file transfer; end-devices would have to listen
for an entire hour while only receiving actual data for a few minutes. This is a waste of energy and radio
bandwidth. For such cases, Class B might be more suitable.
Class B, single ping slot per beacon period
The second use case is LoRaWAN Multicast Class B with a single fragment per beacon period.

FIRMWARE NAME REGION TIME ELAPSED ACTIVE TIME POWER

SETTINGS
90K US915-DR10 17h 10m 7m 00s 0.583mAh
(<0.1%)
120K US915-DR10 22h 53m 9m 20s 0.777mAh
(~0.1%)
90K EU868-DR4 17h 10m 6m 50s 0.570mAh
(<0.1%)
120K EU868-DR4 22h 53m 9m 07s 0.760mAh
(~0.1%)
In this use case, the duration (time elapsed) of a FUOTA session is much longer. It takes almost a day to
broadcast the firmware. But the active time that end-devices are in reception mode stays low, as they are only
listening for one ping slot per beacon period, which is one fragment every 128s. In addition, end-devices also
listen to the beacon itself, which explains the longer active time as compared to Class C.
The power budget is similar to Class C, except for the scenario on the last line, where it stays much lower, due
to the avoidance of activating listening mode for no reason.
Class B, Maximum ping slots per beacon period
The third use case is LoRaWAN Multicast Class B with a maximum number of fragments per beacon period.
The number of fragments depends on the duty cycle restrictions.

FIRMWARE REGION # TIME ACTIVE TIME POWER

NAME SETTINGS BEACON ELAPSED
PERIOD
90K US915-DR10 4 8m 32s 4m 50s 0.403mAh
(<0.1%)
120K US915-DR10 6 12m 48s 7m 15s 0.604mAh
(~0.1%)
90K EU868-DR4 31 1h 06m 5m 50s 0.487mAh
(<0.1%)
120K EU868-DR4 41 1h 27m 7m 43s 0.644mAh
(~0.1%)
In EU868-DR4 region settings, due to duty cycle restrictions, only 16 ping slots per beacon period are allowed
to be used for the given fragments. This lengthens the time elapsed but only slightly affects the total active
time, and therefore the power consumption necessary to receive the file. The power budget stays around 0.1%
of the chosen battery capacity.

5177 Brandin Court, Fremont, CA94538 | Tel: +1 510 -492-4044 | Fax: +1 510 -492-4001 | www.lora-alliance.org

FUOTA FAQ
 27. Is there a specification describing the firmware file format? What about
firmware encryption?

No, the scope of the FUOTA WG is to define a method to transport a large binary file to one or several end-
devices safely and efficiently. The firmware file format is very much manufacturer-specific, depending on chip
vendor, device capabilities, and other factors.
Other standards, like IETF SUIT, are chartered to define a manifest format for firmware updates and its
extensions.

28. If an end-device supports FUOTA, does that require a new certification?

LoRa Alliance certification for FUOTA is ongoing work for the LoRa Alliance and will be part of the LoRaWAN
Certification Test Tool (LCTT), when available.

29. How can I improve the efficiency of FUOTA?

Efficiency of FUOTA can be improved by using the Delta Firmware approach. The objective is to reduce the
time needed for communication and, as a result, the power consumption of the end-device.
With this approach, in place of sending an entire firmware image to the end-device, the FUOTA server will only
send a subset of the firmware image to the end-device.
There are three fundamentally different technological approaches to generating delta firmware files and
applying these files to the firmware image: patching, padding, and computation.

• Patching technology inserts a jump instruction at the beginning of the block to be replaced. The
replacement block is appended to the image in a free expansion area.
• Padding technology adds excess memory or ‘pads’ around firmware blocks that may be replaced.
• Computation technology processes the output from the software compiler and linker to generate
optimized update instructions.

It is up to the device maker to decide which technology to implement in the end-device. In general, the choice
of the delta firmware technology will depend on the hardware capabilities of the end-device.

5177 Brandin Court, Fremont, CA94538 | Tel: +1 510 -492-4044 | Fax: +1 510 -492-4001 | www.lora-alliance.org

FUOTA FAQ