Typical (and recommended) retry behavior of devices when confirmed uplinks are failing

Are there any recommendations (in the LoRaWAN spec or elsewhere) on what a device should do when sending confirmed uplinks and not getting an ACK? I’m also curious as to what others have observed in real-world devices.

I’ve seen a few variations in the field and/or in-house firmware. Those include retrying with an exponential backoff until success (up to a a limit, maybe 4 or 5), no retries but track the number of failures and perform a rejoin after X unacknowledged attempts, and a combination of the two.

I haven’t done any spec digging on the topic. The decisions I was party to were mostly driven by battery life and criticality of the data.

1 Like