That is possible but not recommended and potentially illegal!
One of the functions that the NS a GW is associated with is to enforce/police duty cycle limts (that apply in your jurisdiction). If 2 NS try to send downlinks (MAC commands, join accepts etc.) without awareness of how much duty cycle has been consumed by acting on behalf of the other NS there is a risk of readily breaching the limit. Also if one NS has a downlink scheduled, the other may not be aware and also schedule a downlink at same time where it could have directed the message to another that is also in range and associated. There is then a risk one or both messages may not get sent due to conflict - but originating NS will have no way of knowing it has failed. This is then disruptive to users on both networks. Also many NS/GW pairs work on a JIT basis and if message sent without time for a warning back from the GW to NS to say ‘sorry cant handle that’ there is then insufficient time for the sending NS to response and redirect the message to an alternate GW running a queue - again the downink then misses the schedued message and target node is starved of a response etc…
Erm, No! just to clarify in case I misunderstand what you say/imply… Associate with only one NS!
You may be now thinking allow uplinks for both but only allow downlinks from one - is that what you now have in mind? Again that would be very disruptive to users and so please do not try that with TTN. If you wish to experiment use a private network
Indeed I was meaning uplink (device → NS) for all, only one with downlink enabled.
Understood, only one NS and no packet multiplexer when TTN is involved.
Is the reason valid in all cases, even when there is no GW for miles around (and / thus) with a very low device density ?
Sadly you will have no way of knowing that for certain - not all GW’s are publically declared or visible visible on community maps for various reasons - there might be another close by and owners tick box options may not have told you…also just because no GW today or tomorrow does not mean one wont appear next week or next month, and by then you will have a field deployment that then becomes disruptive!. Logically you may assume “but hey I’m just offering an uplink service where there is none and surely that is helpful”, but sadly the potential for user disruption is significant and cannot be well forseen/planned for. There is a use case for such if you want to offer a private network that offers pure bubble up operation - say to replace a low traffic deployment such as Sigfox - which depending on the payment plan you chose may offer up to 4, 2, 1 or no downlinks (i.e. bubble up only.) But again in context of a LoRaWAN deployment like TTN, even if on a private network, the NS may well have expectations for how a node may behave and may have a need to communicate with a node to change its behaviour…and if it doesnt change (as would happen for uplink only service as it wouldnt see NS downlink instructions) it may be the NS keeps on trying to send downlinks, or at least wanting to, that then becomes disruptive to the NS and the network overall…we see that todaty with crippled nodes that dont correctly handle downlinks and the NS gets into a tizzy trying to fix etc. You would have to recode the NS to set the right expectations also…
To be sure to understand, let me ask again in another way.
In a perfect world, only the TTN LoRaWan network would exist with an optimal coverage.
Suppose I manage a TTN gateway, while living next to a mobile operator antenna which holds its own LoRa GW.
A LoRa device should be declared in one network, or the other, but not both right ?
What would be the difference between this reality, and a unique gateway which would forward LoRa packets to more than one infrastructure ?
With two gateways both will forward the uplinks to their backends. If one of the backends decides a downlink is required (either for the application or a MAC command) it will instruct the respective gateway to send it and it will know that gateway is busy at a certain moment and will be using airtime.
If that one gateway has to send too many downlinks in a certain amount of time where it would exceed legal limits the backend will not schedule downlinks for that gateway.
At the same time the other gateway and backend will use the same mechanism for up- and downlinks.
Now you start using one gateway with two backends. For LoRaWAN to function properly both backends must be able to send downlinks to a node (for MAC commands). If one backend instructs the gateway to send at time X the other backend won’t know about it. As a result one of the downlinks won’t be sent without any feedback to the backend. Also because both backends have their own airtime calculations your gateway might exceed legal transmission limits when a lot of downlink traffic is scheduled.
So two backend with one gateway will lead to (legal) issues.
You can register it on both networks but 99% of firmware only allows you to provision it for one.
There was a recent discussion on how it is very easy to adapt LMIC to cycle through different configurations to join whatever is available and it could be done for LoRaMAC-node. But it will still only join one at a time. You could then save the settings and join another one. Or three. Or four. But you’d have to track the overall transmissions across all the different networks to ensure the device was staying within the legal duty cycle limits.
It would indeed be a unique gateway, as in a very special one of a kind gateway, that forwarded LoRa (or even LoRaWAN) packets to more than one infrastructure, but again, potentially doable, although only one should be designated as the prime for transmitting.
Rather than having it hit two network servers, after you’ve re-written most of the packet forwarder, the usual way is to have something on the gateway that reads the logs and send over the encrypted uplinks to your own server so you can then decrypt it and do as you please with it.
That is good for failover and redundancy - one NS/Backend goes down the other takes over, but not good for full continuous dual/multi running for reasons as outlined by Jac above.
I think we either need to close discussion down now as well off topic (TTIG for Sale!) or move posts to another thread to debate multi-tenancy GW deployments - or is that outside of scope of TTN and this forum? (as not officially supported on TTN & potentially disruptive as outlined above?)
