LoRa Call4

LoRa – Device Activation Call Flow (Join Procedure) using OTAA and ABP

Codeplayon IoT technology - internet of things

LoRa – Device Activation Call Flow (Join Procedure) using OTAA and ABP, When a new End Device (LoRa Device) is added to a LoRa network, it should go through an activation process. Through the activation process, both session keys are shared between the End Device and the Network server. Currently, LoRa provides the following two types of activation methods.

  •  Over-The-Air Activation (OTAA)
  • Activation By Personalization (ABP)
Over-The-Air Activation ( LoRa – Device Activation Call Flow (Join Procedure) using OTAA and ABP )

In the OTAA mode, an End Device communicates with the network server to perform the activation process, which is called Join Procedure. According to the LoRa specifications , the OTAA mode is used when an End Device is already deployed or it is reset. Figure below depicts the join procedure.

LoRa Call4

Steps:

1. Join Request Message: End Device starts the join procedure by sending a join request message. It includes DevEUI, AppEUI, and DevNonce in the join request. DevEUI and AppEUI refer to the Global End Device and Application Identifier, respectively.They follow the IEEE EUI-64 address space format.

The DevNonce is a counter starting from 0 when the device is initially powered up and incremented with every Join-request by End Device. A DevNonce value shall never be reused for a given AppEUI value. If the End Device can be power-cycled then DevNonce shall be persistent (stored in non-volatile memory). Resetting DevNonce without changing AppEUI will cause the Network Server to discard the Join-requests of the device 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 is not incremented.

A MIC value of join request is calculated by End Device and an application key (AppKey) is pre-shared between the End Device and Network Server. The join-request message is not encrypted. It can be transmitted using any data rate and following a random frequency hopping sequence across the specified join channels.

LoRa Call6

2. Authentication and Session Key Generation: After the Network Server receives the join request, it performs the replay attack prevention process, which is based on the DevNonce. If the DevNonce in the join request is previously used, the network server determines that the message is invalid and that the join process will fail. If the message is valid, the network server authenticates the End Device with the MIC value. If the End Device passes the authentication, the Network Server generates an Nwk_SKey and an App_SKey. AppNonce is a counter number generated by the Network Server. NetIDis a 24-bit field, its 5 LSBs are called NwkID which is used to separate addresses of geographically duplicated LoRa networks. The other bits of NetID can be freely determined by the Network Server.

3. Join Accept Message: A join accept message contains AppNonce, NetID, DevAddr, DLSettings, RxDelay,
and CFList. The DevAddr is a 32-bit identifier of the End Device within the current network. The 7 MSBs of DevAddr are referred to as the NwkID, which is also contained in NetID. The other bits can be arbitrarily chosen by the Network Server. DLSettings contains several values related to the downlink configuration. RxDelay is a delay between the transmission and reception process. CFList is an optional field that is about channel frequencies. Finally, the whole join accepts message is encrypted with the AppKey.

LoRa Call7

4. Transfer App_SKey: Since the App_SKey is devised to secure end-to-end communications between the End Device and the Application server, it should be transferred from the Network Server to the Application Server. The LoRa specification does not specify when and how to exchange App_SKey with the application server so it can be implementation specific. It can be an essential part and so can include it in the join procedure.

5. Session Key Generation: After receiving the join accept message, the End Device decrypts it and generates session keys using extracted parameters.

Activation by Personalization 

ABP is the way in which an End Device can belong to a particular LoRa network without performing a join procedure under certain conditions. In the ABP mode, the End Device does not have DevEUI, AppEUI, and AppKey, which are essential for join procedure. Activating an End Device by personalization means that the DevAddr and the four-session keys FNwk_SIntKey, SNwk_SIntKey, Nwk_SEncKey, and App_SKey are directly stored into the End Device instead of being derived from the DevEUI, AppEUI, AppKey and NwkKey during the join procedure.

The End Device is equipped with the required information for participating in a specific LoRa network as soon as it is started. Each device shall have a unique set of F/SNwk_SIntKey, Nwk_SEncKey, and App_SKey. Compromising the keys of one device shall not compromise the security of the communications of other devices. The process to build those keys shall be such that the  keys can not be derived in any way from publicly available information (like the node address  or the End Device’s DevEUI for example)

When a personalized End Device accesses the network for the first time or after a re-initialization, it shall transmit the Reset Ind MAC command in the FOpt field of all uplink messages until it receives a Reset conf command from the network. After a re-initialization, the End Device must use its default configuration (id the configuration that was used when the device was first connected to the network).