Network Server or Application Server?

1

I’ve recently set up a chirpstack server inside of a docker instance thats hosted on an AWS EC2 instance. This is the github repo GitHub - chirpstack/chirpstack-docker: Setup ChirpStack using Docker Compose . I’m fairly new to this networking stuff so this might sound like a dumb question but is this docker instance running a network server or an application server or is it running both? Can someone explain the concept to me? Thanks (:slight_smile:

2

In CS V4 the network server and application server were combined into one for simplicity. So technically it is both.

In traditional LoRaWAN the NS is the component that handles everything required to run the network (filtering uplinks for your network, message de-duplication, downlink routing, etc…) but it does not hold the keys to decrypt the uplinks itself, the network server would communicate with a “join-server” which would create keys and pass them to the application server. The NS would then send its packets to the application server for decryption and data analysis.

Chirpstack does both the Network Servers job, as well as the Join server and Application servers jobs, meaning it creates and has access to the keys to decrypt the LoRaWAN messages. Therefore it is both at once.

1 Like
3

Are the network and application servers using the MQTT protocol to encrypt and decrypt the LoRaWAN messages sent between them?

4

Technically there is no distinction between the Application server and Network server here, it is simply Chirpstack. So there is no need for communication between two layers, Chirpstack stores everything it needs in its Postgresql and Redis databases.

Here is the general flow for an uplink:

  1. A device sends an encrypted message to a gateway using LoRa,
  2. The gateway then sends the encrypted message as a UDP or BasicStation packet to a GW Bridge or MQTT forwarder.
  3. The Gateway Bridge then translates the encrypted packet to an MQTT topic/value and publishes it to the MQTT broker with the following topic: <region_prefix>/gateway/<gateway_id>/even/up
  4. Chirpstack then receives the message from the broker, decrypts the packet, handles it as necessary, then posts the decrypted packet back to the MQTT broker for debugging/integration purposes under the topic: application/<application_id>/device/<devEUI>/event/up.

Chirpstack does not need to communicate with anything else for the keys, as it generates the keys for new devices itself and stores them for when it needs them.

If this is not what you want, there is also the option for end-to-end encryption which turns Chirpstack into a traditional LoRaWAN network server, it will not handle joining new devices and generating keys for them itself, instead you must specify an additional join and application server, and Chirpstack will simply pass the encrypted messages to your application server and not have any knowledge of the keys.

1 Like