If I wanted to have my end device have more than 30 seconds uplink time on air, per day, and more than 10 downlink message per day, including the ACKs for confirmed uplinks, how can I achieve it?
Can my end device upload the sensor data every 5 seconds to my private TTN backend server without being constrained by the Fair Access Policy if I build a private TTN network?
A private network does not have to comply with the TTN fair access policy, however it will still be subject to the regulations for the ISM band you are using. Also for 868Mhz based private implementations you will share at least 3 frequencies with all other LoRaWAN users in the area so your 5 second updates will reduce the amount of other nodes that can be deployed for all providers. If multiple (private) networks in an area ‘abuse’ the shared frequencies in this manner no-one will be able to use any network with any reliability.
LoRaWAN is suited for infrequent small data packets, not frequent packets or large packets.
At first, when you run your own (disconnected) network without Fair Use Policy, this would not be TTN but your own abomination
What will actually prevent you from doing as you describe is duty cycle regulations which apply as soon as you use the public shared medium.
So even if you can trick some hardware in ignoring duty cycle limits, your installation would be illegal.
Every 5 seconds sounds not possible to me. You can get closer to this by using less airtime, i.e. by using lower SF and higher signaling rates.
Confirmed uplinks are especially tricky since the gateway is subject to the same duty cycle constraints.
If you need to do something every 5 seconds your power consumption will be significant -
perhaps LPWAN is not the solution for your problem.
Exactly. LoRa is probably not what you need. Implementing your own backend (or forking TTN) might remove the limitations for you, but will only increase data loss for everyone who uses the frequencies (because physics).
There might be a solution, which is the fact that LoRaWAN can also use FSK modulation. This will have a significantly shorter range, and we will probably not limit the airtime for this modulation.
The fact above would mean any LoRa network including TTN is vulnerable to a sort of DoS (Denial of Service) attack. If someone just turns on a node that transmits data every 5 seconds by mistake, all gateways (gateways of different network operators) in the area that receive the packet from the abusing node are all jammed and can not reliably function. If this is true, the LoRaWAN Alliance would need to address this issue.
And what should be the maximum data transmit frequency per node for TTN (or for nay LoRa network for that matter), assuming all nodes within the same area transmits 25 bytes of payload with the same SF (Spreading Factor).
For people who plan to provide a location tracking service, how often can they update the location of a package using TTN or any LoRa network?
This is why this is buried deeply in the chip’s firmware or driver which (should) enforce duty cycle limitations.
It hard to do this “by mistake”. I would assume intend.
But yes, “the air” can get congested. No LPWAN can guarantee you congestion-free transmissions. Not even in licensed bands. It’s a shared medium. So whatever you pick, plan for limited availability of your coms.
I can not see what they can really do to prevent such use outside regulation.
Of course we can go for “firmware lockdown & DRM” as this might currently happen with wifi. Goodbye to home grown devices and affordable grassroots hardware. That would be a disaster. And remember: All DRM will eventually be broken anyway.
But do not despair: As this applies to all radio transmissions, what usually happens:
Someone complains to the regulator.
The regulator locates the offending device (ever seen a van with lots of antennas on top cruising around?)
The regulator writes the owner of the device a potentially big ticket.
Problem solved.
I won’t expect any large scale (business deployments) that rely on such an abuse because at scale this will be spotted and you will be out of business in second.
A single misbehaving node may not be that bad though, it only can be at one channel at a time and this is also a scenario where “lots of gateway” really helps (at least this is what i think)
I think you are looking for some sort of guarantee or even “service level”
that “it will work”. There is none. LoRaWAN is in a shared ISM band and transmission is best effort.
depending on a lot of things but with every 10 minutes you can be within fair use if your are efficient. Perhaps you can squeeze out a few minutes but that order-of-magnitude. What are you tracking that needs this update rate?
Thanks for the detail explanation on radio communiation, @kgbvax
I believe TTN enforces the duty cycle at the Network Controller (NC) level, not in the node’s (end device) chip firmware level. Correct me if I’m wrong.
The purpose of my question was to understand a sort of a maximum data transmit frequency in general. I watched Semtech’s ‘Introduction to LoRa’ training video on http://www.semtech.com/wireless-rf/internet-of-things/getting_started.php (There is a ‘Introduction to LoRa’ training on this page), and the presenter was talking about a parcel tracking using the LoRa technology (at 17min. 03 sec into the video). So, I tried to understand how real time it can be in parcel tracking using the LoRa technology.
It’s both.
The duty cycle limitations as per regulation is observed by the end-device.
TTN’s fair-use-policy - if enforced - at in the network controller.
While one could avoid TTN’s Fair Access Policy when simply not using TTN’s community network, one should surely come up with one’s own limitations then.
If one hammers a, say, 1% maximum duty cycle all day long, then if one’s devices somehow never transmit simultaneously and if no one else would be using the same radio spectrum, then a gateway could handle 100 devices per frequency/SF. But:
Of course, nodes will transmit simultaneously (including partially overlapping transmissions, where one device is still transmitting when another one starts).
Of course, devices from other networks will share the same radio spectrum (including networks using other LoRa technologies).
I feel the Fair Access Policy has a simple but sound mathematical basis:
The above does not take the density of the network (the number of gateways in an area) into account. But every network, including private networks, needs something like the above.
Any use case that needs more should look into using different technologies, or set up a very dense network where nodes use a very low transmission power, hence the number of nodes per gateway is decreased. Such dense network could (should!) still be connected to TTN, as the radio spectrum is shared anyway, and connecting it to TTN allows ADR-enabled TTN devices to lower their transmission power as well, decreasing the chances for collisions with the devices from the owner of the gateways.
