263  Ad Hoc Networks: Assessment and Practice

263.1 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

263.2 Prerequisites

Required Chapters:

Estimated Time: 30 minutes

263.3 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.

263.4 Ad-Hoc Routing Protocol Comparison

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

Ad-hoc Routing Protocol Comparison

Protocol Type Examples How It Works Overhead Latency Best For
Proactive DSDV, OLSR Maintain all routes continuously High (periodic updates) Low (routes ready) Frequent, predictable traffic
Reactive AODV, DSR Discover routes on-demand Low (only when needed) High (discovery delay) Sparse, occasional traffic
Hybrid ZRP Proactive intra-zone, reactive inter-zone Medium (configurable) Medium Mixed traffic patterns 

%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#E67E22', 'secondaryColor': '#16A085', 'tertiaryColor': '#E67E22', 'clusterBkg': '#f9f9f9', 'clusterBorder': '#2C3E50', 'fontSize': '13px'}}}%%
graph TB
    subgraph Proactive["Proactive (DSDV, OLSR)"]
        P1[Initialize Route Tables]
        P2[Periodic Updates]
        P3[Maintain All Routes]
        P4[Data Ready]
        P5[Immediate Transmission]

        P1 --> P2
        P2 --> P3
        P3 --> P4
        P4 --> P5
        P5 -.->|Continuous Updates| P2
    end

    subgraph Reactive["Reactive (AODV, DSR)"]
        R1[Idle - No Routes]
        R2[Data Needed]
        R3[RREQ Flood]
        R4[RREP Reply]
        R5[Route Found]
        R6[Data Transmission]

        R1 --> R2
        R2 --> R3
        R3 --> R4
        R4 --> R5
        R5 --> R6
        R6 -.->|Route Expires| R1
    end

    subgraph Hybrid["Hybrid (ZRP)"]
        H1[Intra-Zone<br/>Proactive]
        H2[Inter-Zone<br/>Reactive]
        H3[Local Traffic<br/>Fast]
        H4[Remote Traffic<br/>Efficient]

        H1 --> H3
        H2 --> H4
    end

    COMP[Comparison]
    Proactive -->|Low Latency<br/>High Overhead| COMP
    Reactive -->|High Latency<br/>Low Overhead| COMP
    Hybrid -->|Medium Latency<br/>Medium Overhead| COMP

    style P3 fill:#E67E22,stroke:#2C3E50,color:#fff
    style R3 fill:#16A085,stroke:#2C3E50,color:#fff
    style H1 fill:#2C3E50,stroke:#16A085,color:#fff
    style H2 fill:#16A085,stroke:#2C3E50,color:#fff
    style COMP fill:#E67E22,stroke:#2C3E50,color:#fff

Figure 263.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

263.5 Link Quality Classification

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

%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#E67E22', 'secondaryColor': '#16A085', 'tertiaryColor': '#E67E22', 'fontSize': '13px'}}}%%
graph TB
    START[Link Quality<br/>Assessment]

    PDR1{PDR >= 90%?}
    PDR2{PDR >= 70%?}
    PDR3{PDR >= 50%?}

    RSSI1{RSSI > -70dBm?}
    RSSI2{RSSI > -80dBm?}
    RSSI3{RSSI > -90dBm?}

    EXC[EXCELLENT<br/>PDR: 90-100%<br/>RSSI: > -70dBm<br/>Latency: < 20ms]
    GOOD[GOOD<br/>PDR: 70-90%<br/>RSSI: -70 to -80dBm<br/>Latency: 20-50ms]
    FAIR[FAIR<br/>PDR: 50-70%<br/>RSSI: -80 to -90dBm<br/>Latency: 50-100ms]
    POOR[POOR<br/>PDR: < 50%<br/>RSSI: < -90dBm<br/>Latency: > 100ms]

    START --> PDR1

    PDR1 -->|Yes| RSSI1
    PDR1 -->|No| PDR2

    PDR2 -->|Yes| RSSI2
    PDR2 -->|No| PDR3

    PDR3 -->|Yes| RSSI3
    PDR3 -->|No| POOR

    RSSI1 -->|Yes| EXC
    RSSI1 -->|No| GOOD

    RSSI2 -->|Yes| GOOD
    RSSI2 -->|No| FAIR

    RSSI3 -->|Yes| FAIR
    RSSI3 -->|No| POOR

    style START fill:#2C3E50,stroke:#16A085,color:#fff
    style EXC fill:#16A085,stroke:#2C3E50,color:#fff
    style GOOD fill:#E67E22,stroke:#2C3E50,color:#fff
    style FAIR fill:#7F8C8D,stroke:#2C3E50,color:#fff
    style POOR fill:#C0392B,stroke:#2C3E50,color:#fff

Figure 263.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)

263.6 Routing Strategy Comparison

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

%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#E67E22', 'secondaryColor': '#16A085', 'tertiaryColor': '#E67E22', 'fontSize': '13px'}}}%%
graph TB
    SRC[Source Node]
    DST[Destination Node]

    subgraph Shortest["Shortest Path"]
        SP1[Path A<br/>3 hops<br/>100% traffic]
        SPRES[Low latency<br/>Unbalanced load<br/>Bottleneck risk]
    end

    subgraph LoadBal["Load Balanced"]
        LB1[Path A: 34%]
        LB2[Path B: 33%]
        LB3[Path C: 33%]
        LBRES[Distributed load<br/>Higher latency<br/>Better resilience]
    end

    subgraph Energy["Energy-Aware"]
        EA1[Path A: 48%<br/>Low battery]
        EA2[Path B: 30%<br/>Medium battery]
        EA3[Path C: 22%<br/>High battery]
        EARES[Extended lifetime<br/>Battery-aware<br/>Network longevity]
    end

    subgraph QoS["QoS-Aware"]
        QOS1[Best PDR path]
        QOS2[Backup path]
        QOSRES[Maximize delivery<br/>Link quality priority<br/>Reliability focus]
    end

    SRC --> Shortest
    SRC --> LoadBal
    SRC --> Energy
    SRC --> QoS

    SP1 --> SPRES
    LB1 --> LBRES
    LB2 --> LBRES
    LB3 --> LBRES
    EA1 --> EARES
    EA2 --> EARES
    EA3 --> EARES
    QOS1 --> QOSRES

    SPRES --> DST
    LBRES --> DST
    EARES --> DST
    QOSRES --> DST

    style SRC fill:#2C3E50,stroke:#16A085,color:#fff
    style DST fill:#2C3E50,stroke:#16A085,color:#fff
    style SPRES fill:#E67E22,stroke:#2C3E50,color:#fff
    style LBRES fill:#16A085,stroke:#2C3E50,color:#fff
    style EARES fill:#7F8C8D,stroke:#2C3E50,color:#fff
    style QOSRES fill:#E67E22,stroke:#2C3E50,color:#fff

Figure 263.3: Routing strategy comparison showing four approaches from source to destination: Shortest Path sends 100% traffic on 3-hop Path A (low latency but bottleneck risk), Load Balanced distributes 34/33/33% across three paths (distributed load and resilience), Energy-Aware routes 48/30/22% favoring high-battery nodes (extended lifetime), and QoS-Aware prioritizes best PDR path with backup (maximize delivery reliability)

Trade-offs Summary:

Metric Proactive Reactive Hybrid
Control Overhead High Low Medium
Route Latency Low High Configurable
Scalability Poor Good Good
Mobility Support Moderate Good Good

263.7 Knowledge Check

  1. A primary reason multi-hop can be more energy-efficient than a single long-range hop is that:

Path loss increases with distance; achieving a much longer link can require disproportionately higher power. Multiple shorter hops can achieve coverage with lower per-hop power.

  1. Proactive routing protocols like OLSR are generally best when:

Proactive protocols maintain routes continuously, which reduces route setup delay but increases overhead through periodic updates.

  1. A key advantage of reactive routing (e.g., AODV/DSR) is:

Reactive protocols discover routes only when needed, reducing idle overhead at the cost of route discovery latency when traffic starts.

  1. For intermittently connected networks (DTN scenarios), “store-and-forward” multi-copy approaches (like epidemic routing) typically trade:

Multi-copy DTN approaches improve delivery under intermittent connectivity by replicating packets, but that replication increases overhead and energy use.

263.8 Worked Examples

NoteWorked Example: Link Failure Recovery with Multi-Path Redundancy

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.

NoteWorked Example: Hop Count Optimization for Latency-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.

263.9 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.

263.10 Common Misconception

WarningCommon Misconception: “Shortest Path = 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.

263.11 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 Transforms Failures: Pre-cached backup paths reduce recovery time from seconds to milliseconds

  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, energy-aware routing can extend network lifetime by 5x

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

263.12 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.

263.13 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.

263.14 What’s Next?

Having completed the ad-hoc networks production series, we now examine Mobile Phones As A Gateway. The next chapter builds upon these foundations to explore additional architectural patterns and considerations.

Continue to Mobile Phones As A Gateway ->

Deep Dives:

Comparisons:

Learning: