Curious as well what we could improve at that point.
Hi @hoonppark, I think your analysis is very accurate. It’s very helpful for us to see what we’re doing right and where we should improve.
Some comments / background:
TTN Production Server planned to be released in early 2017: I’m positive that it will be before 2017. We’re almost ready to start public testing with the new version of the backend 
Class A only / no plan for Class B and C: Supporting Class B devices is unfortunately not easy in a network where you don’t own/control the gateways. Additionally, you’d have to synchronize the time of each gateway very precisely. Telecom operators do this with GPS modules, but that doesn’t work for TTN, as most of our gateways are placed inside where they can’t keep an accurate GPS fix. I’m quite sure that we’ll never be able to fully support Class B devices (at least, not in the public community network), so we haven’t spent much time on this. We can (and probably will) support Class C devices. However, keep in mind that this is not really low-power anymore.
Fair Access Policy: There’s not much we can do about this. We just have to limit the airtime of devices in order to keep the frequencies available, this will be the same for any network. Some networks limit the number of messages per day, some limit the airtime per day. If networks don’t limit this in any way, the frequencies will eventually be flooded and nobody will be able to send messages anymore.
Question: Have you checked with telecom operators what their message limits are for different subscriptions?
Documentation: We recently took the old wiki offline, so that already cleans up some old stuff. However, documentation is still distributed over a number of places. Please help yourself and the rest of the community by writing great information on our wiki!
No device management: We’re working on it
I personally thought most of businesses would use either Class A (for lower power consumption) or Class C (for places where power can be supplied like street lights) and avoid Class B. I guessed Class B would be difficult even for telecom operators.
And it is good to know the fact that why TTN wouldn’t be able to support Class B because we (TTN community) need to know our limitation so we don’t oversell ourselves and find a way how we can achieve the business goal using Class A or Class C only.
I think what the community needs to know is a sort of a TTN’s product road map, so the TTN community would expect certain things (like Class C support) at a certain time even if the schedule may get postponed later.
Same thing applies to the device management facility. I wasn’t aware of the TTN Global Team was working on it. I think it would be good to make a “TTN Roadmap (or TTN Product Roadmap)” category on the wiki and publish the timeline of TTN components even if some are tentative (then just state that it is tentative).
No, I haven’t checked with a telecom operators. I thought they didn’t have this type of limitation. There is only one telecom operator to ask in Korea, which is SKT. If there is a way I could find out the limitations of SKT LoRaWAN network, I will share it with the community.
If anyone in the community knows their telecom operators limitation on node air time, please share it with the community.
It will be good to find out even telecom operators may have similar limitations. Then, it becomes a fair game.
It is also good to know there isn’t much to be done about Fair Access Policy. Because the policy is based on the technical reasons, not based on any other reason, which means all LoRaWAN networks are in the same boat. We just needs to publish all LoRaWAN networks including telecom operators networks are enforcing this type of airtime policy, then it is not TTN’s weakness anymore.
When I get all the feedback on my SWOT analysis, I’ll try to post it on the wiki. I just need to find a spot where I can upload it. I just began to learn about TTN and LoRaWAN. So, I won’t have much to contribute to the wiki for right now. But, I’ll try to contribute to the wiki when I know more about TTN down the road.
If you’re just talking about device management, that has been there for two months already - the Dashboard. Gateway management (actually just monitoring, because we don’t control the gateways) is still something we’re working on.
I meant the node (end device) management as well as the gateway management. Do all applications should manage their own devices? Something like a battery level warning, locations of the nodes, etc.
I can not find a gateway management (monitoring) screen on the TTN Dashoard. Where can I see it?
Hi @htdvisser, one of the limitations of TTN (or all LoRaWAN networks?) is the following:
“At most 10 downlink messages per day, including the ACKs for confirmed uplinks.”
Does it mean even Class C devices can receive up to 10 downlink messages at most?
If it is the case, I think Class C devices do not have much advantage over Class A devices. This means the Class A unconfirmed messaging would be the only useful messaging for TTN. Would you comment on this?
And, does this limitation apply to TTN only or to all LoRaWAN networks?
The Dashboard is meant for registering/unregistering devices. Tracking battery levels is the responsibility of the application, but it might be possible to build simple support for this this in TTN’s core systems. We currently don’t have any plans to support this (battery levels) specifically, but we are thinking about some standard message formats that allow the Handler to store some information about the device.
We’re still working on that.
That’s correct. We want to support many devices on the network. However, we see that there currently are not enough gateways to have redundancy (more than 90% of all messages is currently received by only 1 gateway). Therefore, blocking 8 channels on a gateway for the duration of each transmission, can have a big impact on the performance of the overall network. For this reason, we need to restrict the number of downlink messages to a number as low as 10 per day. This technical limitation applies to all LoRaWAN networks, and can be easily solved by increasing the density of gateways in an area. When gateways are more widely deployed (2 or more gateways in range of each node), we might be able to determine whether it’s possible to increase the limit without degrading the connectivity of other devices. There will be big differences between different parts of the network. We will have to come up with some algorithm that calculates the impact of each uplink/downlink considering the capacity of the network and base the uplink/downlink limits on that.
1 Like
Nice work! Regarding the threats: from my experience, telcos see LORA as a temporary IOT solution only until 5g is ready and solves all the problems (at least that’s what they’re promised).
It might differ though on the coverage of the country.
I think it might be different by regions or countries. In Korea, SKT (the largest telco in Korea) has deployed a nationwide IoT network based on LoRaWAN a month ago, in July, 2016, along with LTE-M network. They call it a hybrid IoT network. SKT is now very active to sign up solution partners and they are stating the LoRAWAN network is their IoT network. They also have a plan to adopt NB-IoT next year when it is ready for deployment.
I think SKT is trying to get the advantage of being the first-to-the-market in IoT business in Korea. With their LoRaWAN network server platform, called ThingsPlug, once people deploy a solution using ThingsPlug API for applications, it will be difficult to jump to another platform.
So, in some countries telco could be a threat (or competition) to TTN.
Interesting perspective. That would be an opportunity than.
Does it mean the algorithm that limits 10 downlinks per day per device is programmed in the gateway?
@htdvisser: that’s very interesting! I wasn’t aware of the fact that the limitation could be resolved at all. Perhaps at some point, it would make sense to allow this particular limit to be tweaked per region.
@hoonppark: The algorithm that limits the downlinks is programmed in the backend.
@gonzalocasas: Next to the fact that we can send downlinks without reducing capacity too much, more dense deployments of gateways also means we can send at higher data rates. So shorter range and less airtime, both leading to less interference (and better for the duty-cycle).
1 Like
Do you mean the Network Controller?
According to this LoRaWAN 101 document,
LoRaWAN spec defines LoRaWAN™ defines ten channels, eight of which are multi data rate from 250bps to 5.5 kbps, a single high data rate LoRa® channel at 11kbps, and a single FSK channel at 50kbps for Europe.
Is it why you say there are 8 channels on a gateway, because the TTN backend server is currently located in Europe?
And, the same document states the ISM band for North America is from 902-928MHz. LoRaWAN™ defines 64, 125kHz uplink channels from 902.3 to 914.9MHz in 200kHz increments. There are an additional eight 500KHz uplink channels in 1.6MHz increments from 903MHz to 914.9MHz. The eight downlink channels are 500kHz wide starting from 923.3MHz to 927.5MHz for North America.
Does it mean there could be a lot more channels if you placed a regional TTN backend server in the US?
Well, for a mere USD 1.6k/piece, we could add atomic clocks to all TTN gateways: https://www.arrow.com/en/products/090-00218-006/microsemi 
Obviously, the price tag makes it impracticable right now, but there are some companies (that I heard of: jackson labs and a shady Israeli company called d4-ac) claiming they will have chip-scale atomic clocks an order of magnitude cheaper.
Our infrastructure is a bit different from the original idea of LoRaWAN, which was aimed at telecom operators. To avoid confusion, I try to avoid using the term “Network Controller”. With “backend” we mean some “TTN Server”.
The US frequency band is divided into 8 sub-bands, so in the US we also have 8 channels; TTN uses sub-band 2 (903.9 - 905.3 MHz).
I think the statement above applies to TTN only, not to LoRa in general. Because the LoRaWAN spec 1.0 defines a lot more channels - even dedicated uplink and downlink channels - for the US region. Am I right?
Is there a reason TTN uses only 8 channels combined for uplinks and downlinks?
The hardware used in most (all?) gateways supports just 8 channels.
Hi,
Although the amount of spectrum is limited there are regulators contemplating adding additional sub 1 GHz spectrum for low power devices / IoT / M2M.
This means that in the future there might be more spectrum available for LoRa; This does not necessarily mean that the duty cycle restrictions will be much better, but it does mean congestion can partly be solved by using this additional spectrum if/when it becomes available.
( of course for this to be useful the spectrum does have to be assigned under the right conditions).
I guess there are no more inputs on the SWOT analysis on TTN. I’ve consolidated inputs as much as I could. There are a couple of inputs I could not consolidate.
Attached is the latest PDF version of the SWOT analysis as of Aug. 23, 2016. And you can also see it here without bullets for the bullet items.