Limitations: data rate, packet size, 30 seconds uplink and 10 messages downlink per day Fair Access Policy

(Aditya Palagummi) #75

Hi Everyone,
Great to be a part of this wonderful group and people and iam getting to see many things in this group with like minded around. I am a Project Manager working for an LoRa based solution deployment for one of my projects.
I have some queries and hereby requesting for your valuable suggestions.

We are setting up lora network in India with Frequency band and following are facts below:

  1. The setup is arranged such that base station/gateway would support 5000 devices over a 9km range.
    (Here we are planning for one base station fixed with clear LoS. I assume that LoS is crucial aspect for considering number of base station for 5000 end devices. Please suggest?)

  2. Nodes are class A devices with 12 uplink messages/device/day (10 bytes per uplink msg) and 1 download message/device/day.
    (Here i have a couple of doubts,

  • if my consideration of 1 Downlink msg/device/day is valid, then also I hear that for class A for every uplink message there is a downlink ACKs required. So is my consideration for downlink messages number right for my 13 uplink msgs/device/day? Please suggest.
  • Is TTN fair access policy limits and duty cycle dependent of region/frequency band?)
  1. I understand that in LoRa there is no such solution for FOTA for all devices at once.
    (Here i have a doubt if individual firmware upgrading is viable for these 5000 number of devices or any such alternate approaches proven. Also if anyone in their previous experiences have performed FOTA under their LoRa setup, then for what all aspects is firmware upgrading done?)

Looking for your suggestions.

Thank you.


I suggest you have a look at the LoRaWAN specifications

(Aditya Palagummi) #77

Thank you for sharing.
I have gone through it, even though looking for more specific especially on my Point 2 query as mentioned
in above comment.

(Mjunior) #78

You should check this information better… ACK isn’t required in any sutuation. Specially for this huge number (5k/gw) you should consider no ACK at all, in order to have a chance of getting this network working.
What the docs said is for class A devices, after every uplink there is a receiving window opening, so if there is an ACK or any downlink messages to be sent, it must be sent during that window.

Sure, LoS is crucial aspect but not the only one. LoS can guarantee a large coverage distance, and also enables you to use better data rate. You can communicate with 5000 devices on a single gateway having LoS but, without any orchestration, it would probalby occur A LOT of collision and consequently packet loss. I don’t have enought background to support my oppinion, by I believe that you won’t be able to send 12 messages/device/day. Sounds way too much data…

(Bantob) #79

how do you think to solve point 3? i am interested. thanks.

(Aditya Palagummi) #80

Interesting. Thanks alot @mjunior for your suggestion.

Issues with Things Uno OTAA Connection
(Aditya Palagummi) #82

As of now, no firm understanding on that though.
Need more research on finalising an approach i guess

(Bantob) #83

Hi, does that means that in Russia the sub-bands 866-868 and 916-921 are not free? Whereas the others are free?


(Indhu) #84

Hi all! I have a doubt in the Fair Access policy of TTN and usage policy. Here I’m using Gateway (sx1308, Multichannel, antenna dB: 2dB) and Node (sx1276) for LoRaWAN application at Indian frequency of 865-867Mhz with a range gap of 500 meters between the node and a Gateway. In our project, we need to send an uplink message for 5 minutes once and downlink message for 10 minutes once (from TTN). We have recently tested and get to know the issue like we didn’t receive a downlink message for 500 meters gap only we able to get the confirmed message instead of confirmed ack but for the nearer range we able to get downlink messages with acknowledgment. Now my doubt is…

  1. Are there any limitations for downlink message for normal users at longer distance?
  2. Is Fair Access Policy is applicable to the normal user?
  3. If it is applicable, then it’s accessing limitation period is for a day or a month?

(Arjan) #85

The limitations are not related to the distance. However, if to get the longer distance you’re using a lower data rate (a longer time on air for the same number of bytes) then you’re obviously using more of the limits for each transmission.

Yes, on the public (free) The Things Network is applies to all users (per node). However, it’s not yet enforced, so any problems you’re seeing are not related to this policy. It could be that the gateway is busy though, but then you’d get an error saying “no gateways available for downlink”.

When enforced in the future, it will likely be per 24 hours. So it might very well be some sliding window, unrelated to a calendar day. If you use all the limits right now, then you cannot use anything for the next 24 hours, regardless in which time zone you’re operating.

Again, your problems are not related to the Fair Access Policy. But you’re definitely exceeding the limits. A downlink every 10 minutes is really, really, not nice. That’s 144 per 24 hours, during which the gateway that’s transmitting those cannot listen to any uplinks. The same applies to confirmed uplinks. So, you’ll need to rethink your use case.

(Jeff Uk) #90

Just an observation but though the regulations (FUP not withstanding) say you 'may’ use up to 1% dc that doesn’t mean you should/can plan on such high utilisation…if you do then potentially just 100 end nodes could swamp a sub band, and that is without allowing for the GW to go deaf whilst doing its ownTx’s e.g. ack’s, join accepts etc. When developing your application look to use perhaps 1/10th or possibly 1/100th of the available limit to be socially acceptable and play nice with all the other boyz & gurlz! :slight_smile:

Look carefully at what you send and how often + how well data compressed (please as others have said on forum threads never send values a ‘text’ fields! :wink: ), is full data value needed or can you average for a period and send less often, perhaps with excursion limits added for compliance checks etc. Can you just send deltas? if no change can you just send a null payload as a watchdog/network check in? Better yet stay silent and only send in ‘alarm’ conditions (unusually rapid rate of change in values or exceeding some some excursion limits etc.) and just check in once in a while so end application knows you are still available on the network etc. Obviously whilst testing & evaluating running closer to dc limit may be ok - for a few minutes/hours but not as a defacto operating mode.

Remember it doesn’t matter whether you are on the public TTN (with potential FUP issues) or TTI (more relaxed?!) or a private instance or even on a totally different network (Loriot, Orbiwise, Comcast, private…etc.) as you don’t ‘subscribe to’ or join with a specific GW (access point) rather your signal is picked up (and potentially forwarded to associated network server) by ALL GW’s in range of your transmission…you might not be running high dc but add in all the other users in range and you can potentially be saturating any given GW instance! :open_mouth: It is also a good test to consider how your specific application and architecture will behave if you deploy in range of less socially responsible users…can you cope with packet loss & interference etc.?

…consider also might you need to help ‘densify’ the network by dropping additional GW’s in the area where you are deploying to help share the load and distribute access hence helping more nodes to run on short/lower SF’s hence taking less time on air and helping mitigate dc limit issues. I know of many users who are just focused on deploying nodes/sensors in paces where they can see a GW and don’t stop to think hey maybe I should contribute some GW’s at same time…just saying! :wink: If someone doesn’t want to get into GW deployment/management contact others in the area you are targeting who do deploy/run GW’s and perhaps offer to contribute hardware or otherwise help fund/sponsor their efforts… :grin:

(Amedee) #92

Tsvetan Usunov (Olimex) Was was saying recently in a talk that LoraWan has started to be unusable in Sofia because no one cares about duty cycles and they completely saturate the network…

What happens if someone does not follow the guidelines? --> Smart Citys
(Jeff Uk) #93

That I can understand and see happening more & more. I guess not everywhere is like Zurich with >>100GW’s :slight_smile:

Personally I have spent a lot of time & money on the infrastructure/GW side to help facilitate - probably 2:1 vs spend on nodes and sensor development, though now GW’s are out there I’m starting to look more at the use cases and sensor deployments, at least on TTN. For clients and private deployments its probably the other way around. When planning GW placements I do lots of testing at higher SF’s (10-12: not dc friendly) - guilty your honor! - to map and evaluate what is possible/coverage limits, then look at how to ‘densify’ and reduce SF (7-9/10) for sustainability & long term deployments…

(Rafa Sach) #94

Does the network server implement logic of duty cycle or gateway implements it?. If multiple gateways are present , then how network server calculates it?

(Jeff Uk) #95

The challenge here is generally the Node behaviour and that is in the hands of the users/makers/developers/manufacturers. Some modules have s/w stacks that enforce duty cycle policies other dont (but not FUP implementations that is generally a user issue). DC for the Gateways is calculated and enforced via the NS - that is one of its primary functions. If a NS decides that a given GW has reached or is reaching its download (Tx) limit it will queue messages or where messages are time critical e.g response to a RX1 or RX2 windows, join accept priority etc. It may re-order the queue, or where practical and where there are others in range, it may decides to route the downlink message via a neighbouring GW to share the load. This is one of the reasons why it is not usually considered practical to have a GW associated with more than one NS or Network provider, as each is then unable to assess how much DL capacity has been consumed by the other other operator, unless you start getting into complex GW set-ups with GW derived stats, flags and semaphore systems… a nightmare to implement reliably/effectively

(Rafa Sach) #96

That means gateway doesn’t have any intelligence to follow DC limitations or RX windows timing. Everything is implemented in NS itself?

(Jeff Uk) #97

Basically yes that is correct - there are some higher end GW’s that monitor and manage as I understand it but the NS is princial arbiter. Also you can have the NS built into the GW to act as self contained units - example being the Multitech Conduit/MCAP or the original Semtech IoT Starter Kit ref design (now obsolete/unsupported/end off life), many self build (e.g. RPi based) GW’s - typically used for private deployments etc.indeed these are often fully integrated with their own App servers in built or with e.g. internal MQTT broker to connect to external App servers etc.

The fact that the GW is ‘managed’ and downloads queued by the NS is one of the reasons why you need generally low/predictable latency backhaul connections - reflected by e.g. TTN instances distributed globally to increase resilience & reduce ping times - and why sometimes Cellular and almost always Satellite backhaul fails or needs careful set up and timing back-off/mitigation.

(Rafa Sach) #98

Thanks a lot for the info. I am using a multi tech gateway with network server option. What i observe is the network server is able to send data to node for every 1 second time continuously. I connected only one node to that gateway/network server. So is it violation of DC rule or expected behavior?. Is there any mechanism to calculate gateway duty cycle?

(Jeff Uk) #99

I’m sure other forumites will step in and help here - I assume you have read the manuals/docs!? :wink: - my own experience with Multitech is limited as I have defaulted to running those I have deployed for myself & with clients with the support of external NS (e.g. on TTN/TTI).

And yes that sounds like a violation! - Will depend on payload/message size, SF etc. Just 'cause you can doesn’t mean you should - not least as both anti-social for other users not on your system but also remember when GW Tx’ing it isnt listening! :wink:

(Grazy) #101

For my hobbyist node I search a simple way to respect the fair access policy even if the data rate change due to ADR.
For a simple node that send regular message, is it enough to force a global duty cycle of 1/4096 ?
(like the one in chapter 5.3 of lorawan specification 1.0.2)

A duty cycle of 1/4096 => 86400 / 4096 = 21s .
If I transmit 51ms in SF7 I will wait 3,4 min before next message. If i transmit 1318ms in SF12 I will wait
89 min before next message.

Does TTN send some “DutyCycleReq” ?
I ask because I want to set globalDutyRate in LMIC to 12 after join (or before I am not sure) and I worry that the network reset it.

Connecting CAN BUS shield to the TTN UNO to send data to the TTN Gateway