@htdvisser, please note that was an error on my annotation. The correct section at “Act 14448” related to LoRa is 10.3. This is the section related to Chirp Spread Spectrum (CSS). 10.2 is related only to FHSS.
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…
Are there any limitations for downlink message for normal users at longer distance?
Is Fair Access Policy is applicable to the normal user?
If it is applicable, then it’s accessing limitation period is for a day or a month?
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.
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!
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! ), 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! 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! 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…
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…
Does the network server implement logic of duty cycle or gateway implements it?. If multiple gateways are present , then how network server calculates it?
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
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.
The Semtech LoRa calculator will tell you the on air time for a particular spreading factor and packet length.
Assuming your 100 bytes grows to say 120 bytes by the time its sent by TTN , then best case, for nodes that are close is 197mS per packet and worst case 3874mS.
So best case is 567 seconds of air time per day and worse case is 11,157 seconds of air time per day.
The fair access limit is 30 seconds per day.
So best case you would be 19 times the limit, worse case 371 times the limit.
Its also worth pointing out that even the best case scenario, SF7, is running at around 0.7% duty cycle, the restriction is 1%.
So you would need to hard code each node to ensure it could only transmit at SF7, if any shifted to SF8 you would be breaching the restrictions on duty cycle.
For anyone finding this discussion at some point in the future:
The usage described would be illegal in Europe as it exceeds allowed transmission time for the 868MHz (sub)band used for LoRaWAN by TTN (and by Loriot as well given their response).
If you want to break the law, don’t be surprised if at some point in time someone will knock on your door telling you to shut things down, they might impose a fine for illegal radio spectrum use as well.
I am no expert with duty cycle limitations but i have an important question. You mentioned “Every device has the same duty cycle”. When creating a simple LoRa PHY node to node (one node act as gateway) system where the sender node collects some sensing data and sends to receiver node using LoRa. My question is: Are there any duty cycle limits imposed in such LoRa PHY layer devices with regards to the amount of data and transmission time for messages in a day?
Duty Cycle: In Europe, any equipment (regardless of its role - end device, repeater, gateway, beacon, …) that transmits radio signals in the 868 MHz band must respect the European duty cycle regulations. Other regions may have similar duty cycle regulations, so make sure to check with your national regulator. Exceeding these regulations is punishable by law.
Fair Access Policy: On The Things Network’s public community network we have transmission guidelines to make sure that our resources can be shared in a fair way between community members. Any production end device should respect TTN’s fair access policy, which means limiting consumption to 30 seconds of uplink airtime per day, and to 10 downlink messages per day. For development purposes it may be acceptable to exceed the fair access policy. If your production devices need to transmit or receive more, a private network is likely more suitable for you (we can help you with that).
On private networks running The Things Network Stack, the fair access policy does not apply, but the duty cycle limitations are imposed by law for a specific region (Europe) and always apply.
) here:
), 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.
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.?