LoRa Device Activation Call Flow | LoRA Device Join Procedure

by · Published · Updated

LoRa Device 

When a new End Device  or 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 following two types of activation methods.

  •  Over-The-Air Activation (OTAA)
  • Activation By Personalization (ABP)

Over-The-Air Activation

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.

Over-The-Air Activation of LORA IOT Device

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 a 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 preshared 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.

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. NetID is 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 accept message is encrypted with the AppKey.

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 included it in the join procedure.

5. Session Key Generation: After receiving the join accept message, the End Device decrypt 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).

Related Post



Tags:

You may also like...