Using community gateways for a commercial product

It not really a question of relaibilty, but one of who is accountable when it does not work.

If your selling a commercial service, you should not rely on volunteers and free to use community services as part of the business plan.

1 Like

That’s tough, because part of the way something like TTN possibly really works is that commercial users who need coverage build it out - and then hopefully share it in return for getting some chance of coverage in places where they haven’t built something out.

What’s not sufficiently developed are the mechanisms where people with such a need can manage all of the critical pieces to the satisfaction of their requirement, while also sharing the installation with the community.

Possibly there’s some progress with TTI-contracted private installs gaining ability to interchange with the public network. In the general case though, people who have a funded need end up building entirely private networks and interchange with TTN happens at the level of sharing only knowledge, not signals or packets or coverage.

1 Like

No, the community would not necessarily have access to your gateways, only if you choose to do so. And it’s not about reliability, it’s about accountability.

The most obvious company that provides servers for commercial use is The Things Industry. They will host & support you with the servers. But as I said above, YOU provide the gateways.

Absolutely, and I guess this is where the madness that is Helium in the US comes in - by requiring some input to get access - shame it’s a technical ball of tangled knitting.

The original post was rather a red rag to a bull - launch a commercial product on TTN without even having a single gateway of their own and questioning why servers cost money if LoRa is ‘free’. The push back was quite gentle.

Do we have any good practise examples of companies building out coverage?

I’m looking to providing decent coverage of my new home town, assuming I can find safe sites in appropriate locations with reasonably internet access. How this will play out if someone jumps on their use commercially will remain to be seen. I’m already aware of a device in my immediate area that is stuck in a join loop and I haven’t even put up a decent antenna on a mast yet.

Plenty of companies are building out coverage.

But it’s all private networks, because there’s no real practical way to be both sufficiently self-reliant and public.

And no, they’re not necessarily talking about their deployments.

What I don’t have personal knowledge of examples of are gateways funded by a commercial need, which actually connect to TTN servers.

If you define access as in the communities LoRaWAN packets will be forwarded by the gateway, yes that is right. If you are concerned about the community managing/disabling your gateway(s), no that is solely your privilege (and responsibility).

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.

1 Like

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.

1 Like

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.

1 Like

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.