Sorry but as the change to V3 brings some risks to my projects I decided to step out of TTN and migrate to a private Chirpstack Lorawan. Yet I would like to continue to offer my gateway to the TTN community as well. Is it possible to forward packets to different networks at the same time? Currently I use the Semtech packet forwarder and only changed the TTN host address to my private Chirpstack server address and change the gateway ID. I would probably need to have the same gateway ID in both networks, right? Is this a problem?
1 Like
What sort of risks do you perceive?
It would be useful to know how people see the move.
If you are taking cues from the early adopters who have run in to some hiccups with their migrations, please consider that there are a whole pile of us working on getting the kinks out and we still have a while to run before anyone will have to move over.
As well as using TTN v3, I also have the open source version installed on a server. All compliant activity & devices work well. Warping time & space with odd setups does break things, but that’s not exactly a surprise!
That is the issue, my smartmeter readings comply to the duty cycle but not with the TTN fair use policy. So I was only tolerated all the time. And the memory on my devices doesn’t allow for a full implementation of the Lora-Stack so they get confused by downlink MAC commands and trigger too much downlink traffic. I was also not so happy about the overall communication and migration to V3 but that should not be the issue now. I will definetly move to chirpstack but as said I would be happy to forward V2/V3 packets to TTN as well, if possible.
1 Like
Perhaps check out:
There will be problems, according to this thread:
Hi @niels80,
I am running such a configuration since over 2 years with Chirsptack (formerly Loraserver) now. As you I have devices using more bandwidth then TTN allows but less then my regulatory domain allows. (btw also an energy meter :-)).
My main reason for having an own (local) LNS (Lora Network Server) and Application Server is being able to have my sensors working even without internet connection. Chirpstack is hosted on a Pi Zero W which also has the concentrator board connected to it and an influxdb.
As already pointed out one needs a single LNS to handle one antenna/concentrator board, because of duty cycle calculations and conflict resolving, if we have multiple downlinks at the same time or overlapping each other in air/time space.
The problem is less the gateway IDs, then the device addresses. In your local network the gateway ID can be anything you like. Might also conflict with anything in TTN. Your packets stay inside your network anyways. The ID can be faked or changed (at least with Semtech UDP) anyways. The Loraspec assumes the gateways to be relatively dumb (and therefore cheap). What you want is, that your packets from the devices are transmitted locally and to TTN. Packet forwarders (poly and mp) can be configured with multiple LNS backends then sending the data to both resulting in the described problems of having multiple LNS wanting to control one gateway.
I “solved” this by patching mp_pkt_fwd in such a way, that it splits device traffic by netid. The “private” netIDs 00/01 are transmitted to the local chirpstack installation and all other traffic goes to TTN. This still does not solve the problem of downlinks being transmitted at the same time by two different LNS. So I added a priority mechanism based on the server. It will prioritize downlink packets from TTN and throw out all downlinks by chirpstack that might be in conflict from the packet forwarders JIT queue. In this way TTN can assume its own packets are send. As I have almost no own downlinks, I have neglected to implement a duty cycle check at the packet forwarders level.
TTN v3 packet broker can be configured in the exact same way, but would require a local installation of the TTN v3 stack. I understood as long as one only acts as “helper” and does not require routing of own netIDs packet broker is free to use (called passive roaming).
I am thinking about switching my Chirpstack to a local TTN stack installation, as it fixes the duty cycle problem. Chirpstack does not yet have a packet broker implementation, but the talks about it started.
But also packet broker does not (yet) fix the problem of having multiple LNSs feeling responsible for one gateway and conflict resolution.
Additionally my patched version (but also packet broker) “steals” all netIDs 00/01, which seem to be of use for others.
So from the (current) software side I do not see a solution (assuming you want to stay with TTN) without drawbacks. The hardware solution would be to setup a second gateway and have one working locally only and the other only for TTN which gives additional downlink bandwidth but might physically not be possible. And then one needs the material, money and around 3W power for something that can (and most likely will) be fixed with software only.
1 Like
@niels80 @LanMarc77 I have a very interesting announcement to make this Friday (May 28) at The Things Stack Conference (tickets are free for community: https://www.thethingsnetwork.org/conference/), that is exactly about the points you mention.
3 Likes
Uhoh, it seems christmas is early this year. I will need to watch the recording on the weekend though.
And best of all, it looks I can go on using my beloved chirpstack. I hope you mention how I can get the credentials for that additional authentication.
Thank you for the heads up.
The presentation we are talking about: https://www.youtube.com/watch?v=ugt6L5YRNGk&list=PLM8eOeiKY7JVbDrARJo28v86xSr7k-SWl&index=3
Man I hope I understood everything. I asked for access to packet broker based on what Johan described as one-way starting at minute 37.
Johan also summarizes a lot of discussions we had here in the forum about this over the last year. Thank you.
I wrote an email to join packet broker and received the following answer one 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.” 
1 Like
Quick update here; this now works and we have at least one ChirpStack network connected successfully to Packet Broker.
We’re working on getting this documented.
4 Likes
Hi @johan! Thanks to you and the TTN team for the work you do! 
Related to this topic, Im looking forward to work in ChirpStack and TTN at once, so may I ask if you have got some related documentation?
Hi @brafavp please see ChirpStack | Packet Broker Documentation to get started connecting ChirpStack to Packet Broker. You get free access to Packet Broker for making your coverage available to The Things Network.
1 Like