Best strategy for multi-region network server deployments 🤓

Hi Guys

this was asked here before, but not specifically about best strategy for low latency.

If my Chirpstack App server is deployed in EU Region
and I want to create a low-latency network server for AU / AS / US regions

what should I deploy in each region, the chirpstack-network server or is it enough to deploy chirpstack gateway bridge in each region and having all the network servers running in the same region.

Reason is that I would like my resources to share the same managed database, cache cluster etc.

your thoughts?

1 Like

A couple answers:

  • We had no latency issues in testing across the pond from EU to the US. Yes, the latency was slightly higher, but nothing that affected the ability to OTAA join, RX windows, etc. We did have issues going from AU to US years ago testing with a non-ChirpStack network server, and I would be very wary of such latency.
  • Despite no issues with EU-US latency, we deploy completely separate environments in different regions for other reasons (GDPR, isolation of customer data, etc). So yes, we do keep our network and application servers closer to the gateways in production use.

Hi @bconway
thanks very much for providing your keen input

Right, latency is hit or miss, and when GWs are over cellular it is always worst and can cause issues when the network server is lagging. But I do see your point here, but my current client is a manufacturer of lora devices, and he plans to sell kits globally and I would hate to have him log into different App servers to monitor his devices.

So I am thinking, I will try to setup CHIRPSTACK Gateway Bridge in each region, and keep my network servers in one region, sharing managed database, redis cluster, mqtt broker. Gateway Bridge only requires mqtt so setting up new regions will be easy. and I assume that latency between AWS regions will be minimal. I can probably use t3.nano for each :slight_smile: (4usd / month) for each GW until I grow…

In regards to latency and dealing with it,
@brocaar On another LNS server I use for a project, they have a parameter to set network delay per gateway to take network latency into account. So if the GW is averaging 300ms ping, you can play with the delay in the App Server, set it for uplink and downlink, and the LNS will take that into account when handling downlinks to the GW.

1 Like

Another option you could consider is deploying one application server, with a network server colocated with the gateway bridge in each region. You may get better latency/experience.

1 Like

Right, I understand this is probably the best approach, but for resource management I would prefer to keep network servers all in same region, sharing resources, and just have lite installations in each region.

I guess I can do both setups and see…