18  Ad-Hoc Production Readiness

emerging-paradigms
adhoc
prod

18.1 Start Simple

Start with devices that have to pass useful data before any fixed network is guaranteed. In Ad-Hoc Production Readiness, the first question is not the protocol name; it is which neighbors, routes, failure signals, and degraded behaviors you would trust in the field.

18.2 Start With the Readiness Question

A production-readiness assessment asks a blunt question: would this ad-hoc system still serve users when the field behaves badly? Mobility, interference, battery limits, node loss, and operator mistakes all count as normal conditions.

Start with one scenario the system claims to survive. The assessment then becomes a chain of evidence: what must be measured, what threshold is acceptable, and what action follows when the evidence fails.

Phoebe the physics guide

Phoebe’s Why

The quiz answer below is right that “required transmit power grows quickly with distance,” but there are actually two different energy stories hiding under “multi-hop is efficient,” and this chapter’s own numbers show both. One story is physical: splitting one long link into several short ones lets each hop spend far less power, because path loss grows with a power of distance, not linearly. The other story is architectural: every hop – however short – still pays a nearly fixed cost to wake a radio, arbitrate the channel, and receive a frame, so adding hops for their own sake is not free. The gas-leak alert scenario’s 4.0 mJ six-hop path costing more than the 1.9 mJ three-hop path is the architectural story dominating; the free-space inverse-square law is the physical story underneath it.

The Derivation

Spherical spreading makes received power fall with distance to a power \(n\) (the log-distance exponent, \(n=2\) in free space), so holding link margin fixed needs:

\[P_r \propto \frac{1}{d^n} \quad\Rightarrow\quad P_t \propto d^n\]

Doubling distance at fixed margin therefore costs:

\[\frac{P_t(2d)}{P_t(d)} = 2^n\]

Splitting one hop of distance \(D\) into \(N\) equal hops of length \(D/N\) changes total transmit energy from \(\propto D^n\) to \(\propto N(D/N)^n = D^n/N^{n-1}\):

\[\frac{E_{N\text{ hops}}}{E_{1\text{ hop}}} = \frac{1}{N^{n-1}}\]

Worked Numbers: Two Different Multi-Hop Stories

  • Free-space doubling (\(n=2\)): \(2^2=4\times\) power for double the distance – exactly the quiz’s claim.
  • With obstruction (\(n=3\), catalog-typical indoor/industrial): doubling costs \(2^3=8\times\).
  • Splitting one long hop into 3 equal hops of the same total span: \(n=2\) gives \(1/3^{1}=0.333\), i.e. \(3.00\times\) less transmit energy; \(n=3\) gives \(1/3^{2}=0.111\), i.e. \(9.00\times\) less – this is the physics behind “multi-hop is efficient,” and it assumes power scales down with each shorter hop.
  • This chapter’s own 6-hop-vs-3-hop alert path does not show that pattern: \(6\times0.5\text{ mJ}+5\times0.2\text{ mJ}=4.0\) mJ versus \(3\times0.5\text{ mJ}+2\times0.2\text{ mJ}=1.9\) mJ – fewer hops cost less energy here, the opposite of the pure distance-splitting result.
  • The reason is the flat 0.5 mJ/hop figure: it is a fixed per-transmission cost (radio wake, preamble, channel access, ACK), not a distance-scaled one. Real relays rarely retune transmit power to each hop’s actual length, so the fixed-overhead effect (favoring fewer hops) and the path-loss effect (favoring shorter hops) can point opposite ways – exactly why “multi-hop is more efficient” needs a measured per-hop energy number, not just a hop count, before it is a production claim.
In 60 Seconds

Routing protocol selection depends on measured traffic patterns, mobility, link quality, energy state, and recovery requirements. Proactive approaches fit frequent traffic when route tables can be maintained, reactive approaches fit sparse traffic when discovery delay is acceptable, and hybrid approaches fit mixed patterns. Multi-path and energy-aware routing are production claims only after recovery time, delivery loss, relay battery impact, and retest triggers are measured for the deployment.

Minimum Viable Understanding
  • Routing protocol choice depends on traffic patterns: proactive (DSDV/OLSR) for frequent traffic, reactive (AODV/DSR) for sparse traffic, hybrid (ZRP) for mixed patterns.
  • Multi-path redundancy can reduce outage duration when backup paths are prevalidated and the failover trigger is measured.
  • Energy-aware routing can extend network lifetime when relay load and battery state are measured instead of assuming the shortest path is always best.

Without multi-path: link failure detection (100ms ACK timeout) + route discovery (8s for 4-hop RREQ/RREP) = 8.1 seconds outage. With pre-cached backup: failure detection (100ms) + cache lookup (5ms) + first packet on backup (62ms for 4-hop path) = 167ms recovery. The improvement factor is \(\frac{8100ms}{167ms} \approx 48\times\) faster. Worked example: For vineyard sensors transmitting every 300s, single-path loses \(\frac{8.1s}{300s} = 2.7\%\) of packets during each failure. Multi-path loses \(\frac{0.167s}{300s} = 0.056\%\), about 48 times less data loss.

Sammy the Sensor needed to send an urgent temperature reading to the Gateway across the farm, but the direct path was blocked by a tractor!

“No worries!” said Max the Microcontroller. “We have THREE different paths planned ahead of time. Think of it like knowing three different ways to get to school – if one road is blocked, you just take another!”

Bella the Battery added, “But not all paths are equal! I prefer the one where my friends along the way have plenty of energy left. If we always use the same shortcut, those friends get tired really fast.”

Lila the LED blinked to explain: “Imagine passing a note in class. The shortest row might be fastest, but if those kids pass EVERY note, they get tired of it. Spreading notes across different rows keeps everyone happy and willing to help!”

The lesson: Smart networks plan backup routes BEFORE problems happen, and they share the work so no single helper gets worn out!

18.3 Learning Objectives

By the end of this chapter, you will be able to:

  • Apply Routing Knowledge: Select appropriate routing strategies for different deployment scenarios
  • Analyze Network Trade-offs: Evaluate energy vs latency vs reliability trade-offs
  • Solve Production Problems: Work through real-world multi-hop network challenges
  • Diagnose Network Issues: Identify bottlenecks, link failures, and routing inefficiencies
  • Compare Protocol Behavior: Distinguish between proactive, reactive, and hybrid approaches
  • Design Failover Strategies: Implement multi-path redundancy for reliable delivery

18.4 Prerequisites

Required Chapters:

Estimated Time: 30 minutes

This chapter tests your understanding of ad-hoc network concepts through quizzes, worked examples, and scenario-based exercises. If you are new to the topic:

  • Start with the protocol comparison table at the top to review the three routing approaches (proactive, reactive, hybrid).
  • Read the worked examples carefully – they walk through real calculations step by step with numbers you can follow.
  • Try the understanding checks by thinking about the scenarios BEFORE reading the answers. Even if you get them wrong, the explanations will deepen your learning.
  • If any concept is unfamiliar, revisit the Ad-Hoc Network Basics or Multi-hop Fundamentals chapters first.

18.5 Introduction

This chapter consolidates your understanding of production ad-hoc networks through comprehensive knowledge checks, worked examples, and understanding exercises. The assessments cover routing protocol selection, energy-aware design, link quality management, and multi-path failover strategies.

Chapter Roadmap
  • First review protocol families and link-quality thresholds.
  • Then test the basics with quick checks.
  • Next apply the same logic to failover, alert routing, range, social routing, caching, energy, and mobility.
  • After that pressure-test the shortest-path misconception.
  • Finally turn quiz answers into a release record with retest triggers.

Checkpoints recap; collapsed depth-l1 and depth-l2 sections are optional slowdowns.

18.6 Ad-Hoc Routing Protocol Comparison

Understanding the trade-offs between routing protocol types is essential for production deployments.

Ad-hoc Routing Protocol Comparison

  • Proactive: DSDV and OLSR
    • Maintains routes continuously with periodic updates.
    • Uses higher control overhead to keep route latency low.
    • Best for frequent, predictable traffic where routes are needed often.
  • Reactive: AODV and DSR
    • Discovers routes only when traffic needs a path.
    • Keeps idle overhead low but adds route-discovery delay.
    • Best for sparse or occasional traffic.
  • Hybrid: ZRP
    • Maintains proactive routes inside a local zone and discovers distant routes reactively.
    • Balances overhead and latency through the configured zone radius.
    • Best for mixed traffic patterns.
Ad-hoc routing protocol comparison flowchart showing three parallel approaches with trade-off analysis: Proactive protocols (DSDV, OLSR) initialize route tables then maintain all routes continuously through periodic updates enabling immediate data transmission with low latency but high overhead, Reactive protocols (AODV, DSR) stay idle until data needed then flood RREQ/RREP messages for on-demand route discovery providing low overhead but high latency with route expiration requiring rediscovery, and Hybrid ZRP using proactive intra-zone routing for fast local traffic and reactive inter-zone routing for efficient remote traffic achieving balanced medium latency and medium overhead
Figure 18.1: Ad-hoc routing protocol comparison showing three approaches: Proactive protocols (DSDV, OLSR) initialize route tables and maintain all routes continuously with periodic updates providing low latency but high overhead, Reactive protocols (AODV, DSR) stay idle until data needed then flood RREQ/RREP messages for on-demand discovery providing low overhead but high latency, Hybrid ZRP uses proactive intra-zone routing for local traffic and reactive inter-zone routing for remote traffic achieving balanced medium latency and medium overhead

Protocol Selection Guidelines:

  • Connected, static, frequent traffic -> DSDV
  • Connected, mobile, sparse traffic -> DSR
  • Connected, mixed traffic -> ZRP
  • Disconnected, abundant resources -> Epidemic
  • Disconnected, constrained resources, predictable -> CAR

18.7 Link Quality Classification

Understanding how to classify and respond to link quality changes is critical for maintaining network reliability.

Link quality classification decision tree showing hierarchical assessment process starting with Link Quality Assessment node branching through PDR thresholds (>=90%, >=70%, >=50%) and RSSI levels (>-70dBm, >-80dBm, >-90dBm) to classify links into four tiers: EXCELLENT (90-100% PDR, >-70dBm RSSI, <20ms latency) for best quality links, GOOD (70-90% PDR, -70 to -80dBm RSSI, 20-50ms latency) for reliable links, FAIR (50-70% PDR, -80 to -90dBm RSSI, 50-100ms latency) for marginal links, and POOR (<50% PDR, <-90dBm RSSI, >100ms latency) for unreliable links requiring avoidance or replacement
Figure 18.2: Link quality classification decision tree showing four-tier assessment: First check PDR thresholds (90%, 70%, 50%), then verify RSSI levels (-70dBm, -80dBm, -90dBm) to classify links as EXCELLENT (>90% PDR, >-70dBm RSSI, <20ms latency), GOOD (70-90% PDR, -70 to -80dBm, 20-50ms), FAIR (50-70% PDR, -80 to -90dBm, 50-100ms), or POOR (<50% PDR, <-90dBm, >100ms latency)

18.8 Inline Knowledge Check

18.9 Routing Strategy Comparison

Different routing strategies optimize for different objectives. Understanding when to apply each is essential for production deployments.

Trade-offs Summary:

  • Control overhead: proactive is high, reactive is low, and hybrid is medium because the zone radius controls how much state is maintained.
  • Route latency: proactive is low because routes are ready, reactive is high because discovery happens on demand, and hybrid is configurable.
  • Scalability: proactive scales poorly in large or fast-changing networks; reactive and hybrid approaches scale better.
  • Mobility support: proactive handles moderate mobility, while reactive and hybrid approaches usually adapt better to changing links.
Blueprint BinaCheckpoint: Protocol Fit and Link Evidence

You now know:

  • Proactive, reactive, and hybrid routing differ mainly in control overhead, route latency, and how much route state they keep ready.
  • A GOOD link is not a guess: the example classifies 82% PDR, -74 dBm RSSI, and 35ms latency against the 70-90% PDR, -70 to -80 dBm, and 20-50ms bands.
  • A route choice is ready for production discussion only after traffic pattern, mobility, link quality, energy state, and recovery requirement are connected.

18.10 Knowledge Check

Auto-Gradable Quick Check

18.11 Worked Examples

Multi-Path Link Failure Recovery

Scenario: A smart agriculture deployment monitors 40 hectares of vineyard with soil moisture sensors. The gateway receives data from sensors via multi-hop ad-hoc network. During harvest season, vineyard workers and machinery frequently block wireless paths, causing link failures.

Given:

  • Primary path: Sensor S1 -> Node A -> Node B -> Gateway (3 hops, latency 45ms)
  • Backup path 1: S1 -> Node C -> Node D -> Node E -> Gateway (4 hops, latency 62ms)
  • Backup path 2: S1 -> Node F -> Node G -> Gateway (3 hops, latency 58ms, but G has 35% battery)
  • Link A-B failure rate during harvest: 15 failures/day, average recovery time: 8 seconds
  • Data transmission frequency: every 5 minutes (288 transmissions/day)
  • Maximum acceptable packet loss: 2%

Steps:

  1. Calculate expected failures during transmission windows:
    • Transmissions per day: 288
    • Link failures per day: 15
    • Probability of failure during any transmission: 15 x 8s / (24 x 3600s) = 0.14%
    • However, failures cluster during work hours (8am-6pm): 15 failures in 10 hours
    • During work hours: 15 x 8s / (10 x 3600s) = 0.33% per transmission
  2. Evaluate single-path (no backup) packet loss:
    • Each failure blocks 8 seconds of communication
    • Transmissions during failure window: 8s / 300s x 120 (work-hour transmissions) = 3.2 blocked
    • Total blocked: 15 failures x 3.2 = 48 packets/day
    • Packet loss rate: 48/288 = 16.7% (exceeds 2% threshold)
  3. Design multi-path failover strategy:
    • Detect failure: Link-layer ACK timeout (100ms)
    • Switch to backup: Immediate failover to pre-cached alternate path
    • Path selection priority:
      • Backup path 2 (F->G) rejected: G at 35% battery (below 40% threshold)
      • Backup path 1 (C->D->E) selected: All nodes >60% battery
  4. Calculate multi-path recovery time:
    • Failure detection: 100ms (ACK timeout)
    • Path switch: 5ms (cache lookup)
    • First packet on backup: 62ms (backup path latency)
    • Total recovery: 167ms (vs 8 seconds without backup)
  5. Calculate improved packet loss:
    • Packets lost during 167ms recovery: 167ms / 300s = 0.06%
    • Total failures: 15 x 0.06% = 0.9%
    • Final packet loss: <1% (meets 2% threshold)

Result: Implementing multi-path routing with automatic failover reduces packet loss from 16.7% to <1%, meeting the 2% reliability requirement. The energy-aware path selection preserves Node G’s battery for future backup duty.

Key Insight: Multi-path routing transforms link failures from minutes-long outages into sub-second blips. The key is pre-computing and caching backup paths, not discovering them after failure. Path selection should consider both latency and node energy to maintain backup availability throughout deployment lifetime.

Hop Counts for Critical Alerts

Scenario: An industrial safety monitoring system detects gas leaks and must deliver alerts to the control room within 500ms. The default energy-aware routing uses 6-hop paths to preserve battery, but this may violate latency requirements.

Given:

  • Network topology: 25 nodes monitoring a chemical plant
  • Control room gateway: Central location
  • Current routing metric: Energy-aware (minimizes battery drain)
  • Current path: Sensor -> 6 hops -> Gateway (typical latency: 420ms)
  • Alternative path: Sensor -> 3 hops -> Gateway (latency: 180ms)
  • Per-hop latency: ~60ms (transmission + propagation + processing)
  • Energy cost per hop: ~0.5mJ transmission, ~0.2mJ reception
  • Alert frequency: 2-3 per month (rare)
  • Normal telemetry: every 60 seconds

Steps:

  1. Analyze latency breakdown for 6-hop path:
    • Per-hop delay: 60ms average
    • 6 hops x 60ms = 360ms transmission
    • Queueing delays at intermediate nodes: ~60ms
    • Total: ~420ms (within 500ms budget, but minimal margin)
  2. Calculate worst-case latency scenarios:
    • Network congestion (2 packets queued): +120ms
    • Retransmission (1 lost packet): +80ms
    • Worst case: 420 + 120 + 80 = 620ms (exceeds 500ms!)
  3. Design priority-based hop optimization:
    • Normal telemetry: Continue using 6-hop energy-efficient path
    • Critical alerts: Switch to 3-hop minimum-latency path
    • Path selection trigger: Alert priority flag in packet header
  4. Calculate optimized alert latency:
    • 3 hops x 60ms = 180ms baseline
    • Worst case with congestion/retry: 180 + 120 + 80 = 380ms
    • Guaranteed <500ms even under adverse conditions
  5. Evaluate energy trade-off:
    • 6-hop energy: 6 x 0.5mJ + 5 x 0.2mJ = 4.0mJ per packet
    • 3-hop energy: 3 x 0.5mJ + 2 x 0.2mJ = 1.9mJ per packet
    • Surprisingly, 3-hop path uses 52% less energy!
  6. Calculate annual impact:
    • Alerts: 30/year x 1.9mJ = 57mJ (negligible)
    • Telemetry on 6-hop: 525,600 packets x 4.0mJ = 2,102,400mJ
    • Telemetry on 3-hop: 525,600 x 1.9mJ = 998,640mJ
    • 3-hop saves 1,103,760mJ (52.5%) annually

Result: Switching critical alerts to the 3-hop path reduces worst-case latency from 620ms to 380ms, guaranteeing compliance with the 500ms requirement. Unexpectedly, the 3-hop path also uses 52% less energy per packet than the 6-hop “energy-optimized” path.

Key Insight: “Energy-aware” routing doesn’t always mean more hops. Longer paths consume more cumulative energy (more transmissions + receptions) even if each link is energy-efficient. For rare critical alerts, always use minimum-hop paths - they’re both faster AND more energy-efficient. Reserve complex routing optimizations for bulk data transfer where the overhead is amortized.

Blueprint BinaCheckpoint: Worked Failover Claims

You now know:

  • In the vineyard example, single-path loss reaches 16.7%, while pre-cached failover brings the recovery window down to 167ms and final loss below 1%.
  • A backup route must pass both timing and energy checks: the 35% battery path is rejected against the 40% threshold even though it is short.
  • For critical alerts, the 3-hop path changes worst-case latency from 620ms to 380ms and stays inside the 500ms budget.

18.12 Understanding Checks

Apply these concepts to real-world deployment scenarios.

Scenario: Earthquake destroys cellular infrastructure. 50 rescue workers need communication across 2km disaster zone. Each radio: 500m range, 1W transmit power, battery lasts 8 hours continuous transmission.

Think about:

  1. Calculate minimum hops for end-to-end connectivity (2000m coverage)
  2. Why not use a single 2km-range radio (4x power increase)?
  3. How does multi-hop extend battery life in energy-constrained scenarios?

Key Insight: Minimum hops = 2000m / 500m = 4 hops. Path: Source -> Node1(500m) -> Node2(1000m) -> Node3(1500m) -> Dest(2000m). Radio power follows inverse square law: doubling distance requires 4x power. Single 2km link needs 16x power (1W x 16 = 16W) vs four 500m hops at 1W each. Battery impact: 16W transmission = 30 minutes runtime vs 1W multi-hop = 8 hours. Multi-hop isn’t just about range - it’s about energy efficiency. Disaster response networks prioritize battery life over latency.

Scenario: University campus deploys delay-tolerant messaging app for 5,000 students. Epidemic routing floods 50+ message copies per message. SocialCast analyzes: contact frequency (Alice-Bob meet daily), recency (last contact 2 hours ago), location similarity (both frequent library).

Think about:

  1. Why does epidemic routing work but waste bandwidth?
  2. How does SocialCast reduce copies from 50 to 5-10 while maintaining 90% delivery?
  3. What happens when social patterns are unpredictable (random mobility)?

Key Insight: Epidemic = flood everywhere (guarantees delivery but 80% wasted bandwidth). SocialCast = forward only if carrier’s social metrics > current holder’s. Example: Message for “Bob”. Current holder “Charlie” (meets Bob monthly). Encounters “Alice” (meets Bob daily) -> transfer to Alice (higher contact frequency). Encounters “Dave” (never meets Bob) -> don’t transfer. Result: 5-10 targeted copies follow social graph toward Bob. 90% delivery ratio, 80% less bandwidth. Perfect for human mobility (predictable social patterns). Fails for random mobility (no patterns to exploit) - use epidemic instead.

Scenario: Disaster response team uses DSR routing. Command post (stationary) communicates with mobile rescue teams (3-5 m/s). Device caches 5 routes. After 10 minutes, 40% of routes have stale/broken links due to mobility.

Think about:

  1. Calculate optimal cache timeout balancing freshness vs discovery overhead
  2. Why not always perform fresh route discovery (zero cache)?
  3. How does mobility speed affect ideal timeout?

Key Insight: Static timeout fails: 10min timeout -> 40% stale routes -> packet failures. 30sec timeout -> excessive RREQ floods (high overhead). Adaptive solution: Monitor ROUTE_ERROR rate: High errors (>5/min) -> reduce timeout to 2-3min (high mobility). Low errors (<1/min) -> extend timeout to 10min (stable topology). Mobility-aware: Command post to command post: 10min cache (stationary). Rescue team to rescue team: 2min cache (mobile). Mixed: 5min cache. Why not zero cache? Discovery latency: 50-200ms per RREQ/RREP cycle. Real-time voice needs <100ms. Cached routes = instant forwarding. Result: Adaptive caching = DSR’s low latency + mobility resilience. Route lifetime inversely proportional to node velocity.

Scenario: 20-node ad-hoc network has 3 paths from source to gateway: Path A (3 hops, nodes at 40% battery), Path B (4 hops, nodes at 80% battery), Path C (5 hops, nodes at 95% battery). Need to route 1000 packets while maximizing network lifetime.

Think about:

  1. Why doesn’t shortest-path routing (Path A) maximize network lifetime?
  2. Calculate battery depletion if all traffic uses Path A vs distributed across all paths
  3. How does energy-aware routing trade latency for longevity?

Key Insight: Shortest-path (Path A only): 1000 packets drain 40% -> 0% battery on 3 nodes -> network partition (other nodes isolated). Energy-aware distribution: 300 packets on A (40% -> 25%), 400 packets on B (80% -> 70%), 300 packets on C (95% -> 88%). Minimum battery: 25% (vs 0% shortest-path). Network survives 3x longer. Trade-offs: Path C has 67% higher latency (5 hops vs 3) but uses nodes with abundant energy. Production strategy: Route delay-tolerant traffic on long/high-battery paths, route real-time traffic on short/low-latency paths. Prevents premature node deaths that partition network.

Scenario: Ad-hoc network link between Node A and Node B: current RSSI -65 dBm, PDR 95%, nodes approaching at 2 m/s, will separate in 30 seconds. Link quality monitor must predict when link becomes unusable (RSSI < -85 dBm, PDR < 50%).

Think about:

  1. Calculate when proactive rerouting should trigger (before link failure)
  2. Why is prediction better than reactive rerouting after failure?
  3. How does mobility speed affect prediction accuracy?

Key Insight: Path loss increases with distance: RSSI drops ~3-4 dB per doubling distance. At 2 m/s separation velocity: Distance = 2 m/s x 30s = 60m additional separation. RSSI degrades: -65 dBm (now) -> -75 dBm (15s) -> -85 dBm (30s) -> link fails. Proactive rerouting: Trigger new route discovery at 20s (RSSI -80 dBm, PDR 70%) before complete failure. Gives 10s buffer for RREQ/RREP exchange. Reactive rerouting: Wait until link fails (PDR <50%) -> buffer loss, 200ms discovery delay, user-visible disruption. Prediction accuracy: High mobility (5 m/s+) -> prediction horizon 10-15s (short). Low mobility (1 m/s) -> horizon 60s+ (plenty of time). Use velocity-aware prediction windows.

Blueprint BinaCheckpoint: Scenario Transfer

You now know:

  • Range, delivery, cache freshness, battery distribution, and mobility prediction all change the routing answer.
  • Multi-hop range planning trades a 2km single link for four 500m hops; social routing cuts epidemic-style 50+ copies down to 5-10 targeted copies when contact patterns help.
  • Energy-aware selection can leave the weakest route at 25% battery instead of 0%, while mobility prediction reroutes around the -85 dBm failure point.

18.13 Common Misconception

Shortest Path Is Not Best Path

The Misconception: Many developers assume shortest-path routing (minimum hop count) is always optimal for ad-hoc networks. After all, fewer hops mean lower latency and less forwarding overhead, right?

The Reality: In battery-constrained IoT deployments, shortest-path routing can reduce network lifetime by 60-75% compared to energy-aware routing.

Real-World Example - Wildlife Tracking Deployment:

A 2022 wildlife tracking project deployed 50 sensor nodes across 2km^2 of forest to monitor endangered species. Initial deployment used shortest-path routing (AODV with hop-count metric):

Shortest-Path Results (Week 1-4):

  • 3 central nodes (high-betweenness) forwarded 85% of all traffic
  • These 3 nodes depleted batteries in 28 days (4 weeks)
  • Battery drain: 40% -> 5% (critical level)
  • Network partitioned into 3 disconnected islands
  • Remaining 47 nodes had 70-85% battery (wasted capacity)
  • Effective network lifetime: 28 days

Energy-Aware Routing Results (Week 5-24):

  • Deployed battery-aware routing (cost = hop_count / remaining_battery^2)
  • Traffic distributed across 15 nodes instead of 3
  • Minimum battery after 20 weeks: 32% (vs 5% shortest-path at 4 weeks)
  • Extended network lifetime to 140+ days (5x improvement)

Quantified Impact:

  • Network lifetime: 28 days (shortest) -> 140+ days (energy-aware) = 400% improvement
  • Battery variance: sigma=23% (shortest, highly unbalanced) -> sigma=8% (energy-aware, balanced)
  • Latency penalty: +1.2 hops average (acceptable for 1-hour reporting interval)
  • Cost savings: Avoided 3 expensive technician visits for battery replacement

The Lesson: For delay-tolerant IoT applications (environmental monitoring, asset tracking, smart agriculture), energy-aware routing significantly outperforms shortest-path routing despite higher hop counts. Always consider application requirements (latency tolerance, battery budget, network lifetime goals) when selecting routing metrics.

Scenario: Industrial control network uses multi-path routing. Primary path fails - calculate total failover time to backup path.

Given:

  • Primary path: A -> B -> C -> Gateway (3 hops, 45ms latency)
  • Backup path: A -> D -> E -> F -> Gateway (4 hops, 62ms latency)
  • Link failure detection: 100ms (ACK timeout)
  • Routing table update: 15ms
  • Packet buffering: 50 packets max

Steps:

  1. Failure detection: 100ms (first missing ACK)
  2. Route switch: 15ms (lookup backup in cache)
  3. First packet on backup: 62ms (4-hop transmission)
  4. Total recovery: 100 + 15 + 62 = 177ms

Result: <200ms failover meets industrial control requirements. Without pre-cached backup, would need 2-3 seconds for route discovery.

  • Shortest-path routing
    • Lowest delivery latency because it minimizes hop count.
    • Baseline network lifetime, because busy relay nodes may drain early.
    • Simple to implement.
    • Best for latency-critical traffic.
  • Energy-aware routing
    • Usually adds 20-40% latency by choosing less depleted relay nodes.
    • Can extend network lifetime by 300-500%.
    • Requires battery monitoring and route-cost updates.
    • Best for long deployments of two years or more.
  • Hybrid routing
    • Usually adds 10-20% latency.
    • Can extend lifetime by 150-250%.
    • Requires adaptive policy logic.
    • Best when critical alerts and delay-tolerant telemetry share the same network.

Example: Wildlife tracking with a two-year battery requirement favors energy-aware routing despite higher latency.

Backup Path Battery Levels

The Mistake: Pre-caching backup paths without checking node battery levels, leading to failover to dying nodes.

Impact: Primary path fails -> switches to backup -> backup node at 8% battery fails within minutes -> both paths down.

Solution: Validate backup path battery levels during periodic health checks, invalidate backups with nodes <20% battery.

Interactive Quiz: Match Concepts

Interactive Quiz: Sequence the Steps

Common Pitfalls

Students often pick reactive protocols by default without analyzing traffic patterns. Proactive protocols (DSDV/OLSR) outperform reactive ones when traffic rate exceeds about 1 packet per 30 seconds per node because route discovery overhead amortizes. Profile your traffic before selecting a protocol.

Single-path routing fails silently when the primary route breaks, causing 2-5 minute outages while new routes are discovered. Multi-path routing pre-caches backup routes, reducing failure recovery to sub-second. Always implement at least two disjoint paths for critical links.

Deploying shortest-path routing in energy-constrained networks drains high-betweenness relay nodes 3-5x faster than the rest, causing premature network partition. Energy-aware metrics such as residual battery times path length distribute load to extend network lifetime by up to 5x.

Default beacon intervals (1-2 seconds) cause excessive control overhead in static scenarios and stale routes in fast-moving scenarios. Adaptive beaconing (increase rate on link quality changes, decrease when stable) reduces overhead by 40-60% while maintaining route freshness.

Label the Diagram

Code Challenge

18.14 Production Readiness Evidence Record

Production readiness is not the same as solving one routing exercise. A useful ad-hoc assessment asks whether the routing claim still holds when traffic rate, node mobility, relay battery, link quality, interference, gateway placement, or recovery policy changes.

The worked examples are best read as evidence patterns. They show how to compare protocols, classify links, reject weak paths, and calculate failover windows. The production conclusion must stay scoped to the measured scenario instead of becoming a universal promise about all ad-hoc networks.

Ad hoc routing strategy comparison showing four strategies: shortest path puts all traffic on the minimum-hop route with low latency and bottleneck risk, load balanced spreads traffic across several paths, energy-aware shifts load away from weak batteries, and QoS-aware prioritizes the best packet-delivery path with a backup path
Figure 18.3: Ad hoc routing strategy comparison showing shortest-path, load-balanced, energy-aware, and QoS-aware routing choices with their latency, bottleneck, battery, and reliability trade-offs

Production readiness depends on proving which strategy fits the measured condition: the fastest path can create hotspots, load balancing trades latency for resilience, energy-aware routing preserves weak relays, and QoS-aware routing prioritizes delivery evidence.

Assessment area Evidence needed Reject when
Routing fit Traffic pattern, mobility, discovery delay, control overhead, and route-state evidence. The protocol is chosen from a generic table without measured traffic.
Link evidence PDR, RSSI, latency, and retry behavior for the observed radio condition and time window. The record classifies a link from one metric while ignoring the others.
Failover evidence Detection time, switch time, backup-path health, and first-packet delivery. The record claims fast recovery but does not measure the sequence.
Energy evidence Relay-load records, battery thresholds, path count, and route churn. The route is called energy efficient without battery and forwarding evidence.

Assessment rule: Accept the routing claim only for the traffic, topology, node energy, link quality, and failure condition that the assessment actually tested.

Blueprint BinaCheckpoint: Evidence Before Release

You now know:

  • The wildlife example shows why shortest-path routing can drain three central nodes in 28 days while energy-aware routing extends the same deployment to 140+ days.
  • The release decision needs routing fit, link evidence, failover evidence, and energy evidence; a diagram alone is not enough.
  • A production claim must name the retest trigger, such as node movement, battery threshold, gateway relocation, seasonal obstruction, firmware, or traffic change.

18.15 Ad-Hoc Release Record

The release record turns quiz-style answers into a maintainable production decision. It keeps the chosen routing strategy, rejected alternatives, measured limits, operations owner, and retest trigger together.

Record item Question Evidence to attach Reject when
Traffic class How often does each node send, and what happens if a packet is late or lost? Message interval, payload type, alarm priority, stale-data rule, and loss budget. The protocol is chosen before traffic is measured.
Route choice Why does proactive, reactive, hybrid, multipath, or DTN behavior fit this deployment? Control overhead, discovery delay, route age, path count, and mobility evidence. The decision says “shortest path” without relay load, failure, or energy evidence.
Failover window How long is the path unavailable after the specific failure? Detection time, switch time, backup-path health, first packet on backup, and loss count. The record skips one stage of the failover sequence.
Operations trigger When must the routing assessment be rerun? Node movement, battery threshold, gateway relocation, seasonal obstruction, firmware, or traffic change. The team reuses old results after topology or traffic changed.

Use this release workflow:

  1. State the deployment claim. Name the traffic, area, node count, gateway, mobility, and recovery requirement.
  2. Test the weak path. Use the worst likely relay, battery, obstruction, or mobility condition as the release gate.
  3. Record rejected routes. Explain which paths were excluded for latency, battery, PDR, security, or stale-route risk.
  4. Set the recheck trigger. Name the exact field change that invalidates the current assessment.

18.16 Failover State Machine Review

Fast recovery depends on the sequence of events, not the label “multi-path.” A node must detect the failed link, reject unsafe alternatives, choose a backup path with enough link and battery evidence, update forwarding state, and deliver the first packet under the new path. Each stage can fail or add delay.

Energy-aware routing has the same structure. It is not enough to avoid low-battery nodes once. The review must track relay duty, route churn, battery thresholds, link quality, and whether a backup path quietly moves the bottleneck to a different node.

State What to verify
Detection ACK timeout, missed beacons, neighbor aging, and route expiry define when the node knows a path failed.
Candidate Backup paths need current PDR, latency, battery, hop count, and loop-avoidance evidence.
Commit The switch is complete only after forwarding state changes and the first packet succeeds on the backup path.
Decay Cached routes decay as nodes move, batteries drain, radios change, and seasonal obstructions appear.

Failure-analysis rule: When a recovery calculation looks strong, ask which state transition was measured and which was assumed. The unmeasured transition is usually where the production claim is weakest.

18.17 Summary

This chapter consolidated key concepts for production ad-hoc network management through assessments and practice problems.

Key Takeaways:

  1. Protocol Selection Depends on Traffic Patterns: Proactive for frequent traffic, reactive for sparse traffic, hybrid for mixed patterns

  2. Link Quality Classification Enables Smart Routing: PDR, RSSI, and latency thresholds classify links into four tiers for routing decisions

  3. Multi-Path Redundancy Needs Measured Failover: Pre-cached backup paths can reduce recovery time when detection, switch, and first-packet delivery are recorded

  4. Energy-Aware Routing Extends Lifetime: Distributing load across nodes prevents premature battery depletion and network partition

  5. Shortest Path is Not Always Best: For delay-tolerant applications, measured relay load and battery state can justify energy-aware routing

  6. Adaptive Strategies Beat Static Ones: Mobility-aware cache timeouts, priority-based path selection, and proactive link prediction outperform fixed configurations

18.18 Further Reading

Foundational Papers:

  • Perkins, C. E., & Bhagwat, P. (1994). “Highly dynamic destination-sequenced distance-vector routing (DSDV) for mobile computers.” ACM SIGCOMM.
  • Johnson, D. B., & Maltz, D. A. (1996). “Dynamic source routing in ad hoc wireless networks.” Mobile Computing, Springer.
  • Haas, Z. J., et al. (2002). “The zone routing protocol (ZRP) for ad hoc networks.” IETF Draft.

DTN and Epidemic Routing:

  • Vahdat, A., & Becker, D. (2000). “Epidemic routing for partially connected ad hoc networks.” Duke University Technical Report.
  • Fall, K. (2003). “A delay-tolerant network architecture for challenged internets.” ACM SIGCOMM.

Context-Aware and Social Routing:

  • Musolesi, M., et al. (2005). “CAR: Context-aware adaptive routing for delay-tolerant mobile networks.” IEEE Transactions on Mobile Computing.
  • Costa, P., et al. (2008). “Socially-aware routing for publish-subscribe in delay-tolerant mobile ad hoc networks.” IEEE JSAC.

IoT-Specific:

  • RPL: IETF RFC 6550 - Routing Protocol for Low-Power and Lossy Networks
  • Al-Karaki, J. N., & Kamal, A. E. (2004). “Routing techniques in wireless sensor networks: A survey.” IEEE Wireless Communications.

18.19 References

  1. Perkins, C. E. (2001). Ad Hoc Networking. Addison-Wesley.

  2. Abolhasan, M., Wysocki, T., & Dutkiewicz, E. (2004). “A review of routing protocols for mobile ad hoc networks.” Ad Hoc Networks, 2(1), 1-22.

  3. Zhang, Z. (2006). “Routing in intermittently connected mobile ad hoc networks and delay tolerant networks: Overview and challenges.” IEEE Communications Surveys & Tutorials, 8(1), 24-37.

  4. Spyropoulos, T., et al. (2008). “Efficient routing in intermittently connected mobile networks: The multi-copy case.” IEEE/ACM Transactions on Networking.

  5. IoT Routing Survey: Rajandekar, A., & Sikdar, B. (2015). “A survey of MAC layer issues and protocols for machine-to-machine communications.” IEEE Internet of Things Journal.

18.20 What’s Next