ST I-CUBE-LRWAN User manual

Introduction
This user manual describes the I-CUBE-LRWAN LoRaWAN® Expansion Package implementation on the STM32L0 Series,
STM32L1 Series, and STM32L4 Series microcontrollers. This document also explains how to interface with the LoRaWAN® to
manage the LoRa® wireless link.
LoRa® is a type of wireless telecommunication network designed to allow long-range communications at a very low bit-rate
and enabling long-life battery-operated sensors. LoRaWAN® defines the communication and security protocol that ensures
interoperability with the LoRa® network. The LoRaWAN® Expansion Package is compliant with the LoRa Alliance® specification
protocol named LoRaWAN®.
The I-CUBE-LRWAN main features are the following:
• Integration-ready application
•Easy add-on of the low-power LoRa® solution
• Extremely-low CPU load
• No latency requirements
• Small STM32 memory footprint
• Low-power timing services provided
The I-CUBE-LRWAN Expansion Package is based on the STM32Cube HAL drivers (Refer to LoRa standard overview).
This user manual provides customer examples on NUCLEO-L053R8, NUCLEO-L073RZ, NUCLEO-L152RE, and NUCLEO-
L476RG using Semtech expansion boards SX1276MB1MAS, SX1276MB1LAS, SX1272MB2DAS, SX1262DVK1DAS,
SX1262DVK1CAS, and SX1262DVK1BAS.
This document targets the following tools:
•P-NUCLEO-LRWAN1, STM32 Nucleo pack for LoRa® technology (Legacy only)
•P-NUCLEO-LRWAN2, STM32 Nucleo starter pack (USI®) for LoRa® technology
•P-NUCLEO-LRWAN3, STM32 Nucleo starter pack (RisingHF) for LoRa® technology
•B-L072Z-LRWAN1, STM32 Discovery kit embedding the CMWX1ZZABZ-091 LoRa® module from Murata
•I-NUCLEO-LRWAN1, LoRa® expansion board for STM32 Nucleo, based on the WM-SG-SM-42 LPWAN module (USI®)
available in P-NUCLEO-LRWAN2
• LRWAN-NS1, expansion board featuring the RisingHF modem RHF0M003 available in P-NUCLEO-LRWAN3
STM32 LoRaWAN® Expansion Package for STM32Cube
UM2073
User manual
UM2073 - Rev 12 - September 2021
For further information contact your local STMicroelectronics sales office.
www.st.com

1General information
The I-CUBE-LRWAN Expansion Package runs on STM32 32‑bit microcontrollers based on the Arm® Cortex®-M
processor.
Note: Arm is a registered trademark of Arm Limited (or its subsidiaries) in the US and/or elsewhere.
1.1 Terms and definitions
Table 1 presents the definitions of the acronyms that are relevant for a better contextual understanding of this
document.
Table 1. List of acronyms
Acronym Definition
ABP Activation by personalization
App Application
API Application programming interface
BSP Board support package
FSM Finite‑state machine
FUOTA Firmware update over the air
HAL Hardware abstraction layer
IoT Internet of things
LoRa®Long-range radio technology
LoRaWAN®LoRa® wide-area network
LPWAN Low-power wide-area network
MAC Media access control
MCPS MAC common part sublayer
MIB MAC information base
MLME MAC sublayer management entity
MPDU MAC protocol data unit
OTAA Over-the-air activation
PLME Physical sublayer management entity
PPDU Physical protocol data unit
SAP Service access point
SBSFU Secure Boot and Secure Firmware Update
UM2073
General information
UM2073 - Rev 12 page 2/52

1.2 Overview of available documents and references
Table 2 lists the complementary references for using I-CUBE-LRWAN.
Table 2. References
ID Description
[1] LoRa Alliance specification protocol named LoRaWAN version V1.0.3 July 2018 final release
[2] Low-Rate Wireless Personal Area Networks (LRWPANs) IEEE Std 802.15.4TM, 2011
[3] LoRaWAN® Regional Parameters v1.0.3revA, July 2018 release
[4] LoRa Alliance Fragmented Data Block Transport over LoRaWAN Specification v1.0.0 September 2018 [TS‑004]
[5] LoRa Alliance Remote Multicast Setup over LoRaWAN Specification v1.0.0 September 2018 [TS‑005]
[6] LoRa Alliance Application layer clock synchronization over LoRaWAN Specification v1.0.0 September 2018
[TS‑003]
[7] Application note Integration guide for the X-CUBE-SBSFU STM32Cube Expansion Package (AN5056)
[8] Application note I-CUBE-LRWAN embedding FUOTA, application implementation (AN5411)
[9] Application note Examples of AT commands on I-CUBE-LRWAN (AN4967)
[10] Application note How to build a LoRa® application with STM32CubeWL (AN5406)
[11] User manual Getting started with the P-NUCLEO-LRWAN2 and P-NUCLEO-LRWAN3 starter packs (UM2587)
[12] User manual STM32 Nucleo-64 boards (MB1136) (UM1724)
[13] User manual STM32WL Nucleo-64 board (MB1389) (UM2592)
[14] WM-SG-SM-42 AT Command Reference Manual located under USI_I-NUCLEO-LRWAN1(1)
[15] RHF-PS01709 LoRaWAN Class ABC AT-Command Specification available from RiSiNGHF home page(1)
1. This URL belongs to a third party. It is active at document publication, however, STMicroelectronics shall not be liable for
any change, move, or inactivation of the URL or the referenced material.
UM2073
Overview of available documents and references
UM2073 - Rev 12 page 3/52

2LoRa® standard overview
2.1 Overview
This section provides a general overview of the LoRa® and LoRaWAN® recommendations, particularly focusing
on the LoRa® end device that is the core subject of this user manual.
LoRa® is a type of wireless telecommunication network designed to allow long-range communication at a very
low bit rate and enabling long-life battery-operated sensors. LoRaWAN® defines the communication and security
protocol ensuring interoperability with the LoRa® network.
The LoRaWAN® Expansion Package is compliant with the LoRa Alliance® specification protocol named
LoRaWAN®.
Table 3 shows the LoRaWAN® class usage definition. Refer to Section 2.2.2 for further details on these classes.
Table 3. LoRaWAN® classes intended usage
Class name Intended usage
A - All
• Battery-powered sensors or actuators with no latency constraint
• Most energy-efficient communication class
• Must be supported by all devices
B - Beacon
• Battery-powered actuators
• Energy-efficient communication class for latency controlled downlink
• Based on slotted communication synchronized with a network beacon
C - Continuous
• Main powered actuators
• Devices that can afford to listen continuously
• No latency for downlink communication
Note: While the physical layer of LoRa® is proprietary, the rest of the protocol stack (LoRaWAN®) is kept open and its
development is carried out by the LoRa Alliance®.
2.2 Network architecture
The LoRaWAN® network is structured in a star of stars topology, where the end devices are connected via a
single LoRaWAN® link to one gateway as shown in Figure 1.
Figure 1. Network diagram
LoRaWAN® end device Gateway Network server Application server
Pet tracking
Smoke
alarm
Water meter
Trash
container
Vending machine
Gas
monitoring
UM2073
LoRa® standard overview
UM2073 - Rev 12 page 4/52

2.2.1 End-device architecture
The end device is composed of an RF transceiver (also known as radio) and a host STM32 MCU. The RF
transceiver is composed of a modem and an RF up-converter. The MCU implements the radio driver, the
LoRaWAN® stack and optionally the sensor drivers.
2.2.2 End-device classes
The LoRaWAN® has several different classes of end-point devices, addressing the different needs reflected in the
wide range of applications.
Bi-directional Class-A end devices (all devices)
• Class-A operation is the lowest power end-device system.
• Each end-device uplink transmission is followed by two short downlinks receive windows.
• Downlink communication from the server shortly after the end‑device has sent an uplink transmission (Refer
to Figure 2).
• Transmission slot is based on the own communication needs of the end device (ALOHA-type protocol).
Figure 2. Tx/Rx time diagram (Class-A)
Rx1 Rx2Tx
RxDelay2
RxDelay1
Bi-directional end‑devices with scheduled receive slots - Class-B - (beacon)
• Mid power consumption
• Class-B devices open extra receive windows at scheduled times (Refer to Figure 3).
• For the end device to open the receive window at the scheduled time, the end device receives a time-
synchronized beacon from the gateway.
• As Class‑A has priority, the device replaces the periodic ping slots with an uplink (Tx) sequence followed by
Rx1 or Rx2 received windows when required by the device.
Figure 3. Tx/Rx time diagram (Class-B)
Rx1 Rx2 Tx
RxDelay2
RxDelay1
PNG
BCN BCN
Beacon Period
Period Ping
PNG
UM2073
Network architecture
UM2073 - Rev 12 page 5/52

Bi-directional Class-C end devices with maximal receive slots (continuous)
• Large power consumption
• Class-C end devices have nearly continuously open receive windows, only closed when transmitting (Refer
to Figure 4).
Figure 4. Tx/Rx time diagram (Class-C)
RxC
Tx
RxDelay2
RxDelay1
Extends RxC until next uplink
On-air transmit time
Rx1 Rx2
RxC
RxC
2.2.3 End-device activation (joining)
Over-the-air activation (OTAA)
The OTAA is a joining procedure for the LoRaWAN® end device to participate in a LoRaWAN® network. Both the
LoRaWAN® end device and the application server share the same secret key known as AppKey. During a joining
procedure, the LoRaWAN® end device and the application server exchange inputs to generate two session keys:
• A network session key (NwkSKey) for MAC commands encryption
• An application session key (AppSKey) for application data encryption
Activation by personalization (ABP)
In the case of ABP, the NwkSkey and AppSkey are already stored in the LoRaWAN® end device that sends the
data directly to the LoRaWAN® network.
UM2073
Network architecture
UM2073 - Rev 12 page 6/52

2.2.4 Regional spectrum allocation
The LoRaWAN® specification varies slightly from region to region. The European, North American, and Asian
regions have different spectrum allocations and regulatory requirements (Refer to Table 4 for more details).
Table 4. LoRaWAN® regional spectrum allocation
Region Supported Band (MHz) Duty cycle (%) Output power
(dBm)(1)
EU Y 868 < 1 +13
EU Y 433 < 1 +10
US Y 915 No +27
CN N 779 < 0.1 +10
AS Y 923 No +13
IN Y 865 No +27
KR Y 920 No +11
RU Y 864 < 1 +13
AU Y 915 No +28
CN Y 470 No +17
1. The output power values are defined with the default maximal EIRP (Refer to the region associated section in [3]) and the
default antenna gain (2.15 by default): Default_Power = floor (Default_Max_EIRP - Default_Antenna_Gain)
UM2073
Network architecture
UM2073 - Rev 12 page 7/52

2.3 Network layer
The LoRaWAN® architecture is defined in terms of blocks, also called “layers”. Each layer is responsible for one
part of the standard and offers services to higher layers.
The end device is at least made of one physical layer (PHY), that embeds the radio frequency transceiver, a MAC
sublayer providing access to the physical channel, and an application layer, as shown in Figure 5.
Figure 5. LoRaWAN® layers
Upper layer
MAC
PHY
Physical medium (air interface)
2.3.1 Physical layer
The physical layer provides two services:
• The PHY data service, that enables the Tx/Rx of physical protocol data units (PPDUs)
• The PHY management service, that enables the personal area network information base (PIB) management
2.3.2 MAC sublayer
The MAC sublayer provides two services:
• The MAC data service, that enables the transmission and reception of MAC protocol data units (MPDU)
across the physical layer
• The MAC management service, that enables the PIB management
2.4 Message flow
This section describes the information flow between the N-user and the N-layer. The service request is performed
through a service primitive.
2.4.1 End-device activation details (joining)
Before communicating on the LoRaWAN® network, the end device must be associated or activated following one
of the two activation methods described in End-device activation (joining).
UM2073
Network layer
UM2073 - Rev 12 page 8/52

The message sequence chart (MSC) in Figure 6 shows the OTAA activation method.
Figure 6. Message sequence chart for joining (MLME primitives)
End-device
App layer
MLME.Req
(join request) Join request MLME.Ind
(join request)
Join response (ask)
MLME.Resp
(join accept)
MLME.Ind
(join accept)
MLME.Conf
(join accept)
MACWaitTimer
End-device App server
End-device
MAC layer
Network
MAC layer
Network
App layer
2.4.2 End-device class-A data communication
The end device transmits data by one of the following methods: through a confirmed-data message method
(Refer to Figure 7) or through an unconfirmed-data message (Refer to Figure 8).
In the first method, the end device requires an Ack (acknowledgment) to be done by the receiver while in the
second method, the Ack is not required.
When an end device sends data with an Ackreq (acknowledgment request), the end device must wait during an
acknowledgment duration AckWaitDuration to receive the acknowledgment frame (Refer to Section 4.3.1 ).
UM2073
Message flow
UM2073 - Rev 12 page 9/52

If the acknowledgment frame is received, then the transmission is successful, else the transmission failed.
Figure 7. Message sequence chart for confirmed data (MCPS primitives)
MCPS.Req
(data request)
Data (Ackreq=1)
Acknowledgment frame
MCPS.Ind (data)
MCPS.Conf()
AckWaitDuration
End device App Server
End-device
App layer
End-device
MAC layer
Network
MAC layer
Network
App layer
Figure 8. Message sequence chart for unconfirmed data (MCPS primitives)
End-device
App layer
MCPS.Req (data request) Data
(Ackreq=0)
MCPS.Ind (data)
MCPS.Conf()
End device App server
End-device
MAC layer
Network
MAC layer
Network
App layer
UM2073
Message flow
UM2073 - Rev 12 page 10/52