(I'm trying to combine some information found in other posts and on Slack, as a reference for a future FAQ or Wiki page.)
In an open network with many different end-devices (nodes), which are not connected 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.
Here are some of the sources of the limiting factors.
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 / DutyCyclesubbband) - 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.
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.
Beware that the LoRaWAN protocol adds at least 13 bytes to the application payload.
The Things Network Fair Access Policy
The TTN Fair Access Policy limits the data each end-device can send, by allowing an average of 30 seconds time on air, per day, per device.
This 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’
Examples
Close to a European gateway, an application payload of 55 bytes (out of the maximum of 222 bytes) might take 71.81 milliseconds when using the highest data rate. This implies the end-device needs to wait just 7,109 milliseconds before it may try to use the same sub-band again, as 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 417 packets of 71.81ms per day. So while it may send another packet after waiting 7.1 seconds, on average it may only send once every 3.5 minutes.
Much further away from a gateway, sending the maximum application payload of 55 bytes using the lowest data rate may take 36 times longer, 2,629.63 milliseconds. Then the device needs to wait 4.4 minutes before it may try to send another packet (in the same sub-band). But it can also only send 11 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 30.85 and 1,318.91 milliseconds. That allows for twice as many packets per day when complying to the TTN Fair Access Policy.