LoRaWAN® overview

Coming soon

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

1. LoRaWAN^® overview

1.1. What is LoRaWAN^® ?

This section provides a general overview of LoRaWAN^® , particularly focusing 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 (suitable for transmitting small size payloads like sensor data) and enabling long-life battery-operated sensors and actuators (they can last up to 10 years on a single coin cell battery).
Classical use case is for smart farms to measure soil moisture in rural areas, but thanks to the deep indoor penetration (e.g. easily cover multi floor buildings) it is used also for indoor application. It can be deployed on public network as on private network (saving operator fees).
LoRaWAN^® defines the communication and security protocol ensuring interoperability with the LoRaWAN^® network. The secure communication between the end device and the application server uses AES-128 encryption. The authenticity and integrity of messages between the end device and the network server uses AES-CMAC (Cipher-based Message Authentication Code). Often in LoRaWAN^® literature "Message Authentication Code" is called MIC (Message Integrity Code) because MAC acronymous is used for "Media Access Control".

By a technical point of view LoRaWAN^® is a MAC (Media Access Control) layer protocol built on top of LoRa^® modulation.

LoRa^® (from "Long Range") is a proprietary low-power wide-area network (LPWAN) modulation technology based on spread-spectrum modulation techniques that is similar to and a derivative of chirp spread spectrum (CSS) modulation. It was developed by Cycleo, later acquired by Semtech.
LoRa^® can be operated on the license free sub-gigahertz bands, like EU433 (433.05-434.79 MHz) and EU863-870 (863–870 MHz) in Europe, US902-928 (902–928 MHz) in North America, and so on for other countries and continents. That explains why private network can be implemented.

LoRaWAN^® is a software layer which defines how devices use the LoRa^® hardware, it is protocol which defines the communication rules from the format of the messages to the network architecture and security aspects.
LoRaWAN^® message types are used to transport MAC commands and application data. They can be uplink and downlink. Message types depends on the specification’s versions 1.0.x and 1.1.

The LoRaWAN^® protocol is developed and maintained by the LoRa Alliance^®.
As announced by the LoRa Alliance^® on December 7, 2021, LoRaWAN^® is officially approved as a standard for Low Power Wide Area Networking (LPWAN) by the International Telecommunication Union (ITU). The LoRa Alliance^® certification program certifies end devices and provides end-users with confidence that the devices are reliable and compliant with the LoRaWAN^® specification.

The LoRaWAN^® 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.

1.2. LoRaWAN^® Device

... only when their sensors notify a particular change in their environment or when some other event is triggered, such as a timer expiring.

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.

End-devices spend most of their time asleep. 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.

1.3. LoRaWAN^® 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.

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 gateway to the network server.

In a LoRaWAN^® network, Packets broadcast asynchronously by end devices will be picked-up by one or more gateways within the network

• 

  LoRaWAN core network

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

1.3.1. LoRaWAN^® Gateway

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

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

• LoRaWAN Nwk GW.png

  LoRAWAN Gateway

A Gateway is required in a LoRaWAN Network. It is the interface between LoRaWAN End Device and the Cloud. A Gateway is basically converting Lora ^® packet from/into an udp 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.3.2. 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 will be 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 by the network controller.
• Network and Gateway Monitoring: Gateway(s) 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 gateway(s).

• LoRaWAN Nwk server.png

  LoRaWAN Network Server

• Loriot
• TTN
• Actility
• ChirpStack

1.3.3. LoRaWAN^® Application Server

In addition, the LoRaWAN^® network communicates with other servers to organize roaming, links to application servers and more.

The LoRaWAN^® protocol is designed to support different types of networks. In some cases the network provider and the application provider are the same entity. In other cases they are not in the same entity.
Given these differences, application servers may be integrated with the network server or hosted elsewhere. Indeed, different application vendors provide heterogeneous applications

• LoRaWAN Appli server.png

  LoRaWAN Application Server

2. Wiki LoRaWAN^®: pages breakdown

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

• STM32WL Ecosystem
  • Cube Software setup
  • Hardware setup

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

3. Getting started with STM32WL Series and LoRaWAN^®

The STM32WL device architecture leverage state-of-the art STM32 ultra-low-power process node and is available from 64KB up to 256KB of Flash memory and from 20KB 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 256KB of Flash and 64KB of SRAM), as well as an STLINK-V3 debugger/programmer, 3 users LEDs, 3 users buttons, 1 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 2 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

4. STM32WL learning center

4.1. STM32WL LoRaWAN^®

STM32WL Online Training

This training set introduces the STM32WL 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 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. STM32WL software application notes and user manuals

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

• AN5481 LoRaWAN^® AT commands for STM32CubeWL

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

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

• AN5687 Long-packet operation with STM32CubeWL

• AN5564 Getting started with projects based on dual-core STM32WL microcontrollers in STM32CubeIDE

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

6. STM32WL hardware guidance

• STM32WL Series Product selector

• NUCLEO-WL55JC Development board

• RM0453 STM32WL5x (Dual Core) Reference Manual

• DS13293 STM32WL5x (Dual Core) Datasheet

• RM0461 STM32WLEx (Single Core) Reference Manual

• DS13105 STM32WLEx (Single Core) Datasheet

• 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

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

9. LoraWAN Alliance

https://lora-alliance.org/ lorawan-certification

10. Frequently Asked Questions

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

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 exemple 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 exemple

• How to debug a Dual Core project?

Follow the AN5564 (see section 5 STM32WL software application notes and user manuals), don't 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 can't debug, I have the following message "target not responding"

Don't 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 will 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 will find a field corresponding to the L2_SPEC_VERSION

When you configure your device in The Thimg Network for exemple, you will 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’s 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 will allow the device to support LoRa^® MAC commands related to multicast.

On the server side, you must ensure the Application Server you are working with use 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).

Also, you can 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 don't find the answer to your question here ? Check if someone else haven't already answer it in the ST Community !

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

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

11. The ST Blog

FUOTA

12. Terms and definitions

Term	Definition
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
LoRa®	Long Range radio technology
LoRaWAN®	LoRa® wide-area network
LPWAN	Low-power wide-area network
MAC	Media access control
MIC	Message integrity code
MSK	Minimum-shift keying
SMA	Subminiature version A
SRAM	Static random access memory