I’m concerned about the gateways to be down if there are many nodes communicating with it regardless if it’s a paid service or not.
And talking about not installing gateways, in my case it means installing gateways all over the country to get coverage which doesn’t make sense for my application
I’ve deployed a number of gateways (with the help of volunteers providing locations and (sometimes) internet). I’ve also invested many (as in hundreds of) hours in TTN by answering questions, moderat8ng the forum, running workshops for the local community and writing a packet forwarder and one thing I can assure you, you won’t be making any money from those activities while others will.
The TTN manifest allows commercial use of the network (whether it is wise or not without SLAs is a different matter) so once you deploy gateways anyone can use them and that might mean someone is making money based on your investment. Accept it from the start or don’t deploy gateways. You’re not allowed to filter traffic because you don’t want commercial users to use them.
Not to the community network, that would be unwise. (I think we both agree)
With the packet broker we might start seeing traffic from commercial (TTI) deployments injected into the community network.
Unwise, yes, but an obvious cost saving to be made so likely to be happening - at the least by people who don’t know better.
I’m fully aware and I realise I have to live with such things - as volunteer ambulance crew, I’m well used to doing all the work and not being appreciated!
Gateways can handle a lot of traffic and won’t go down due to traffic, they go down because someone switches them off outside office hours. Or because someone decides to stop running a gateway. And another gateway might receive the transmission and forward it to TTN.
In that case TTN won’t work for you, not one country where TTN is has it complete coverage. So go looking for a commercial LoRaWAN provider.
Put a small node close to each gateway that transmits a small payload once every couple of minutes, then you get 2.5 minutes heads up that a gateway is down.
So what about that?
Well looking at the map of germany there’s good coverage (or at least enough)
Actually i find the concept really nice but we already realized the drawbacks if i’m commercially using the gateways i will be deploying my own gateways later because it should still work as a community and not only profit based. That’s the only way will make the technology going on
What about what? You wanted a way to know if a gateway was down …
Actually I don’t think it would be unwise. I think it’s really the only way a community network actually works. Look at say, Linux - the time when it was just hobbyists is long past, sure, there are some hobbyists in key roles but most of the developers draw a paycheck from companies who benefit from the result. Something like TTN would work if the situation with gateways were similar, most maintained by the budgets of funded needs.
That’s a start… but TTI is a small part of the commercial LoRaWAN space.
For Linux that works because me running it on my systems does not depend on a central server being on-line. For the community network we all depend on the back-end being available and when it isn’t we’re unable to fix it and need to wait for TTI to do so.
That could be solved by starting our own ‘community’ network, however just like Linux in the early days that would fragment things. In the Linux world fragmentation didn’t help progress, only when the number of distributions was radically reduced and key players were earning sufficient money to invest in staff significant improvements appeared.
Fragmenting the community network would reduce coverage which could well result in things collapsing in stead of improving the situation.
BTW Linux being developed by hobbyists was 25 years ago… and even then commercial companies started cashing in on the work of those hobbyists.
Exactly - you can’t talk the folks writing the check into buying something they can’t tune and manage to their satisfaction.
This is why I think the only way for TTN to be able to benefit from the “excess capacity” of gateway deployments funded by those with a commercial need for their data to get through, is to have a situation where their data normally goes from their nodes through their gateways to their servers, without touching public infrastructure at all. Only traffic that isn’t theirs (or traffic from their nodes when it comes in through a gateway that isn’t theirs) would touch public infrastructure.
And by “their servers” I mean servers of their choice and tuned to their needs, not contracted TTI instances.
So we are looking for a system where those that have funded gateways talk to their own servers and if they chose to allow community access, the gateways understand how to talk to the community network server. As this is only their server plus TTN, this seems doable.
The incentive here would be that in return for doing that, their devices can also use the community systems, where by the gateways know to connect to something to know how to route stuff - or the TTN backed does - at which point this gets complicated. Unless the device carries two sets of credentials and can switch to community access if it is out of range of the commercial coverage, which seems doable just in user space code. Would be helped with geofencing as well.
The alternative is to provide a traceable system for deployed gateways and provide greater message counts, bandwidth or priority to those that have contributed to coverage - at which point this gets complicated, qf Helium Mining etc
I can imagine quite some commercial applications where a blackout of several hours or even a day is not that important, but the added coverage from the community is. Even if that community coverage is only used seldom.
If someone needs better, they also need to get at least 2 seperate gateways that have a seperate internet connection. Not to forget the needed server infrastructure and supervision.
Hi @descartes,
I’m a TTN gateway operator and a commercial customer of the TTI cloud-hosted v3 service. I think that you have talked yourself into something very close to what TTI have been working for 2 years to deliver with v3 and the Packet Broker.
As a TTI customer, I have had the privilege of privately meeting both Mr. Giezeman and Mr. Stockking and discussing these matters with them. I wanted to make sure that the commercial approach being taken by the people that I work for was not contrary to TTI/TTN principles. I believe that the WG/JS view of the future architecture is for many commercial and community v3 systems inter-connected [or not] via Packet Broker. People who need SLAs and TTI’s engineering and operations support will pay and will be commercial customers. People who want to do all the work themselves or self-organise into non-commercial communities will be free to do so via the v3 software being open-source.
But they need a valid Lora Alliance assigned address block which requires membership which sets you back at least $3K a year if they want to join packet broker.
Indeed, if at all possible we tend to install a gateway backhauled on each of two mobile network providers.
The key question here would be if the packet broker ends up usable by something that is not the TTN v3 stack - not just not the off the shelf version, but an entirely distinct codebase.
If there’s an extractable interchange standard that’s flexible enough to interwork with a variety of commercial needs, this may work. But if it’s only going to work for local builds of essentially the same software, that’s limiting.
Hi @kersing, you are correct.
Many forum members may be unaware that public/routable LoRaWAN dev_addr addresses cost real money that has to be paid to the LoRa Alliance and that TTI currently pays the high cost of this for the TTN network. This should be taken up with the LoRa Alliance.
Any organisation - commercial or community - that does not need to roam or use packet broker does not need to pay.
Hi @cslorabox,
The packet broker API specifications and code are all on github at https://github.com/packetbroker
Very nice, but I’m quite sure that a lot of applications don’t “need” that.
I’m suffering a failure of imagination regarding how this community and business thing works.
If sessions are between back-end servers and nodes, and gateways will pick up any packet at least for analysis to see if it needs to pass it on to the server, isn’t a DDoS trivial? Even the fair use policy could only be implemented by the servers and I assume gateways can’t selectively listen for nodes because they don’t know who’s talking until they’ve received and examined the message.
It sounds like a risk setting up a network of commercial gateways that can easily be flooded even if they’re not forwarding the uplinks to a server. I assume LoRaWAN is pretty rare still so this isn’t an immediate problem but I can’t wrap my head around how it’s supposed to work in future.
And what is the impact of people breaking the rules using these RF bands? Do other technologies suffer?