On of our clients has hundreds of sites located all over the world. We need to collect all telemetry from the devices in a central location. For this we could install our application centrally on Amazon AWS.
But what about the ChirpStack architecture and setup?
When you think about network latency, will a single centrally installed ChirpStack Network Server be enough? My gut feeling is that we need multiple network servers spread across different continents.
If so, how should this be set up?
What is your experience? Any information or suggestions are highly appreciated.
Looking at the ChirpStack architecture (see image), we usually provide gateways with the packet forwarder and gateway bridge installed on the gateway.
The idea is that a customer site just needs to install gateways and point to the correct (central or regional) ChirpStack Network Server location and be ready to go.
Since RX1 exists 1s after every uplink, your Round-Trip Time (RTT) between the LoRa node, LNS and back, must be within 1s for downlinks via RX1 to work. As you know, this probably means that you have to locate your servers regionally to avoid giving users from the edge regions a hard time.
Unless, you decide to relocate RX1, which is possible because you are the LNS operator. Note that Chirpstack will also spend something like 200ms for packet de-duplication, which will add onto the RTT.
I wouldn’t say that you surely need to install the Chirpstack Gateway Bridge (concentratord) on the gateway. While it’s an option, it also couples the gateway with Chirpstack. Other packet forwarder solutions like the Semtech Basic Station and the classic Semtech UDP Packet Forwarder also exist.
Please note that both the rx1 delay as the deduplication delay are configurable
One thing that I have learned from some discussions / feedback from clients is that it might help to use a cloud provider which has worldwide coverage, as often their internal networks have a lower latency between continents. At least that is what I have been told. I have no numbers to back this up.
In this case the gateways would connect to an endpoint / server close to the gateway, so that most of the “communication distance” is handled by the cloud provider, which should help reducing the latency.
