LoRa and LoRaWAN – Part 3: LoRaWAN Activation- OTAA and ABP in Versions 1.0.x and 1.1 Leave a comment
LoRaWAN Activation- OTAA and ABP in Versions 1.0.x and 1.1
We previously reviewed LoRaWAN device classes. Every LoRaWAN device must be registered in a network before it can send or receive messages. This process is called activation. There are two methods:
1.Over-The-Air Activation (OTAA)
The most secure and recommended method. In OTAA, the device performs a join procedure with the network. During this, a dynamic device address is assigned, and security keys are negotiated between the device and network.
2.Activation By Personalization (ABP)
The opposite of OTAA — the device address and security keys must be manually hardcoded into the device. This method has lower security. Additionally, a major limitation: an ABP-activated device cannot easily change networks unless the keys and address are manually updated in the device.
Final note: The join process differs slightly between LoRaWAN versions. Specifically, there are differences between 1.0.x and 1.1 that need to be explained separately.
Over-The-Air Activation in LoRaWAN 1.0.x
In LoRaWAN 1.0.x, the join (activation) process occurs via the exchange of two MAC messages between the device and network server:
- Join-request: Sent from the device to the network server.
- Join-accept: The response sent from the network server to the device.
Before activation begins, the following data must be pre-provisioned in the device:
- AppEUI and DevEUI — identifiers for the application and device. These are not confidential.
- AppKey — a 128-bit AES root key. This is shared only between the device and network and must be pre-provisioned on both.
Critical point: The AppKey is never transmitted over the air. This is the core security of OTAA — the root key remains protected and is used only to derive session keys.
Step 1 in the Join Process (LoRaWAN 1.0.x)
The join process always starts from the device. The device sends a Join-request message to the network it wants to connect to. This message consists of three main parts:
- AppEUI: A 64-bit unique identifier in the IEEE EUI64 address space that identifies the application capable of processing the Join request.
- DevEUI: A 64-bit unique identifier that identifies the device itself in the IEEE EUI64 address space.
- DevNonce: A 2-byte random and unique value generated by the device. The network server uses DevNonce to ensure the Join request is not a replay. If the device sends a repeated DevNonce (known as a replay attack), the server rejects the Join-request and denies registration.
To ensure security, a Message Integrity Code (MIC) is calculated over all these fields. This MIC is generated using the AppKey and then appended to the Join-request message.
The Join-request can be sent at any data rate and via one of the dedicated join channels. For example, in Europe, the device can randomly select one of the frequencies: 868.10 MHz, 868.30 MHz, or 868.50 MHz. The message is then forwarded through one or more gateways to the network server.
Step 2 in the Join Process (LoRaWAN 1.0.x)
After the network server receives and validates the Join-request, if the device is authorized to join the network, it generates two session keys:
- NwkSKey for network communications
- AppSKey for application data
It then prepares and sends a Join-accept message to the device. This message includes the following fields:
- AppNonce: A random or unique identifier generated by the network server. The device uses AppNonce along with AppKey to derive the two session keys (AppSKey and NwkSKey).
- NetID: Contains the network identifier (NwkID), which forms the 7 most significant bits (MSB).
- DevAddr: A 32-bit address assigned by the network server to the device for identification within the network.
- DLSettings: A 1-byte field containing downlink message settings the device must follow.
- RxDelay: Specifies the delay duration between transmission (TX) and reception (RX).
- CFList: An optional list of channel frequencies the device can use. This list is region-dependent.
For security, a Message Integrity Code (MIC) is calculated over all these fields using the AppKey and appended to the Join-accept message.
Step 3 in the Join Process (LoRaWAN 1.0.x)
Once the network server prepares and encrypts the Join-accept message, it sends it to the device like a normal downlink message. The device receives it, decrypts it, and derives its session keys based on the information inside (such as AppNonce, NetID, and DevAddr). From this moment, the device is fully joined to the network and can communicate securely.
Step 4 in the Join Process (LoRaWAN 1.0.x)
After the Join-accept is processed and the device joins the network, the network server manages the session keys. The NwkSKey (network key) is kept by the network server to validate and manage network-related messages. In contrast, the AppSKey (application key) is forwarded to the application server. This ensures that data sent by devices can only be decrypted by the intended application, not by the network operator.
This separation enables multi-tenant networks — one operator can serve multiple companies or applications without accessing their actual data.
Step 5 in the Join Process (LoRaWAN 1.0.x)
When the device receives the Join-accept, it decrypts it using AES in encrypt mode. At this stage, the device uses AppKey and AppNonce to derive its two session keys:
- NwkSKey or Network Session Key
- AppSKey or Application Session Key
From this point, the device is officially activated on the network and ready for secure communication.
After activation, several important pieces of information are also stored in the device:
- DevAddr: A 32-bit address assigned by the network server to identify the device within the network.
- NwkSKey: This key is used to calculate and verify the Message Integrity Code (MIC) for all data messages to ensure integrity. It is also used to encrypt and decrypt payloads containing MAC commands.
- AppSKey: This key is used to encrypt and decrypt application data in messages, with its primary role being to maintain data confidentiality.
Thus, the device receives both its network address and the necessary security keys. The result is that both data integrity and confidentiality are guaranteed — without the root key (AppKey) ever being transmitted over the network.
Over-The-Air Activation in LoRaWAN Version 1.1
In LoRaWAN 1.0.x, the join process involved exchanging two MAC messages between the device and network server: Join-request and Join-accept. However, in version 1.1, a major change was introduced — the process now occurs between the end device and the Join Server.
Before activation begins, the following data must be pre-provisioned in the device:
- JoinEUI and DevEUI: Unique identifiers for the application and device. These are not confidential and visible to everyone.
- AppKey and NwkKey: Confidential 128-bit (AES-128) root keys.
For the process to work correctly, the same AppKey, NwkKey, and DevEUI must also be pre-provisioned on the Join Server, as it is responsible for processing the Join request and generating session keys.
Step 1 in the Join Process (LoRaWAN 1.1)
As in the previous version, the join process always starts from the device. The device sends a Join-request message to the network it wants to join. This message consists of three main parts:
- JoinEUI: A 64-bit identifier in the IEEE EUI64 address space that uniquely identifies the Join Server. This is the server that will later assist in processing the Join request and generating session keys.
- DevEUI: A 64-bit unique identifier that introduces the device itself in the IEEE EUI64 address space.
- DevNonce: A 2-byte counter that starts at zero upon initial device power-on and increments by one with each Join-request. This DevNonce prevents replay attacks.
A Message Integrity Code (MIC) is calculated over all these fields — this time using NwkKey — and appended to the Join-request.
The device can send this message at any data rate and via one of the dedicated join channels. For example, in Europe, the device can randomly select one of the frequencies: 868.10 MHz, 868.30 MHz, or 868.50 MHz. The Join-request reaches the network server through one or more gateways.
Finally, if the request is not accepted by the server, no response is sent to the device — server silence means rejection of the Join-request.
Step 2 in the Join Process (LoRaWAN 1.1)
When the network server receives the Join-request, it forwards it to the relevant Join Server. This is the server responsible for processing Join requests and managing security keys.
Step 3 in the Join Process (LoRaWAN 1.1)
The Join Server processes the Join-request. If the device is authorized to join the network, the Join Server generates four session keys:
- AppSKey: Key for application data — used to encrypt and decrypt application payloads.
- FNwkSIntKey: Forwarding Network Session Integrity Key — for message integrity.
- SNwkSIntKey: Serving Network Session Integrity Key — for integrity at the serving level.
- NwkSEncKey: Network Session Encryption Key — for encrypting network payloads.
This is a major difference from LoRaWAN 1.0.x, where only two session keys (AppSKey and NwkSKey) existed. In 1.1, network keys are split into three for greater security and clearer separation of responsibilities.
Step 4 in the Join Process (LoRaWAN 1.1)
If the Join Server approves the connection and successfully generates the keys, the network server prepares the Join-accept message. This message includes:
- JoinNonce: A per-device counter generated by the Join Server. The device uses it with root keys to derive its session keys (FNwkSIntKey, SNwkSIntKey, NwkSEncKey, and AppSKey).
- NetID: A 24-bit unique network identifier.
- DevAddr: A 32-bit address assigned by the network server to identify the device in the network.
- DLSettings: A 1-byte field containing downlink settings.
- RxDelay: The delay to observe between TX and RX.
- CFList: An optional list of channel frequencies (region-dependent).
For security, a Message Integrity Code (MIC) is calculated over all fields. In LoRaWAN 1.0, this used NwkKey; in 1.1, it uses JSIntKey. The MIC is appended to ensure no tampering in transit.
The Join-accept message itself is encrypted. The network server uses AES in ECB mode (interestingly, the **AES- AES-ECB Decrypt operation is used to encrypt).
- If responding to a Join-request, it uses NwkKey.
- If responding to a Rejoin-request, it uses JSEncKey.
Finally, the encrypted Join-accept is sent to the device as a regular downlink message. The device then processes it and derives its session keys.
Step 5 in the Join Process (LoRaWAN 1.1)
Once the join process completes and keys are generated, the Join Server is responsible for distributing them:
- AppSKey → Sent to the Application Server. Used only to encrypt/decrypt application data — ensures real data is readable only by the destination application.
- FNwkSIntKey, SNwkSIntKey, NwkSEncKey → Sent to the Network Server. Handle message integrity and network payload encryption.
This separation adds a stronger security layer in LoRaWAN 1.1. The network operator has no direct access to application data (since AppSKey stays with the application server). Meanwhile, the Network Server ensures integrity and security using its dedicated keys.
Thus, the device becomes fully activated, and the network is ready for secure, reliable communication.
Step 6 in the Join Process (LoRaWAN 1.1)
When the device receives the Join-accept message, it decrypts it using the AES algorithm in encrypt mode. Then, using the root keys (AppKey, NwkKey) and the JoinNonce value, it derives its session keys.
The key derivation method differs by LoRaWAN version:
- In LoRaWAN 1.0.x:
- AppSKey is derived from NwkKey.
- All three network keys (FNwkSIntKey, SNwkSIntKey, NwkSEncKey) are derived from NwkKey.
- In LoRaWAN 1.1:
- AppSKey is derived from AppKey.
- The three network keys (FNwkSIntKey, SNwkSIntKey, NwkSEncKey) are derived from NwkKey.
At this point, the device is officially activated on the network and ready for secure data exchange.
After activation, the following information is stored in the device:
- DevAddr: A 32-bit address assigned by the network server to identify the device within the network.
- FNwkSIntKey: A session key used to calculate part of the MIC for uplink messages to ensure data integrity.
- SNwkSIntKey: A session key used to calculate part of the MIC for uplink messages and the full MIC for downlink messages.
- NwkSEncKey: A session key used to encrypt and decrypt MAC payloads in uplink and downlink messages to preserve confidentiality.
- AppSKey: A shared key between the device and application server, used to encrypt and decrypt application data in messages.
With Step 6 complete, everything is ready: the device has its address, full security keys, and a secure channel for exchanging data with the network and application.
FAQ LoRaWAN Activation- OTAA and ABP in Versions 1.0.x and 1.1
Resources
Master range, data rate, and battery life in one go.
Dive into Part 4: Guide to Spreading Factors and ADR in LoRaWAN –
to fine-tune your network for maximum performance and efficiency.
