“Big” can mean three things
When people ask how big a mesh can get, they usually mean one of three limits:
- How many devices can join the same network.
- How far a message can travel, measured in hops.
- How much traffic the network can carry before it slows down.
These limits come from different places. The first is usually written into a standard. The second is set by the hop limit each message carries. The third comes from the physics of shared radio channels.
Limits written into standards
Some mesh standards publish hard numbers.
- Thread. The OpenThread primer lists the device limits for a single Thread network: 1 Leader, 32 Mesh Extenders, and 511 End Devices per Mesh Extender. Thread also tries to keep the number of Mesh Extenders between 16 and 23, adding or removing them as the network changes.
- Bluetooth Mesh. The Bluetooth SIG’s mesh FAQ says the specification allows up to 32,000 nodes to be provisioned, and adds that it does not expect those numbers to be reached quickly in the real world.
These are ceilings, not promises. A standard’s address space tells you how many devices it can name, not how many can share the air while doing useful work.
For mobile ad hoc networks the IETF never set one number. RFC 2501, written as the IETF’s MANET work began, expected some networks to be relatively large, such as tens or hundreds of nodes per routing area, and noted that the mechanisms needed for scalability in such networks were likely to be different from those on the wired internet.
The limit physics sets
In 2000, P. Gupta and P. R. Kumar published “The Capacity of Wireless Networks” in IEEE Transactions on Information Theory. Their abstract shows that when identical, randomly placed nodes share a wireless channel, the throughput each node can get to a randomly chosen destination shrinks as the number of nodes grows. Even with nodes, traffic and ranges placed optimally, the throughput each user gets still falls toward zero as users are added.
The reason they give is that 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 result. They suggest that networks connecting fewer users, or where most connections are with nearby neighbours, may be more likely to find acceptance.
So for a large mesh, how much traffic crosses it, and how far, matters as much as how many devices join. A mesh where each device mostly talks to devices a few hops away can grow larger before it slows down than one where every device talks to every other across the whole network.
Hops limit how far a message goes
Every mesh needs a way to stop messages from circulating forever, and most use a hop limit, also called a TTL. Each relay lowers it by one and drops the message when it runs out. That makes the hop limit a bound on how far any single message can reach, however many devices are in the network.
Implementations choose their own defaults. In Offline Protocol’s mesh SDK v0.27.0, for example, messages start with a TTL of 8 hops and groups hold up to 256 members by default, and the docs say range and capacity depend on the radios, the environment and the workload.
How protocols stretch the limits
Protocols that aim for larger meshes all try to cut the number of transmissions per message.
- Fewer relays. OLSRv2 (RFC 7181) uses MPR flooding, in which a message is relayed by only a reduced subset of the routers in the network instead of all of them.
- Roles. Thread lets End Devices rely on a single Mesh Extender instead of forwarding for others, and Bluetooth Mesh relays only through mains-powered nodes.
- Group addressing. The Bluetooth SIG says its publish and subscribe addressing lowers messaging traffic on the network, which helps it scale.
- Structure. Splitting a large network into areas, or reducing it to a partial mesh with a few well-chosen relays, keeps each device’s share of the work bounded.
Sizing a real deployment
No formula gives you a safe size for your own mesh. RFC 2501 lists what to vary when testing: the number of nodes, how many neighbours each has, how fast the topology changes, effective link speed, traffic patterns and how often nodes sleep. Test with your real devices and your real traffic, and watch how delivery time and loss change as you add devices. When they start to climb, more devices will not help; less traffic per device, or shorter routes, will. The next question is whether the mesh gets slower as it grows, and why.