I want find a solution to setup a network server to support multiple regional regional bands concurrently in one computer server. The Keyword “name” in section “[network_server.band]” in network server configure file support to config only one regional band. For example, I need to run AS923, KR920 and IN865 at the same time, but I only have one computer server, is there a solution to realize it?
You can only support one region at a time in the network server. However, you can run many network servers attached to the same (or multiple) application servers. If you’re using the containerized versions, you can easily run as many network servers on the same host as you want.
Just remember to separate the MQTT topics so you don’t get overlapping traffic between NSes.
2 Likes
Hi @bconway
What’s the problem to have an overlapping ?
Asking because I’m working on a implementation that should have only one UDP port to serve all gateways, including different frequencies.
This leads me to the issue that I can’t really route the traffic through MQTT topic.
Then I was jut wondering, one gateway and one device would exists only in one NS, what is the problem to other NS instance (frequency) to receive the packets from the unknown GW / Device ?
I did some tests and seems that the ALL NSes that are receiving the packets are responding to it (like join accept, etc). Just can’t understand why it is happening.
Any help on that ?
Just to let you know, I’m working on a refactor (not yet public) that should make it a lot easier to deal with multiple regions 
3 Likes
Hi Brocaar,
Would this refactor just be for different regions or would it also help for using different sub-bands within the same region, but on different gateway deployments, similar to this topic
Thanks!
Yes, the refactor will allow you to run multiple regions concurrently. It also allows you to run multiple configurations of the same region (e.g. US915 channels 0 - 7 and US915 channels 8-15).
3 Likes
Hello, What is the update about this ?
With Helium, global network, managing different chirpstack gateways witha single source looks confusing.
I did not find a documentation aout this yet.
Paul
Multi-region support is supported by ChirpStack v4 out of the box, and the chirpstack-docker repo includes a sample configuration that works for as many regions as you would like.
Hi
Yes it is multi-region but not device moving across region. A tracker as an exemple is moving from a region to another and basically the mqtt topic gets the zone, so the LNS could respond according to the right zone and don’t have a device profile associated to a given region.
What regions and frequencies are you trying to move between?
any region, EU868 to US915 then AU915 …
I still have this question on how to manage devices that are distributed globally and ready for being use. when it’s commissioned I have no idea where the device is going to be deployed, so I can’t set a region.
So the first message received will make us know it. Basically having a dynamic region setup would make sense : basically is should goes from where it comes.
Any idea before I hack it ?
Simple.
Just let the end-user to set the region of the nodes.
In the device-profile users can select the region (e.g. US915, EU868), as well the region configuration. If the user only selects the region, then the region configuration of the receiving gateway will be applied. This makes it possible to adapt the device to different region configurations (e.g. US915 8 channels to 64 channels).
If you want to configure the device for a specific region configuration, then the user can also select the region configuration (e.g. region: US915, region configuration: US915 channels 0 - 7).
1 Like
It’s more like we are selling devices in any region and we don’t know if it will be configured EU868 or US915 or … So it’s only at first frame reception we know this.
What I’m doing is dynamically changing the device_profile for this device after the reception of a frame coming from a different region. I assume it will work.
This could also be managed by chirpstack itself : getting the region config from the listener configuration.
The only tricky part is that some of the device-profile parameters are different per region. E.g. if your device would be an ABP device, then the RX2 frequency would be different too per region. In such case setting the region automatically would not work.
1 Like
It detects the Join-Request to switch, so it’s OTAA everytime in my case.