STMicroelectronics FUOTA Application note
AN5411
Application note
I-CUBE-LRWAN embedding FUOTA, application implementation
Introduction
This application note describes the FUOTA application embedded in the expansion software (I-CUBE-LRWAN) implementation
on STM32L4 Series devices, and explains how to make use of the overall FUOTA process in order to provide the components
needed for a FUOTA campaign.
This document applies within the framework of a FUOTA project, and is intended for teams or individuals, either internal
or external to ST. It particularly targets FUOTA project integrators, or those integrating FUOTA modules in a wider system
implementing end-device functions.
LoRa® is a type of wireless telecommunication network designed to allow long range communication at a very low bit
rate, enabling long-life battery operated sensors. LoRaWAN® defines the communication and security protocol to ensure
interoperability with LoRa networks.
AN5411 - Rev 2 - March 2021
For further information contact your local STMicroelectronics sales office.
www.st.com
1 General information
This document applies to STM32L476xx Series Arm®-based microcontrollers.
Note: Arm is a registered trademark of Arm Limited (or its subsidiaries) in the US and/or elsewhere.
AN5411
General information
AN5411 - Rev 2
page 2/33
AN5411
Overview
2 Overview
The FUOTA application in I-CUBE-LRWAN is compliant with the LoRa Alliance® specification protocol (LoRaWAN
version V1.0.3) [1].
The FUOTA feature is implemented in the application layer, and is based on and compliant with the specific
functionalities defined by the LoRA Alliance. These functionalities allow a multicast group (Remote Multicast
Setup Spec V1.0.0 [4]) to be set up, to fragment and to send data packets (Fragmented Data Block Transport
Specification v1.0.0 [3]) and finally to synchronize clocks (LoRaWAN Application Layer Clock Synchronization
Specification v1.0.0 [5]) so that all devices can agree on the start of a FUOTA session.
Note: Throughout this application note, the IAR™ EWARM IDE is used as an example to provide guidelines for project
configuration.
2.1 Application supports
The firmware update over-the-air (FUOTA) application supports:
• full firmware upgrade image (the entire firmware image is sent to the end-device)
• only applicable in Class-C mode
• only runs on STM32L476xx targets
• third-party middleware, mdedTLS (open source code) for the cryptographic services.
2.2
Terms and acronyms
Table 1. Acronyms used in this document
Acronym Definition
ABP Activation by personalization
APDU Application protocol data unit
FUOTA Firmware update over the air
FW Firmware
HAL Hardware abstraction layer
LoRa Long-range radio technology
LoRaWAN LoRa, wide-area network
MAC Media access control
MCPS MAC common part sublayer
MLME MAC sublayer management entity
MPDU Mac protocol data unit
MSC Message sequence chart
OTA Over-the-air
PLME Physical sublayer management Entity
PPDU Physical protocol data unit
SBSFU Secure boot and secure firmware update
SFU Secure firmware update
TPDU Transport protocol data unit
SAP Service access point
AN5411 - Rev 2
page 3/33
Term Definition
Firmware image A binary image (executable0 run by end-device as user application
Firmware header Meta-data describing the firmware image to be installed.
mbedTLS mbedTLS implementation of the TLS and SSL protocols and the associated cryptographic algorithm.
“.sfb” file Binary file packing the firmware header and the firmware image.
2.3 References
Reference Document
[1] LoRa Alliance Specification Protocol (LoRaWAN version V1.0.3), March 2018
[2] IEEE Std 802.15.4TM - 2011. Low-Rate Wireless Personal Area Networks (LR-WPANs)
[3]
[4] LoRa Alliance Remote Multicast Setup over LoRaWAN Specification v1.0.0, September 2018 – [TS-005]
[5]
[6] AN5056 Integration Guide for the X-CUBE-SBSFU STM32Cube Expansion Package – application note
[7] UM2262 - Getting started with the X-CUBE-SBSFU STM32Cube Expansion Package – user manual
[8] UM2073 – STM32 LoRa Expansion Package for STM32 - user manual
AN5411
References
Table 2. Terms used in this document
Table 3. Document references
LoRa Alliance Fragmented Data Block Transport over LoRaWAN Specification v1.0.0, September 2018 –
[TS-004]
LoRa Alliance Application layer clock synchronization over LoRaWAN Specification v1.0.0, September 2018
– [TS-003]
AN5411 - Rev 2
page 4/33
LoRa standard and FUOTA application feature
3 LoRa standard and FUOTA application feature
This section provides a general overview of the LoRa and LoRaWAN recommendations. It deals in particular with
the LoRa end-device and the FUOTA feature, which are the core subjects of this application note.
The LoRa software expansion is compliant with the LoRa Alliance LoRaWAN specification protocol [1].
3.1 Network architecture
Figure 1 shows the components and their protocol relationships, allowing the implementation of the firmware-
over-the-air feature.
Figure 1. Network diagram
AN5411
Note: In the I-CUBE-LRWAN FUOTA package, the device management block is not implemented. The LoRa Alliance
technical FUOTA working group is working on a LoRaWAN Firmware Management Protocol Specification, which
documents and defines this block. The proposed implementation in the FUOTA application is a proof of concept.
3.1.1 Client/server architecture
The end-device where the software or firmware is to be updated is referred to as the end node or client. The other
part of the system is referred to as the cloud or server, and provides the new software or firmware ( Figure 2).
Figure 2. Client/server architecture example
AN5411 - Rev 2
page 5/33
AN5411
End-device classes
3.1.2 End-device architecture
An end-device consists of a host MCU that reads sensor data in order to transmit the sensor reading over the
LoRa network by means of the LoRa radio module.
Data is encrypted by the host MCU and the radio packet is received by the gateway, which forwards it to the
network server. The network server then sends data to the application server, which has the right key to decrypt
the application data.
3.2 End-device classes
LoRaWAN [1] has several end-device classes to address the various needs of a wide range of applications.
The FUOTA application described in this application note is only 'Class-C enable'. In other words the FUOTA
application is validated for network infrastructure supporting only Class-C mode.
Note: The end-device supports Class-B mode. Nevertheless it is only 'Class B capable'. To be 'Class B enable' it is
mandatory to proceed to a new integration and validation phase on a network infrastructure supporting Class-B
mode for the FUOTA campaign.
3.2.1 Class definition
• Bi-directional end devices - Class A - (all devices) see [1]
• Bi-directional end-devices with scheduled receive slots - Class B – (Beacon) see [1]
• Bi-directional end-devices with maximal receive slots - Class C – (Continuous)
Class-C mode is implemented to support FUOTA. Class-C end devices have almost continuously-open receive
windows (RxC where the data blocks are received), and are only closed when transmitting (Tx) and receiving
(Rx1, Rx2) in Class-A mode (Figure 3).
Figure 3. Tx/Rx timing diagram (Class C)
AN5411 - Rev 2
page 6/33
3.3 FUOTA - firmware update over the air
The FUOTA update process transfers a new software image (data file) from the server to the client, and updates
the current software image (version N) running on the client with the new received software image (version N+1).
Obstacles to successful completion of the FUOTA update process are:
• Communication. The new firmware image must be sent from the server to the client. This challenge is
performed through the application-layer protocols running over LoRaWAN, which provide remote-multicast
setup, fragmented data-block transport, and application-layer clock-synchronization services. The LoRaWAN
Mac layer provides Class-C mode to transmit the data file in unicast or multicast mode.
• Firmware update. The client must migrate from the current to the new firmware image. This task is
performed by the Update_Agent module. To succed, the Update_Agent module relies on the services
provided by the SBSFU application.
• Memory. The software architecture must be organized so that it can be executed when the update process
completes. The solution must ensure the recovery of the new software version if there are installation issues.
This task is handled by the SBSFU application.
• Security. When a new firmware image is sent wirelessly from server to client, several security services
must be assured, such as: authentication, confidentiality and integrity. This must be done either through the
LoRaWAN protocol or by means of the SBSFU application security services.
3.4 Network protocol architectures
This section describes the end-to-end network protocol architecture (see Figure 4). The following protocol
exchanges are used:
• MAC protocol data unit exchanges (MPDU)
• application protocol of an application data unit exchanges (APDU)
• LoRaWAN protocol physical protocol data unit layer (PPDU).
AN5411
FUOTA - firmware update over the air
Figure 4. LoRa network protocols
AN5411 - Rev 2
page 7/33
3.4.1 Network layer
The LoRaWAN architecture is defined in terms of blocks called layers. As shown in Figure 5, each layer is
responsible for one part of the standard and offers services to higher layers. An end-device is made up of :
• a PHY, which embeds the radio frequency transceiver
• the MAC sublayer that provides access to the physical channel
• application layers that provide access to the LoRaWAN services protocol.
AN5411
Network protocol architectures
Figure 5. LoRaWAN layers
Upper layers (apps)
MAC
3.4.2 Physical layer (PHY)
The physical layer provides two services:
• the PHY data service enables the Tx/Rx of physical protocol data units (PPDUs)
• the PHY management service enables the personal-area network-information base (PIB) management.
3.4.3 MAC layer
The MAC layer provides two services:
• The MAC data service enables transmission and reception of MAC protocol data units across the physical
layer (MPDU)
• The MAC sublayer management enables the PIB management.
Phy
Physical medium (air interface)
AN5411 - Rev 2
page 8/33
3.4.4 Application layer
The application layer provides several messaging packages running over the LoRaWAN protocol. Here, FUOTA
scopes the following:
A clock synchronization package (port Number 202)
• Synchronizes the end-device real-time clock to the network’s GPS
• Makes all end devices of a multicast group to switch to Class C temporarily and synchronously.
A fragmented-data-block transport package (port Number201)
• Sets up / reports / deletes fragmentation transport sessions
• Several fragmentation sessions may be supported simultaneously by an end-device
• Fragmentation can be used either over multicast or unicast
• Reports the status of a fragmentation session.
A remote multicast setup package (port Number 200)
• Remotely creates a multicast group security context inside a group of end devices
• Reports the list of multicast contexts existing in the end-device
• Remotely deletes a multicast security context.
• Programs a Class-C multicast session
• Programs a Class-B multicast session.
Firmware management package (port Number 203) - (proof-of-concept implementation only)
• Queries/manages the firmware version running on an end-device (including availability of the firmwareupdate version)
• Queries/manages the end-device hardware version
• Manages the end-device reboot at a given time.
Update agent module
• Interfaces a LoRaWAN stack block to an SBSFU block
• Get and transmit the complete file (after recombination) to the secure firmware update (SFU) process of the
SBSFU.
User application
• Sensor/actuator processing – application use cases
• Required to start a FUOTA session, with some user uplinks to open useful Rx windows for the packages
described above.
AN5411
Network/end-device interworking
3.5
Network/end-device interworking
This section only shows the information flow between end-device and application server at the application-layer
level during a FUOTA campaign. For a complete view and description of the end-device and network interactions,
refer to the STM32 LoRa expansion package user manual [8].
3.5.1 Multicast and fragmentation set-up
Time synchronization
Before seting up a FUOTA session, the end-device must have synchronized its timing with the network using
either AppTimeReq or DeviceTimeReq as shown in Figure 6.
AN5411 - Rev 2
page 9/33
Network/end-device interworking
Figure 6. Message sequence chart for device timing
AN5411
Note: For the purposes of this presentation, the TimeReq sent by the MSC is divided into DeviceTimeReq and
AppTimeReq parts. The LoRaWAN specification allows a MAC command to be piggybacked in an application
payload. In the current implementation DeviceTimeReq is piggybacked in the AppTimeReq payload.
Multicast, fragmentation setup and session creation (Class C only)
In order to receive a data block at the application level, it is necessary to have some exchanges between the
network application layer and the end-device application layer. These exchanges are mainly to define: a Multicast
Group ID, the fragmentation parameters (frag number and frag size), and the multicast Class C session (start time
and end time).
AN5411 - Rev 2
page 10/33
Loading...