Technically what happens if there are multiple LoraWan network providers in range? (eg TTN + Helium, with channels overlapping) This is more and more common as the map fills.
Based on code I can’t set where to connect to. (in case of OTAA I might not even be able to activate)
And there is no feedback that my credentials got rejected (huge protocol design flaw) because I’m trying to use the wrong network.
I suspect there can be a deadlock condition, or node sticking to the wrong network,
thus this is a good way to jam Lora Nodes. (lot more effective than full spectrum RF jamming)
Does the node random choose channels to start a session? What if the wrong network is closer to the node? Does it always have precedence, or is there some randomness built in?
You only register to one network - if not registered the network back end drops you and ignores - no deadlock! Only your home network will respond and let you join (OTAA)…if no response I would start with checking you have entered the correct credentials, both programmed into node and set up in TTN console. If using ABP foreign network will simply drop your message…
Yes, having multiple networks means potentially more traffic but remember this is the ISM band - open to all. That is why best practice is 1) keep it legal, 2) keep SF low, 3) keep Tx power low, 4) minimise TX rate to whats need for the application vs what is nice to have or just 'cause you can, 5) follow and stay within FUP, 6) use ADR where possible (static nodes), 7) use bit packing techniques to minimise payload etc… basically just play nice with all the other boyz & gurlz - socially responsible spectrum use. Note LoRa modulation is quite resiliant not only to other modulation schemes but also to other LoRa traffic when on different SF’s
Wont happen!
Why should it - it just ignores you - not a design flaw but by design
Nope!
Nothing - it wont give a FiSK! and will just ignore you…you are noise to the other network!
all gateways for all networks in range receive the transmission and forward it to their backend
only the backend with the matching combination of DevEUI, AppEUI (also named JoinEUI) and AppKey is able to decrypt and process the request and build a response
the backend instructs a gateway that received the join request to transmit a reply.
for all communication from that point session information (DevAddr and AppSKey and NetSKey) will be used.
There can’t be any feedback because all the networks that can’t process the join request do not know whether they should process it. If they can’t they should not reply because that would be a good DOS attack. So that is not a design flaw, it is a very good security decision.
So you do code where to connect to. You make sure the right backend has the credentials and only one backend at the time has these credentials.
What channel the node uses and what the distance is doesn’t matter (as long as the right network has a gateway within RF range)
I see, so the node transmits the challenge (join request), and only the valid network replies to it and other remain silent. So network selection is built into the protocol. In that case it can really scale.
Thank you!
