I was seeing if someone would be able to explain why a user of LoRaWAN would want to use The Things Network over an alternative product or not one at all.
I have heard of solutions out there including LoRaServer which use LoRaWAN. What I don’t understand is that this seems to provide similar functionality as TTN, but if TTN is free to use, is the only purpose of this for larger scale or independent/private projects?
In other words, can you use LoRaWAN without TTN (which I’m 99.9% I know is yes) and if so, what do you miss out on?
Also seeings TTN uses the LoRaWAN network for its main functionality, is TTN a network above the transmission system of LoRaWAN?
This post is not about looking away from using TTN, it is rather about understanding the difference between the LoRaWAN network and TTN because in general conversation the two can sometimes referred to as one and the same.
TTN provides a network server; which is doing the complicated part in creating a lorawan network (handling duplicate packets from multiple gateways, shunting data to servers, handling joins, etc.). LoRaServer, Kerlink’s, gotthardp/lorawan-server and many more are all network servers.
One of the benefits of LoRaWAN when compared with things like NB-IOT and Sigfox is that you can be the network operator; therefore un-encumbered by restrictions imposed by specific network operators. So if you want to create your own SLA’s, not have to follow TTN’s fair use policy, etc. then you can freely create your own network and set your own rules (as long as you follow your countries rules concerning transmission rate, etc.).
However being a network operator can be quite an untrival matter - you need to be concerned about servers, network availabilty, intergrations, etc. The advantage of TTN is someone else does much of the complicated bit for you - you send packets and they generally pop out at your endpoint. You also get to utilise the coverage provided by TTN, thanks to gateways that others have joined to it.
The choice of what network server you ulimately use is up to you and should come down to what your project requires. Would I use TTN in a commericial situation that requires high levels of availability – probably not, as I can’t garantee that someone won’t unplug a gateway to do the hoovering (potentially dropping connectivity for a single/bunch of nodes). Does TTN work for most cases that I need and saves me a lot of hassle - yes.
To me, a single large shared network such as The Things Network is to be preferred over many private networks, as that allows that single network to take full advantage of ADR.
With ADR, nodes may be instructed to lower their transmission power when the network knows they are close to some gateway. Keeping gateways private implies that other nodes need to increase their transmission power to reach gateways that will forward their data. And the higher transmission power will increase the chance of collisions.
TTN is a lot of things, so everyone here will have different reasons for using it or being a part of it.
TTN develops an implementation of a LoRaWAN network server. There are other (free, open source) implementations, as @azazeal wrote, and each has a specific goal (run on the gateway, private networks, development, …). Our v2 implementation works really well for world-scale distributed networks like TTN, and our upcoming v3 stack will allow you to start with a tiny development network (on your RPi gateway) and grow into a highly available, distributed, worldwide enterprise network. Using TTN’s network server means that a network can grow to TTN scale. We’ve already proven that it works and we have companies providing enterprise networks with support and SLAs. Of course the beauty of LoRaWAN is that it’s open, so you are free to choose a different network server if that works better for you.
TTN provides a worldwide LoRaWAN network. This network allows anyone to connect their gateways, register devices and send/receive data for free. The servers are hosted by sponsors such as The Things Industries, Meshed, Switch and DigitalCatapult. You also can set up your own, private LoRaWAN network, or use one provided by your national telecom operator. I think the biggest advantage of TTN is that you can use existing coverage without any investment, and add coverage when you need more.
TTN is 50 000+ developers gathered in 600+ communities in 100+ countries. Those communities bring people together: developers, businesses, governments work together on building cool things and on solving (local) problems.
TTN is probably the best source of LoRaWAN knowledge out there. With the shared knowledge of our “Learn” section, our “Labs” stories and this forum we are on Google’s first page for any LoRaWAN question you may have. If there’s no answer, you can ask the community here on the forum, or on Slack.
I would actually be very interested to hear the reasons people may have for not using TTN…
Off the top of my head there are a few reasons why:
The fair use policy. They could believe it is too restrictive and too limited for their use case scenario, therefore they want to use LoRaWAN with the only limitation being the local duty-cycle restrictions.
In some situations a company may not want to share their gateways due to a believed “clogging” of their own network which they invested their resources and energy into deploying. This may also be down to a misunderstand as the theoretical maximum number of nodes a gateway can support which I’ve heard maxes out at about 100 000.
“Why should we share our network with others if all they are going to be doing is utilising our resources?” This is an interesting case particularly in less developed LoRaWAN areas such as Australia because IMO, most businesses would likely believe that we do not currently have enough gateways nationally for them to feel they are getting a fair deal by deploying their own gateways on TTN and also having the opportunity to use others as well.
Privacy. I am not talking about security, rather the idea of someone not exposing their network and their infrastructure publicly on the internet as some sort of way to protect their own business and its practices.
They want full control of their LoRaWAN network. They may not want a middleman as a way to improve efficiency, increase personal privacy and security and to reduce the opportunity for their network breaking in the case that TTN gets shut down (not that I’m hoping for it to).
I think some points have been made pretty clear here. But I am also a little confused about a few points.
Either Lachlan’s solution by using LoRaServer or the solution provided by TTN mentions a Server here. Is a server here for management or for clouding?
I am pretty new to LoRa and we are searching for a long range low rate solution for our sensor network in the polar. Today I contacted a local company and they told me they have their own solution with a similar function to TTN. Hence our data from sensors have to be sent to their server for decryption and then sent to our own cloud server. He also said that this is unavoidable.
I didn’t quite understand what he meant by ‘unavoidable’. We did set up a sensor network based on WiFi-LTE gateway before and our data was routed to our cloud server with FTP directly. But why do we need to use the service provided by TTN or the local company? Can’t the sensor data be sent directly to our own cloud server with a LoRa-LTE gateway, without any intermediate server? Which part in the WiFi-based sensor network resembles the funciton of TTN/local company in LoRa-based sensor network?
Thanks guys in advance for your time and attention.
When we refer to a server, this is primarily around management and setup, not so much around cloud storage. TTN simplifies the setup and management of nodes and gateways on the network, whilst also opening up the opportunity of you being able to use the communities gateways and the community being able to use yours. TTN stores an unlimited amount data for a period of 7 days which can be extracted using the API available.
When that company you contacted said the network server was unavoidable, they were half correct. Yes, a network server must be used for LoRaWAN if you want to be able to easily setup and manage your nodes and gateways, however you do not have to use a solution developed by them or even TTN for that matter, you could develop you own (if you had the hardware, man-power and ability).
The difference between LoRaWAN network servers are the features they provide. TTN is centred around community, whereas the solution this company offers likely is an enterprise option with direct support. If you go onto building your own, you won’t have these features, but you will have full control on everything you do.
What I think you should consider are the benefits and disadvantage of that company’s solution, TTN and developing your own. Also check to make sure that the company you contacted does not restrict you to their ecosystem of hardware.
Please note that even though TTN is a free solution, it does have a fair use policy, which may be more restrictive than paid options to allow the community network to operate suitably.
Finally, on The Things Network’s public community network, we have a Fair Access Policy that limits the uplink airtime to 30 seconds per day (24 hours) per node and the downlink messages to 10 messages per day (24 hours) per node . If you use a private network, these limits do not apply, but you still have to be compliant with the governmental and LoRaWAN limits.
Hope this helps. If you wish to discuss this more, be sure to contact me.
I’m wondering, is this management server is necessary, when we have a really tiny network.
In our current WiFi-based sensor network, we’ve got three sensor-datalogger pairs dispersed in a small range, each of which is connected to a WiFi-LTE Modelm via a radiohead. We use the FTP function in the datalogger to upload the data to the cloud server.
I am wondering whether LoRa employs a similar network protocol to collect the data, or it is shielded by LoRa protocols thus we don’t really care about how data is collected.
I also think that it is simpler to manage and collect the sensor data with a centralized software system instead of programming every sensor/datalogger for FTP-based data collection. Just now sure whether these IP-based protocols are supported or not.
By the way. I seldom see LoRa-based IoT network devices mentioning datalogging function here (I guess because data is regarded as real-time uploaded, but we really care about the system power consumption so we need to schedule a less frequent upload with some data accumulation). Are there a few alliance verified dataloggers to choose from?
If you have only 3 dataloggers in some always fixed position, of course you do not need much of the infrastructure of LoRaWAN. You might simply develop your own layer over LoRa to collect data. But if you accumulate a lot of data, LoRaWAN is not for you because is made for transferring limited amounts of data (although by collecting them, let’s say, up to 50 bytes at a time instead of sending 2 bytes 25 times, you save a lot of overhead).
Regarding power consumption, again if your single packet of data is compatible with loRaWAN sizes, LoRa should be way below your current solution.
(By the way, FTP seems a very rough approach to data transfer in this century…)
It’s not that much. Tens of kilobytes per day for each of them, so I think LoRa is enough in the bandwidth.
Haha I know FTP is really old school but geoscientists are really too stubborn to trust new technologies. They rely on yearly travels to the Polar for data collection… I went into the project and saw few options offered by the dataloggers and FTP was the easiest one.
And have you got suggestions for the datalogger? Thanks in advance.
We used CR1000 in the past but we are seeking to reduce the cost… CR1000 is pretty limited in the RAM (2MB) with a high cost (~3000USD). It is robust in Arctic and fully-functional, but maybe a little overqualified for us.
Mmm… on TTN, fair access policy is such that is almost impossible to send more than 18KB/day (in the best conditions). LoRaWAN alone, with EU duty cycle limits, let you more room. However, if for distance or conditions you need SF12, no way.
and what about ‘artic proof’ solar powered LoRaWAN gateways and nodes/sensors , how do you connect them … by satellite ? that’s a custom build imho and not so cheap at all.
anyway… we’re going way off topic here.
