How can an operational node be triggered to join a different network?

End Devices (Nodes)
1

I know “commonly used” is vague, but: do commonly used LoRaWAN modules/libraries (such as used in the TTN UNO) make it easy to change networks?

For Over-the-Air Activation (OTAA) the LoRaWAN R1.0 specifications only define:

An end-device has to go through a new join procedure every time it has lost the session context information.

I guess an application could use a node’s downlink receive window to tell it to commence a new join procedure, or a node could do that when it’s not getting any response from its application at all. But I don’t know if “standard” LoRaWAN modules/libraries can then be programmatically triggered to clear the session data or to trigger a join procedure some other way.

(I am asking this to avoid any vendor lock-in. Like if TTN goes down after a few years. Or to switch from private LoRaWAN networks to TTN, where the private network might still be operational and might not even want to help switching to a different network. For that same reason I would never use Activation By Personalization (ABP) using hardcoded network keys in the nodes.)

2 Likes
2

I found some documentation on the UNO beta, which tells me it is using the Microchip RN2483 (with embedded LoRaWAN Class A protocol) which also offers:

mac join otaa

Likewise, version 1.5 of the IBM “LoRa WAN in C” offers LMIC_reset, LMIC_startJoining and LMIC_tryRejoin (with the latter the session to the current network is kept if no new network is found).

So, assuming that for the RN2483 mac join otaa also works if a different network was already joined earlier: all this seems easy enough, if the node is programmed to execute this after it has not received any response from the application.

3

The switching to new network is described clearly when previous network is “ready to help” and forget about your nodes (to not answer to your nodes). But I guess in that case ABP works too – node will just use new network.

But it’s still not clear for me, is that possible to switch the network with OTAA if previous network is not ready to forget the node (let’s say the interface for that is broken or hacked at the old network)?

I guess this understanding will help to differ ABP and OTAA advantages and disadvantages better.

4

For OTAA, the node knows an end-device identifier (DevEUI), the application identifier (AppEUI), and a secret application key (AppKey), which preferably is unique for every node. That secret is also known to the application server, but not to the other parts of the LoRaWAN infrastructure. So in the end only the application server can allow a node to register itself with a network.

However, the application server might be provided by the same organisation that provides the LoRaWAN network. Like for The Things Network, when not using one’s own application server, TTN’s Console nicely takes care of all that. Now, if you want to register with another LoRaWAN network while the previous network is still operational and its application server is still handling OTAA requests for your node, then the node might indeed (randomly) register with the wrong network.

I guess chances that a previous provider will do this are low. But if you want to be sure then either sign some strong legal agreements, or set up your own application server and don’t share the application secrets with the LoRaWAN provider.

For ABP, the node knows a hardcoded device address (DevAddr), secret network session key (NwkSKey) and secret application session key (AppSKey). If the previous network is willing to forget about those, then you could probably use the same keys with a new LoRaWAN provider, assuming they provide a way to specify one’s own keys. (Which they probably will.) Using just any DevAdrr is not possible, as it includes a network identifier:

The most significant 7 bits are used as network identifier (NwkID) to separate addresses of territorially overlapping networks of different network operators and to remedy roaming issues. The least significant 25 bits, the network address (NwkAddr) of the end-device, can be arbitrarily assigned by the network manager.

I don’t know if this is really used. (And implementation might differ for different networks.)

TTN has their own id, so cannot support those of others.

5

Have you considered a mechanism to remotely switch the node AppKey. Suppose you provision each node with say 5 AppKeys. Then you can switch to another network by using another AppKey and issue a new OTAA. This would be triggered by some download command (or the lack off within a certain time frame). If all fails, you could fall back to a maintenance AppKey for recovery.

1 Like