LoRaWAN devices, Join and Re-Join

Devices
1

I see quite a lot of cases where 5-8% of the LoRaWAN devices is not communicating after some time.
There can of course be several reasons for this, but I want to focus on if there is a general practice on how the device FW should handle it.

The class A devices running on battery that I have evaluated follows the following steps

  1. Device is activated
  2. Device sends a Join request and gets a Join accept in response
  3. The meter continues to send unconfirmed uplinks ever 4h
    If LoRaWAN radio conditions are good all works Ok.

But if the radio conditions are on the limit and the GW/NS stops to receive uplink frames after some time.
In this case since the device is sending unconfirmed uplinks the device and FW does not “know” if the uplinks really reaches the GW/NS.
My questions are related to if there is the general recommendation for how the device FW should handle this situation?

Q1: Should the device use confirmed uplinks In ~5-10% of the cases to know if the uplink frames are actually received?
Q2: Should the device FW attempt a new Join with a long interval time to validate that there is actually a GW/NS that receives the uplinks?
Q3. Is there any other way for a device FW to solve this situation?

The same condition can also happen if the Chirpstack configuration is changed.
For example if the device is deleted and added again with the same configuration and by that loses the device address and the keys leading to that a new join is required.

Best Regards
//Johan Sandberg

2

I think this is really application specific, depending on the uplink interval and the amount of acceptable packet-loss. In general I would advice to have some sort of mechanism to rejoin the network in case the device thinks it became disconnected.

Have you looked at the ADR backoff algorithm that is specified in the LoRaWAN specs? I don’t believe it handles the rejoin, but it does handle moving to a lower datarate and higher tx power…