Hmmm, I guess it would be interesting to see if it gives an NS access to other networks gateways.
Which if it doesn’t, it means downlinks are problematic (can’t be queued).
And if it does, it means downlinks are problematic (may be double queued).
It allows queing downlinks, just as feeding multiple servers directly does.
What’s missing is any resolution of conflict - someone loses.
Actual conflict resolution would look at the gateways available to transmit the conflicting downlinks and try to assign them so that both get sent.
Or failing that, learn that the requested gateway is unavailable in time for the losing network server to try any others in range.
But the combination of TTN + packet broker hasn’t been designed to do that.
Interesting discussion here.
I would agree that the cost of running package broker is prohibitive for most. Add the complexity of the PB setup to the cost, makes it look even less attractive.
If someone with a private gateway/NS wants to contribute to TTN, then from my (greenhorn ) point of view it would be much easier, and cheaper (and maybe naive), to just setup 2 gateways at the same location, one for the private NS, the other for TTN. Just make sure of proper antenna distance between the two gateway. Sure, there is still chance of collisions for downlink transmissions, alas at a lower rate since there is a good chance that occasional simultaneous downlinks would be transmitted at different frequencies.
We may or may not like the idea of gateways being physically placed close together , but I think that over time, as LoRaWAN grows, gateways for various NS will be deployed within close distances, since operators try to place them at optimal locations. Thus the clustering of gateways at prime locations is almost inevitable and probably has already happened. Which rises the question what the practical impact on downlinks at such existing hotspots is. This impact could/should be measured with test nodes able to report missing testdata downlinks. I would expect that any serious network operator has such tests already in place to continuously measure quality of downlink service. (same goes for uplinks)
2 Likes
I think I will wait for a better or more elaborate explanation on how PB may be used in this “single HQ” location scenario with operators that wish to circumvent the stacked antenna situations you see in mobile network operator towers: either one takes it all, or it is a christmas tree with multiple same band antennas. Looking forward to updates on this on packetbroker.org
From any perspective a SW or network defined solution would be preferable IMHO. For economy, equipment maintenance… even when we dont dare to touch the holy grail of ownership…
With the current backend software multiple gateways is the only viable solution. It also increases the downlink capacity, the two networks won’t be competing for allowed airtime which might become a serious issue when firmware updates over the air are performed.
Mounting multiple antennas might not always be possible but is preferable for the foreseeable future.
And the cost of a lorawan gateway install is small compared to other solutions (like getting a netid from the Lora Alliance, at at least $3000 a year).
Since a few days I have installed a second gateway for TTN V3 in addition to my gateway for TTN V2. They are at the same location, there antennas have an altitude-difference of 2m.
They do not seem to influence each other, although they will. imho If one gateway transmits it will block the receiver of the other gateway. But they transmit rather seldom so that the chance of a signal coming through is high.
Using the same antenna might be a problem - not for receiving you ca use a splitter for this. But for transmitting - the transmitter of one gateway might blow up the receiver of the other gateway.
On the other hand combiner/splitter can have an isolation of more than 20dB - if the impedance-matching is good. The receiver of a gateway might withstand a power of -6dBm. What about using one antenna, a combiner and two gateways?
No risk - no fun!
As promised: the statement from Mikrotik support about the multiple server setting in the LTAP LR8:
Response:
Adding multiple servers may cause issues if an LoRa node is added to multiple applications, for example, one served on TTN and the other on Chirpstack, but, actually, I cannot think of a reason one should do that. On the other hand, if you have nodes that are added only to an application served on TTN and other nodes that are added to an application served on your own Chirpstack server, you can use a single gateway to get everything working.
3 Likes
Hi… Question why can i not start a new topic? I hope to get some advice for a new gateway.
Some tips?
Because you are are new user so it’s a forum spam prevention measure.
What sort of gateway? Are you looking to sort out multiple network server routing for the Mikrotik LR8 which is this topic?
Good morning everyone,
Thank you to everyone who has invested a lot of time in exploring the details of Packet Broker. Since there are a bunch of open questions, I would like to invite you to the conference on Friday. We will have a breakout session on the packet broker at 11 am CET.
Please use the chat function to post questions which will be picked up by the team or Johan directly.
Registration for community members are free:
1 Like
Hi all, great read here. Like Felix says, we’re doing a session on Packet Broker this Friday and the community can attend for free. I’ll be covering your things (no pun intended) mentioned here and in other places in the forum as well. I’ll be doing live Q&A in the chat.
In any case, I wanted to jump in here on a few issues raised here:
I agree with you that conflict resolution is trying alternative routes in real time. The Things Stack and Packet Broker are in fact designed for this on multiple layers.
There is one constraint though: once a downlink message has been scheduled on a gateway, it cannot be unscheduled. There are two reasons for this: 1) we don’t want to roundtrip to the gateway for (un)scheduling downlink because of latency (the gateway backhaul is most often the bottleneck to make RX1) and 2) packet forwarders don’t support unscheduling downlink.
What we do have, however, by design in The Things Stack and Packet Broker is:
- Downlink message prioritization. This is currently only used for allocating duty cycle budget (lorawan-stack/pkg/gatewayserver/scheduling/sub_band.go at bdbf2c2b5243d30cf0f7be6eac5a5c5c1833f9ba · TheThingsNetwork/lorawan-stack · GitHub), so you can prioritize join-accepts over application-layer downlink. This is implemented in Packet Broker API as well (api/v3/enums.proto at e80ed37341424a094c84fd69200b908a8b5ad9d2 · packetbroker/api · GitHub) which will be used to also configure the maximum priority that peering networks can use for scheduling downlink. This is technically not the type of conflict you are referring to, namely overlapping downlinks, but configuring the right prioritization will reduce conflicts.
- When scheduling downlink, The Things Stack Network Server sorts all possible downlink paths from most desired to least desired. This takes into account various things: SNR, to which extent the gateway can or should be used for downlink, and lastly downlink via Packet Broker (https://github.com/TheThingsNetwork/lorawan-stack/blob/v3.13/pkg/networkserver/downlink.go#L636). This is not a fire-and-forget scheduling process: all these paths are tried first-to-last. If downlink cannot be scheduled on any path, the next one is tried immediately. For instance, The Things Stack Gateway Server attempts to schedule downlink in the given order of downlink paths, taking into account existing downlink messages (lorawan-stack/pkg/gatewayserver/grpc_nsgs.go at bdbf2c2b5243d30cf0f7be6eac5a5c5c1833f9ba · TheThingsNetwork/lorawan-stack · GitHub).
- Forwarders connected to Packet Broker report downlink scheduling result back to Packet Broker. This can simply be success, in which case it is assumed that the downlink message gets transmitted, or it can be one of the many errors (api/v3/enums.proto at e80ed37341424a094c84fd69200b908a8b5ad9d2 · packetbroker/api · GitHub), including
COLLISION_PACKET. This is (will be) treated by The Things Stack Network Server as a scheduling failure and it will try again on a different downlink path, which could be another downlink path via Packet Broker.
1 Like
Hello everybody,
Very interesting topic here, thanks for all the answers.
I agree with @alpu, it should be easy for any member to share their private gateways with the TTN community and to be able to have their private stack at the same time. I think having two gateways at the same spot is somehow a wast of hardware/money/power.
As a HAM radio community in Switzerland, we have access to some good located spots on mountains and we are slowly deploying LoRaWAN in our area. We are using our own stack on a local server for our traffic but want to help the TTN community as well. We cannot put multiples gateways on those places as they are all solar powered and we want to limit the power consumption. We are using Mikrotik wAP LR8 kits everywhere (easy to power from 24V) and without knowing this is problematic before reading this post, we are setting the two servers (our and TTNv3) on the gateways.
I understand the point that this is a problem as the two stacks are not aware of each other using the gateways at the same time. But buying a NetID for 3’000$ a year to peer with TTN is clearly out of question for a small community like us. We are not doing that for money, only on a voluntary basis to help the local community. We still want to help the TTN community and the only way we find today is to add the two servers on the gateways.
We do not have many local traffic, but let assume the two servers want to transmit at the same time on the same gateway. One of the two server will not be able to send the downlink and the device will not receive it. But anyway we are loosing traffic on air due to various reasons (weather, interferences…). The stacks and devices are anyway designed to account for packet losses: ADR algorithms will wait for an ack from the device, we have confirmed down/up link if we want to be sure that the information is received and so on. The protocol for the gateways is UDP, this do not guarantee that the information will be received by the gateways as well. I think the stacks and devices are already designed to account for small losses like that and without a better solution we will keep providing coverage for TTN this way. After all, we are all on a best effort basis, this is anyway better than no TTN gateway on this area.
I would be glad to change the way we do help the TTN community if technical solutions exist. Preferably without buying two gateways for each spot and without the 3’000$/year NetID.
Thank you to the TTN team for the great work!
There was a presentation on packet broker by @johan earlier today at The Things Stack Conference that showed how this can be solved. It will become available on YouTube in the (near) future. I’ll post the YouTube link when it’s available.
2 Likes
The link to the YouTube video: https://youtu.be/ugt6L5YRNGk
(I didn’t update my previous post as people wouldn’t get update notifications and miss the link)
Please don’t obsess on this figure - TTI could carve off a chunk of theirs for a very reasonable price if it gave good coverage …