Issue link: https://read.uberflip.com/i/1539840
Developing LoRaWAN Devices Technical Recommendation TR007-1.1 ©2021-2025 LoRa Alliance ® Page 13 of 28 The authors reserve the right to change documents without notice. 2 Send a LinkCheckReq, which requests an LinkCheckAns from the network. 394 3 Send an application-layer message, which requests an application-layer response in 395 a Class A window. 396 It is further RECOMMENDED that end-devices only deploy these techniques in a manner that 397 mirrors the ADR back-off algorithm: 398 1 The end-device reverts to default ADR and channel configuration in a stepwise 399 manner. 400 2 Any Class A downlink halts the back-off procedure and confirms network connectivity. 401 3 The network is given multiple attempts to send the confirming Class A downlink during 402 each back-off step. 403 4 Loss of connectivity is only determined after multiple attempts at default RF 404 configuration – keep in mind that in many fixed channel plan regions, only 1/8 th of 405 transmitted messages may be received by some gateways – the determination of loss 406 of connectivity MUST take this into account and not prematurely assume connectivity 407 is lost. 408 4.4 Reacting to Loss of Network Connectivity 409 4.4.1 Description 410 If an end-device determines it is no longer in contact with the network (using the procedures 411 described above), it MAY take additional steps to mitigate connectivity issues not related to 412 RF coverage (which are addressed above). These root causes are: 413 1 Loss of state synchronicity between the end-device and the network (session keys or 414 frame counters). 415 2 Cessation of operation or contractual agreement between the end-device owner and 416 the network operator and the need to establish connectivity with a new operator. 417 ABP end-devices have no recourse in these situations, therefore the recommendations are 418 scoped to OTAA end-devices. 419 4.4.2 Recommended Practice 420 End-devices that support LoRaWAN 1.1+ SHALL use ReJoin Type 1 messages to probe the 421 network for an opportunity to synchronize end-device security and radio state (DevAddr, 422 session keys, frame counters, channel plans, and downlink RF parameters). This technique 423 mitigates both cases described above without impacting the end-device's ability to continue to 424 deliver uplink messages. 425 End-devices that support versions of LoRaWAN prior to 1.1 MAY use Join-Request messages 426 to attempt to restore connectivity in these cases. While this technique mitigates both cases 427 described above, it does so at the expense of the end-device's ability to continue to deliver 428 uplink messages. Once the end-device issues a Join-Request, uplink messages are no longer 429 valid until a valid Join-Accept is received and processed. In the case of downlink-only 430 connectivity issues, the act of sending the Join-Request will cause the end-device to no longer 431 be able to transmit any uplink messages until a valid Join-Accept is received. As a result, the 432 decision to send a Join-Request while a security session is already established SHOULD only 433