Fair Use Policy explained

End Devices (Nodes)
1

For The Things Network’s public community network the Fair Access Policy limits the data each end-device can send, by allowing:

  • An average of 30 seconds uplink time on air, per 24 hours, per device.
  • At most 10 downlink messages per 24 hours, 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. An online airtime calculator can give you some insight.

The following regulations apply as well:

LoRaWAN data rate, spreading factor, and application packet sizes

The data rate DR (defined by spreading factor SF and bandwidth BW) and maximum packet size roughly depend on the distance to the nearest gateway, and are also defined in the specification for each region. Like for the European 863-870MHz band, the maximum application packet size varies:

  • 51 bytes for the slowest data rates, SF10, SF11 and SF12 on 125kHz
  • 115 bytes for SF9 on 125kHz
  • 222 bytes for faster rates, SF7 and SF8 on 125kHz (and SF7 on 250kHz)

Note that the LoRaWAN protocol adds at least 13 bytes to the application payload. And beware:

  • Some libraries, such as LMiC, only support 51 bytes for all data rates.
  • Some providers, such as the Dutch KPN, only support 51 bytes for all data rates.
  • Some regions define a maximum dwell time, reducing the maximum payload size for slow data rates (high SF).

Devices with fixed hardcoded spreading factors 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. Like for US915, no legal maximum duty cycles between transmissions are defined, but a 400 ms dwell time applies that limits the length of each transmission itself. Also, LoRaWAN may still define additional maximum duty cycles for, e.g., join requests. And for AU915, a recent Regional Parameters document states:

If the field UplinkDwellTime is set to 1 by the network server in the TxParamSetupReq command, AU915-928 end-devices SHALL adjust the time between two consecutive uplink transmissions to meet the local regulation. Twenty seconds (20s) are recommended between 2 uplink transmissions when UplinkDwellTime = 1 but this value MAY be adjusted depending on local regulation.

Why?

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

Examples

Close to an European gateway, an application payload of 55 bytes will take 123.14 milliseconds when using EU868’s highest data rate DR5, SF7 on 125kHz. This implies the end-device needs to wait just 12,314 milliseconds (12.3 seconds) 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 24 hours. So while for a 1% maximum duty cycle it may send another packet after waiting 12.3 seconds, when sending all day long then on average it may only send this packet on this data rate once every 354.6 seconds, or 5.9 minutes.

Much further away from a gateway, sending the same application payload of 55 bytes using the lowest EU868 data rate DR0 of SF12/125kHz may take 24 times longer, 2,957.31 milliseconds. Then the device needs to wait 295.7 seconds, or 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. Even more: the LoRaWAN specifications define a maximum total size of 64 bytes for SF10, SF11 and SF12 in EU868, so one could send at most 51 bytes of application payload in that case anyway.

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.

In US915, the lowest data rate DR0 is SF10 on 125kHz, which only allows for 11 bytes of application payload.

31 Likes
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.

2 Likes
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.

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

1 Like
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?

1 Like
13

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

1 Like
16

I did my best to explain the duty cycle in this wiki page: https://www.thethingsnetwork.org/wiki/LoRaWAN/Duty-Cycle

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

2 Likes
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?

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.

24

4 posts were split to a new topic: Simulated confirmed downlinks no longer getting to the gateway

25

Also, this would only be true for SF7 (to be exact: 10 bytes of payload data allow at most 486 messages at SF7). But if ADR tells the node to use SF8, the number is already limited to half of that. For SF10 you’d be down to 80 messages per day, and you would still be pushing the limit all day then. Please consider the maximum to be an upper limit; if everyone would push the limit then a gateway can only support 1,000 nodes.

28

Please clear me if i get something wrong
what i understood is: there may be two types of duty cycle limits
1- Duty Cycle imposed by European Commission and that is the same throughout the EU
2-Under generic EU limitations, there is further a fair usage poilcy of 30 messages per node per day imposed by TTN.

What if i only follow the 1 but do not follow the 2nd in my own network?

If yes, can i say
The maximum number of packets per hour per node can be seen as 60*60/Time on Air + Time off

31

There are two types of duty cycle: (1) the one imposed by regulations and (2) the one imposed by LoRaWAN.

The Fair Access Policy is there to make sure that the community network is not abused by large deployments and applies to all of the community network, not just EU.

In your own private network you only have to be compliant with the (1) and (2), not with the fair access policy of TTN.

34

Please read the relevant articles in the wiki.

Duty cycle limitations are not latency. Latency is the delay between transmitting a packet and its arrival at its destination. In TTN this takes somewhere between 100ms to several seconds.

LoRaWAN is not a real-time communication technology in the sense that you can almost continuously transmit, e.g. like in wifi or cellular. It is meant to transmit short bursts of data at long intervals between bursts. If you need to transmit more data or in a more continuous way, you should look to other technologies.

2 Likes
35

Thanks for your reply @Epyon. I was looking at LoRaWan for industrial monitoring (As mentioned on Semtech webage, it is suitable for this use cases) but i was interested to calculate the communication latency of lorawan to find out suitable communication intervals. How can I calculate it if you have any idea?
Secondly, the latency you referred in your last comment is only from the end node to gateway?not to the LoRa communication server?

36

It depends on what you mean by latency.

If you mean the delay between the emission of a LoRaWAN message by an end node and its reception by your application, then it’s generally < 5s. If you mean the average delay between the emission of downlink by your application and the reception by your end node, then it depends on how often you send uplinks in the first place. As a rule of thumb, you can’t expect to do much better than 15 minutes.

In a nutshell, there’s no “communication” in LoRaWAN like you would find on an IP network. There are messages, but no connection.

37

Latency and duty cycle are not really related anyway. However, some class A devices send uplink messages to poll for downlink data periodically, and by this polling exceeding the duty cycle or fair access policy. This need is removed when Class B and C become generally available, not only in TTN but also in end device stacks. Class B is going to be a bit challenging though, but definitely doable on GPS time synced gateways.

In any case, the fair access policy is not being enforced today, and exceptions will be made for R&D. I can imagine the following steps:

  1. Formulate and communicate fair access policy: done
  2. Make ADR generally available in all regions and to optimize capacity on the network level: in progress
  3. Monitor to see how devices and applications are behaving with respect to the fair access policy: in progress
  4. Give solution makers insight in how their devices and applications behave and provide documentation on how to use less capacity (= less power consumption too): in progress
  5. Send warnings to application owners that are consistently exceeding the fair access policy for a larger number of devices, so this is where we make exceptions for R&D: todo
  6. Use MAC commands to reduce uplink from the devices, e.g. tighten duty cycle levels, if applicable: todo
  7. If the warnings and duty cycle don’t help, trigger QoS measures to partially drop uplink or downlink traffic: todo

So basically we don’t go from formulating the fair access policy to dropping traffic right away. We’re only at step 2 and 3 of the above.

2 Likes
38

@Gig If you mean the delay between the emission of a LoRaWAN message by an end node and its reception by your application, then it’s generally < 5s.
Yes, I exactly mean this but how is it possible to calculate this precisely? It may serve the two fold purpose.
1- It would be useful to determine the suitable monitoring interval in predictive maintainance
2- can be used to calculate the energy consumption of LoRaWAN
Thanks again

40

Both depend on the spreading factor (SF) you use. If you have good reception and are at SF7, you can transmit your message in tens of milliseconds to your gateway. If you have bad reception and are at SF12, it can take up to 1,2 seconds. At SF7 you will be able to send more messages because each message takes up less airtime. If you keep the messages short, you can also send more. See this thread for airtime calculation.

The transit time from the gateway to your application completely depends on the solution you choose. On TTN and with a gateway connected through wired Ethernet this will only take some tens of milliseconds (at current load levels). If the gateway uses a slow cellular connection this delay will of course add up. If suddenly tens of thousands of people start using TTN, it will probably slow down too.

Remember that the TTN service is ‘best effort’. In a commercial setting you will probably sign (and pay) SLA’s with commercial providers which will indicate the maximum latency between gateway and your application.

I agree with the wording of @Gig that LoRaWAN is not for real time communication but for (short) message sending. Like you would send an e-mail or a text message. Latency isn’t the factor determining the quality of the service here, as long as the message gets delivered in a timely fashion.

41

Yes

Adding to that: this is typically variable with ADR enabled, the recommended setting for static devices

So summarizing, on a high level:

Latency = Time On Air + Gateway to NS network latency + Deduplication Window + Routing Services processing time [1] + MQTT broker to Application network latency

[1] this is minimal when data stays in the same region, otherwise there’s of course the network latency between regions