2 Ad-Hoc Multi-Hop Routing
A rescue sensor must send a warning through two battery-powered relays. The team can see all three radio links on a map, but routing also costs time before the first warning moves. Routing that finishes discovery after the warning deadline has missed its application purpose.
2.1 Start Simple
Make the Route Earn Trust One Hop at a Time
Picture rescue sensors placed after a storm where no fixed network remains. One sensor can hear a second, and the second can hear a link point, but a route that worked once may vanish when people move or batteries fade.
A protocol is an agreed set of message and timing rules. A gateway is a device that joins one network to another. Name the source, destination, possible neighbours, message deadline, and safe behaviour when no route exists. Keep route discovery separate from proof that the final reading was accepted.
Start with one path, then move a relay, remove a neighbour, replay an old route, add competing traffic, and restart the gateway. Record when a route is learned, how long it remains valid, which failure removes it, and whether a reply can return. Check that degraded service is visible rather than guessed away.
This small field cannot prove every moving group or radio condition. The deeper sections compare route families, repair rules, stored state, and delay costs so the chosen approach remains bounded by evidence instead of a familiar name.
Start with devices that have to pass useful data before any fixed network is guaranteed. In Ad-Hoc Multi-Hop Routing, the first question is not the protocol name; it is which neighbors, routes, failure signals, and degraded behaviors you would trust in the field.
2.2 Start With a Route That Has to Be Earned
Ad-hoc routing is different from ordinary routing because the path is not a stable fact. Devices move, batteries fade, links appear and disappear, and a route has to be discovered, refreshed, or repaired using evidence from the network itself.
Start with one source, one destination, and no fixed infrastructure. The routing family you choose should explain how the source learns a path, how stale paths are detected, and how much control traffic the field can afford.
2.3 Routing Without Fixed Paths
In an ad-hoc network, a packet may need to cross several peer devices before it reaches the destination or a gateway. That relay behavior extends coverage beyond one radio hop, but it also consumes shared airtime, battery energy, memory, and trust in intermediate nodes.
The first routing decision is not a protocol acronym. It is whether the network benefits more from routes that are already known, routes discovered only when needed, or a mixture of local route knowledge and on-demand discovery for distant destinations.
That choice should be tied to the first failure the application cannot tolerate. A fire-ground status network may value fast local delivery after setup, even if it spends more periodic control traffic. A wildlife tracker may value low idle energy and accept discovery delay. A vehicle warning flow may value freshness so strongly that a stale route is worse than a dropped message.
Multi-hop reach is therefore not "free range extension." Each extra relay can improve coverage while also increasing contention, retry probability, queueing delay, and the number of devices that must be trusted to forward correctly. The routing family is the policy for paying those costs.
A useful overview names the traffic shape before the protocol family: periodic telemetry, burst alarms, command messages, location beacons, or bulk logs. Each shape stresses a different mix of ready routes, discovery delay, repair behavior, and relay duty.
Before routing Without Fixed Paths, inspect Figure to compare "on demand" with "Routes maintained". Their juxtaposition makes choose the routing family by control overhead and first-packet delay: ready tables, on-demand discovery, or a zone-based mix visible.
Read Figure from "on demand" to "Routes maintained". Taken together, "on demand" and "Routes maintained" express choose the routing family by control overhead and first-packet delay: ready tables, on-demand discovery, or a zone-based mix. For routing Without Fixed Paths, the observed relationship between "on demand" and "Routes maintained" is evidence that "on demand" carries into the next decision.
Proactive routing
Nodes maintain route tables before data appears. This reduces first-packet delay, but the control traffic continues even when little application data is moving.
Reactive routing
Nodes discover a route when a packet needs one. This can save idle overhead, but discovery delay and flood traffic appear at the start of a flow.
Hybrid routing
Nodes keep nearby routes ready and discover farther routes on demand. The design trades local responsiveness against zone-maintenance cost.
Use the routing family that matches the evidence: traffic pattern, mobility, node density, energy budget, link stability, memory limits, and the consequence of the first packet being delayed.
2.4 Evidence-Based Routing Family
A routing selection record should describe what the network needs before naming DSDV, DSR, ZRP, or any other implementation. The record is a compact contract: how often nodes talk, how quickly the first packet must move, how much topology changes, how much energy can be spent on control traffic, and who validates route failures in the field.
Make the comparison in operational units, not slogans. For a proactive candidate such as DSDV, record update interval, sequence-number freshness, table size, and control duty cycle. For a reactive candidate such as DSR or AODV, record route-request scope, discovery latency, route-cache or route-error behavior, and retry limits. For a hybrid candidate such as ZRP, record zone radius, intra-zone maintenance cost, and inter-zone discovery delay.
Approval steps
- Write the service requirement: latency, delivery tolerance, traffic cadence, and coverage boundary.
- Record topology evidence: node density, mobility, expected link changes, and gateway placement.
- Compare proactive, reactive, and hybrid behavior against that evidence.
- Pilot the chosen family with route repair, node loss, weak links, and traffic bursts.
- Approve only when the field trace matches the selection record.
Do not approve a routing choice only because a simulator delivered one packet. The field gate should include route setup, repair, stale route handling, and the energy cost paid by relays.
2.5 Control Traffic vs Data Traffic
Every routing family spends control traffic differently. Proactive protocols spend it continuously to keep tables fresh. Reactive protocols spend it when discovery or repair is needed. Hybrid protocols spend it locally all the time and farther away only on demand. The right model counts control packets, retransmissions, overhearing, memory pressure, and route invalidation behavior, not just data-packet delivery.
Proactive designs usually rely on freshness metadata so nodes can reject older routes. DSDV, for example, uses destination sequence numbers to prefer fresh information and avoid loops, but the table-update cadence still consumes airtime and memory. That is a distance-vector style of proactive routing: a node keeps only a next hop and a metric per destination. OLSR takes a link-state style instead: each node builds a wider view of nearby topology from link information relayed by others, then computes its own paths from that view. The mechanism that keeps OLSR affordable is the multipoint relay, or MPR. Each node first learns its two-hop neighborhood by exchanging periodic "hello" packets that carry the sender's own one-hop neighbor list; once a node can see who its neighbors' neighbors are, it greedily picks the smallest set of one-hop neighbors that together cover every two-hop neighbor, and only that MPR set is required to rebroadcast future topology updates. That reduces broadcast overhead compared with every node flooding every update, but it also makes the MPR choice part of the evidence: weak or overloaded relays can save control traffic on paper while concentrating battery, forwarding, and resilience risk in the field. The field question is whether the application benefits enough from ready paths to pay that continuing cost.
Reactive designs move cost to the moment a route is needed. Route requests, route replies, cached source routes, or route errors can keep idle overhead low, but they create delay and bursty control traffic at flow start or repair time. A quiet demo may miss the worst case: many nodes discovering or repairing routes at once after movement, obstruction, or gateway loss.
Hybrid designs add another tuning knob. A zone that is too small behaves like reactive routing for too many destinations; a zone that is too large spends proactive control traffic across links that rarely carry useful data. The zone radius is not a decorative parameter; it is a claim about local traffic patterns and topology stability.
Acceptance testing should therefore capture route lifetime, control bytes per delivered payload byte, duplicate route discoveries, route-error rate, relay energy, and time from link break to application-visible recovery. Those measurements reveal loops, black holes, stale caches, and overworked relays before they become field incidents.
Freshness
Tables can become stale when nodes move, batteries die, or interference changes links. Freshness mechanisms reduce stale routes but add overhead.
Discovery scope
Flooding can find a route without prior knowledge, but broad floods consume airtime and can collide with useful traffic.
Loop and failure handling
Sequence numbers, route errors, cached-path expiry, and repair rules exist because old path information can create loops or black holes.
Worked reasoning pattern
For a static industrial mesh with frequent monitoring traffic, proactive maintenance may be acceptable because the network buys low first-packet latency. For a mobile emergency team with sparse event traffic, reactive discovery may be more defensible because idle overhead matters and topology changes often. For a large mixed deployment, hybrid routing may be useful when local traffic is common but distant traffic is occasional.
The important test is not whether the family name sounds efficient. It is whether measured control traffic, route repair time, relay energy, and delivery behavior match the service requirement under representative field movement and interference.
2.6 Infrastructure-Free Networking
2.6.1 Start Simple
Prove the First Relay Before Trusting the Route
Picture three rescue sensors placed after a storm. The first can hear the second, the second can hear the third, and no fixed network is ready. A map line between them looks useful, but the team needs proof that a warning can cross the line and that a failed relay is noticed.
An access point is a fixed radio that nearby devices normally join. A gateway is the device that carries local traffic into another network. A protocol means the agreed rules devices use to exchange messages. Here, begin before any of those fixed services can be assumed. Name each sensor, its nearest neighbour, and the final receiver.
Send one marked warning. Move the middle sensor, fill its waiting space, repeat the warning, and remove it. Check whether another path appears, whether the receiver sees one clear result, and whether the team is told when no path remains.
This small trial does not prove every radio, route method, or moving site. The deeper sections show how discovery, forwarding cost, changing paths, security, and recovery turn the first relay into a defensible design.
Start with devices that have to pass useful data before any fixed network is guaranteed. In Infrastructure-Free Networking, the first question is not the protocol name; it is which neighbors, routes, failure signals, and degraded behaviors you would trust in the field.
2.6.2 Start With No Infrastructure
An ad-hoc network starts with devices that cannot assume an access point, gateway, or fixed route is waiting for them. They have to discover neighbors, exchange state, and build enough local agreement to move useful data.
That is the field story behind emergency sensors, temporary worksites, mobile robots, and pop-up monitoring. Start with two devices meeting in the field, then decide what they must learn before trusting each other to forward traffic.
2.6.3 Ad-Hoc Without Infrastructure
An ad-hoc network is a wireless network that can form without a pre-installed access point, base station, or fixed router. Nodes discover nearby peers, exchange messages directly when they can, and may forward traffic for other nodes when the destination is out of direct radio range.
The concept is useful in IoT because many field systems cannot assume stable infrastructure at the moment data is produced. Emergency teams may arrive before communications are restored. Sensors may be deployed in remote terrain. Vehicles, robots, or UAVs may move faster than a fixed coverage plan can follow. In those cases, the network has to be treated as a temporary, local, changing system instead of a static service.
The gateway question is separate from the local-formation question. A mesh may eventually hand data to Ethernet, Wi-Fi, LTE, satellite, or a vehicle gateway, but the ad-hoc claim is about what happens before that exit path is reachable: neighbor discovery, relay choice, local buffering, and repair.
Before ad-Hoc Without Infrastructure, inspect Figure to compare "Multi-hop route" with "If one link fails, peers can". Their juxtaposition makes ad-hoc operation removes the fixed access point as the organizing assumption; peer devices must discover, relay, and repair paths themselves visible.
Read Figure from "Multi-hop route" to "If one link fails, peers can". Taken together, "Multi-hop route" and "If one link fails, peers can" express ad-hoc operation removes the fixed access point as the organizing assumption; peer devices must discover, relay, and repair paths themselves. For ad-Hoc Without Infrastructure, the observed relationship between "Multi-hop route" and "If one link fails, peers can" is evidence that "Multi-hop route" carries into the next decision.
No fixed anchor
The network can start from the devices that are present. A gateway may still exist, but the local network is not defined by one permanent access point.
Peer forwarding
A node can be both an endpoint and a relay. That forwarding role is what lets the network reach beyond one radio hop.
Changing paths
Routes may change when nodes move, batteries fail, interference appears, or an operator places a relay in a better location.
Shared wireless cost
Every relay hop consumes airtime, energy, and buffer space. More paths do not automatically mean more usable capacity.
2.6.4 Ad-Hoc Design Before Protocol
A practical ad-hoc design starts with the operating record: who is moving, what must be delivered, what infrastructure cannot be assumed, and what the gateway exit looks like when a gateway is available. Only then should the team choose between proactive, reactive, hybrid, geographic, or delay-tolerant approaches.
The record should be small enough for a design review but specific enough to test. It should separate the local mesh claim from the end-to-end service claim. A packet reaching a nearby relay does not prove that the message reaches the operator, cloud system, or actuator in time.
2.6.5 Discovery, State, Airtime, Repair
Under the hood, an ad-hoc network is a set of local control loops. Nodes discover neighbors, decide which links are usable, maintain or discover paths, forward packets, and repair routes when the topology changes. The exact protocol may differ, but the evidence questions are similar across the family.
Proactive routing keeps path state ready before data arrives, which reduces first-packet delay but spends control traffic even when the application is quiet. Reactive routing discovers a path when data needs one, which can reduce idle overhead but adds discovery delay and can flood the local network. Hybrid and geographic methods try to contain that overhead by limiting what must be maintained or discovered. Delay-tolerant designs go further: they accept that no continuous path may exist and use store-carry-forward behavior instead.
Stale state is the common failure mode behind many confusing field bugs. A node can keep forwarding into a route that no longer exists, retry a neighbor that is asleep, or deliver a message after its decision window has expired. Repair policy therefore needs timers, sequence or freshness evidence, and an application rule for when to stop retrying.
Discovery
Nodes learn which peers are reachable now. Link quality, movement, interference, and duty cycling all affect whether a neighbor is useful.
Path state
The protocol either maintains paths ahead of time, discovers them on demand, limits state to a zone, uses location hints, or stores data until contact.
Forwarding cost
Each hop shares the same wireless medium, consumes energy, and can add loss or delay. Shorter radio hops are not free if they create too many relays.
Repair
When a link breaks, the system must detect the break, avoid stale paths, and either reroute, buffer, retry, or declare the message undeliverable.
For IoT, the hardest part is often not route discovery itself. It is proving that the chosen repair behavior fits the application. A wildlife tracker can tolerate long delay if eventual delivery is enough. A safety alert, actuator command, or operator alarm may need a different architecture because stale delivery can be worse than no delivery.
2.6.6 Summary
Ad-hoc networking is a design choice for local communication when fixed infrastructure cannot be assumed. It lets nodes form peer relationships, relay traffic, and adapt to movement or failure, but it also shifts responsibility to the device mix, routing protocol, forwarding load, gateway exit, and repair behavior. A defensible IoT design records those facts before it claims that an ad-hoc approach is appropriate.
2.6.7 Key Takeaway
Ad-hoc networks are valuable when local formation and peer forwarding fit the operating problem, but they are proven by evidence of discovery, relay cost, route repair, gateway handoff, and degraded behavior, not by the wireless label alone.
2.6.8 See Also
2.7 Spend the Warning Deadline on Discovery and Forwarding
Assume a reactive routing trial spends 180 ms finding the path. Each of its three hops then takes 20 ms for the tested exchange, including the measured access and forwarding delay. The first warning needs 180 ms + 3 × 20 ms = 240 ms. Against an illustrative 200 ms deadline, it arrives 40 ms late. These are measured-style test inputs, not fixed timing properties of a named protocol.
A proactive routing choice might already hold the path. Under the same hop assumptions, forwarding takes 60 ms and fits the deadline. Proactive routing pays its preparation cost by refreshing information even when no warning is being sent. If the relays move often, maintenance traffic can consume airtime without guaranteeing that the stored path still works at the next alarm.
Now remove the middle relay after discovery. The routing layer must detect the broken next hop and either repair the route or expose failure. A source that keeps placing warnings on a stale path can show a growing queue while the destination sees silence. Count route-control transmissions as well as useful data during the recovery test; the repair flood may be the largest load in a quiet network.
Predict whether a fourth hop always improves reach. Without fixed infrastructure, another hop may bridge a gap but adds a forwarding stage and a relay dependency. With the same 20 ms assumption, a ready four-hop path needs 80 ms before any further losses. Next, ask whether a received neighbour beacon proves that an application reply can return. Neighbour discovery does not prove reverse routing or the receiving service’s acceptance.
This connects infrastructure-free networking to its operational tradeoff. Proactive, reactive and hybrid routing place the discovery cost at different times and places. Routing selection needs the warning cadence, movement and relay energy of this field, including the missing-route state. A routing failure reported clearly lets the rescue team use a fallback instead of trusting an unexplained success icon.
2.8 Summary
- Multi-hop routing extends range by forwarding through peers, but every relay hop consumes airtime, energy, buffer space, and operational trust.
- Proactive routing keeps routes ready and can reduce first-packet delay, at the cost of continuing control traffic.
- Reactive routing discovers paths on demand and can reduce idle overhead, at the cost of discovery delay and repair floods.
- Hybrid routing keeps local routes ready and discovers farther routes when needed, but zone maintenance is still a real cost.
- A defensible selection record includes traffic pattern, mobility, relay energy, route repair, and field validation evidence.
2.9 Key Takeaway
Choose ad-hoc routing from the service evidence. The best protocol family is the one whose control overhead, repair behavior, latency, and relay energy match the field requirement, not the one that wins a quiet single-packet demo.
2.10 See Also
Infrastructure-free operation, peer forwarding, and topology change.
Route-table maintenance and proactive trade-offs.
DSR Fundamentals and Route Discovery
On-demand discovery, cached paths, and repair behavior.
Local zones and inter-zone discovery.