OTAA JOIN - works again after re-registering the device


I have had some OTAA devices regsitered in TTN and they worked fine.
Due to a gateway outage for 2 weeks the devices were (off course) not online during that period.

The Gateway is fixed and is running now. However the devices are not able to JOIN.
I did try to let the devices JOIN via several gateways -> No success.

As a last resort I deleted the devices from TTN and re-registered them. And surprisingly the devices were able to JOIN the network again. However I am puzzled how this could have happened.

Does anybody have a idea how this occured?


LoRaWAN devices are never “online”. They just transmit when they want to, and hope that one or more gateways receive their transmissions and forward that to TTN. So, ADR and confirmed uplinks aside, in general devices won’t know that no gateways received their transmissions.

If a device is using ADR then it might have increased its SF when it didn’t get any commands from the network for a long time. But even that does not necessarily mean that a device will try to re-join at some point soon. And if it did try to re-join, it might better still keep its old session keys in case the re-join failed while the existing keys might work again at some later time.

So for an educated guess of what happened we’ll need many more details, including:

  • How often do the devices transmit, and how did they know they needed to join again? If you don’t know, then it might help to know what LoRaWAN stack the devices use (like Microchip RN2483, LMIC, LoPy, …)

  • What exactly does “try to let the devices JOIN via several gateways -> No success” mean? How did you make them join, what SF did they use, what did you see?

  • When re-registering in TTN, did you use the existing EUIs and AppKeys, or did you also reprogram the devices?


Thanks for your feedback Arjan.

The device default has ADR + confirmed. Agree with you the term “online” is not 100% proper wording.

As I could not see any traffic coming from the device I restarted (! cold restart !) the device.

  • After the restart it sends a JOIN request (ADR starts at SF7).
  • Looking at gateway traffic I can see the actual JOIN request
  • However no device traffic or JOIN activity (console: application> devices> deviceId > data)
  • As last resort I re-registering the device at TTN
    • Removed the existing device
    • Register with exactly the same keys (so no reprogramming the device)
  • Reregistration resulted in a JOIN plus traffic flow :face_with_raised_eyebrow:

To me it looks like the device was in some kind of `quarantine´ (if that exists in TTN)

Chrs, Jeroen

Maybe it is a combination of issues:

  • Not seeing any traffic when the gateway came back online: the devices might have given up due to not receiving any confirmations (if that’s true: yet another reason to not use confirmed uplinks), or when trying to re-join a lot during the two weeks that the gateway did not work?

  • Not being able to join after the reset: are these LoRaWAN 1.1 devices? LoRaWAN 1.1 uses an incremental value for the DevNonce, and devices should always store the last value they used. If the reset made them (erroneously) start at zero again, then TTN would ignore the first join attempts, until at some point a value is used that TTN has not seen earlier. However: (earlier) TTN would show an error then; see OTAA shows "Activation DevNonce not valid: already used".

The first bullet point might not be relevant. How much time did you wait to see if data came in after the gateway was back online? At some point a proper device will back off in its join attempts, so a long time might pass between two tries.

But re-registering a device does remove the history of DevNonces, so if the issue at hand is related to that, then I’d assume a 1.1 device (or a bad 1.0.x device). You could easily verify by resetting a device again, and/or see the DevNonce using an online decoder.

As an aside: in the first post you wrote “some devices”, in the last “the device”. This applied to multiple devices, right?

The community network does not support 1.1 yet, but the 1.0.x and 1.1 Join Requests are the same, except that in 1.0.x the DevNonce is a random value which makes the chances for using the same value much smaller. After receiving a 1.0.x Join Accept, a 1.1 device will fall back to 1.0.x.

1 Like

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.