Multiple NS to One AS and One GW Bridge

Hi there

I’m trying to implement multiple frequencies schema using only one AS and one GW Bridge.
The idea is to keep only one port opened (i.e. 1700) on our UDP rule and all gateways from all different frequencies being connecting to same address/port.

On GW Bridge, I would need to route the traffic to the right NS instance.
Is there any possibility to achieve that ?

Route all traffic to all NS is an option ?
I did the test:

2 NS instances, 1 AU915 and 1 US915. Both subscribed to same gateway topic.
1 AS.
2 Gateways pointing to same topic.
Provisioned both gateways on AU915.
Provisioned one device to AU915.

US915 NS still empty, no gateways, no devices, no profiles.

For some unknown (yet) reason, the logs on NS US915 (the empty one) shows some activity, like it was accepting the join request:

12/7/2021 12:29:29 PMINFO[1373] gateway/mqtt: uplink frame received           gateway_id=7076ff02acb2ff00 uplink_id=914835ce-5bee-4dab-bae0-ed1568656666
12/7/2021 12:29:29 PMINFO[1373] gateway/mqtt: uplink frame received           gateway_id=000080029cc78e2e uplink_id=6a0e3077-2953-4c3d-80a1-ca4c302963ef
12/7/2021 12:29:35 PMINFO[1379] gateway/mqtt: uplink frame received           gateway_id=000080029cc78e2e uplink_id=f03732a6-1bb6-4efa-9e98-96e09f6ba968
12/7/2021 12:29:35 PMINFO[1379] gateway/mqtt: uplink frame received           gateway_id=7076ff02acb2ff00 uplink_id=43e775c3-081a-4e4f-98ea-e8947c603e82
12/7/2021 12:29:39 PMINFO[1384] backend/gateway: downlink tx acknowledgement received  downlink_id=658b19ee-3244-4e90-81d9-6de2d75b1e22 gateway_id=7076ff02acb2ff00
12/7/2021 12:29:39 PMINFO[1384] device-session saved                          ctx_id=658b19ee-3244-4e90-81d9-6de2d75b1e22 dev_addr=e074eba5 dev_eui=848bcdfffe60a2ba
12/7/2021 12:29:39 PMINFO[1384] sent downlink meta-data to network-controller  ctx_id=658b19ee-3244-4e90-81d9-6de2d75b1e22
12/7/2021 12:29:40 PMINFO[1385] gateway/mqtt: uplink frame received           gateway_id=7076ff02acb2ff00 uplink_id=af7d1b51-0d6f-4603-a639-d4ab795143fc
12/7/2021 12:29:40 PMINFO[1385] gateway/mqtt: uplink frame received           gateway_id=000080029cc78e2e uplink_id=e5569413-e429-43aa-8405-61448af54006

Which should not happen in my understanding.
All profiles (gateway, device, service) are pointing to AU915 NS instance.

In this test, the device becomes lost. It asks for join several times (seems to be on both NS) and loose its keys suddenly and need to join again. Once I stop the US915 service, it works normally.

The only populated table on US915 database is the rounting_profile, which points to AS API address.

Shouldn’t the US915 instance just ignore those packets ? In my understanding is almost the same case as one unknown device on gateway range sending packets to it.

Any hint about this infra is really appreciated.


It’s really preferable to run the gateway bridge on the gateway or as close to it as possible, since the UDP protocol between a legacy packet forwarder and the gateway bridge is not very robust or secure compared to MQTT over SSL between the gateway bridge and network server.

Multiple regional settings tends to be mean you’re covering a large geographic area. If at all possible try to run the gateway bridge in each gateawy. If not, you may need an instance of it for each region, ideally closer (in network terms) to the gateways it serves.

What are you using for gateways? There are setup pages here that describe how to get the gateway bridge onto many, many types.

Hi @cstratton

Thanks for your answer.
In fact, I plan to have several FSB on same frequency and enable specific channels for the specific sub-band. Which means that, for example, US915:
2 instances: FSB 1 and FSB 2 on same region and so may have gateway overlapping.

More than that, to provide it I would need, in the standard deployment, 2 UDP ports linking 2 GW Bridge, one for each FSB.
I’m seeking a way to use same GW Bridge, and so same UDP port, for both and forward the packets to:

  • OR the right LNS
  • OR to both LNS and have it handled by the one that has the device provisioned.

What is happening is that both LNS are “competing” to handle the packets, even if the device doesn’t exists on that LNS DB.

The gateways belongs to our customer so we don’t have any control over it and can be a wide range of brands and models.


We made some tests some time ago and finally our conclusions were:

  • Use different NS with own setup depending on requirements.

  • One GW Bridge linked to each NS

  • One domain name with different ports for each GW Bridge / Different domains with same port for each GW Bridge.

  • One App server

It works really well like that.