LoRaWAN device leaving a network and then coming back... what Join behavior to expect?

Question

For smart-city or industrial campus type of projects, there are devices that leave the network for e.g. 2 days (worker leaving on a week-end), and then come back... but they might remain disconnected for a while until the next Re-join.

The LoRa alliance has a best practice that mandates exponential back-off of joins, but it is still a bit vague on detection of isolation (which triggers Re-joins) and this question is to ask what are the best practices on the field, pros/cons of rejoining strategies, and what is effectively tested as part of LoRaWAN certification.

Answer 1

LoRaWAN end devices have to cope with 2 different types of network connectivity issues:

1. The device temporarily loses network connectivity.
   This can happen in the following example cases:
   • There is no network coverage at the current location of a moving device
   • There is a temporary network outage at the area of a fixed device. (e.g.: the LoRaWAN Gateway that is supposed to serve the device lost backhaul connectivity.)
2. The network server loses the session context (AppSkey, NwkSkey) of the device.
   This can happen if
   • the network server had a non-recoverable db failure or a new server is taking over the role of an old one without providing session continuity.
   • or the owner simply deleted the device from the network server and provisioned it again.

Lost network connectivity

The device has 2 ways to detect that the network connectivity is temporarily lost:

• In case ADR is on: It sets the ADRACKReq bit of its uplink frames to 1 after ADR_ACK_LIMIT uplinks not followed by downlink that tells the network that it expects a downlink frame within the next ADR_ACK_DELAY frames.
• In any cases: The end device can send a LinkCheckRequest MAC command to the network that must be answered by the Network by a LinkCheckAns MAC command.

If the device detects (in any way) that the network is not available, it should first try sending uplink messages (e.g.: LinkCheckReq messages) with the lowest possible data rate (that will increase the link budget to the maximum), and if it still does not fix the connectivity problem, the device should exponentially back off consecutive uplink messages. In practice, end devices are rather sending new JoinRequest messages than basic UL messages. The next chapter explains why.

Lost session context

In a LoRaWAN 1.0 network, if the network server lost the session context, the only way to reconnect a device is to make it send a new join request.
However, the device has no means to check if its network connectivity problem is due to temporary network outage or because of the lost session. (Both result in no downlink messages.) The solution to this issue is that in case of any long-term connectivity problem (that cannot be fixed by lowering the data rate), the device starts sending new Join Request messages that will make the Network Server start a new session context and reset the frame counter too.

This "lost session" problem is managed by LoRaWAN 1.1 networks in a much better way. LoRaWAN 1.1 introduces a new message type: Rejoin-Request. End devices are regularly sending Rejoin-Request Type 1 messages, that offers the Network Server an option to create a new device session by answering them by a Join Accept message. However, in case the Network Server still has a valid session, it will silently drop these messages. This solution prevents triggering unnecessary reset of valid device sessions in case of connectivity issues and increases the level of security.

Answer 2

Here is the detailed behavior for Abeeway brand trackers.

Network timeout monitoring

Not receiving any downlink communication from the network is a serious symptom. It can mean that the tracker became isolated from the network, in no longer active in this network, or potentially that the device LoRa radio (or the MCU driver for it) has become unstable. A device cannot know if lack of downlink communication from the network is due to a problem, or simply because the network or application server have nothing to say. In order to solve that problem the LoRaWAN MAC offers the LinkCheckRequest.

On Abeeway trackers the following parameters are provided:

• network_timeout_check: once this duration elapses the tracker prepends a Link Check Request to all LoRaWAN uplinks (to force the network to trigger a downlink). The associated timer is restarted each time a LoRaWAN downlink is received.
• network_timeout_reset: this duration covers the link check request period. Once elapsed without a Link Check Answer, the tracker will assume there is a problem and will reset. This will cause the device to attempt a Re-Join. We advise to keep this behavior as it is the only way to ensure that orphan devices ultimately generate very low parasitic traffic in a network (because of Join exponential back-off).

Example:
network_timeout_check= 172800 seconds (2 days)
network_timeout_reset= 86400 seconds (1 day)
If after 2 days the tracker did not receive any downlink, it starts the link check request process. After 1 day of link check request process without answers, the tracker resets.

Any downlink received by the tracker restarts the timer/mechanism. This watchdog features are disabled if you set zero values in the corresponding parameter.

Joining and exponential back-off

The LoRaWAN spec imposes a Duty-cycle for Join (common to all region), which is designed to avoid the network being locked-up in a traffic storm.

The duty cycle back-off is applied per band. For example, the IN865 region uses a single band: BAND0.

• Within the first hour, the duty cycle = 100 .
• Between the first hour and the next 10 hours, the duty cycle = 1000 seconds
• Above 11 hours, the duty cycle = 10000 seconds

Abeeway trackers follow the LoRaWAN specification, however, a button press will skip the wait timer at the application level and trigger an immediate Join. Because this is a user triggered action, it cannot cause a message storm.