The value chain of a LoRaWAN project is extensive, and the sources of limitations and other bottlenecks are numerous and varied. Our customers regularly ask us about the physical limits of our solutions: how many sensors can the system support? How many messages can be transmitted with one instance?
Here, we focus on performances of the Chirpstack LNS, which is used in some of our products.

Chirpstack, per Chirpstack own website, “is an open-source LoRaWAN Network Server which can be used to setup LoRaWAN networks“.

At Wi6labs, we already use it for one of our own solution: µWiotys, so naturally we got curious about performances.

To quantify theses, we will put Chirpstack in near-real scenarios to see how it will behave under loads (see Result).

Please notes, that results will depend on used hardware, software and such. It is to be used as an indication.

Chirpstack’s own creator provide a simulator to create and send LoRaWAN frame to one Chirpstack instance. While this is really helpful (and we may write a post about it), in our case this complicated our analyses:

• The simulator generate random sensors, gateway and such at each run.

• Each sensors must complete a Join procedure before sending any Uplink (and thus before generating new sessions keys).

To avoid randomness, instead of using the simulator, we decided to create a Postgres migration. This allow us to have static informations.

By experiences, we know that the Join procedure is not generally an edge case and represent a minor part of a network traffic. In a sensor life, Join procedures are done fewer times than Uplinks (except for some really strange or badly configured sensors).

So our tests will only focus on sending Uplinks and seeing how many Chirpstack can process before things goes awry.

Thanks to our migration, we will “only have” to send Uplinks by simulating what a gateway would send to Chirpstack on port 1700 (more on that in the next part).

Finally, to make our tests a little more realistic, will have a lot sensors (300 000) and gateways (2 000) registered on Chirpstack to see if this impact performances.

By using the Semtech Protocol, we can send data directly to Chirpstack. To do so, we will use the linux tool netcat with options to not wait and to send data to our Chirpstack instance on port 1700.

This looks like nc -w 0 -u chirpstack 1700

To stress loaded our instance, we send payloads to Chirpstack using one bash script that take a list of payloads and gateways and send them as fast as possible. We generated the list with the same payload ‘00’ and this give us LoRaWAN frames with same sizes.

Our Chirpstack instance is configured to send Uplinks to our local webhook (see Testing platform used), this way we can extract the time it took for processing and sending of Uplinks.

All test were done using a Proxmox container:

• 16 GiB RAM

• 128 Gb Disk

• 8 Processors

• Rocky linux 9.4-x86_64

And using:

• Docker 28.5.1

• Chirpstack 4.16.2

  • docker version with no modifications

• Webhook

  • Using provided docker-compose.yamlwith a modification to allow receiving more than 500 messages

Our tests and results are listed in following array:

As you can note, we lost some Uplinks between what we sent and what it was received, this is expected because of netcat and how we are using it.

Also, it is pleasant surprise to see that the number of gateway does not really matter.

In the end, we got between 147 and 258 Uplinks per second. This means that we could theoretically expect a maximum of around 13 to 22 Millions Uplinks per day processed.

Keep in mind that:

• Because of the way we are sending Uplinks, this may hide some issues or result in other performances than with real gateways.

• We only sent short burst of packets, performances could be reduced if it is a constant load.

• We also saw a little decrease of performances when Uplinks’ number increased.

• No codecs are currently applied, using those may decrease performances.

• We did not configure Chirpstack, so playing with its configurations may impact performances (one way or the other).

We also tried to find the limit before our instance would take significantly more time to process Uplinks. We set an arbitrary threshold to 15s of delay.

Please note that, because it is not a clear boundary and we are not 100% sure that it’s Chirpstack that is truly taking more time, we decided against putting it in the above array.

So, take the following number as an indication more than a result. We seems to hit a limit above 260 msg per second sent for few minutes (3min), where the last Uplink would be sent to our webhook few seconds later (~30s).

Chirpstack is way more capable of what we initially though. And based on our results, one can hope to have more performances if it’s deployed on a more powerful computer.

In the light of this, we may run, theses kind of tests on our solution µWiotys, to see how it perform under theses loads. Also, we may tweak Chirpstack configurations to see if it will impact performances.

We wanted to thanks following amazing projects that we used during our tests:

• https://proxmox.com/en/

• https://github.com/chirpstack/chirpstack

• https://github.com/brocaar/chirpstack-simulator

• https://github.com/webhooksite/webhook.site

• https://github.com/Lora-net/packet_forwarder

• https://netcat.sourceforge.net/