What is LoRaWAN Duty Cycle?

LoRaWAN is beautifully frugal. That’s why we use it for long-range tracking, warehouse visibility, vehicle yards, worker safety, cold-chain monitoring, and all those awkward places where Wi-Fi cabling would be a project in itself.

LoRaWAN usually operates in shared, unlicensed ISM spectrum. In Europe, that means the EU863-870 MHz band. Because many devices share the same air, regulators and network operators limit how long each device may transmit. That limit is called the duty cycle.

In simple terms, duty cycle is the percentage of time a radio is allowed to occupy a channel or frequency band. If the limit is 1%, a device can transmit for 1 second, then it must stay silent long enough to keep its total transmit time within that 1% window. The Things Network explains the same principle as “the fraction of time a resource is busy.” ⁽¹⁾

For asset tracking, that matters a lot.

A temperature sensor sending one small reading every 15 minutes is easy. A gateway forwarding hundreds of Bluetooth beacon messages? Different story. A worker badge reporting location every few seconds from a busy industrial site? Now we need to plan.

Why Duty Cycle Matters in Lansitec Tracking Projects

We’ve seen this in real deployments: the problem is rarely one tracker. It’s the fleet.

One Badge Tracker reporting every minute is harmless. Five hundred badges, a few Passerelles Bluetooth, confirmed uplinks, poor spreading factor selection, and oversized payloads? That can become noisy fast.

Duty cycle affects three things that customers actually feel:

This is why a “5-second report interval” should not be read as “use 5 seconds everywhere.” Many Lansitec LoRaWAN devices allow very short configurable report intervals, for example, adjustable position report intervals based on 5 s x n and heartbeat intervals based on 30 s x n, but the right value depends on the use case, region, spreading factor, payload size, gateway density, and network policy.

That sounds like a lot. It is. But the design logic is simple: send what matters, only when it matters.

How LoRaWAN Duty Cycle Works Across Channels and Sub-Bands

This is the part many people miss.

Duty cycle can apply at different levels: device, channel, and sub-band. Actility’s article makes this distinction clearly, and it is worth keeping because it explains why a device may be able to transmit on one channel but not another. ⁽²⁾

In the European EU863-870 MHz band, The Things Network lists ETSI sub-band limits such as 0.1%, 1%, and 10%, depending on the exact frequency range. For example, 865-868 MHz and 868-868.6 MHz are listed at 1%, while 869.4-869.65 MHz is listed at 10%. ⁽³⁾

So, when someone asks, “Can we send every 10 seconds?”, the honest answer is: maybe.

Which band? Which data rate? How many bytes? Which spreading factor? How many devices? Public network or private network?

You need all those answers to engineer the correct solution.

Airtime: The Real Currency of LoRaWAN

Duty cycle is the rule. Airtime is what you spend.

Every uplink occupies the air for a certain time. That time depends mainly on payload size, bandwidth, coding rate, and spreading factor. Higher spreading factors increase range and receiver sensitivity, but they also increase time-on-air. The Things Network notes that a fixed payload sent with a higher spreading factor needs a longer time-on-air, and higher spreading factors also shorten battery life because the radio stays active longer. ⁽⁴⁾

Here’s the practical version:

This is why payload filtering matters. Several Lansitec Passerelles Bluetooth can filter Bluetooth payload bytes and report only the useful data through LoRaWAN. The Solar, Macro, Micro, and Passerelles Bluetooth compactes also support Bluetooth data compression and can pack up to 15 beacon messages into a single LoRaWAN package at SF9, with a maximum of 105 beacon messages supported, as noted in the product catalog.

Why Small LoRaWAN Messages Still Consume Network Capacity

Let’s say a gateway forwards BLE beacon IDs, RSSI values, and a small sensor field. One message is small. No drama.

Now put that in a parking lot, a hospital, a warehouse, or a construction site.

A B-Mobile setup may include Balises Bluetooth on assets or people, Passerelles Bluetooth fixed at known locations, and a LoRaWAN gateway that forwards data to the network server and application.

Lansitec’s LoRa solution describes this flow clearly: balises periodically advertise data, Passerelles Bluetooth receive and reformat it, then forward it via LoRaWAN to the network server and app.

At low density, you can report often. At high density, the design should become smarter:

• Use gateway-side filtering.
• Batch beacon messages.
• Report change events instead of repeating stable states.
• Let static assets be quiet.

Short and boring? Good. Boring networks scale.

EU868 Example: 1% Sounds Generous, Until You Calculate It

A 1% duty cycle gives 864 seconds of airtime per day. A 0.1% duty cycle gives only 86 seconds per day. A 10% duty cycle gives 8,640 seconds per day. These are daily airtime budgets, not message counts. ⁽³⁾

That distinction matters.

A device sending short SF7 packets may fit comfortably. The same device at SF12, with larger payloads and retries, may burn through airtime much faster. Public networks may be stricter too. The Things Network’s Sandbox Fair Use Policy limits uplink airtime to 30 seconds per day per node and downlink messages to 10 per day per node, while private networks must still comply with regulatory and LoRaWAN limits. ⁽¹⁾

For Lansitec customers using private LoRaWAN infrastructure, this is good news and bad news.

Good: You can design around your own application requirements.

Bad: You own the capacity planning.

How Lansitec Deployments Should Think About Report Intervals

The easiest mistake is to start with the fastest possible interval. Can the tracker report every 5 seconds?

Technically, some devices support that minimum interval. Operationally, you probably don’t want that for every device, all day.

A better question is: what decision will this message trigger?

Lansitec’s B-Fixed solution provides a useful real-world benchmark: a Badge Tracker reporting every minute at SF7 is described as supporting a single gateway accessing 500 devices, with a note to use a network capacity evaluation tool for accurate estimation. It also lists a 5-second minimum location-report interval, but that should be treated as a configuration option rather than a default for large fleets.

We like fast data when it helps. We don’t like fast data when it only proves the device is still where it was 10 seconds ago.

ADR Helps, But Only When The Device Behaviour Fits

Adaptive Data Rate, or ADR, helps optimize data rate, airtime, and power consumption. It can adjust the spreading factor, bandwidth, and transmit power. The Things Network recommends ADR when RF conditions are stable, generally for static devices, while mobile devices should use ADR only when they can detect that they are stationary for longer periods. ⁽⁵⁾

That maps neatly to tracking.

• A fixed indoor gateway? ADR can be useful.
• A tracker moving between a warehouse, yard, and truck? Be careful.
• A vehicle tracker parked overnight, then moves during the day? A hybrid strategy makes more sense.

For tracking systems, the device may move through very different RF conditions. Behind metal racks. Near forklifts. Inside a container. Outdoors. Under a roof. That instability can make ADR less predictable unless the application logic understands motion states.

Why Downlinks Can Break LoRaWAN Network Capacity

Uplinks get most of the attention, but downlinks can hurt a network faster.

Why? Because a gateway transmitting a downlink is not listening at that moment. It also must respect regional duty-cycle limits. In dense tracking systems, too many confirmed uplinks or routine downlink commands can create self-inflicted congestion.

Use downlinks for things that matter:

• Configuration changes
• Alarm acknowledgment when required
• Firmware or operational control workflows
• Carefully planned maintenance windows

Avoid using downlinks as a polling habit. LoRaWAN is not a chatty protocol. It rewards restraint.

Practical Design Rules for Lansitec LoRaWAN Tracking

Here is the field version we’d use in a project review.

In our experience, the “busy hour” is where designs reveal themselves. A site may look fine at 2 PM, then collapse at 7 AM when 400 badges wake up, 30 forklifts move, and passerelles start forwarding fresh beacon observations.

How this applies to B-Mobile and B-Fixed

Dans B-Mobile, balises are mobile, and Passerelles Bluetooth are fixed. The gateway hears nearby BLE advertisements, restructures the data, and forwards it through LoRaWAN. This is efficient when passerelles filter and batch intelligently. It is also where payload compression and reporting-interval tuning do the real work.

Dans B-Fixé, le balises are fixed, and the tracker reports what it hears. That can be excellent for worker tracking and indoor-outdoor movement, but the tracker’s reporting strategy becomes critical. Lansitec’s B-Fixed documentation notes a three-second Réception Bluetooth window and recommends beacon advertisement intervals such as 800 ms, 500 ms, or less, while also warning that shorter intervals improve positioning but consume more beacon power.

Different architecture but the same principle, without flooding the air.

A Sensible Starting Configuration

Every site needs its own survey, but this is a practical starting point for many Lansitec tracking projects:

Then test.

Not in a lab with three devices. Test with real density, real walls, real metal, real movement, and the actual network server. A parking lot full of cars is not the same as an empty parking lot. A hospital corridor at night is not a hospital corridor during shift change.

Common LoRaWAN Duty Cycle Mistakes to Avoid

The most common duty-cycle problems are not exotic. They’re boring, which is why they slip through.

First, teams overspecify reporting frequency because “real time” sounds good in a sales meeting. Then they discover that the business process only needs location every minute, except during alarms.

Second, teams forget payload size. A few unnecessary bytes may not matter once. Across thousands of packets per day, they matter.

Third, teams use confirmed uplinks too casually. Confirmation feels safe, but it increases downlink demand. In a dense LoRaWAN deployment, that safety can become a bottleneck.

Finally, teams treat gateway count as the only scaling lever. More passerelles improve coverage and link quality, but they do not override duty-cycle rules. Airtime is still airtime.

Conclusion

LoRaWAN duty cycle is not an annoying technical footnote. It is one of the reasons LoRaWAN works so well when properly designed.

For Lansitec tracking deployments, the goal is not to transmit as often as possible. The goal is to transmit useful, compact, timely information while keeping the network quiet enough to scale.

That is where LoRaWAN shines.

A Badge Tracker does not need to shout every few seconds if nothing has changed. A Passerelle Bluetooth does not need to forward every byte it hears. A private network does not need to behave like a public sandbox, but it still needs discipline.

The best tracking network is the one that tells you what changed, when it matters, and leaves the air free for the next important message.

Resources and Further Reading:

1. TTN docs: Duty cycle
2. Actility: Understanding Duty Cycle in LoRaWAN
3. TTN docs: Regional parameters
4. TTN docs: Spreading factor
5. TTN docs: ADR
6. RP002-1.0.5 LoRaWAN Regional Parameters