What movement changes
In a fixed mesh, links between devices are mostly stable and routes, once found, stay good. When devices move, that stops being true. RFC 2501, the IETF’s description of mobile ad hoc networks, puts it plainly: nodes are free to move arbitrarily, so the topology “may change randomly and rapidly at unpredictable times”.
Three things go wrong as a result.
- Neighbour lists go stale. A device that was in range a minute ago may not be now, and a new one may have arrived.
- Routes break in the middle. A route through three relays fails if any one of them walks away.
- Links become lopsided. RFC 2501 notes that a mobile network may contain unidirectional links as well as bidirectional ones. As distance grows, one device may still hear the other while its own replies no longer get through.
A mesh has to keep learning, and it has to decide how hard to work at it. The general mechanics of detecting a break and rerouting are covered in What is a self-healing network?. Movement adds some problems of its own.
Noticing a neighbour has gone
Mesh protocols can detect movement through regular announcements. The MANET Neighborhood Discovery Protocol (RFC 6130) uses HELLO messages so each router can track its 1-hop and symmetric 2-hop neighbours, and is designed to keep that information current “in the presence of a dynamic network topology”. AODV (RFC 3561) lets a device that stops hearing anything from a neighbour for a set number of hello intervals assume the link is lost.
The word symmetric matters. Because links can work in one direction only, NHDP distinguishes a link that has merely been heard from a symmetric one, where each side hears the other. B.A.T.M.A.N. makes a similar check: a node waits to hear its own announcements rebroadcast by a neighbour, and ignores the link if they do not come back.
Not reacting to every flicker
A device at the edge of radio range is a problem of its own. Its signal comes and goes, and a mesh that adds and drops it every few seconds would keep rebuilding routes and telling everyone about each change. That is called flapping.
NHDP’s answer is hysteresis. A link must reach one quality threshold before it is accepted, and must fall below a lower threshold before it is declared lost. Between the two, it keeps whatever status it last had. The RFC says that with suitable values this “prevents overly rapid changes of link status”. The cost is that a genuinely failing link is noticed a little later.
How often to update
Every mesh that keeps routes ready has to choose how often devices announce themselves. More often means the network sees a move sooner; less often means less airtime and battery spent on control traffic.
The batman-adv documentation makes the choice explicit. Its originator interval sets how often each node broadcasts its announcement, and “in very mobile scenarios” the documentation suggests lowering it, which makes the mesh more responsive to topology changes “but will also increase the overhead”.
On-demand protocols take a different path. AODV does not track routes nobody is using. When a link on an active route breaks, the device just upstream of the break may try a local repair: it searches for the destination with a limited hop count, buffering data packets meanwhile, so a short detour can be found without involving the original sender. If that fails, it sends a route error back towards the devices using the route.
When the destination moves
A moving destination is a different problem from a moving relay, because every route to it can go stale at once. Messages already in flight are still heading to its old position.
The batman-adv project documents one solution for client devices that roam between mesh nodes. When a client appears at a new node, that node sends a roaming advertisement straight to the node that served it before. The old node then redirects any packets that still arrive for the client to its new location, until the whole mesh has caught up. For a while, traffic takes a slightly longer path through the old node; the point is to avoid losing packets that were already on their way.
When movement is the path
Sometimes no route exists at all. Two groups of devices may be completely out of range of each other. A fixed network would simply fail. A mobile one has another option: wait for movement to connect them.
RFC 4838, the delay-tolerant networking architecture, calls these opportunistic contacts. Its example is a handheld device and an airport kiosk that can talk over an infrared or Bluetooth link only while the device is carried near the kiosk. Networks built for this use store-and-forward: a device keeps a message in storage and passes it on when a suitable device comes into range. A phone carried from one group to the other can bring messages with it, which is called data muling.
Designing for devices that move
- Expect routes to be temporary. Keep retries and a bounded outbox, so a message survives a route that breaks halfway.
- Make repeats harmless. A message retried over a new path may arrive twice, so operations should be idempotent.
- Tune timers to real movement. People walking and vehicles driving need different announcement rates and loss thresholds.
- Test with people moving. A mesh that works on a desk can behave very differently when the devices are carried around.