SWOT Analysis on TTN

[wienkegiezeman]

Interesting perspective. That would be an opportunity than.

[hoonppark (Hoon Park)]

@htdvisser

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.

Does it mean the algorithm that limits 10 downlinks per day per device is programmed in the gateway?

[gonzalo (Gonzalo Casas)]

@htdvisser

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

@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.

[htdvisser (Hylke Visser)]

@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).

[hoonppark (Hoon Park)]

@htdvisser

The algorithm that limits the downlinks is programmed in the backend.

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?

[gonzalo (Gonzalo Casas)]

@htdvisser

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.

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.

[htdvisser (Hylke Visser)]

@hoonppark

Do you mean the Network Controller?

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”.

@hoonppark

Does it mean there could be a lot more channels if you placed a regional TTN backend server in the US?

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).

[hoonppark (Hoon Park)]

@htdvisser

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?

[kersing (Jac Kersing)]

@hoonppark

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.

[_alex_]

Hi,

@htdvisser

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.

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).

[hoonppark (Hoon Park)]

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.

The Things Network SWOT Analysis-2016.08.23.pdf (1.7 MB)

[skramer]

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

[hoonppark (Hoon Park)]

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.

[skramer]

Very Kind … Thank you!

[chrismerck]

@hoonppark

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?

@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.

[hoonppark (Hoon Park)]

@chrismerck

the application can immediately schedule a downlink to a Class C device

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:

@hoonppark

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.

[gonzalo (Gonzalo Casas)]

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:

(Source)

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.

[pz1]

@gonzalocasas

Regarding the ‘Fair Usage Policy’ being listed as a weakness, I am not so sure

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.

See Wikipedia re SWOT

[chrismerck]

@hoonppark: Do you have a specific application in mind?

Sadly, downlink-intensive applications will need another solution. Unless we eventually support multicast :).

[hoonppark (Hoon Park)]

@chrismerck

Do you have a specific application in mind?

No, I do not have a specific application in mind. I’m talking about the limitation on the number downlinks per day, so people are aware of the limitation.