Hi, I’m wondering about lots of LoRaWAN MAC commands and downlink capacity.
As we know, gateways capable with 8 simultaneous demodulation could not receive packets from end devices while it transfers ACK packets for confirmed message or packets from server conveying MAC Commands.
So, if we just use Class A, I think that a lot of downlink traffics for configuring end nodes with mac commands would be harmful in terms of uplink capacity…
am i right?? if yes, is there any solution for this situation now?
That is exactly why we ask our users to consider the rest of the community before sending their downlink messages. Our network server also does its best to keep MAC commands to a minimum and prefers to piggy-back them on application downlink.
All of this will become less of an issue when gateways are more densely deployed, allowing us to use more efficient data rates and thus lowering the transmission times. More importantly even, there will be other gateways that are still available for receiving uplink messages while the first gateway is busy.
Basically the solution to many issues is to simply deploy more gateways
btw, if the number of gateways is the solution for whole LoRaWAN system, why do ttn have such restriction for downlinks or number of confirmed packets and dutycycle limit (1%)?
if there are so many gateways deployed, that restrictions would be unnecessary?
The duty cycle limit of 1% is imposed by government regulations for the radio spectrum and there’s nothing we can do about it.
The “fair access policy” exists because we want to avoid that a few very active users (commercial applications for example) impact the performance of many other community members. Therefore we set a (soft) limit on the number of uplink/downlink messages a device can send. The impact of sending more than this, will be lower when there are more gateways, but the limit also proved to be a good way to force developers to build more efficient solutions. Finally it is a good indication of what LoRaWAN should be used for. If you really need more data, it’s probably better to investigate alternative technologies like WiFi/Bluetooth for short range and GPRS/3G/LTE for long range communication
Currently the network server is sending a MAC command (12 bytes port 0) as response on almost every uplink message (which don’t ask for ACK) I receive from my nodes on both my gateways.
This wasn’t the case a few days ago (the ratio was about 1 MAC response/20 uplinks), has something changed recently?
You are correct. The duty cycle limit applies to both end devices and gateways. When a gateway is close to its limit, the backend can no longer use it to send downlink messages.
So how can we handle 10,000 nodes per day then, if we have to STOP after hitting this hard limit?
Kerlink says its good for 700,000 per gateway! How is this the case?
Who has calculated the MAX real capacity for these made up rules/guide!
The EU duty cycle is actually averaged over an hour, not over a full day. In the USA there is no such duty cycle.
I never really understood why everyone mentions a number of end devices a network can handle. Gateway manufacturers do it, network operators do it and I’m pretty sure TTN did it too. These numbers are estimates that rely on tens of assumptions, so in my opinion it’s very misleading. If you find any reference to a number on our website or documentation, please let me know, then I’ll make sure it’s removed asap.
The most important assumption in those calculations is that most traffic is uplink-only. Gateways are very good at receiving multiple messages at the same time. They can receive on 8 (or 16) channels and can decode multiple orthogonal spreading factors at the same time. This means that you can easily deploy thousands of end devices that only send uplink messages. Another assumption is that end devices only transmit very infrequently (on average once every 15-30 minutes).
For end devices, the device firmware is responsible for staying under the limit. For gateways, the backend is responsible (although some gateways also implement it in their firmware). If an end device does not comply, there probably won’t be a LoRa policeman knocking at your door, but your end device will also not get the CE certification needed to sell/deploy it commercially. If a network server or operator does not comply, it’s easier for the authorities to take action, so we just have to make sure to keep transmissions under the limit.
I joined your group in Amsterdam, as my local group is still sleeping in Inverness.
Pushed IoT / LoRaWAN / Security from 2015 to 2017.
Gave up as no one is interested in the technology in Inverness.
PS Do you guys know and use U2F from FIDO as a hardware security token?
PHP library available to add to your web sites. Let us make this world a safe one.
Please take a look at this as it is 100% better to use public key cryptography in hardware.
Also 508a from Atmel gives us this for our IoT kit.
Take a look, very nice kit.
We’re going a little off-topic here, so I’ll keep my answer short: Yes, we recently got a bunch of YubiKey 4C’s for the core team and FIDO U2F is on the wishlist (we’re looking at this implementation). On the hardware field we’re also planning to do some research into asymmetric crypto on top of LoRaWAN, but I don’t know the details about that.
I hope this is not too offtopic, but I wonder why uplink messages are required. Admittedly I‘m used to BLE and new to LoRa, so I‘m thinking in terms of „Advertising“.
Is it really not possible to send UDP-like messages from a LoRa „broadcasting“ gateway to many Class C nodes?
Use case behind that: toggle light switches in an industry location without requiring ACK (which is handled differently)
