LoRaWAN - Device Activation Call Flow (Join Procedure) with OTAA and ABP
When a LoRaWAN end device is added to a LoRaWAN network, it must go through an activation process to communicate with the LoRaWAN network server. The two session keys required for communication are shared between the end device and the network server during the activation process.
There are two types of activation methods:
1. OTAA – Over-The-Air-Activation
2. ABP – Activation by Personalization
1. OTAA – Over-The-Air-Activation
In OTAA mode, the application key (AppKey) is stored in the LoRaWAN network server before activation. Using this common, cryptographic basis, the LNS generates the necessary keys and exchanges them securely with the end device. The AppKey is never transmitted via LoRaWAN in order not to compromise it. The following figure shows the join procedure.
Step 1: Join Request
The end device starts the join process by sending a join request message. This contains DevEUI, AppEUI and DevNonce. DevEUI and AppEUI refer to the Global End Device and Application Identifier respectively and follow the IEEE EUI-64 address space format.
The DevNonce is a random number that increases with each join operation. To do this, the DevNonce must be stored in non-volatile memory. Resetting DevNonce without changing AppEUI causes the network server to discard the device's join requests. For each end device, the network server keeps track of the last DevNonce value used by the end device and ignores join requests if DevNonce has not been incremented.
An MIC value of the join request is calculated by the end device. The join request message is not encrypted. It can be transmitted at any data rate and according to a random frequency hopping sequence via the specified join channels.
What is in a Join Request?
Step 2: Authentication of the end device
When authenticating and generating session keys, the network server performs a replay attack prevention process based on the DevNonce after the join request. If the DevNonce has already been used in the join request, the join process fails and the network server decides that the message is invalid. If the message is valid, the network server checks the end device with the MIC value. If the check was successful, the network server generates a Nwk_SKey and an App_SKey.
Step 3: Join Accept
In addition to AppNonce, NetID and DevAddr, a Join-Accept Message contains various parameters for the communication of the end device with the server. The DevAddr is a 32-bit identifier of the end device in the current network. The first seven bits of the DevAddr are called the NwkID. The other bits can be chosen arbitrarily by the network server. The DLSettings contain several values related to the downlink configuration. RxDelay is a delay between the transmit and receive process and CFList is an optional field that deals with channel frequencies. Finally, the entire Join Accept message is encrypted with the AppKey.
What's in a Join Accept?
Step 4: App_SKey Austausch
Since the App_SKey is designed for secure end-to-end communication between the end device and the application server, it should be transmitted from the network server to the application server. When and how the App_SKey is exchanged with the application server is not specified in the LoRa specification. Thus, the specific implementation can be addressed. This can be an essential component and can therefore be included in the join procedure.
Step 5: Generation of the session keys
After receiving the join-accept message, the terminal decrypts it and generates session keys using extracted parameters. This completes the join process.
Over-The-Air-Activation by QR-Code
The LoRa Alliance has set the goal of simplifying the onboarding of sensors and proposes the use of QR codes as an easily implementable method. Many manufacturers are already using these, making LoRaWAN a technology that can be used in the long term not only by people with specialist knowledge. The QR codes transmit the necessary information and, if necessary, additional elements such as the serial number of the sensor in a standardized form.
1. Schema ID D0
2. JoinEUI (formerly AppEUI): 11-22-33-44-55-66-77-88
3. DevEUI: AA-BB-CC-DD-EE-FF-00-11
4. Profile ID: AABB-1122
5. Owner Token: AABBCCDDEEFF
6. Serial Number: YYWWNNNNNN
7. Proprietary: FOOBAR
8. CheckSum: AF2C
This results in the example:
LW: D0 : 1122334455667788 : AABBCCDDEEFF0011 : AABB1122 :O AABBCCDDEEFF :S YYWWNNNNNN :P FOOBAR :C AF2C
The schema ID, JoinEUI, DevEUI and profile ID must always be provided according to the standard, the other specifications are optional.
2. ABP – Activation by Personalization
ABP is the way an end device can belong to a specific LoRa network without performing a join operation under certain conditions. In ABP mode, the end device does not have DevEUI, AppEUI and AppKey, which are essential for the join procedure. Activating a terminal device by personalization means that the DevAddr and the two session keys Nwk_SKey and App_SKey are stored directly in the terminal device instead of being derived from DevEUI, AppEUI, AppKey and NwkKey during the join operation.
The end device is already equipped with the necessary information for participation in a specific LoRa network at startup. Each device must have a unique set of Nwk_SKey and App_SKey. The process for creating the keys must be such that the keys cannot be derived in any way from publicly available information (such as the node address or the DevEUI of the end device).
When a personalized end device accesses the network for the first time or after a reinitialization, it must send the Reset Ind MAC command in the FOpt field of all uplink messages until it receives a reset conference command from the network. After reinitialization, the end device must use its default configuration (the configuration used when the device first connected to the network).
LoRaWAN should work easier? Datacake is the solution!
You just want to enter a number and automatically onboard your sensors in the backend and immediately get the data displayed in an already configured dashboard on a website or app?
What role does the Basic Station Protocol play in gateway update and configuration management?
FAQ´s
OTAA (Over The Air Activation) and ABP (Activation By Personalisation)
For each OTAA join request, the dev-nonce value is incremented by a random number.
For the correct interpretation of a payload, the payload description matching the sensor is required.
Data transmission is secured with 128-bit AES encryption.
LoRaWAN with the 868 MHz frequency has a spreading factor of SF 7 to SF 12.
A packet multiplexer can be used to distribute LoRaWAN packets from a gateway to several network servers. However, this is only recommended for non-critical applications.
No, this cannot be avoided. However, since your data packets are encrypted and your Sensor is not known to the foreign LNS, the risk is manageable. If you transmit critical data via LoRaWAN, we can advise you on further data protection measures.
You can use the support of our IoT experts request here.
You have further questions?
Our daily business consists of providing our customers with advice and support. We are happy to share our knowledge about products and application possibilities.