Distance measured in hops
In a mesh, distance is not counted in metres. It is counted in hops: the number of times a message is passed from one device to the next before it arrives. A message to a neighbour in direct radio range takes one hop. A message that two other devices relay on the way takes three.
A hop limit puts a ceiling on that number. The sender writes a starting value into the message, each relay lowers it by one before forwarding, and a relay that would take it to zero does not forward it. IPv6 works this way: RFC 8200 defines an 8-bit Hop Limit that each forwarding node decrements by 1, and a packet is discarded if the field reaches zero. The same RFC adds a detail that matters for meshes: a node that is the packet’s destination should still process a packet whose Hop Limit is zero. The limit stops forwarding, not delivery.
Some protocols count the other way. RFC 5444, the common message format for mesh routing protocols, defines both a hop limit, set by the originator and lowered at each hop, and a hop count, which starts at 0 and rises at each hop. It says both exist to stop messages “endlessly circulating” in the network.
“TTL” is also used for a time limit on how long a message is worth keeping. That is a different control; What is a message TTL? covers expiry times and the history of the name. This article is about the hop count.
Why a mesh needs one
On the internet, routers mostly forward along routes computed in advance, so a packet caught in a loop is a sign that something has gone wrong. In a mesh, every device can relay, links appear and vanish as devices move, and many meshes deliberately broadcast. That makes three problems normal rather than rare.
Loops
When routes change faster than every device learns about them, a message can be passed round a cycle of devices. RFC 2501, the IETF’s statement of mobile ad hoc networking considerations, describes this as packets “spinning around in the network for arbitrary time periods” and says TTL values can bound the problem. A hop limit does not prevent the loop, it guarantees the loop ends.
Storms
In flooding, every device that hears a message for the first time rebroadcasts it. Each extra hop of reach can pull in more devices, and each of them transmits. The OLSR routing protocol (RFC 3626) states the purpose plainly: by setting the TTL, the originator of a message can “limit the flooding radius”. Without that cap, one message would be sent by every device in the network. Duplicate detection does the other half of the job, by making each device forward a given message once; see how mesh networks avoid duplicate messages.
Airtime and battery
Every hop is a radio transmission that occupies a shared channel and spends energy on a device that may be running on battery. Bluetooth Mesh documentation says setting the TTL lets nodes “conserve energy, by ensuring messages are not relayed further than is required”. A message that only needs to reach the next room should not be relayed across the whole building.
Small values do useful jobs
A hop limit is also a way to say who a message is for.
- Neighbours only. In Bluetooth Mesh, a TTL of zero means the message has not been relayed and should not be, so it reaches only devices in direct radio range. AODV (RFC 3561) sends its Hello messages, which announce a device to its neighbours, with a TTL of 1.
- Searching outward. AODV uses an expanding ring search to find a route without flooding the whole network at once. The first route request goes out with a small TTL, and each time it fails, the sender tries again with a larger one. The RFC’s default values start at 1, add 2 each time up to a threshold of 7, and then use the full network diameter, which it sets at 35 hops by default.
- Learning the right value. Bluetooth Mesh heartbeat messages carry the TTL they started with, so a receiver can work out how many hops away the sender is and address later messages with a TTL “no higher than it needs to be”.
Choosing a hop limit
The right value comes from the shape of the network, not from a wish to reach as far as possible.
- Start from the longest useful path. Estimate how many relays a message must cross between the devices that need to talk, then allow a little slack for detours when a direct path breaks.
- Count the cost of slack. In a flooded mesh, extra hops let a message reach more devices that do not need it. In a routed mesh, a higher limit mostly matters when something has gone wrong, which is when you want it to stop early.
- Use different limits for different traffic. Discovery and presence messages often need one hop. Messages to a specific device need enough to reach it. Network-wide announcements need the full diameter.
- Watch the hop counts you actually see. If messages routinely arrive with almost no hops left, the limit is too tight for the network as deployed.
As one example, the Offline Protocol mesh SDK documents an initial TTL of 8 hops by default for messages crossing its mesh in v0.27.0, and the value can be configured.