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

(Arjan) #1

The TTN Fair Access Policy limits the data each end-device can send, by allowing:

  • An average of 30 seconds uplink time on air, per day, per device.
  • At most 10 downlink messages per day, including the ACKs for confirmed uplinks.

A good goal is to keep the application payload under 12 bytes, and the interval between messages at least several minutes.

The following regulations apply as well:

LoRaWAN data rate and application packet sizes

The data rate and maximum packet size roughly depend on the distance to the nearest gateway and the type of data to be sent, and are also defined in the specification for each region. Like for the European 863-870MHz band, the application packet size varies between 51 bytes for the slowest data rate, and 222 bytes for faster rates. Note that the LoRaWAN protocol adds at least 13 bytes to the application payload. And beware:

Devices with fixed hardcoded data rates of SF12 or SF11 are not allowed to join the network.

LoRaWAN transmit duty cycles and dwell times

To avoid network congestion, LoRaWAN defines some maximum transmit duty cycles and maximum transmit times (dwell times). These depend on many factors including the region and the type of operation (like sending data, or broadcasting a request to join a network).

For the European EU 863-870MHz ISM Band the specification limits the duty cycle to 1% for data:

The LoRaWAN enforces a per sub-band duty-cycle limitation. Each time a frame is transmitted in a given sub-band, the time of emission and the on-air duration of the frame are recorded for this sub-band. The same sub-band cannot be used again during the next Toff seconds where:

Toffsubband = (TimeOnAir / DutyCyclesubband) - TimeOnAir

During the unavailable time of a given sub-band, the device may still be able to transmit on another sub-band. If all sub-bands are unavailable, the device has to wait before any further transmission. The device adapts its channel hopping sequence according to the sub-band availability.

Example: A device just transmitted a 0.5 s long frame on one default channel. This channel is in a sub-band allowing 1% duty-cycle. Therefore this whole sub-band (868 – 868.6) will be unavailable for 49.5 s.

For other regions, quite similar limitations apply.


In an open network with many different end-devices (nodes), which are not connected but just start sending when they need to (ALOHA-like protocol), and all have a different data need and connection quality, there are many limiting factors to keep things working. Like when an end-device is far away from a gateway, it needs to use a low data rate to ensure at least one gateway receives its data. But a lower data rate implies a longer air time for each byte. This limits the maximum packet size, to ensure other end-devices get time to use the network as well. And when transmitting takes longer, a device cannot send as often as it might want to.

The uplink limit of the TTN Fair Access Policy is based on the following:

  • 8 frequencies
  • 5% receive duty cycle on the gateway
  • 86,400 seconds in a day
  • 1,000 nodes

Or: (8 × 86,400 × 0.05) / 1,000 yields approximately 30 seconds per node per day.

From The Things Network 2016 Update:

Fair Access Policy: Practice

  • Golden rule: 30 seconds air-time per device per day
  • For 10 bytes of payload, this translates in (approx.):
    • 20 messages per day at SF12
    • 500 messages per day at SF7
    • more for SF7BW250 and FSK (local-area)
  • If your application requires more bandwidth, think of another solution
  • This allows for >1000 nodes per gateway
  • Downlink bandwidth is even more restricted
    • you can’t send all messages as ‘confirmed uplink’

As for the downlink (including confirmed uplinks), during the February 29th Tech Update (at 32’12"), TTN tech lead @johan explained:

This would mean that for each uplink message there would be a downlink message. But since the gateway also has a duty cycle, there is a limit on how much downlink we can support. So, this is also a restriction: confirmed uplink will not be possible for all devices. This means that people, application developers, should be careful when using this feature. […] By the way, the Fair Access Policy is more based on the gateway limitations than on the limitations of an individual node.

And TTN developer @htdvisser wrote:

All devices have to comply with these regulations, so that includes gateways. As a result, downlink capacity of the network is even smaller than uplink capacity. This means that you should use unconfirmed messages unless you really need confirmed messages and send as little downlink data messages as possible.

Also note that current LoRaWAN gateways are all half-duplex, implying they cannot listen to incoming uplinks while transmitting a downlink packet to a node. Even more: while sending it can only transmit on one channel, while for listening it can use 8 channels simultaneously.

For the 10 downlink messages per day, @Thomas wrote on Slack:

It’s not in seconds because the node/app don’t have influence on the data rate (RX1 vs RX2). It does include ACK’s, but maybe we should exclude ADR. The main problem is to manage the TX time of the gateway(s), because at TX interrupts any ongoing RX, so it might affect network performance quite a bit. 10 messages of 10 byte payload (on average?) at SF9 (RX2) are about 2 seconds of airtime.

Finally, see LoRaWAN Limitations on the Wiki.


Close to an European gateway, an application payload of 55 bytes (out of the maximum of 222 bytes) might take 123.14 milliseconds when using EU868’s highest data rate, SF7/125kHz. This implies the end-device needs to wait just 12,314 milliseconds before it may try to use the same sub-band again, when limited by the 1% LoRaWAN duty cycle rule. (Other sub-bands might be available.) But given the TTN Fair Access Policy of 30 seconds, the device is also limited to sending only 243 packets of 123.14 milliseconds per day. So while for a 1% maximum duty cycle it may send another packet after waiting 12.3 seconds, on average it may only send once every 5.9 minutes.

Much further away from a gateway, sending the maximum application payload of 55 bytes using the lowest EU868 data rate of SF12/125kHz may take 24 times longer, 2,957.31 milliseconds. Then the device needs to wait 4.9 minutes before it may try to send another packet (in the same sub-band). But it can also only send 10 such packets per day, on average less than once every 2 hours.

Limiting the application payload to only 8 bytes (which will still need at least an extra 13 bytes for the LoRaWAN protocol) decreases the above air times to 56.58 and 1,482.75 milliseconds. That allows for twice as many packets per day when complying to the TTN Fair Access Policy.

Send picture via LoRaWAN?
Best practices to limit application payloads
Remote fire up of car heater
Duty Cycle - Time on Air
Time synchronisation of a Node
Configure Downlink Frequency of a Gateway
TTN Node Receive problem Convert the received value to int or long
Duty Cycle - Time on Air
Unclear what exactly is possible with LoRaWAN technology
LoRa Maximum Transmission Unit
How to modify Microchip RN2483 code and upload to chip
What is the maximum number of characters I can send with LMiC?
Best practices when sending GPS location data
Can I get the ACK of a confirmed downlink in the HTTP integration?
Restart ttn-pkt-forwarder reset my config
LMIC Library Always Does Unwanted Downlink
LMIC Library Always Does Unwanted Downlink
LT-33222-L LoRa I/O Controller - Payload decoder and downlink config
Breaking duty cycle limitation by resetting RN2483?
Packet loss problem with STM32L432/I-CUBE-LRWAN V1.2.0
RAK 5205 tracker
The LIBRARY basement part 8
No RX TTGO-BEAM with TTN Mapper
LoRaWan for device monitoring?
What is the best integration for paging messages?
LoRa Mac Node with EFM32PG custom board + SX1276 or RFM95 module
How to Find Maximum Packet Size
FW update best pratices
Maximize LoPy message size
Device not activated Lora feather 32u4 RFM9X
How many gateways are needed to support 1,000 nodes sending 10 bytes per 5 minutes?
Send picture via LoRaWAN?
Downlink messages limitations over TTN
LMiC fails to send application payload larger than 51 bytes
The LIBRARY basement part 5
"retry confirmed" in application data view - what does it mean?
Possible to receive message when in sleep or receive last message on request?
Got Adafruit Feather 32u4 LoRa Radio to work and here is how
Cannot read payload Laird LoRa Gateway
Packets getting lost on the TTN Console (or LoRa Gateway)
Determine which gateway is used by a given node
Best practices when sending GPS location data
SWOT Analysis on TTN
Can I avoid Fair Access Policy by implementing a private TTN network?
Node with ESP8266 and RFM95W
Best practices when sending GPS location data
RN2483 datarate not changing
Send picture via LoRaWAN?
Haarlem, The Netherlands
Duty Cycle - Time on Air
Spreadsheet for LoRa airtime calculation
How can it be pushed data from LoRa gateway to TTU mote?
Who owns the network?
Location by triangulation
Lights on/Off TTN Node Code
Connecting NETVOX sensors
ST LoRa® IoT tracker - STEVAL-STRK01
Still stuck at EV_JOINING
LMIC get duty cycle timer for channel
Dragino+pi3 node transmission problems
LMiC's TX_COMPLETE event takes 20-30 seconds to fire
Single Channel Gateway part 1
Single Channel Gateway part 1
Single Channel Gateway part 1
Duty cycle regulations in Europe
RN2483 now supporting Class C: what does that mean for TTN?
Downlink to Node with LMIC
Getting Badgerboard to work with TTN
Simple payload conversion
I am getting downlink for every cnf uplink
Sending UDP packets via LoRaWAN
How many gateways are needed to support 1,000 nodes sending 10 bytes per 5 minutes?
Is LBT (Listen-Before-Talk) supported by The Things Gateway?
Downlink to SX1276 using Arduino LMiC
LoraWan Pager project
Time synchronisation of a Node
(Jac Kersing) #2

Thanks for the write up. A couple of things that came to mind:

  1. The number of packets for a day is limited because of the access policy, however the packets do not need to be distributed evenly over the 24 hour timespan to stay within the 30 second limit. The 11 packet worst case allowance could be used in 1 hour when no data is transmitted during the remainder of that day.
    (This can cause issues if a significant number of nodes within reach of a gateway all choose the some time frame to consume their allowance)

  2. A node that’s close to a gateway at a certain point in time may not be close to a gateway at other times. This might be because the node is moving or because a gateway is down (for whatever reason). So its hard to predict what transmission speed is appropriate to reach any gateway. Using ADR could solve this (once TTN supports it) however this makes it harder to estimate what the ‘save’ amount of data and transmit interval is.


If and when these limitations are implemented in the TTN network, I sincerely hope that it will be announced and discussed in detail before… The problem boils down to the fact that we are dealing with a new technology with extreme small bandwidth and with great coverage, and a lot of applications doesn’t fit in this environment but can work in the existing mobile networks or with wifi.

Considering this, I believe that sometime in the future some algorithms protecting the network and “fair use” must and will be implemented. But, and this is also important, it should be implemented with care and not as “10 messages per day and node” :slight_smile:

I have the greatest respect for the the work I have seen here and on github, my setup are based on the work of others and I feel the same impatience that we are moving fast but it can be faster, and as soon we have a real TTN Gateway delivered focus will shift, I hope… To the network and to the nodes and to the applications.

I have two setups working today, but if the TTN community kills them without reason and discussion then I do not know… what to do.


Not without reason and I think there are enough people involved in the discussion of things like those limits.
It’s a bit harsh to just call putting a limit on the number of downlink messages per sensor “kill” but I can imagine how this must feel.

The reaon for setting a limit on the number of downlink messages is that the gateway has the same duty cycle limits that apply for sensors. But if a sensor sends a confirmed data up message with this 1% limit, this means that the gatway will reach its limit when there are just a hand full of those sensors around.

Some people have been doing calculations. Based on the expected number of sensors per gateway and the percentage of messages being confirmed + the remaining downlink messages, the limit of 10 popped up.
That may look like a very low limit but remember that this is also based on the fact that sensors are not supposed to perform regular confirmed data up messages.

Performing a request for an ACK or sending too many downlink messages will however “kill” the gateway. It is then blocked for sending messages to other nodes…


I completely understand the reason and need for some kind of usage policy. One thing of concern is testing and development… Right now I am working on a LoRa solution and while trying to get everything right and working properly I definitely “break” the fair access rules (e.g. much more than 10 confirmed messages during a day of testing)… I set up a gateway myself, and for sure there are not 1000 nodes sending stuff at the moment (I’ve never encountered any packets other than my own).

Anyway, my questions are:

Is there some kind of solution envisioned for testing purposes?

When is the fair access policy going to be implemented (if it is on the roadmap)?

(Hylke Visser) #6

No worries, @mahe. We’re all developers, so we understand that you might have to send more traffic during development. As long as you comply with the legal limitations (such as the duty cycles in Europe) everything should be fine.

Just design your solution in such a way that when it is finished, it stays well below the limits :slight_smile:

(Jakl5749) #7

Is the Duty Cycle limitation for LoRaWAN Gateways and thus the maximum amount of transmitted messages the same like for end-devices (1%)? I haven’t used TTN so far but gateways in two other networks I used also didn’t comply with the +14dBm TX signal strength limitation so I am wondering if there are different regulations for gateways for example due to the usage of another sub-band.

(Hylke Visser) #8

Every device has the same transmit duty cycle, gateways are no exception. The TTN backend is compliant with these regulations, so in Europe we stay under the 1% duty cycle for g and g1 and under 10% for g3. By default, gateways transmit with maximum allowed TX power (14 for EU-868).

(Sridhar Naidu Chappa) #9

Hi ,
Duty Cycle limitation is for the entire EU-868 band or for that particular frequency only?

means if i have 865.0625,865.4025,865.9850 frequencies,then first i transmit on first frequency and immediately can i send it on second frequency?

(Hylke Visser) #10

It’s one duty cycle for all transmissions within the band.

(Weffel) #12

Is there also a minimum duty cycle or messages a day/week that you have to follow?

Either in the TTN Fair Access Policy or in the European EU 863-870MHz ISM regulation?

(Hylke Visser) #13

There is no minimum. A device can sleep for weeks or months between messages.

(Osman) #14

This whole sub-band would be unavailble to all the nodes or the one that just transmitted?


Just the one that transmitted of course. Otherwise any useful communication would be close to impossible.

(Hylke Visser) #16

I did my best to explain the duty cycle in this wiki page:

If there’s still anything unclear, let me know (or improve the wiki page)

(Mediocre Lora User) #18

the application packet size varies between 51 bytes for the slowest data rate, and 222 bytes

What are you refering to with ‘application packet size’. Is this the actual payload that is being send by a node?
And if so, does this mean that the maximum length of a LoRaWAN frame is 222 bytes + 13 bytes?

(Arjan) #19

The maximum application payload size is indeed, well, the maximum application payload size. It is defined as:

The maximum application payload length in the absence of the optional FOpt control field

So indeed without any LoRaWAN headers. For EU868, that is between 51 and 222 bytes, which according to the specifications is between 64 and 230 total size for EU868 then – not sure how that is calculated, but if you’re getting close to the lower limit of 51, then you probably want to reconsider using LoRa:

Technically, you can send 51 bytes. But, the more bytes you’ll send, the more airtime the package will cost you and the sooner you’ll hit your maximum allotted time. So, don’t ask yourself how many you can possibly send but rather ask how few could do the job.

(Abin Raj) #21


Am I right in assuming that, for my 1000 nodes connected to the gateway, each node can send about 500 messages per day with 10 bytes of data as payload?

Also, for a single node transmitting 10 byte payload, will it allow me to send more than 500 messages per day ?

(Jac Kersing) #22

Nodes do not connect to a gateway. Nodes broadcast a radio signal and your gateway may receive it. Other gateways may receive it as well. Having 1000 nodes sending 500 messages a day is a heavy load on the available radio spectrum at one location so expect a lot of collisions and as a result of that packet loss.

(Abin Raj) #23

Hi @kersing

Having 1000 nodes sending 500 messages a day is a heavy load on the available radio spectrum at one location so expect a lot of collisions and as a result of that packet loss.

Thank you for the info. Will keep it in mind.
I just wanted to know if what I understood is correct.