This article introduces the fundamentals of the LoRaWAN protocol from a technical perspective, divided into four parts: overview, MAC message format, regional parameters, and network access. Advanced topics such as MAC commands, Class B, ADR, and gateways will be covered in the next article.
1. Overview
LoRaWAN stands for LoRa Wide Area Network, which is a type of Low Power Wide Area Network (LPWAN). As the most widely used and mature LoRa networking standard, LoRaWAN has been deployed in 143 countries and regions worldwide. This standard is established by the LoRa Alliance, an open non-profit organization dedicated to promoting the global application of the LoRaWAN standard, currently boasting over 500 members, including more than 133 LoRaWAN network operators across 58 countries and regions. The official website of LoRaWAN is: https://lora-alliance.org/, where you can access a series of documents on LoRaWAN specifications, regional parameters, certification requirements, etc., which are open to the public and can be downloaded without registration.
By using the LoRaWAN protocol, a high-capacity, low-power, long-distance star network can be formed. A single gateway can cover a range of 1-2 km in urban areas and can support access for tens of thousands of nodes (Note: actual capacity depends on the number of gateway channels and the communication frequency of nodes). The LoRaWAN network consists of three parts: the server (Network Server), the gateway (Gateway), and the nodes (End Nodes). Nodes can be classified into three types: Class A, Class B, and Class C, with the main differences in their transmission and reception timing.
Class A, known as Class A all End Devices, is the baseline node device type for the LoRaWAN protocol. This node type follows the rule of random uplink transmission, opening a receive window (RX1) after each uplink. If no data is received in the first receive window, a second receive window (RX2) will be opened, making it very suitable for applications that primarily use battery power for uplink communication.
Class B, known as Class Beacon, is a node device type that synchronizes through beacons and receives periodically. It adds beacon synchronization functionality to Class A, synchronizing time and location information through beacon frames and periodically opening receive windows, with a cycle between 1-128 seconds, during which the server can send messages to the node. When the node’s location changes, it needs to send a message to the server to update the message routing path, suitable for applications that require random downlink and can tolerate some delay in downlink.
Class C, known as Class Continuously, is a node device type that continuously receives. It extends the second receive window to all time domains except for uplink and the first receive window. This allows the node to receive messages from the server at any time, but it significantly increases power consumption, making it suitable for applications that require random downlink with no delay and are not power-constrained.
Like all wireless communication technologies, LoRaWAN also faces issues of concurrency, anti-collision, and anti-interference.
Regarding concurrency, LoRaWAN gateways can support multiple channels for simultaneous transmission and reception, and each node can use different channels and different DRs for uplink simultaneously. Each uplink uses a frequency-hopping method by randomly selecting a channel. Thanks to the use of spread spectrum modulation technology, communication at different DRs on the same channel will not interfere with each other.
In terms of anti-collision, LoRaWAN adopts an acknowledgment mechanism, sending messages via confirmed messages, where the receiver must send an ack back to the sender. If the sender does not receive the ack, it will retransmit until it receives the ack or exceeds the maximum retransmission count.
For anti-interference, LoRa itself has good anti-interference performance, and LoRaWAN also employs several methods such as Listen Before Talk (LBT), Duty Cycle, and Dwell Time to reduce interference. Currently, the CN470 frequency band does not implement LBT, Duty Cycle, and Dwell Time mechanisms. According to the latest announcement from the Ministry of Industry and Information Technology, LBT and Dwell Time mechanisms may be adopted in the future.
2. MAC Message Format
LoRaWAN is a MAC layer protocol specification based on LoRa modulation technology, defining the MAC layer message format by segmenting and defining the Payload of the LoRa PHY Layer. The MAC layer message consists of three parts: MHDR, MACPayload, and MIC. MHDR is the MAC header, containing two fields: MType and Major. MACPayload can be expanded into FHDR, FPort, and FRMPayload. MIC is a 4-byte Message Integrity Code (MIC).
The MType field of MHDR indicates the message type. LoRaWAN defines a total of 7 types of messages: JoinRequest and Join Accept for network access messages, Confirmed and Unconfirmed messages for business data messages, where Confirmed messages require the receiver to reply with an Ack and can be retransmitted multiple times, while Unconfirmed messages do not require an Ack and can be redundantly retransmitted, and Proprietary messages can be customized. The Major field of MHDR is the MAC protocol version number field, currently 00b, indicating LoRaWAN R1.
|
MType |
Name |
|
000 |
Join Request |
|
001 |
Join Accept |
|
010 |
Unconfirmed Data Up |
|
011 |
Unconfirmed Data Down |
|
100 |
Confirmed Data Up |
|
101 |
Confirmed Data Down |
|
110 |
RFU |
|
111 |
Proprietary |
FHDR includes four parts: DevAddr, FCtrl, FCnt, and FOpts. DevAddr is a 4-byte node address, FCtrl is a control byte, FCnt is the message sequence number, and FOpts is optional, with a length of 0-15 bytes determined by the FOptsLen field in FCtrl, used to carry MAC commands.
The ADR bit in FCtrl is used to enable the Adaptive Data Rate (ADR) function, and the ADRACKREQ bit is used to request a network reply message during the ADR process to confirm that the gateway can receive messages from the node. The benefit of ADR is that it can reduce node power consumption while increasing network capacity. ACK is the confirmation bit for Confirmed messages. FPending indicates that the gateway has more messages waiting to be sent, and the node should immediately send an uplink message to open a new window to receive messages. Class B indicates that the node is in Class B mode and can receive messages during the Ping slot. FOptsLen determines the length of FOpts.
The FPort value of 0 indicates that FRMPayload is a MAC command, while a non-zero value indicates that FRMPayload is business data. When FOptsLen is non-zero, FPort can only be non-zero; it is not allowed to have MAC commands in both FOpts and FRMPayload simultaneously.
3. Regional Parameters
LoRa mainly operates in the Sub-GHz ISM band. Due to differences in the division of ISM bands around the world and the different wireless regulatory laws and regulations in various countries and regions, LoRaWAN has developed different regional parameters for different countries and regions, mainly reflected in frequency bands, modulation methods, channels (Ch), bandwidth (BW), communication rates (DR), transmission power (TxPower), Listen Before Talk (LBT), duty cycle, and dwell time aspects.
In major countries and regions, China uses 470MHz-510MHz, referred to as the CN470 frequency band; Europe uses 863MHz-870MHz, referred to as the EU868 frequency band; North America uses 902MHz-928MHz, referred to as the US915 frequency band; and India uses 865MHz-867MHz, referred to as the IN865 frequency band. This article uses the CN470 frequency band as an example; other regional parameters can be found on the LoRaWAN official website https://lora-alliance.org/.
The CN470 frequency band has divided 96 uplink channels and 48 downlink channels. Uplinks start at 470.3MHz, with 1 channel every 200KHz, while downlinks start at 500.3MHz, with 1 channel every 200KHz. The modulation bandwidth is uniformly set at 125KHz, with a coding rate of 4/5, and the rate range is DR0-DR5, with a maximum transmission power of +17dBm. CN470 only uses LoRa modulation.
The correspondence between uplink and downlink channels is: RX1 channel = uplink channel % 48, with RX2 channel defaulting to 505.3MHz/DR0.
|
DataRate |
Configuration |
bit/sec |
|
0 |
LoRa: SF12 / 125 kHz |
250 |
|
1 |
LoRa: SF11 / 125 kHz |
440 |
|
2 |
LoRa: SF10 / 125 kHz |
980 |
|
3 |
LoRa: SF9 / 125 kHz |
1760 |
|
4 |
LoRa: SF8 / 125 kHz |
3125 |
|
5 |
LoRa: SF7 / 125 kHz |
5470 |
Currently, CN470 only specifies that the maximum transmission time must not exceed 5000ms, with no regulations on LBT, Duty Cycle, and Dwell Time; however, other frequency bands may have regulations due to the differing laws and regulations in various countries and regions.
4. Network Access
To communicate with the server, LoRaWAN end nodes must first access the network, which is the process of authenticating the end nodes. LoRaWAN supports two network access methods: OTAA (Over The Air Activation) and ABP (Activation By Personalization).
The OTAA method authenticates node devices through DevEUI, AppEUI (also known as JoinEUI), and AppKey. DevEUI is an 8-byte globally unique device ID, AppEUI is an 8-byte application ID, and AppKey is a device-specific 128-bit AES root key. DevEUI, AppEUI, and AppKey are collectively referred to as a triplet, stored on both the server and node sides.
The network access process begins with the node initiating a JoinRequest message, which consists of AppEUI, DevEUI, and DevNonce. DevNonce is a random number, and to prevent replay attacks, the LoRaWAN protocol requires a unique DevNonce to be generated for each network access message. The server records a certain number of previously used DevNonce values for each node. During the network access phase, the MIC value is calculated using the AppKey via AES CMAC.
|
Size (bytes) |
8 |
8 |
2 |
|
Join Request |
AppEUI |
DevEUI |
DevNonce |
After receiving the node’s network access request message, the server authenticates the node by looking up AppEUI, DevEUI, and the corresponding AppKey in the database, calculates the MIC, and if the MIC matches, replies with a message accepting the network access. This message consists of AppNonce, NetID, DevAddr, DLSettings, RxDelay, and CFList.
Both the node and the server use AppKey as the key to perform 128-bit AES encryption on AppNonce, NetID, and DevNonce to generate AppSKey and NwkSKey. AppSKey is used for encrypting subsequent Confirmed and Unconfirmed messages, while NwkSKey is used for subsequent MIC calculations and MAC command message encryption.
The low 7 bits of NetID are used to distinguish adjacent LoRaWAN networks, called NwkID, which is the same as the high 7 bits of DevAddr, while the low 25 bits of DevAddr are called NwkAddr and are assigned by the server.
DLSettings’ RX1DRoffset specifies the rate difference between the first downlink receive window and the uplink rate, while RX2 Data rate specifies the rate for the second downlink receive window.
|
Bits |
7 |
6:4 |
3:0 |
|
DLSettings |
RFU |
RX1DRoffset |
RX2 Data rate |
RxDelay specifies the delay between the first receive window and the uplink.
CFList is an optional field used to specify communication channels; the CN470 frequency band uses a channel mask to enable channels, where each bit represents a channel, with 1 enabling that channel and 0 disabling it.
After receiving the message accepting network access, the node can send Confirmed or Unconfirmed messages to the server for business communication.
The ABP method directly stores NetID/DevAddr/AppSKey/NwkSKey in the node before leaving the factory, allowing it to send Confirmed or Unconfirmed messages directly to the server, with the server only verifying the legitimacy of the message through MIC. Compared to the OTAA method, AppSKey and NwkSKey are not dynamically generated, and RX1DRoffset, RX2 Data rate, RxDelay, and CFList are also preset on the node side.
It is worth noting that, typically due to cost reasons and other factors, such as the CN470 frequency band channels 6-38 and 45-77 being occupied by the power system in certain areas, LoRaWAN gateways do not support all 96 uplink channels, but selectively support some, so it is best for the node to pre-configure the channels before accessing the network, or it may fail to access the network.
At the end of the article, here is a link to a node’s LoRaWAN SDK: https://github.com/asrlora/alios-asr-lora. This SDK was released by the domestic LoRa chip manufacturer ASR and has been tested to be usable on ASR6501.
Feel free to follow my personal public account “IoT Notes”.