Multiple LoRa servers for application separation

Hello,
I have created multiple LoRa network servers, a database for each, added gateways and created multiple applications with nodes registered to them. Goal is to make sure that data from nodes are sent via specific gateway. The problem is that even though there are separate network servers used for separate gateways, separate all possible profiles, data from every node is received through both gateways. For example, if I shut down one of my two gateways, both my apps are still updated despite of the fact that the gateway corresponding to one of apps is not online. The only thing in my configuration which, I think, could be wrong, is that I use the same user for both databases:
dsn=“postgres://loraserver_ns:mypassword@localhost/loraserver_ns_us01?sslmode=disable”
dsn=“postgres://loraserver_ns:mypassword@localhost/loraserver_ns_us02?sslmode=disable”
So, should I create multiple users, one for each db? Or am I missing something else?
Thanks in advance!

There are many ways you can segregate your traffic further. You could filter at the Gateway Bridge by NetID. You could run different MQTT servers. You could run different topics on the same MQTT server. Etc.

This is a mistaken goal, because that is not how LoRaWAN works.

The problem is that even though there are separate network servers used for separate gateways, separate all possible profiles, data from every node is received through both gateways.

Indeed, because that is how both radio and LoRaWAN work.

The issue is that your original goal was mistaken.

You don’t need to do any filtering or follow any of the mistaken suggestions in the post above. If you wish to have distinct servers (for some unclear reason…) just only register a given node in the device database of one. The other may hear signal reports of nodes that don’t belong it it, but will ignore them (and in fact be unable to decode them), just as it would ignore and be unable to decode nodes belonging to other people.

Generally, you would not want to intermix backhaul traffic between gateways “belonging” to two different network servers, but that is because independent servers could both ask the gateway to transmit at the same time, not receive issues. If your goal is “application segregation” what you may want actually is two distinct application servers interacting with the same network server and collection of gateways, but first make sure you can’t meet the goal just with the account and application mechanisms. Building fully independent systems is probably only a good idea if your eventual goal is to geographically separate them, but you are temporarily running both out of your office while bringing them up, or something like that.

My goal is not mistaken. That is what I need for testing purposes at this point. I know, how LoRaWAN works, thank you!
If this all does not work as I expected, then I do not see the point of specifying the used Network server for Gateway-profiles, Service-profiles, Device-profiles and Gateways. My logic, which now seems wrong, was that if I have created an application which uses Service profile “One”, in which there is defined to use the Network server “One” and there also is a Gateway which also is added so that it uses the Network server “One”, then if my two gateways receives a LoRaWAN frame from a single node, they both definitely forms packets and sends them to my gateway-bridge server, as both gateways have configured to send the packets to the same IP address and port. Then gateway-bridge forwards the packets to all network servers, network servers send the packets to application server and there in the application server, in my understanding, application server should understand that packets from this exact node should only be received/accepted from Network server “One”, as this node is added to the application, which uses the Device-profile “One” in which there is configured to use Network server “One”.

I guess, I would like to hear what bconway knows about filtering at the Gateway Bridge by NetID. It would help me a lot.

then if my two gateways receives a LoRaWAN frame from a single node, they both definitely forms packets and sends them

That is indeed what would happen

to my gateway-bridge server, as both gateways have configured to send the packets to the same IP address and port.

If you are meaning to have distinct networks, you probably do not want to combine flows at this point, but rather keep them separate, but again, not for the reason you are currently worrying about.

in my understanding, application server should understand that packets from this exact node should only be received/accepted from Network server “One”, as this node…

It doesn’t seem like the application server should need to concern itself with things coming in via the “wrong” network server.

Rather, the issue you seem to be facing is that somehow a network server (apparently) managed to recognize and decode traffic from a node that doesn’t belong to it’s network.

It shouldn’t be able to do that. Did you use the same network key on both networks?

Your real solution should be to try to figure out why the network server “knows” network key of a node that it is not supposed to.

It may be that you’re just running into odd cases by trying something unusual: typically you’d either have a unified network and not care which path was used, or have distinct networks that having nothing in common but spectrum and geography, and so can’t make any sense of each other’s traffic.

Generally, if you have information sharing, then it is because the goal is to unify (for example to let a node continue to work when it moves to a different area of coverage), not to segregate.

Thanks for your detailed answer! For easier management, all my nodes have equal AppKey and JoinEUI, but, unfortunately, I am not quite sure what do you mean by “Network key”. Do you mean “Network session key”? Could it be that Network session key is generated using AppKey? Then it would mean that I have to use different App keys for my nodes that should be separated. That would work for me, if so.

If your intent is to segregate your traffic by gateway, and you are unable to run the network bridge on the gateway itself (recommended), you will probably want separate infrastructure-based gateway bridges to match each of your network servers. We do so for both business and technical reasons.

So, you also create a separate MQTT servers, right? That means that only application server could have single instance? Every other part of the whole system should be multiplicated?

That’s one option, but there are many. You could also use different topics on the same MQTT server, similar to how you would run different regions on the same MQTT server (https://forum.loraserver.io/t/is-multi-tenant-supported-by-the-architecture/970/2). A lot of it comes down to your capacity planning and business requirements. We are configured to spin up an entire LoRa stack with one command, and these choices are frequently driven by business needs (data isolation, etc).

Unfortunately, I still cannot figure it out, how to use different topics.
If I add “us01/” as prefix in gateway-bridge configuration and “us01/” prefix to my server named us01, then in the journalctl I see that there is no activity at all on my sever named us02 which is logical, but still I receive all the data from all the nodes on both applications from both my gateways. Which also is logical. I took a look at https://www.loraserver.io/lora-app-server/integrate/sending-receiving/#event-types and thought that I could filter my traffic by application name if I added that to gateway-bridge MQTT topics, but, unfortunately, adding {{ .applicationName }} in topic tamplates just gave me an error, because it looks like gateway-bridge does not know anything of application names…

Of course not. As explained way back up at the start, gateways have no awareness of applications. They don’t even really know if the traffic they are passing is LoRaWAN at all.

Sometimes people do limited packet inspection in the gateway, looking at say (potential) LoRaWAN addresses, but the gateway doesn’t have the information to know if that is actually a LoRaWAN address, or random bytes from some other protocol, because the gateway doesn’t have the secrets to validate a LoRaWAN message integrity check, and that’s not it’s job.

It’s never been clear what you are really trying to accomplish here, but what it sounds like you are trying to do is in conflict with how LoRaWAN is designed to work.

If you goal is to prove that some set of things works independently without assistance of some other set of things, then you should probably create a completely independent setup sharing no components whatsoever, or relocate one set of hardware (gateway(s) and nodes) to a different location out of range. In some regions of the world it may be possible to put a network on a different set of uplink frequencies, that would prevent unintended cooperation, though it can still cause destructive interference if nodes are close to a gateway on a different sub-band.