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.
Sorry I just saw this…
Though you have ‘no ISM bands for Asia’
the same is true (I think) for South America…
We have significant business in Guatemala and there is no standard there…
You might want to add to the Weakness Block… thank you
Hi @skramer, I’ve added ‘no ISM band for Guatemala’ to the ‘THREAT’.
Attached is the updated SWOT Analysis.
The Things Network SWOT Analysis-2016.08.23-2.pdf (1.7 MB)
You can also see it online here.
Very Kind … Thank you!