LoRa – Device Re-activation Call Flow (Rejoin Procedure)

LoRa Technology supports the handling and configuration of rejoin-requests for LoRa End Devices. Using a rejoin-request, a device is able to request the network-server to re-activate, without being ‘disconnected’ until receiving the activation. In other words, when it doesn’t receive a new activation, the device will continue to use the old security context.

With the rejoin-request, it is possible to reset the device context including all radio parameters  (device address, frame counters, session-keys, radio parameters) restore a lost session context or re-key a device (device address, session-keys and frame-counters).

• Once activated a device may periodically transmit a Rejoin-request message on top of its  normal application data.
• Rejoin-request message periodically gives the backend servers the opportunity to initialize a new session context for the End Device.
• Rejoin request may be used to hand-over a End Device between two networks or to re-key and/or change devAddr of a device on a given network.
• Network Server may also use the Rejoin-request opportunity to reset the device’s reception parameters in case there is a MAC layer state de-synchronization between the device and the Network Server.

Types of Rejoin Requests

There are three types of Rejoin-request messages that can be transmitted by an End Device. Rejoin Request message  first byte indicates the Rejoin Type. The following table describes the purpose of each Rejoin-Request message type.

Rejoin-request Message

The Rejoin-request type 0 or 2 message contains the NetID (identifier of the device’s home network) and DevEUI of the end-device followed by a 16 bits counter (RJcount0).  RJcount0 is a counter incremented with every Type 0 or 2 Rejoin frame transmitted. RJcount0 is initialized to 0 each time a Join-Accept is successfully processed by the end- device.

For each end-device, the Network Server must keep track of the last RJcount0 value (called RJcount0_last) used by the end-device. It ignores Rejoin-requests if (Rjcount0 <= RJcount0_last) RJcount0 SHALL never wrap around. If RJcount0 reaches 2^16-1 the device shall stop transmitting ReJoin-request type 0 or 2 frames. The device MAY go back to Join state.

The Rejoin-request message is not encrypted.  The device’s Rejoin-Req type 0 or 2 transmissions duty-cycle SHALL always be <0.1%

Rejoin-Request type 0 message is meant to be transmitted from once per hour to once every few days depending on the device’s use case. This message can also be transmitted following a  ForceRejoinReq MAC command. This message may be used to reconnect mobile device to a visited network in roaming situations. It  can also be used to rekey or change the devAddr of a static device. Mobile devices expected to roam between networks should transmit  this message more frequently than static devices.

Rejoin-Request type 2 message is only meant to enable rekeying of an end-device. This message can only be transmitted following a ForceRejoinReq MAC command.

Rejoin-Request type 1  is similarly to the Join-Request, the Rejoin-Request type 1 message contains the JoinEUI and  the DevEUI of the End-Device. The Rejoin-Request type 1 message can therefore be routed to the Join Server of the End Device by any Network Server receiving it. The Rejoin-request Type 1 may be used to restore connectivity with an End Device in case of complete state loss of the Network Server. It is recommended to transmit a Rejoin-Request type 1 message a least once per month.

The RJcount1 for Rejoin-request type 1 is a different counter from the RJCount0 used for Rejoin-request type.  RJcount1 is a counter incremented with every Rejoin-request type 1 frame transmitted. For each End Device, the Join Server keeps track of the last RJcount1 value (called RJcount1_last) used by the End Device. It ignores Rejoin-requests if (Rjcount1 <=  RJcount1_last).

RJcount1 shall never wrap around for a given JoinEUI. The transmission periodicity of Rejoin-Request type 1 shall be such that this wrap around cannot happen for the lifetime of  the Device for a given JoinEUI value. The Rejoin-request-type 1 message is not encrypted. The device’s Rejoin-Req type 1 transmissions duty-cycle shall always be <0.01%.

The Rejoin-Request type 1 message is meant to be transmitted from once a day to once a week. This message is only used in the  case of a complete loss of context of the server side. This event being very unlikely a latency of 1 day to 1 week to reconnect the device is considered as appropriate.

Rejoin-Request Message Processing

Any time the network sever processes a Re-Join-Request (type 0,1 or 2) and generates a Join-accept message. It shall maintain both the old security context (keys and counters, if any) and the new one until it receives the first successful uplink frame using the new context, after which the old context may be safely discarded.

In all cases, the processing of the Rejoin-request message by the network server is similar to the processing of a standard Join-request message, in that the Network Server initially processing the message  determines if it should be forwarded to a Join Server to create a Join accept message in response.

Network Server respond with A join-accept message if it wants to modify the device’s  network identity (roaming or re-keying). In that case RJcount (0 or 1) replaces DevNonce in the key derivation process. Network server also send a normal downlink frame optionally containing MAC commands. This downlink shall be sent on the same channel, with the same data rate and the same delay that the Join-accept message it replaces.

Reference

1. LoRaWAN™ 1.1 Specification

Related Post

• Low Power Wide Area Network (LPWAN)
• LoRa Technology, It’s Features and Application
• LoRa- (Long Range) Network and Protocol Architecture with Its Frame Structure
• LoRa – Device Activation Call Flow (Join Procedure) using OTAA and ABP
• LoRa – Device Re-activation Call Flow (Rejoin Procedure)
• LoRa Sensitivity and Link-budget Calculations