# Mesh Network Capacity and Congestion

## LoRa Channel Capacity

LoRa is a low-data-rate technology. Unlike Wi-Fi, the RF channel is shared by all nodes simultaneously using a CSMA-like approach combined with Meshtastic's **managed flooding** mesh mechanism (every node rebroadcasts packets that still have hop limit remaining; there is no routing table). Understanding channel capacity helps you design a network that doesn't saturate itself.

## Airtime Utilisation Metrics

Meshtastic displays **Channel Utilization** and **Air Utilization** percentages in the app. These are your primary indicators of network load. Channel Utilization is measured over a rolling 1-minute window, and the app colour-codes it: green below 25%, orange 25 - 50%, and red above 50%.

- **Channel Utilization &lt; 25% (green):** healthy. Around the 25% mark the firmware begins to self-throttle - it *defers* its own transmissions to avoid colliding on a busy channel, so packets are delayed (queued), not dropped outright.
- **Channel Utilization 25 - 50% (orange):** busy/degrading. Expect added latency as nodes back off and defer.
- **Channel Utilization &gt; 50% (red):** congested. Sustained load at this level risks queue overflow and real packet loss.
- **Air Utilization TX:** the fraction of time *your* node spends transmitting. Keep it low (a few percent is a reasonable target); a high value means your node is contributing a lot of airtime - reduce its broadcast intervals. (There is no documented hard "15%" Air Utilization rule.)

## Sources of Traffic in a Mesh

- **Position and NodeInfo broadcasts:** nodes announce themselves periodically. Position and NodeInfo are *separate* broadcast types sent at different default intervals (NodeInfo is typically far less frequent than position). As a rough example, 50 nodes each sending a position packet on a 15-minute interval is one position packet roughly every 18 seconds (50 ÷ 900 s) on average - before any user traffic, and before the additional NodeInfo, telemetry, and rebroadcast load. (Verify the exact default intervals against your current firmware/preset, as they vary by role and modem preset.)
- **User messages:** text traffic generated by operators.
- **Telemetry:** device metrics (battery, voltage) and environmental sensor readings.
- **ACKs and routing overhead:** mesh protocol housekeeping packets.

## Traffic Reduction Strategies for Dense Networks

- Increase position broadcast interval to 30 - 60 minutes on non-mobile nodes.
- Disable telemetry on nodes where it is not needed.
- Use the **Medium Slow** or **Medium Fast** preset - the higher data rate means each packet occupies the channel for less time, even if physical range is unchanged.
- Be deliberate about infrastructure roles. Both **ROUTER** and **REPEATER** rebroadcast with *elevated* priority (they will rebroadcast even after hearing another node do so), so neither is "less aggressive" than the other. The practical difference is that a REPEATER is headless - it does not run the client app or participate in the node database - not that it retransmits less. To actually cut redundant airtime, reduce the *number* of high-priority infrastructure nodes in range of each other and keep ordinary nodes in the default CLIENT role rather than promoting many of them to ROUTER/REPEATER.
- Limit hop count: most community networks set a maximum of 3 - 5 hops (the firmware default is 3, max 7). Longer hop chains amplify traffic because each hop retransmits every packet.

## The Hop Storm Problem

If many nodes retransmit the same packet, a single user message can trigger a burst of dozens of transmissions across the mesh. Meshtastic uses duplicate-packet detection to suppress already-seen packets and prevent routing loops, but in dense networks already near maximum airtime utilisation, a sudden burst of messages can temporarily saturate the channel and cause widespread packet loss. Keeping hop counts low and broadcast intervals long is the primary mitigation.

## Monitoring Your Network

Use the Channel Utilization and Air Utilization figures in the [Meshtastic app](https://wiki.meshamerica.com/books/hardware-guide/page/meshtastic-app) to assess local network load before and after adding new nodes. If deploying a new repeater in a dense area, monitor whether its addition increases congestion - a new high-visibility, high-priority infrastructure node can increase channel load for every other node in range.