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


(Kalon33) #48

@arjanvanb I didn’t found that info in TTNmapper FAQ, do you know which packet rate (nb of seconds between packets, or packets/min) is authorized in SF7 (BW125) in Europe when performing mapping (and only mapping of course)? As for R&D, I imagine it’s higher than what is defined in Fair Access Policy? Because it’s hard to map with 5 minutes or so between packets with a moving node…

Thanks for your help.


(Arjan) #49

For mapping and any R&D, any duty cycle regulations for one’s region would still apply as usual.

The Fair Access Policy is a daily maximum of 30 seconds. As even a zero byte application payload would be fine for mapping, you could send 647 packets in SF7, with a delay of 4.6 seconds (assuming a 1% maximum duty cycle). So, you could be mapping for almost an hour without hitting the Fair Access Policy either. Even more, it’s not enforced yet.


Same values for 1 and 2 bytes application payloads (plus the 13 bytes header)


(Sil) #50

If I set up a private network as described in your tutorial , is Fair Access Policy automatically disabled or is there a configuration parameter to do that ? Thanks


#51

Fair Access Policy isn’t enforced yet on the public servers, nothing to disable on private networks either.


(Am4 I) #55

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


(Hylke Visser) #56

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.


(Mjunior) #57

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.


(Hylke Visser) #58

Could you share (a link to) the official documents here?


#59

https://www.thethingsnetwork.org/docs/lorawan/frequencies-by-country.html :wink:

P.S. BTW, for Russia, freq. plan and the reference to the regulatory document are incorrect.


(Jac Kersing) #60

@hobo

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)


#61

I did quite catch him.
Brazil-RegDocs


#62

GKRCh (State Comission for Radiofrequencies allocation) Decision #07-20-03-001, Appendix 11 (NOT Appendix 10):
GKRCh

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:

RURegParams


(Mjunior) #63

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 :confused: ) 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.


(Mjunior) #64

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.


(Mjunior) #65

@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.


(Bantob) #66

thanks lot, very informative. According to such limitations, am i correct that FW updated OTA would not be possible (well unless the time to complete it would be over days…)?


(Bantob) #67

Hi forum,

my understanding is that GWs updates can be supported by the bandwidth however i also understand that nodes have to respect Duty Cycle limitations. Hence updates OTA are almost unfeasible. What are the best practices here?

thanks lot


(Amedee) #68

(Bantob) #69

thanks very informative. If i understand correctly updates are possible but should be done on a set of devices otherwise that would be very inefficient, right? How is this orchestrated/scheduled/synchronized? Is it already available on TTN?

thanks lot.


#70

No it isn’t