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.
@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).
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?
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?
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.
@hoonppark: The advantage of Class C is reduced downlink latency. An application wishing to operate an actuator attached to a Class A device must wait until the next transmission (several minutes or hours), while the application can immediately schedule a downlink to a Class C device, subject only to downlink queues, duty cycle, and perhaps a criterion of not interrupting an uplink packet in-progress.
In real life, you want to control your Class C devices any time during a day as many times as you want. If you were limited to send a downlink message to your Class C device only 10 times a day at most, it couldn’t be a real life solution. That’s what I meant by saying the statement below:
Regarding the ‘Fair Usage Policy’ being listed as a weakness, I am not so sure. Swisscom just recently published their data plans for the usage of their lorawan network, and I think it’s actually more limiting than TTN’s policy:
Only the biggest data plan has more than 10 downlink/day and only by a small difference (14 downlink/day). On the other hand, the uplink is way more limiting on Swisscom than on TTN, because it is based on number of messages instead of air time efficiency. With Swisscom, the biggest data plan allows for 144 uplink/day, while on TTN, and still respecting the fair usage policy, you max out at around 600 uplink/day (assuming heartbeat / single-sensor payload on SF7). Of course, if you are very sloppy and send large payloads with inefficient spreading factors, the number goes down a lot.
As long as one does not specify an objective for a Swot analysis, anything can be everywhere in the matrix. I am missing that objective in these discussions.
