Chirpstack and

After the TTNv3 and announcements, is Chirpstack Network Server planned to participate in the ecosystem?
Yours sincerely,

Is there any news on this (@brocaar)? I guess with the transition from TTN v2->v3 by September this year this gets more momentum.
I attached a picture how I would imagine the behaviour for a private network, which keeps private netIds local, if they are handled by the local installation.

For everyone not knowing what packet broker is here a 10min explaination:

I think ideally the PacketBroker integration should be an external component, not something embedded within the ChirpStack Network Server. If somebody would be interested to work on such component, then I’m happy to share my thoughts, but I don’t have any plans to create such component yet.


@brocaar I would like to hear about your thoughts and also a bit of light on how to work with Chirpstack and Packet forwarder.

Thanks in advance.

You mean a Packet Forwarder or Packet Broker?

I mean Packet broker, i made a mistake sorry.

The way I would see an integration with the Packet Broker is:

[Packet Broker integration] <--> [MQTT broker] <--> [ChirpStack Network Server]

E.g. it would just behave like a gateway or gateways.

1 Like

as far as I understood the current packet broker agent implementation it needs also a way to determine, if a downlink packet could be scheduled.
I interpreted this from here and here

Would that be possible with the MQTT interface?

Actually, the Packet Broker does have a Passive Roaming interface :slight_smile: This means that you can setup a Passive Roaming agreement between ChirpStack and the Packet Broker. See also this talk that I’ll be giving this Friday: Packet Broker – how to peer with 40k gateways worldwide – The Things Conference.


Looking forward to it. I would really like to stay with Chirpstack.

Hi broocar,

I watched your ponence and was very interesting. But I have a doubt about what passive roaming means.
If we have a private Chirpstack based LoRaWAN network server, we could connect with this passove roaming setup?

Hi again, just watched the recording. I understood in that way, that one can get free access by writing an email to and describe that one only wants to contribute to TTN in what johan describes as one-way. This means that a local running Chirpstack will continue to handle it’s own netIds (e.g. for me 00/01) but forwards everything else to packet broker and vice versa.
Orne+Johan also explained other options to roaming, but I understood that Orne only went into configuration details for the passive roaming, as I described it. I also understood I would not need an own official expensive netId for this passive roaming configuration.
I just wrote an email to join packetbroker in that way and hope that my assumptions/understandings are right.

1 Like

I’ve watched your talk about passive roaming and packer broker. What I don‘t get is, if it is possible to connect 2 chirpstack network servers both with netid 0x00/0x01 just using the already implemented join server?

I’d be interested in the answer. We manage a city-wide (Public utility company) deployment and would like to support the different communities.

1 Like

With the test NetIDs (000000 / 000001) you can’t through the Packet Broker. As Johan explained, you can connect to the Packet Broker, but this would be uplink only (e.g. contributing to the TTN coverage).

Please note that if you only want to share data between your own instances, there is no need to use the Packet Broker. You can directly link your instances. E.g. configure NS 000000 with a roaming agreement for 000001 and NS 000001 with a roaming agreement for 000000.

A company that I’ve worked with is using a kind of “auto discovery” of roaming partners. They use the default / catch-all roaming agreement + DNS resolving and a common CA certificate. This only works when the device OTAAs through the fNS as based on the DevEUI (part of the join-request) it is able to to request the home NetID of the device. For already activated the only information that you have is the DevAddr, which can only be matched against a NetID if you have one of multiple NetIDs to match against.

In this case all NS have their own client certificate signed by the common CA. As each server is setup with the CA certificate, they are able to authenticate the other NS instances without the need to pre-configure these per NetID :slight_smile:

1 Like

I received the following message on day later:

Hi Marcel,
Thanks for following up. We have a community plan which if it is used without any commercial interest.
We’ll follow up in the coming weeks how you can join.

So: “Patience you must have, my young padawan.” :slight_smile:

Got my key, but have problems setting it up. Made a new thread for setup as it might also happen to others.