Hello
When a ‘Link Check commands’ is used, the TTN send an Downlink with empty payload.
Is this downlink is count in restriction ( 10 downlink per day ) ?
Thank for response
All downlinks count, also downlinks sent in response to requests sent by the device. This includes ACKs to confirmed uplinks and responses to MAC requests such as LinkCheck for example.
1 Like
In Brazil we use the AU915, which is quite similiar to the US915.
Most recent regulation stands that for bandwiths less than 250kHz the transmision should hop through at least 35 different frequencies and the mean dwell time should be under 400ms within a 14s interval.
For bandwiths greater or equlas to 250kHz it should hop through at least 17 different frequencies and the mean dwell time should be under 400ms within a 7s interval.
Is this the same restriction applied in the USA by FCC15? Or does this 14s (or 7s) window actually defines a duty cycle, also?
Anyway, this clearly limits the SF usage, prohibiting the usage of SF12/BW125 since the 1byte payload message would take about 600ms. Is this correct? @htdvisser did such a great job explaining the duty cycle here (https://www.thethingsnetwork.org/docs/lorawan/duty-cycle.html), I would like to have a clear picture about those other restrictions as well.
Could you share (a link to) the official documents here?
https://www.thethingsnetwork.org/docs/lorawan/frequencies-by-country.html 
P.S. BTW, for Russia, freq. plan and the reference to the regulatory document are incorrect.
Hylke knows where to find the TTN documentation, he needs links to the official documentation as provided by the appropriate authority for a country.
You state the information for Russia is incorrect, it would help if you point to the correct information (preferably in English)
1 Like
I did quite catch him.
GKRCh (State Comission for Radiofrequencies allocation) Decision #07-20-03-001, Appendix 11 (NOT Appendix 10):
864-865 MHz: EIRP 25 mW, duty cycle 0.1% (or LBT, note that there’s no need in AFA), may not be used close to airfields.
868.7 - 869.2 MHz: EIRP 25 mW, no duty cycle limitations.
Also, you may take a look at LoRaWAN regional settings doc:
1 Like
Yes, sure! I recently updated the links here: https://www.thethingsnetwork.org/docs/lorawan/frequencies-by-country.html
And the official docs are availabel (only in Portuguese 
) here:
http://www.anatel.gov.br/legislacao/resolucoes/2017/936-resolucao-680
http://www.anatel.gov.br/legislacao/atos-de-requisitos-tecnicos-de-certificacao/2017/1139-ato-14448
The dwell time definitions are at the “Act 14448” document, section 10.2
Docs attached, here.
ANATEL - Resolution 680.pdf (94.5 KB)
ANATEL - act 14448.pdf (186.9 KB)
If you need help translating, just ask me!
Regards.
Yes !
I just updated those docs reference about 2 weeks ago. It was incorrect, linking to the old regulation that was revoked by this ones.
1 Like
@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… 
3 Likes
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…
2 Likes
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
1 Like
That means gateway doesn’t have any intelligence to follow DC limitations or RX windows timing. Everything is implemented in NS itself?
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.
2 Likes
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.
3 Likes