0

We are moving our Lora-wan gateways and end-device from Loriot to another opensource network server. But we are experiencing problems with some of our devices, when trying to rejoin using OTAA.

What is the 'best practise' for connecting and joining end-devices to another network server? Are you always able to reset or rejoin devices using a downlink, or is there maybe another smart way of doing it?

Improve this question
3
  • Are you keeping all the details (app and device ids, key) the same? Do you need the devices to actually rejoin? Do you need to do it remotely? I don’t think all devices support remotely triggered rejoin, IIRC that was added in a later LoRaWAN version.
    – jcaron
    Aug 20, 2021 at 22:11
  • Yes, we are keeping the same app and device IDs. Im unsure about the keys? We do need to do it remotely yes, because we have sensors underground. I don't know if in need an actual rejoin, we just need then to start sending data on the new network server.
    – Alexander Ibsen
    Aug 22, 2021 at 13:56
  • If you have the ability to transfer the full existing state, including keys, frame counters, etc, that would probably be the easiest, though I have no idea whether this is easy to do. If you actually need the devices to join again to be recognised by the new LNS, then it will depend a lot on the devices and in which conditions they do a join again… some will never join again unless they are manually reset, others will act on LoRa rejoin commands, and others may do so if something “goes wrong”. Without details of the devices, hard to say more…
    – jcaron
    Aug 22, 2021 at 14:04

1 Answer 1

Reset to default
4

Unfortunatelly, the LoRaWAN 1.0.x spec does not define any standard way for having end-devices rejoin the same or another LoRaWAN network and generate new session keys. This is a big operation issue. Just image what happened if your production Network Server lost (because of a datacenter disaster) all session keys. All devices would be disconnected without having any way to reconnect. (LoRaWAN 1.1 introduces a new message type: rejoin request, that solves this issue.)

Device manufacturers usually implement proprietary solutions in the application layer of their firmware to let devices join the same or a new network after session keys are lost. The most common technic is that upon detecting that the Network Server stops answering to LinkADRReq MAC commands (for a certain period: e.g.: for 6 hours) , the device sends new JoinRequests until the new or recovered NS replies with a new JoinAccept so that new session keys can be created.

According to my experience 90% of the device manufacturer (but not all of them) implement this technic. Therefore I suggest the following procedure to move end devices from the old NS to a new one.

  1. Perform lab tests with all types of devices connected to your current network server and check if they really try to rejoin after a certain period of time not being connected. (You can remove the device from your current NS, and immediately provision it again so that you can be sure that it's session keys are deleted.)
  2. Remove all your devices from your current Network Server
  3. Provision all your devices on your new Network Server
  4. Visit those devices (<10%) that do not automatically rejoin upon not receiving LinkADRAns messages and restart them manually. (You must have identified all these devices during lab tests before you started the migration procedure)
  5. Wait until the rest of the devices rejoin to the new network.

This procedure is far not ideal, but there is currently nothing better. (In theory you could copy the session keys device by device, from the old NS to the new NS but in practice it would require additional integration effort with your old and new NS vendor that would bee too costly.)

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.