There is a perfectly good scheme for people to share their private gateways with the TTN community that was developed (ie funded) and setup by TTI. So no one is saying do not share. If gateway manufacturers have misguidedly put some extra facilities that trashes the LoRaWAN spec, that’s down to them.
1 Like
@descartes @kersing I need to think more on this when not just dipping in an out of Forum and distracted by day jobs but whilst PB potentially solves the problem of traffic routing and sharing between multiple network, or simpy bridging between networks as in V2 to V3 TTN traffic, I dont think it helps solves the problem where NS1, NS2, …NSn, TTNNS(V2 or V3), TTINS are all working through PB and using a given GW - there is no way for NS2(say) to know that NS4 is scheduling a downlink at the same time through the same GW and there is still a risk of collision, nor any way to know what NS2’s view of used duty cycle at that specific GW vs NS4’s view, right? (I need to look deeper as I say).
Nope, just a few allow it. Most gateways run software from Semtech (UDP packet forwarder of BasicStation) which doesn’t allow multiple backends.
I am sharing >15 private gateways with the TTN community. As in I privately paid for those gateways and connected them to TTN to allow anyone (within TTN) to use them.
I do not see the need to run a private LoRaWAN backend as my use cases all fall within the TTN fair access policy and sharing the gateways with the community is important to me.
Looking at the logs of my gateways I notice local (NetID 00) deployments that couldn’t use TTN and are even breaching legal limits. If there are too many of those LoRaWAN will become unusable (we share the same radio spectrum after all) so everyone looses.
From what I understood PB should facilitate this. But it might be better to ask the appropriate authority on the subject. @johan, can you comment?
1 Like
So we have
- one church tower,
- one gw/antenna allowed by the building owner.
- and both a private and TTN community competitor for the location.
The Private Operator is open to forward whatever traffic as long as it does not hinder them, or cost them extra money or difficult arrangements or configuration.
The TTN community is open to forward whatever traffic as long as the GW is open for TTN.
A “how to” on what is the preferred way of handling this type of situation would be welcome.
The worst outcome would be both parties negotiating with the church owner, leading to 2 gateways: one TTN and one Private.
Further: apart from all the previously mentioned issues, am I right that it makes no real difference where multiple-server-packet-forwarding takes place, either on the gateway or by a dedicated multiplexer? ( eg by How does the ChirpStack Packet Multiplexer work? - Gateways - ChirpStack Community Forum )
Ill try to reach out to MikroTik to ask them what the use case is for this setting.
2 Likes
I have to be heavily medicated before people can cope with my advanced negotiation skills so I’m entirely sure I’m the right person to ask. Or is it they have to be medicated. Can’t remember.
This isn’t really a technical problem, more about what the community would like or benefit from coupled with appealing to the private operators sense of Corporate Social Responsibility & any associated PR benefits for them.
If the private operator can meet the non-trivial requirements to link to the Packet Broker service, I’d ask them to do that, promise to put their name as a Platinum sponsor on the community website and put the gateway & antenna you have somewhere else.
Good suggestion to improve your negotiation skills !
From what I understand, after re watching the 2020 TTN conference video on YouTube Link about packet broker is that you need to have an assigned NetID which is only available as a member of the LoraWAN alliance. This costs ~US$3,000 per annum.
This is out of reach of most people who want to have the ability to operate a private gateway (or cluster of) to achieve a private LoRaWAn capability but provide the community at large the benefit of the gateway participating with TTN and passing (up and down link) traffic to users within the coverage of their gateway (or cluster of).
Please correct me if I am wrong.
Perhaps packetbroker needs to consider some sort of networking RFC1918 (192.168.x.x 172.16.x.x 10.x.x.x) equivalent for the NetID [edit… am aware of " NetID 00"] where localised use for the private is possible as a mask and the catch-all traffic is sent on.
Anyone doing this seriously is likely to be operating in a commercial context, so the additional costs shouldn’t be much in the grand scheme of things. You can rent a small block of IDs from TTI that will cost less than membership.
The alternative is to run the private network using a TTI instance that can then automagically peer.
It’s not clear what your project is about or indeed how many gateways make a cluster - why do you need a private network?
That is mistaken
While packet broker should have been designed to solve this problem, specific questions here in the past reveal that at present it actually doesn’t do anything to address it at all.
How so?
Why would TTI have put so much effort in to creating it if it wasn’t going to allow networks to peer?
Who knows.
Just like feeding multiple network servers directly, it makes it look like peering works, but actually the networks denial of service attack each other because theres no logic to let the loser of a conflict try a different gateway.
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?