ChirpStack Architecture

ChirpStack (v4)
1

Hi everyone,

I’m currently working on understanding the ChirpStack ecosystem and how data flows through it. I’m a bit unsure about certain aspects and would really appreciate some guidance.

I have ChirpStack and other programs running on my laptop with docker and no connections to cloud as everything is hosted locally.

Specifically, I would like to understand how data moves between different components of the ChirpStack system (e.g., Network Server, Application Server, etc.). Or am i missing some components from the picture.

Thanks in advance for your help!

Best regards,
Artturi

chirpstack Architecture
chirpstack Architecture1363×577 21.7 KB

2

Have you seen the official architecture diagram?

I think your diagram is largely correct, but I have the following comments:

  • There is a Chirpstack Gateway Bridge (GWB) component and this is the part that communicates between the Network Server (NS) and LoRa Gateway components. I guess it’s missing from your diagram as you’re running the GWB inside the LoRa gateway? This is specific to Chirpstack. If you use a packet forwarder, that would be inside the LoRa gateway, while GWB is inside the cloud.
  • Chirpstack NS and AS used to exist as separate components and communicated over gRPC, but Redis was always a separate component. It’s an in-memory database that Chirpstack uses to be able to respond fast.

The uplink data flow is something like this:

  1. Frame is demodulated by software in LoRa gateway.
  2. LoRa gateway software forwards it to the Chirpstack GWB component.
  3. Chirpstack GWB pushes the message to NS, over MQTT.
  4. NS does de-duplication of message, waiting for some time (e.g. 200ms or whatever you set) for all copies to arrive from all gateways in range.
  5. NS will update the node’s state data in Redis.
  6. NS will push the uplink to AS.
  7. AS may carry out some application-level processing.
  8. AS pushes the message to 3rd party applications, over integration(s).

The RDBMS (PostgreSQL in your diagram) is used for saving settings and the device profile, but the session data is saved in Redis. In the latest versions of Chirpstack, NS and AS were merged into a single module, and the device session data is also persisted into the database too.

As for how multiple GWB work during downlinks, they’ll only subscribe to the downlink command topic (NS → GWB) if the gateway has been communicating with it. Thus, there will not be any ambiguity over which GWB to use for communicating with a gateway.

3

I really appreciate the time and effort you put into your response. Your explanation helped me understand the ChirpStack ecosystem and data flow better.

Thank you so much!