Each device gets less airtime
For each device, usually yes. A wireless mesh shares a limited resource, airtime, among every device within range of each other, and a mesh spends part of that airtime relaying other devices’ traffic. As more devices join and send messages further, each device’s share of the channel gets smaller.
That is not the same as saying the mesh gets worse at everything. More devices can fill coverage gaps and add alternative paths. But the speed each device sees, and how quickly a message crosses the whole network, tend to fall as the mesh grows busier.
Why shared airtime is the limit
On a wire, each link has its own capacity. In radio, nearby transmissions interfere, so devices within range of each other take turns. A device that relays for others uses its turns on their traffic as well as its own.
The classic analysis is “The Capacity of Wireless Networks” by P. Gupta and P. R. Kumar, published in IEEE Transactions on Information Theory in 2000. Their abstract shows that, for identical randomly placed nodes, the throughput each node can get to a randomly chosen destination falls as the number of nodes grows, and that even under optimal placement the throughput furnished to each user diminishes to zero as users are added. The network’s total carrying capacity, measured as bits moved times distance, still grows with more nodes, but more slowly than the number of nodes.
They name the cause: every node has to share whatever portion of the channel it uses with the nodes in its local neighbourhood. Splitting the channel into several subchannels does not change the results.
Where the time goes on each hop
RFC 2501, the IETF’s document on mobile ad hoc networks, describes wireless links as bandwidth-constrained and variable, with realised throughput often much lower than the radio’s maximum rate once multiple access, fading, noise and interference are counted. It adds that congestion is typically the norm rather than the exception.
On top of that, the network’s own housekeeping takes airtime. RFC 2501 points out that if control and data traffic share the same limited channel, excessive control traffic often hurts data delivery. Route discovery, neighbour announcements and acknowledgments all grow with the size and activity of the mesh.
Then each extra hop adds its own wait for the channel, its own transmission, and another chance of loss, which is why a message crossing a mesh over many hops arrives later than one crossing a single link.
Flooding makes it worse, so protocols limit it
The simplest way to spread a message is flooding: every node rebroadcasts what it hears. In a small mesh that is fine. In a dense one, a single message can trigger a rebroadcast from every device in range, and those copies compete with real traffic. Protocols cut this down in different ways.
- Fewer relays. OLSRv2 (RFC 7181) has each router choose multipoint relays that cover its two-hop neighbourhood, so a flooded message is relayed by only a reduced subset of routers, reducing the number of transmissions.
- Relay roles. The Bluetooth SIG’s mesh FAQ says its managed flood uses only mains-powered nodes as relays, while low-power nodes do not relay.
- Targeted addressing. The same FAQ says publish and subscribe group addressing lowers messaging traffic on the network.
- Dropping copies. Nodes remember message identifiers and discard repeats, so each node relays a given message only once. How mesh networks avoid duplicate messages covers how.
What keeps a growing mesh responsive
The Gupta and Kumar abstract ends with a design hint: networks connecting smaller numbers of users, or featuring connections mostly with nearby neighbours, may be more likely to find acceptance. In practice that points to a few habits.
- Keep traffic local. Messages between nearby devices use few hops and little shared airtime.
- Bound the hops. A hop limit stops any one message from spreading across the whole network.
- Cap relaying. Limit how much traffic each device will forward, so one busy sender cannot fill everyone’s airtime. Offline Protocol’s mesh SDK v0.27.0, for example, admits relayed messages by default at 10 per second with a burst of 30, and 5 per second with a burst of 15 for each peer. Its docs describe these as defaults and bounds, not throughput guarantees.
- Send less. Smaller messages, batching and fewer control messages leave more airtime for data.
- Measure on real hardware. Delivery time and loss under your real workload, as devices are added, tell you more than any rule of thumb.
What it does not mean
A slower mesh per device is not a broken one. For many uses, such as short text messages, status updates, or small records that move between nearby devices, a modest share of airtime is enough. The point is to plan for it: expect each device’s share to shrink as the mesh grows, design traffic to stay local, and treat how big a mesh can get as a question about traffic as much as about device count.