Can a Node connect to multiple LoRaWAN networks/servers?

[patmolloy]

Hi,

I am ashamed to admit that I don’t understand enough about the architecture of LoRaWAN to know the answer to this.

If a given node is in earshot of multiple LoRaWAN networks (in my case TTN and a loraserver.io system) can this node join both networks (assuming it is provisioned on both) or does the first join preclude this.

It’s definitely the case the the TTN gateway and the loraserver.io gateway can see the packets from the node … but my assumption is that it can actually only join ONE network.

I am using OTAA.

Is my assumption correct? For both OTAA and ABP?

Thanks!

[jreiss (Jason Reiss)]

Only one packet can be received by the end-device. Both network servers may send Join Accept packets at the same time or in Rx1 and Rx2, where Rx1 would be received and Rx2 skipped. If both send in Rx1 the strongest packet may be received if it is 3dB higher than the other. If they are near the same strength the downlink may be corrupted.

The Join Accept message contains a NONCE value from the network used to setup the session keys.
Only one of the networks may have valid session keys after the join unless they happen to both use the same NONCE value. If the same NONCE is used the end-device will be able to send uplinks to both networks and downlinks would be issued from both networks.

[BoRRoZ]

see

One device on multiple LoraWAN networks simultaneously

Hi, We are experimenting with the things network right now, and also we joined the Cibicom network in Denmark. We added our test device to both LoraWAN networks. My plan was to use TTN as the primary network, and then Cibicom as a kind of backup network, where TTN does not cover properly. I am testing with a dragino lgt92 gps tracker. Unfortunately it seems that the device on power up connects and exchange keys with a network, and then its not able to communicate on the other network until i…

[patmolloy]

Thanks Jason. So, to summarize, it is possible if the NONCE value issued are identical, but in the real world unlikely. If a device issues a join request, whatever Join Accepts first will preclude the device from joining again (to another server).

[patmolloy]

Thanks! Will read. I thought I basically understood all this, But I clearly don’t!

[cslorabox]

@patmolloy

Thanks Jason. So, to summarize, it is possible if the NONCE value issued are identical, but in the real world unlikely.

Even that would not really work. Situations where both network are visible at once would be a disaster due to on-the-air collisions in trying to downlink. And situations where one network is not visible for large periods of time are unworkable because even if the server does not expire the session, the implicit upper bits of the frame counter would walk out of the range the server would be willing to search, and the unicremented downlink frame count used by a server that hadn’t been seen in a while would be rejected by the node as a replay attack.

Essentially the only way this can work is if the servers coordinate, and then you’re really not joining two networks, but rather joining one network that also supports having you roam to another.

[patmolloy]

Great stuff. Got it!!

[sritam2]

I assume that you use OTAA. In this case if the device is receiving the join accept message of network server A then the device is actually using the session keys(AppSKey and NwkSKey) of A and not B. When it transits from the range of A into the range of B then it will not be able to connect with B even though the device is added in B. Because adding a device in B need not necessarily mean that the device has an active session. Device will only have active session with that server whose join request it accepts. So, it has to again restart and resend a fresh join request after which B will send join accept and then the message transmission will happen successfully. This is what my understanding is