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

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 calledJoin 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.

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.DevEUIandAppEUIrefer to the Global End Device and Application Identifier, respectively.They follow the IEEE EUI-64 address space format.

TheDevNonceis a counter starting from 0 when the device is initially powered up and incremented with every Join-request by End Device. ADevNoncevalue shall never be reused for a givenAppEUIvalue. If the End Device can be power-cycled then DevNonce shall be persistent (stored in non-volatile memory). ResettingDevNoncewithout 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 lastDevNoncevalue used by the end-device and ignores Join-requests ifDevNonceis not incremented.

AMICvalue of join request is calculated by End Device and an application key (AppKey) is pre-shared between theEnd DeviceandNetwork 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.

2. Authentication and Session Key Generation: After theNetwork Serverreceives thejoin request, it performs the replay attack prevention process, which is based on theDevNonce. If theDevNoncein 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 theMIC 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 calledNwkIDwhich is used to separate addresses of geographically duplicated LoRa networks. The other bits ofNetIDcan be freely determined by the Network Server.

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

4. Transfer App_SKey: Since theApp_SKeyis 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 exchangeApp_SKeywith 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, theEnd Devicedecrypts 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 haveDevEUI,AppEUI, andAppKey, which are essential for join procedure. Activating an End Device by personalization means that the DevAddr and the four-session keysFNwk_SIntKey,SNwk_SIntKey,Nwk_SEncKey, andApp_SKeyare directly stored into the End Device instead of being derived from theDevEUI,AppEUI,AppKeyandNwkKeyduring 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 ofF/SNwk_SIntKey,Nwk_SEncKey, andApp_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 theReset Ind MACcommand in the FOpt field of all uplink messages until it receives aReset conf commandfrom 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).