Introduction to LoRaWAN®

This page contains information such as, application examples, document references, and tips related to STM32 LoRaWAN®.

1. LoRaWAN^® overview

1.1. what is LoRaWAN^®

LoRa Alliance^® , is a nonprofit association that defines and promotes the LoRaWAN^® .
This section provides a general overview of LoRaWAN^®. It particularly focuses on the LoRaWAN^® end device. LoRaWAN^® is a type of wireless telecommunication network designed to allow long-range communication (kilometers) at a very-low bit rate. Hence, it is suitable for transmitting small-size payloads such as sensor data. Moreover, it enables long-life battery-operated sensors and actuators (they can last up to 10 years on a single coin cell battery).
Typical use cases are for examples smart farms to measure soil moisture in rural areas. However, thanks to the deep indoor penetration, for example, to cover easily multifloor buildings. It is used also for indoor application or for water-meter counters in cities. It can be deployed both on public and private networks since it operates on license-free subgigahertz bands. Moreover, it allows saving operator fees.

LoRaWAN^® is a MAC (media access control) layer protocol built on top of LoRa^® modulation.

LoRa^® (which stands for "Lo(ng) Ra(nge)") is a proprietary (Semtech) low-power wide-area network (LPWAN) modulation technology. It is based on spread-spectrum modulation techniques that are similar to and a derivative of chirp spread spectrum (CSS) modulation.
LoRa^® operates on the following license-free subgigahertz bands:

Region	Band (MHz)	Duty cycle (%)	Output power
EU	868	< 1	+13
EU	433	< 1	+10
US	915	No	+27
CN	779	< 0.1	+10
AS	923	No	+13
IN	865	No	+27
KR	920	No	+11
RU	864	< 1	+13
AU	915	No	+28
CN	470	No	+17

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® .

LoRaWAN^® is a protocol layer that defines how devices use the LoRa^® radio. It defines the network architecture, the communication, and security protocol and ensures interoperability with the LoRaWAN^® network.
LoRaWAN^® message types are used to transport both MAC commands and application data. They can be uplink and downlink. Message types depend on the specification’s versions 1.0.x and 1.1. The authenticity and integrity of messages between the end device and the network server uses AES-CMAC (cipher-based message authentication code). It is also called MIC (message integrity code). The secure communication between the end device and the application server uses AES-128 encryption.

The LoRa Alliance^® develops and maintains the LoRaWAN^® protocol.
As announced by the LoRa Alliance^® on December 7, 2021, LoRaWAN^® is officially approved as a standard for LPWAN (low power-wide area networking) by the International Telecommunication Union (ITU). The LoRa Alliance^® certification program certifies end devices. It provides end users with confidence on the devices reliability and compliancy with the LoRaWAN^® specification.

1.2. LoRaWAN^® network architecture

The LoRaWAN^® network is structured in a star of stars topology where end devices are connected via a single LoRaWAN^® link to one gateway.

The overall architecture is mainly composed by the following elements:

• End devices are wirelessly connected to a LoRaWAN^® network through radio gateways.
• Gateways forward all received LoRaWAN^® radio packets to the network server.
• Network server is the center of the star topology. It runs on a server that manages the entire system.
• Application servers handle all the application layer payloads of the associated end-devices and provides the application-level service to the end user.

LoRaWAN® core network

LoRaWAN^® networks primarily use the ALOHA method for communication between end devices and their associated network servers.
End devices send data through one or more gateways to the network server.
In a LoRaWAN^® network, packets broadcast asynchronously by end-devices are picked up by one or more gateways within the network.
There are several network server (NS) providers (private and public). However, gateways are only registered to a specific NS. Hence, end devices should be registered only to one NS. As already mentioned, the message that is sent by the end device is always received by all gateways in the range of the signal. Each gateway forwards the message to the network server that is associated to that gateway. If the end device is not registered on that NS, the NS discharges the message. If the NS receives the same message from different gateways (registered on that NS), it handles the multiple copies keeping the best. On the downlink side, the NS chooses the best gateway to communicate with a given end device. All end devices in the range (with opened Rx windows) receive that message but only the targeted end device (or end devices in the multicast use case) decodes it.
The application layers of end devices are typically connected (via the network server). There are connected to one or more application servers in the cloud (such as, dashboard, logger, proprietary protocol solution as FUOTA). The end device, exchanges messages on different ports to "the cloud". Each port is redirected to the specific application server defined into the NS.

1.2.1. LoRaWAN^® end device

LoRaWAN end-devices are typically sensors or actuators. They spend most of their time asleep, for example they wake up only when their sensors notify a particular change in their environment or when some other event is triggered such as timer expiring. During this time, they consume less than one microampere of energy. This power-saving method ensures that applications can achieve a lifespan of 10 years on a very small battery.

The LoRaWAN^® end device classes are defined in the table below:

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

All LoRaWAN^® devices must implement Class-A, whereas Class-B and Class-C are extensions to the specification of class-A devices.

Bi-directional class-A end devices (All devices)
After the end device sends the uplink, it listens for a message from the network one and two seconds after the uplink before going back to sleep.

• 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.
• Transmission slot is based on the own communication needs of the end device (ALOHA-type protocol).

Tx/Rx time diagram (Class-A)

Bi-directional Class-B end devices with scheduled receive slots

• Mid-power consumption
• Class-B devices open extra receive windows at scheduled times.
• For the end device to open the receive window at the scheduled time, the end device receives a beacon-synchronized time 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.

Tx/Rx time diagram (Class-B)

Bi-directional class-C end devices with maximal receive slots

• Large power consumption
• Class-C end devices have nearly continuously open receive windows, only closed when transmitting

Tx/Rx time diagram (Class-C)

In order to connect to a LoRaWAN^® network, the end device must follow an activation procedure.
There are two types of activation procedure:

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.

1.2.2. LoRaWAN^® Gateway

Gateway is a multi-channel and multidata rate radio-frequency device that can scan and detect the packets broadcasted by one or more end-devices on any of the active channels and then demodulate the packets. Gateway is a simply path to the core network and has no built-in intelligence.

• Gateway is made of very simple and inexpensive hardware device.
• Roaming from cell to cell is not required. End devices broadcast packets without making any assumption about which gateway is to receive these packets.

A gateway is required in a LoRaWAN^® network. It is the interface between LoRaWAN^® end device and the cloud. A gateway is basically converting RF LoRa^® packet from/into an UDP/IP packet to the cloud.

• P-NUCLEO-LRWAN2: STM32 Nucleo pack LoRa^® HF band sensor and gateway
• P-NUCLEO-LRWAN3: STM32 Nucleo pack LoRa^® LF band sensor and gateway
• STM32MP1+RAK Gateway

Other Gateway:

• The Things Gateway
• Kerlink Gateways

And many more exists out there!

1.2.3. LoRaWAN^® network server

The network server is the central component of a LoRaWAN^® network. It carries all the required intelligence to manage the network and dispatch data to other servers. It communicates with other servers (join server) to organize roaming and links to application servers. It is responsible for :

• Packet validation: multiple copies of the same data packet may reach the network server via multiple gateways. The network server must keep track of these copies, analyze the quality of the packets received, and inform the network controller.
• Routing: for messages, which are sent from the network server to an end device, the network server decides which is the best route to send a message to a given end device. Therefore, this decision is based on a link quality indication that is calculated based on the RSSI and SNR of the previously delivered packets. This decision can also be made following the availability of the gateway (is it possible to transmit, exhausted duty cycle?).
• Control: the link quality can also help the network server to decide the best SF for the communication speed for a given end device. This is the ADR policy, which is managed through the network controller.
• Network and gateway monitoring: gateway is typically connected to the network server via an IP link. Similarly, the network usually has a gateway commission and monitor interface allowing the network provider to manage and monitor their gateways.

Following public network servers can be used:

• Loriot
• TheThingsNetwork
• Actility
• AWS IoT Core for LoRaWAN

The following open-source code is also available to implement a private network server:

• ChirpStack (Open Source)

1.2.4. LoRaWAN^® application server

The application server handles all the application layer payloads of the associated end-devices and provides the application-level service to the end user. It also generates all the application-layer downlink payloads towards the connected end-devices. There may be multiple application servers connected to a network server, and an application server may be connected to several network servers (operating end-devices through several networks, for example). An application server may also be connected to multiple join servers, which manage the Over The Air end-device activation process.

Many "connectors" or "application outputs" are usually proposed to forward LoRaWAN^® end-device data to third party HTTP cloud services

• Amazon AWS IoT
• Azure IoT Hub
• IBM Cloud
• myDevices Cayenne
• Many MQTT sockets or REST APIs

2. Wiki LoRaWAN^®: pages breakdown

STMicroelectronics offers different devices and hardware tools to evaluate and develop a LoRaWAN^® End-Device. STMicroelectronics LoRaWAN^® products are summarized here. The choice depends on the customer constraints and AN5408 can help to choose.

• STM32WL Ecosystem with specifically its
  • Cube Software setup also known as STM32CubeWL
  • Hardware setup

• I-CUBE-LRWAN ecosystem including
  • B-L072Z-LRWAN1: STM32L0 Discovery kit LoRa^®, Sigfox, low-power wireless
  • I-CUBE-LRWAN: LoRaWAN^® software expansion for STM32Cube

3. Getting started with STM32WL Series and LoRaWAN^®

The STM32WL device architecture leverage state-of-the-art STM32 ultra-low-power process node. It is available from 64 KB up to 256 KB of flash memory and from 20 KB to 64 KB of SRAM. The silicon die integrates an Arm^® Cortex^®-M4 and Cortex^®-M0+ core (single and dual-core architectures) as well as a sub-GHz radio based-on Semtech SX126x.
Various packages are available: UFQFN48, UFBGA73.

The STM32WL Nucleo-64 development board is the NUCLEO-WL55JC integrating the STM32WL microcontroller dual-core in UFBGA73 package (with 256 KB of flash memory and 64KB of SRAM). It also integrates an STLINK-V3 debugger/programmer, 3 users LEDs, three users buttons, one reset push-button, and several boards connector (Arduino expansion connector, ST morpho extension pin headers and SMA connector). The board is delivered with an SMA antenna.

The Nucleo development board exists in two frequency bands:

Nucleo Reference	Description
NUCLEO-WL55JC1	High-frequency band. RF frequency range from 865 to 928 MHz for EU/US/APAC
NUCLEO-WL55JC2	Low-frequency band. RF frequency range from 433 to 510 MHz for EU/CN

On the software side, the STM32CubeWL MCU Package provides a software solution to allow customers to quickly and easily develop their own firmware thanks to:

• several LoRaWAN^® certified applications
• several Radio applications based on LoRa^®, (G)FSK, (G)MSK, and BPSK modulations

The STM32CubeWL software Package can also be found on Github here

Most RF applications in STM32CubeWL MCU package include the ioc file to be used with STM32CubeMX tool. This allows to modify several parameters and regenerate the code accordingly. It can also be used to port the code on Azure ThreadX RTOS instead of the sequencer. A video tutorial is available on YouTube: How to port an existing RF application on Azure ThreadX RTOS.

4. STM32WL learning center

4.1. STM32WL LoRaWAN^®

LoRaWAN^® Hands-on Development with the STM32WL
LoRaWAN^® Hands-on Development with the STM32WL Wireless System-on-Chip MCU

STM32WL Online Training
This training set introduces thepSTM32WL and ecosystem

4.2. STM32WL MOOC (massive online courses)

LPWAN theory
Learn main principles concerning LPWAN protocols

STM32CubeMonitor: how to perform RF functional tests on STM32WL MOOC
Learn basic principles concerning STM32WL55 RF parameters monitoring using STM32CubeMonitor

STM32WL security MOOC
Learn main principles concerning security within the STM32WL family and LoRaWAN^®

STM32WL LoRa Guide
Learn how to setup a LoRaWAN^® Network using a STM32WL with a LoRaWAN_EndNode including environmental and motion sensors

5. STM32CubeWL software application notes and user manuals

• AN5406 How to build a LoRa^® application with STM32CubeWL

• AN5408 Migrating from STM32L0, STM32L1, and STM32L4 Series associated with SX12xx transceivers to STM32WL Series microcontrollers

• AN5481 LoRaWAN^® AT commands for STM32CubeWL

• AN5554 LoRaWAN^® firmware update over the air with STM32CubeWL

• AN5556 Getting started with STM32WL dual core using IAR™ and Keil^®

• AN5564 Getting started with projects based on dual-core STM32WL microcontrollers in STM32CubeIDE (contains also useful tips for dual core debug !)

• AN5682 How to secure LoRaWAN^® and Sigfox™ with STM32CubeWL

• AN5687 Long-packet operation with STM32CubeWL

6. STM32WL hardware guidance

• STM32WL
  • STM32WL Series Product selector
  • RM0453 STM32WL5x (Dual Core) Reference Manual
  • DS13293 STM32WL5x (Dual Core) Datasheet
  • RM0461 STM32WLEx (Single Core) Reference Manual
  • DS13105 STM32WLEx (Single Core) Datasheet

• Boards
  • NUCLEO-WL55JC NUCLEO-WL55JC Development board
  • AN5407 Optimized RF board layout for STM32WL Series
  • AN5457 RF matching network design guide for STM32WL Series
  • AN5566 RF certification process for NUCLEO-WL55JC
  • AN5664 RSSI and SNR for LoRa^® modulation on STM32WL Series]

• Reference Designs
  • 4-Layer Reference design based on SMDs with STM32WL UFQFPN MCU
  • 2-Layer Reference design based on SMDs with STM32WL UFQFPN MCU
  • 4-Layer Reference design based on SMDs with STM32WL UFBGA MCU
  • Multiconnectivity asset tracking reference design based on STM32WB5MMG and STM32WL55JC
  • Generic Node Sensor Edition reference design

7. Specific tools

• STM32CubeMonitor- Software tool to test the RF performance of STM32-based hardware devices. Refer to wiki STM32CubeMonitor for LoRa for more details.

• STM32CubeMX - STM32Cube initialization code generator. Refer to wiki STM32CubeMX for more details.

• STM32CubeProgrammer- Software Programmer for all STM32.

• STM32CubeIDE- C/C++ development platform for all STM32. Refer to wiki STM32CubeIDE for more details.

• STM32PowerShield - Power and Analyze current consumption

8. Frequently asked questions

• Where can I find the source code of the firmware and examples running on STM32WL5x/Ex boards ?

The last firmware package can be found on st.com : https://www.st.com/en/embedded-software/stm32cubewl.html, in the Get Software section

• Where do I have to do my first modifications to modify the data sent and received?

1. In your project, for example End_Node, go to Application/User/LoRaWAN/App/lora_app.c, you will find the function SendTxData(), where you can modify the buffer that will be sent via LoRa modulation (and add (or replace) for example AppData.Buffer[i++]=YourValue;)
2. You can use the same process with the received data in the function OnRxData()

• Is it possible to communicate in LoRa^® without using the LoRaWAN^® stack ?

Yes we have examples it the STM32Cube_FW_WL_V1.2.0 firmware package.

subGHz_Phy examples (Ping_Pong, AT_slave, PER) describe how to communicate only with LoRa^® modulation "STM32Cube_FW_WL_V1.2.0\Projects\NUCLEO-WL55JC\Applications\SubGHz_Phy\SubGHz_Phy_PingPong" for example

• How to debug a Dual Core project?

Follow the AN5564 (see section 5 STM32WL software application notes and user manuals), do not forget to increase the port number of at least 3 in the CM0+ debug config

Be sure to set the LOW_POWER_DISABLE and DEBUGGER_ENABLED variables to 1 in the CM4 and CM0+ project

If you use STM32CubeIDE, please do not use v1.9.0, there is an issue with the last version of this IDE, instead use v1.8.0.

• I cannot debug, I have the following message "target not responding"

Do not forget to set to 1 the two following variables in sys-conf.h (found in the include section), to be able to debug your software LOW_POWER_DISABLE and DEBUGGER_ENABLED

• Modifying the "APP_KEY" but it is impossible to join The Thing Network

The problem is that it is not clear how the different keys were named and what they are use to. The "APP_KEY" define in The Thing Network, is the key you need to join the network.

This implementation differ from the Link Layer specifications but we choose to stay closer from this implementation. That is what is done in the code, but it does not concord with The Thing Network expectations. If you modify the "APP_KEY" you will have a mismatch because the "APP_KEY" in The Thing Network means the "NWK_KEY", and so it's not the same you register in your device config.

So if you use the "LmHandlerSetAppKey()" function to modify the "APP_KEY" of The Thing Network, you will need to use "LmHandlerSetNwkKey()" function.

• I want to switch from LoRaWAN Link Layer version from 1.0.3 to 1.0.4, how can I do ?

You can refer to the AN5406, you can access from STM32WL software application notes and user manuals section

One thing you have to know is that those two versions does not work the same, so you have to specify, when you configure your network, the right version.

To see on which version you are configured, or you can access the file lorawan_conf.h you can access from your project in : "Application/User/LoRaWAN/Target". You will find the variable LORAMAC_SPECIFICATION_VERSION that can take two values "0x01000400" corresponding to 1.0.4 version and "0x01000300" corresponding to 1.0.3 version.

You can also verify the version used by connecting the board to your PC via UART, and when you restart your program, you find a field corresponding to the L2_SPEC_VERSION

When you configure your device in The Thing Network, for example, you have to specify "Firmware Ver.", if you use 1.0.3 select LoRaWAN_End_Node v1.1.0, if you use 1.0.4 select LoRaWAN_End_Node v1.2.0.

• How can I do multicast in classC with End_Node project

First, you must know the multicast is not implemented in Class-B on our devices, it is supported only in Class-C.

On the device side, you must use the remote multicast package that is use when you want to enable a FUOTA session

(LmhpRemoteMcastSetup.c).

You have to enable this package by calling the function LmHandlerPackageRegister (PACKAGE_ID_REMOTE_MCAST_SETUP, NULL) define in LmhpPackagesRegistration.c

This allows the device to support LoRa^® MAC commands related to multicast.

On the server side, you must ensure that the application server you are working with uses the same protocol as the one implemented in the device.

When we develop our code, we use the technical specification TS005 1.0.0 as reference, so if the server Loriot, or The Thing Network, or Actility… do not use the same protocol with the same commands you could not establish a multicast session (check the spec of each server to know which one is supported).

You can also create your server and if you follow the TS005, create the MAC commands the server need to send to the devices to match with the ones describes in TS005, and enable a multicast session.

For more information, you can refer to this application note: AN5554, on section 2.4.4 Application Layer, section 2.5.2 multicast, fragmentation setup and session creation (Class C only) and section 5.1 LoRaWAN middleware initialization or to the following post on the ST community: https://community.st.com/s/question/0D53W00001JCdeESAT/has-anyone-managed-to-make-a-working-lorawan-multicast-with-stm32wl-if-so-how

• You do not find the answer to your question here? Check if someone else has not already answered it in the ST community !

Feel free to create an account and ask your question if no one has encountered your problem before, we provide you a solution as soon as possible!

https://community.st.com/s/

9. See also

• FUOTA with Actility
• How to create a LoRaWAN server on local PC 1/2
• How to create a LoRaWAN server on local PC 2/2

10. Terms and definitions

Term	Definition
ABP	Activation by personalization
ADR	Adaptive Data rate
AES	Advanced encryption standard
CMAC	Cipher-based Message authentication code
CSS	Chirp spread spectrum
BPSK	Binary phase-shift keying
BSP	Board support package
FSK	Frequency-shift keying
HAL	Hardware abstraction layer
HTTP	Hypertext Transfer Protocol
LoRa®	Long Range radio technology
LoRaWAN®	LoRa® wide-area network
LPWAN	Low-power wide-area network
MAC	Media access control
MCU	Microcontroller unit
MIC	Message integrity code
MSK	Minimum-shift keying
OTAA	Over-the-air activation
PER	Packet error rate
RF	Radio Frequency
RSSI	Received Signal Strength Indicator
Rx	Reception
SF	Spreading Factor
SMA	Subminiature version A
SNR	Signal-to-Noise Ratio
SRAM	Static random access memory
Tx	Transmission