Duty Cycle - Time on Air

TTN Network and Services
23

You’d wish, but no:

  1. The duty cycle should be taken into account each time you send. It’s not some hourly or daily total, so you cannot send 36 seconds and then be quiet for the remaining hour. Instead, from the specifications:

    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

  2. The duty cycle is meant to lower the chances that two nodes send simultaneously. (Which would cause collisions and data loss if that happens.) However, if each node would use the maximum 1% duty cycle (assuming they would never send simultaneously with some other nodes, and would do perfect channel-hopping using 8 channels), then a gateway could only support 800 nodes! (Okay, a bit more if nodes happen to use different spreading factors, but far less as nodes send randomly.)

    In other words: the maximum duty cycle is the absolute minimum time a node needs to be quiet between two messages. But on average, you should be far below the maximum duty cycle.

  3. The TTN Fair Access Policy nicely summarizes 1. and 2. by limiting air time to 30 seconds per node per day.

    And as we all share the same radio frequencies: even when using different networks, nodes affect each other, so consider the reasoning for TTN’s limit when trying to circumvent it using another network. (See “Why?” in Limitations: data rate, packet size, 30 seconds uplink and 10 messages downlink per day Fair Access Policy.)


It is per node. Nodes do not know what other nodes did.


I don’t understand. Seems like this is answered above.

2 Likes