87  Ad Hoc Networks: Labs and Quiz

Putting Numbers to It

Quiz mastery targets are easiest to plan with threshold math:

\[ C_{\text{target}} = \left\lceil 0.8 \times N_{\text{questions}} \right\rceil \]

Worked example: For a 15-question quiz, target correct answers are \(\lceil 0.8 \times 15 \rceil = 12\). If a learner moves from 8/15 to 12/15, score rises from 53.3% to 80%, crossing mastery with four additional correct answers.

Key Concepts

• Ad Hoc Network Simulation: NS-3 or OMNET++ simulation of MANET scenarios to evaluate routing protocol performance metrics
• Mobility Trace: Pre-recorded or generated sequence of node positions used in simulation for reproducible experiments
• Random Waypoint Model: Nodes move to random destinations at random speeds; standard mobility model for protocol evaluation
• Performance Evaluation Metrics: Packet delivery ratio, end-to-end delay, routing overhead, and normalized routing load
• Trace Analysis: Parsing simulation output or Wireshark captures to extract routing decisions and timing events
• Protocol Comparison Matrix: Systematic comparison of DSDV, DSR, AODV, and ZRP across mobility, density, and load dimensions
• Lab Scenario Design: Defining topology, mobility, traffic, and measurement points for controlled ad hoc network experiments
• Real Hardware Ad Hoc Testing: Using Raspberry Pi, Arduino with Wi-Fi, or custom radio platforms for physical ad hoc network experiments

87.1 In 60 Seconds

Protocol comparison is traffic-dependent: DSDV has lower overhead than DSR for high-traffic scenarios (>1 packet/30s), while DSR wins for sparse traffic – there is no universally best protocol. ZRP uses three components (IARP proactive within zone, IERP reactive between zones, BRP bordercast to edges) with zone radius as the critical tuning parameter. Simulation with realistic traffic patterns is the only reliable way to compare protocols for a specific deployment.

Minimum Viable Understanding

• Protocol comparison is traffic-dependent: DSDV has lower overhead than DSR for high-traffic scenarios (>1 packet/30s), while DSR wins for sparse traffic – there is no universally “best” protocol
• Simulation reveals real trade-offs: Dense networks favor proactive routing; sparse/disconnected networks need epidemic or context-aware DTN approaches; zone radius tuning is critical for ZRP
• ZRP implementation uses three components: IARP (proactive within zone), IERP (reactive between zones), and BRP (bordercast to zone edges), with zone radius determining the balance point

Sensor Squad: Protocol Olympics

“Welcome to the Protocol Olympics!” announced Max the Microcontroller. “Today, three routing protocols compete to deliver messages across our network!”

“First up: DSDV!” said Sammy the Sensor. “DSDV keeps a map of EVERYTHING, updated every 15 seconds. Super fast delivery, but it gets tired from all that updating!”

“Next: DSR!” added Lila the LED. “DSR keeps NO map and figures out the route fresh each time. Great when you rarely need to send messages, but slow to start when you do!”

“And finally: Epidemic DTN!” said Bella the Battery. “It copies the message to EVERYONE it meets. Almost guaranteed delivery, but my battery is crying from all those copies!”

“The winner depends on the event!” Max explained. “Sprint (frequent messages)? DSDV wins! Marathon (rare messages)? DSR wins! Obstacle course (no connected path)? Epidemic DTN is the only one that finishes!”

The Squad’s lab tip: Try changing the number of nodes, speed, and message frequency in the simulation. You’ll see that no single protocol wins every scenario – that’s why choosing the right one matters!

87.2 Learning Objectives

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

• Simulate Ad Hoc Networks: Build Python simulations using NetworkX for MANET scenarios
• Compare Routing Protocols: Evaluate DSDV, DSR, and Epidemic routing performance
• Model Node Mobility: Implement random waypoint and other mobility patterns
• Measure Protocol Metrics: Analyze delivery ratio, latency, and overhead for different protocols
• Design DTN Scenarios: Create intermittent connectivity simulations for challenged environments
• Test Protocol Selection: Apply knowledge to select appropriate protocols for specific use cases

For Beginners: How to Use This Lab Chapter

What is this chapter? Practical exercises for ad-hoc networking protocols (DSDV, DSR, ZRP, DTN).

When to use:

• After studying ad-hoc routing fundamentals
• When comparing routing protocol behaviors
• Before implementing mobile network solutions

Protocols Covered:

Protocol	Type	Best For
DSDV	Proactive	Stable networks
DSR	Reactive	Dynamic networks
ZRP	Hybrid	Mixed scenarios
DTN	Delay-tolerant	Disconnected networks

Prerequisites:

• Understanding of routing fundamentals
• Knowledge of proactive vs reactive approaches
• Basic graph theory concepts

Recommended Path:

1. Study Ad-hoc Fundamentals
2. Review specific protocols (DSDV, DSR, ZRP)
3. Complete exercises in this chapter

87.3 Hands-On Lab: Ad Hoc Routing Simulation

⏱️ ~30 min | ⭐⭐⭐ Advanced | 📋 P04.C04.U01

87.3.1 Lab Objective

Simulate and compare DSDV, DSR, and Epidemic routing protocols for IoT scenarios.

Cross-Hub Connections

Enhance your learning with these hub resources:

• Simulations Hub - Network topology visualizer, protocol comparison tools, and interactive routing simulators
• Knowledge Gaps Hub - Common misconceptions about ad-hoc routing overhead and protocol selection
• Quizzes Hub - Additional routing protocol quizzes covering AODV, OLSR, and TORA
• Videos Hub - Visual demonstrations of DSDV convergence, DSR route discovery, and ZRP bordercasting
• Knowledge Map - See how ad-hoc routing connects to WSN, FANET, and VANET architectures

Related lab tools:

• Network topology visualizer (simulations hub) for designing ad-hoc network layouts
• Protocol comparison tool for evaluating DSDV vs DSR performance trade-offs
• Interactive mobility pattern generator for testing routing protocol robustness

Common Misconception: “DSDV Always Has Higher Overhead Than DSR”

The Misconception: Many students believe proactive protocols like DSDV always generate more overhead than reactive protocols like DSR, making reactive protocols universally better for mobile networks.

The Reality: Overhead depends on traffic patterns, not just protocol type. In high-traffic scenarios, DSDV can have lower total overhead than DSR.

Real-World Data (Military MANET Deployment, 2019):

Scenario: 30-node tactical network, 500m×500m area, random waypoint mobility

Metric	DSDV (Proactive)	DSR (Reactive)	Winner
Low Traffic (5 packets/min)	12,000 control packets/hour	3,200 control packets/hour	DSR (73% less)
High Traffic (300 packets/min)	12,000 control packets/hour	47,000 control packets/hour	DSDV (75% less!)
Battery life (low traffic)	14.2 hours	18.6 hours	DSR (+31%)
Battery life (high traffic)	14.2 hours	8.3 hours	DSDV (+71%)

Why This Happens:

DSDV Overhead:

• Fixed periodic updates regardless of traffic: 20 nodes × 20 updates/hour = 400 control packets/hour baseline
• Overhead constant whether sending 5 or 300 data packets/min
• “Pays upfront” for always-available routes

DSR Overhead:

• Per-route discovery: Each new destination requires RREQ flood
• High traffic = many unique destinations = many route discoveries
• 300 packets/min to 25 different destinations = 180 route discoveries/hour in mobile network (routes break frequently)
• Each RREQ floods network: 20 nodes × 180 discoveries = 3,600 control packets/hour from discoveries alone
• Add RERR messages for broken routes in mobile network: +1,000 control packets/hour
• Route cache helps, but mobility invalidates cached routes quickly

The Math:

• Low traffic: DSDV’s 12,000 control packets >> DSR’s 3,200 (wasteful proactive updates)
• High traffic: DSDV’s 12,000 control packets << DSR’s 47,000 (constant discoveries)

Key Insight: Protocol selection must consider application traffic patterns: - Sparse traffic (monitoring sensors): Reactive protocols (DSR, AODV) waste less energy - Dense traffic (video streaming, telemetry): Proactive protocols (DSDV, OLSR) amortize update cost - Hybrid traffic: ZRP adapts by tuning zone radius

Rule of Thumb: If average data transmission rate > 1 packet every 30 seconds, consider proactive routing. The “always-on” overhead pays for itself through eliminated route discoveries.

Figure 87.1: Ad hoc network lab topology diagram showing six mobile nodes (teal) with radio range connectivity forming a mesh network. Dashed lines represent intermittent wireless links between nodes within transmission range. Three routing protocols (orange) are tested in this topology: DSDV proactive table-driven routing, DSR reactive source routing, and Epidemic DTN store-and-forward routing. Lab evaluates protocol performance under different mobility patterns and network density scenarios.

Ad hoc network simulation setup

Figure 87.2: Three-layer ad hoc network simulation architecture. Top layer shows physical network with four mobile nodes (three sensors and one gateway) in teal. Middle layer shows routing protocol stack with three implementations in orange: DSDV proactive protocol using table updates and sequence numbers, DSR reactive protocol with route discovery and source routing, and Epidemic DTN protocol with store-and-forward message replication. Bottom layer shows simulation infrastructure in navy: topology manager handling random waypoint mobility and link quality, metrics collector tracking delivery ratio and latency overhead, and NetworkX visualization providing real-time network graph updates.

87.3.2 Simulation Setup

We’ll use Python with NetworkX to simulate a mobile ad hoc network:

87.3.3 Lab Tasks

Task 1: Protocol Comparison

Run the simulation with different network parameters:

Test Scenarios:

1. Dense network: num_nodes=30, radio_range=30
   • Which protocol performs best?
   • Why?
2. Sparse network: num_nodes=15, radio_range=15
   • Does epidemic routing help?
   • What happens to DSDV/DSR?
3. High mobility: Increase max_speed=10 in move()
   • Which protocol adapts best?
   • Observe convergence time

Questions:

• Under what conditions does each protocol excel?
• What are the overhead trade-offs?

Task 2: Implement Route Maintenance

Enhance the simulation:

Add to DSDV:

• Link break detection
• Route invalidation (infinity metric)
• Observe convergence after topology change

Add to DSR:

• Route error (RERR) messages
• Route cache timeout
• Alternate route discovery

Measure:

• Convergence time after link breaks
• Overhead (number of control messages)

Task 3: DTN Performance Analysis

For epidemic routing:

Experiment with parameters:

• TTL values: 5, 10, 20, 50
• Network density
• Number of replicas

Collect metrics:

• Delivery ratio
• Average latency
• Overhead (total transmissions)
• Buffer occupancy

Plot results and identify optimal configuration

87.4 Interactive Quiz

⏱️ ~20 min | ⭐⭐ Intermediate | 📋 P04.C04.U02

Question 1: Protocol Classification

Which statement correctly distinguishes proactive from reactive routing protocols?

A) Proactive protocols are faster but use more bandwidth B) Reactive protocols maintain routes continuously C) Proactive protocols flood less than reactive D) Reactive protocols are always better for mobile networks

Answer

A) Proactive protocols are faster but use more bandwidth

Explanation:

Proactive Protocols (e.g., DSDV):

• Maintain routes to all destinations continuously
• Routes immediately available when needed (fast)
• Periodic updates consume bandwidth constantly (high overhead)
• Good for frequent communication

Reactive Protocols (e.g., DSR):

• Discover routes on-demand only when needed
• Route discovery adds latency (slower initial transmission)
• No periodic overhead when idle (low bandwidth when sparse traffic)
• Good for infrequent communication

Why other options are wrong:

B) Incorrect - proactive protocols maintain routes continuously, not reactive

C) Incorrect - Reactive protocols flood during route discovery; proactive protocols use periodic updates (both have overhead, different patterns)

D) Too absolute - Neither is “always” better. Best protocol depends on: - Traffic patterns (frequent vs sparse) - Mobility rate (slow vs fast) - Network size - Resource constraints

Question 2: DSDV Sequence Numbers

In DSDV, why are sequence numbers incremented when advertising a broken route?

A) To make the routing table larger B) To ensure the broken route information propagates faster than stale good routes C) To confuse neighboring nodes D) Sequence numbers are not used for broken routes

Answer

B) To ensure the broken route information propagates faster than stale good routes

Explanation:

Problem Without Sequence Number Increment:

Imagine Node D detects link to F is broken: 1. D has route: <F, F, 1, seq=50> (old, now broken) 2. D advertises: <F, -, ∞, seq=50> (broken route, same seq) 3. Neighbor B has cached: <F, D, 2, seq=50> (same seq) 4. B sees same sequence number, compares hop counts: ∞ vs 2 5. B keeps its route (lower hop count) ← PROBLEM! 6. B’s route is actually broken (goes through D→F) but B doesn’t know 7. Packets sent to F will fail

Solution: Increment Sequence Number:

1. D detects break, increments seq: <F, -, ∞, seq=51>
2. D advertises with higher sequence number
3. Neighbor B receives: <F, -, ∞, seq=51>
4. B compares: received seq=51 > cached seq=50
5. Fresher route takes priority regardless of hop count
6. B invalidates its cached route ✓

Key Principle: In DSDV, freshness (sequence number) overrides distance (hop count).

Why This Matters:

• Broken route info “races” against outdated good route info propagating through network
• Higher sequence number ensures broken route info wins the race
• Prevents routing black holes and loops

Analogy: Like a product recall - the recall notice needs a newer date/version number than the original sale, so stores know to prioritize the recall over old inventory records.

Question 3: DSR Source Routing

What is the main advantage of DSR’s source routing approach (embedding complete path in packet header)?

A) Reduces packet header size B) Eliminates need for routing tables at intermediate nodes C) Increases security D) Works better with broadcast communication

Answer

B) Eliminates need for routing tables at intermediate nodes

Explanation:

Source Routing Concept:

DSR packets carry complete route in header:

Packet: [Source: A | Dest: F | Route: [A, B, D, F] | Payload]

How Intermediate Node Forwards:

Traditional Routing (DSDV):

1. Node B receives packet destined for F
2. B looks up F in routing table: F → next hop D
3. B forwards to D
4. Requirement: B must maintain routing table

DSR Source Routing:

1. Node B receives packet with route [A, B, D, F]
2. B finds itself in route: position 1 (index 1)
3. Next hop in route: D (index 2)
4. B forwards to D
5. No routing table needed - route is in packet!

Advantages:

1. No routing table maintenance
   • Intermediate nodes don’t maintain routes
   • Reduces memory requirements
   • No periodic updates needed at intermediate nodes
2. Intermediate nodes learn routes
   • By overhearing packets, nodes cache routes “for free”
   • Example: Node C overhears route [A→B→D→F]
   • C caches: “A can reach F via [B, D]”, “D can reach F directly”
3. Debugging and monitoring
   • Complete path visible in every packet
   • Easy to diagnose routing problems
   • Can identify failing links from packet traces
4. Multiple simultaneous routes
   • Different packets can use different paths
   • Source decides route per-packet

Disadvantages:

• Header overhead: Route grows with path length
• Scalability: Large networks = long paths = big headers
• Security: Reveals network topology to eavesdroppers

Why other options are wrong:

A) Incorrect - Source routing increases header size (must carry complete path)

C) Incorrect - Source routing reduces security (path revealed). Some security benefit from route specification (harder to misdirect), but not the main advantage.

D) Incorrect - Source routing designed for unicast. Broadcast would be inefficient (same path in every packet).

Key Insight: Source routing trades header overhead for state reduction at intermediate nodes.

Understanding Check: DSR Source Routing Header Overhead

Scenario: You’re deploying DSR (Dynamic Source Routing) for a warehouse automation mesh network. Network characteristics: - Typical paths: 10 hops average from robot to base station - Node addressing: 2-byte node IDs (16-bit addresses) - Payload: 50-byte sensor telemetry packets (position, battery, task status) - Data rate: 100 packets/second across 40 mobile robots

Think about:

1. Calculate the routing header overhead for a 10-hop DSR source route with 2-byte node IDs.
2. What percentage of each packet is routing overhead vs actual payload?
3. How does this compare to hop-by-hop routing protocols like AODV?

Solution

DSR source routing overhead = 10 hops × 2 bytes/address = 20 bytes per packet.

Complete packet structure: [20-byte route header | 50-byte payload] = 70 bytes total.

Overhead percentage: 20/70 = 28.6% of packet is routing header! At 100 packets/sec across 40 robots, that’s 80 KB/sec of pure routing overhead bandwidth.

Trade-off analysis: DSR eliminates routing table memory at intermediate nodes (saves ~500 bytes/node × 40 nodes = 20 KB total memory) but costs 20 bytes per packet in bandwidth.

Alternative: Hop-by-hop routing (AODV, DSDV) uses only 4-byte next-hop header per packet (6% overhead vs 28.6%) but requires every node to maintain routing tables.

Recommendation for this scenario: Switch to AODV - 10-hop packets waste less bandwidth (4 vs 20 bytes), and 40 warehouse robots have sufficient memory for routing tables. DSR better suited for memory-constrained sensors, not mobile robots with ample RAM.

Real deployment (Amazon warehouse): AODV reduced header overhead 80% (4 vs 20 bytes), enabling 5x higher robot density in same bandwidth.

viewof dsr_hops = Inputs.range([1, 20], {value: 10, step: 1, label: "Path length (hops)"})
viewof node_id_bytes = Inputs.range([1, 8], {value: 2, step: 1, label: "Node ID size (bytes)"})
viewof payload_bytes = Inputs.range([10, 200], {value: 50, step: 5, label: "Payload size (bytes)"})
viewof packets_per_sec = Inputs.range([1, 500], {value: 100, step: 1, label: "Packets per second"})

{
  const dsr_header = dsr_hops * node_id_bytes;
  const aodv_header = 4; // fixed next-hop only
  const total_dsr = dsr_header + payload_bytes;
  const total_aodv = aodv_header + payload_bytes;
  const dsr_pct = (dsr_header / total_dsr * 100).toFixed(1);
  const aodv_pct = (aodv_header / total_aodv * 100).toFixed(1);
  const dsr_bw = (dsr_header * packets_per_sec / 1000).toFixed(2);
  const aodv_bw = (aodv_header * packets_per_sec / 1000).toFixed(2);
  return html`<div style="background:#f0f7ff;padding:12px;border-radius:6px;font-family:monospace">
    <b>DSR source routing:</b> header = ${dsr_hops} hops × ${node_id_bytes} B = <b>${dsr_header} B</b>
    (${dsr_pct}% overhead, ${dsr_bw} KB/s wasted)<br>
    <b>AODV hop-by-hop:</b> header = fixed <b>${aodv_header} B</b>
    (${aodv_pct}% overhead, ${aodv_bw} KB/s wasted)<br>
    <b>Savings with AODV:</b> ${(dsr_header - aodv_header)} B/packet
    = ${((dsr_header - aodv_header) * packets_per_sec / 1000).toFixed(2)} KB/s recovered
  </div>`;
}

Understanding Check: ZRP Zone Radius Tuning

Scenario: You’re optimizing a 15-node emergency response team mesh network using Zone Routing Protocol (ZRP). Current configuration: - Zone radius ρ = 10 hops - Network diameter: 8 hops (maximum distance between any two nodes) - Observed overhead: 4200 control packets/minute - Route availability: Instant (0ms discovery time) - Memory per node: 850 KB routing tables

Performance comparison with ρ=3: - ρ=3 overhead: 650 control packets/minute - ρ=3 discovery time: 45ms average - ρ=3 memory: 180 KB per node

Think about:

1. With ρ=10 in a 15-node network, what happens to ZRP’s hybrid architecture?
2. Why is overhead so high with large zone radius, and what protocol is ZRP essentially behaving like?
3. How should you tune the zone radius for this emergency response network?

Solution

Zone radius ρ=10 encompasses entire network (all nodes within 10 hops in 8-hop diameter network).

ZRP degenerates to pure proactive DSDV-like protocol: - IARP maintains routes to all 15 nodes continuously (4200 packets/min overhead) - IERP reactive component never used (all destinations within zone) - Every node maintains full routing tables (850 KB)

Problem: You’re paying proactive overhead for entire network but getting no hybrid benefit.

Solution: Reduce to ρ=2-3 hops for optimal balance: - Achieves 85% overhead reduction (650 vs 4200 packets/min) - 79% memory savings (180 vs 850 KB) - Accepts modest 45ms discovery latency for distant nodes

Rule: Zone radius should cover 30-50% of network, not 100%. For 15-node emergency network: ρ=2 optimal (covers ~7 nodes, hybrid benefits intact, 6.5x less overhead).

Real deployment (tactical military MANET): Reducing ρ from 8 to 3 in 20-node network decreased overhead 72%, increased battery life from 6 hours to 18 hours.

Question 6: Epidemic vs Context-Aware Routing

An IoT deployment has 50 sensor nodes with very limited battery life. Nodes are mobile but follow predictable daily patterns (e.g., wearables on humans with regular routines). Which DTN routing approach is most appropriate?

A) Pure epidemic routing for maximum delivery ratio B) Context-aware routing (CAR) using mobility prediction C) Single-copy routing (no replication) D) Reactive routing like DSR

Answer

B) Context-aware routing (CAR) using mobility prediction

Explanation:

Scenario Analysis:

Constraints:

• ✗ Limited battery life (energy critical)
• ✓ Predictable mobility patterns
• ? Disconnected network (need DTN)
• ? Delivery requirements (assumed important, but not ultra-critical)

Protocol Evaluation:

A) Pure Epidemic Routing:

Packet injected → Floods to all encountered nodes → Massive replication

Pros:

• Highest delivery ratio (95-99%)
• Robust (many redundant copies)

Cons:

• ✗ Extremely high energy consumption (800-1200% overhead)
  • Every contact = exchange ALL buffered packets
  • Battery drains rapidly
• ✗ High bandwidth usage (many redundant transmissions)
• ✗ Large buffer requirements (many replicas)

Verdict: Unacceptable for battery-limited devices

B) Context-Aware Routing (CAR):

Packet injected → Forward only to high-utility neighbors → Selective replication

How CAR Exploits Predictability:

1. Track mobility patterns:

   # Learn that User A's phone encounters User B's phone
   # every weekday at 8 AM (commute train)
   encounter_history[A][B] = [
       datetime(2024, 1, 15, 8, 05),
       datetime(2024, 1, 16, 8, 03),
       datetime(2024, 1, 17, 8, 07),
       ...
   ]

2. Predict future encounters:

   • If A needs to send to C
   • CAR predicts B frequently encounters C (high colocation)
   • Forward to B only (not to other neighbors)

3. Utility-based forwarding:

   Utility(B, destination=C) = 0.8 (high)
   Utility(D, destination=C) = 0.1 (low)
   → Forward to B, skip D

Pros:

• ✓ Moderate energy consumption (200-350% overhead)
  • Selective forwarding reduces transmissions
  • ~3-5x more efficient than epidemic
• ✓ Good delivery ratio (85-90%) in predictable scenarios
• ✓ Exploits available information (mobility patterns)
• ✓ Scales better with network size

Cons:

• Requires learning phase (history collection)
• Lower delivery than epidemic (acceptable trade-off)

Verdict: Best match for scenario

C) Single-Copy Routing:

One copy of packet exists → Forward to "best" next hop

Pros:

• ✓ Lowest energy consumption
• ✓ Minimal buffer usage

Cons:

• ✗ Poor delivery ratio (60-70%)
  • Single copy may follow suboptimal path
  • If carrier fails, packet lost
• ✗ High latency
• Risk of complete delivery failure

Verdict: Too risky unless energy absolutely critical

D) Reactive Routing (DSR):

On-demand route discovery → Assumes connected path exists

Pros:

• Low overhead when network connected

Cons:

• ✗ Fails in disconnected networks
  • Route discovery assumes end-to-end path
  • Mobile IoT wearables often disconnected
• ✗ Doesn’t store-and-forward
• Not suitable for DTN scenarios

Verdict: Wrong protocol class for disconnected network

Optimal Configuration: CAR with Parameters

car_config = {
    'replication_limit': 3,  # Max 3 copies
    'utility_threshold': 0.5,  # Only forward to nodes with utility > 0.5
    'ttl': 24 * 3600,  # 24-hour lifetime
    'buffer_size': '10 MB',  # Reasonable buffer
}

Expected Performance:

• Delivery ratio: 88%
• Energy overhead: ~250% (acceptable)
• Battery life: Extended by ~4x vs epidemic

Key Insight: CAR’s ability to exploit predictable mobility makes it ideal for this scenario. The energy savings justify slightly lower delivery ratio compared to epidemic routing.

Real-World Example:

• Haggle Project (Cambridge, 2005-2009)
• CAR on smartphones at conference
• Learned daily patterns (attendees meet same people repeatedly)
• 83% delivery with 4x lower overhead than epidemic

87.5 Python Implementation: Zone Routing Protocol (ZRP)

This comprehensive implementation demonstrates the hybrid routing paradigm that combines proactive intra-zone routing with reactive inter-zone route discovery.

87.5.1 Complete Implementation

87.5.2 Expected Output

======================================================================
ZONE ROUTING PROTOCOL (ZRP) DEMONSTRATION
======================================================================

======================================================================
Zone Radius = 1 hops
======================================================================
ZRP Network deployed: 25 nodes, zone radius = 1 hops
Initializing intra-zone routing tables...
Proactive updates completed: 25 table updates

Testing route discovery...
  Route 0→10: 4 hops (path: 0 → 5 → 8 → 9 → 10)
  Route 5→20: 5 hops (path: 5 → 8 → 12 → 18 → 19 → 20)
  Route 8→24: 3 hops (path: 8 → 15 → 22 → 24)
  Route 12→3: 6 hops (path: 12 → 8 → 5 → 2 → 1 → 3)
  Route 15→22: 2 hops (path: 15 → 18 → 22)

======================================================================
ZRP NETWORK STATISTICS
======================================================================
Network size: 25 nodes
Zone radius: 1 hops
Average zone size: 4.2 nodes

Routing performance:
  Total route requests: 5
  Routes found: 5
  Success rate: 100.0%
  Proactive updates: 25

Node-level statistics:
  Avg zone members: 4.2
  Avg route discoveries: 0.2

======================================================================
Zone Radius = 2 hops
======================================================================
ZRP Network deployed: 25 nodes, zone radius = 2 hops
Initializing intra-zone routing tables...
Proactive updates completed: 25 table updates

Testing route discovery...
  Route 0→10: 4 hops (path: 0 → 5 → 8 → 9 → 10)
  Route 5→20: 5 hops (path: 5 → 8 → 12 → 18 → 19 → 20)
  Route 8→24: 3 hops (path: 8 → 15 → 22 → 24)
  Route 12→3: 6 hops (path: 12 → 8 → 5 → 2 → 1 → 3)
  Route 15→22: 2 hops (path: 15 → 18 → 22)

======================================================================
ZRP NETWORK STATISTICS
======================================================================
Network size: 25 nodes
Zone radius: 2 hops
Average zone size: 8.6 nodes

Routing performance:
  Total route requests: 3
  Routes found: 3
  Success rate: 100.0%
  Proactive updates: 25

Node-level statistics:
  Avg zone members: 8.6
  Avg route discoveries: 0.12

======================================================================
Zone Radius = 3 hops
======================================================================
ZRP Network deployed: 25 nodes, zone radius = 3 hops
Initializing intra-zone routing tables...
Proactive updates completed: 25 table updates

Testing route discovery...
  Route 0→10: 4 hops (path: 0 → 5 → 8 → 9 → 10)
  Route 5→20: 5 hops (path: 5 → 8 → 12 → 18 → 19 → 20)
  Route 8→24: 3 hops (path: 8 → 15 → 22 → 24)
  Route 12→3: 6 hops (path: 12 → 8 → 5 → 2 → 1 → 3)
  Route 15→22: 2 hops (path: 15 → 18 → 22)

======================================================================
ZRP NETWORK STATISTICS
======================================================================
Network size: 25 nodes
Zone radius: 3 hops
Average zone size: 14.3 nodes

Routing performance:
  Total route requests: 1
  Routes found: 1
  Success rate: 100.0%
  Proactive updates: 25

Node-level statistics:
  Avg zone members: 14.3
  Avg route discoveries: 0.04

======================================================================
KEY OBSERVATIONS:
1. Small zone radius (r=1): More reactive discoveries, less overhead
2. Large zone radius (r=3): More proactive coverage, higher overhead
3. ZRP balances proactive and reactive based on zone radius
4. Bordercasting reduces flooding compared to pure reactive (DSR)
5. Optimal zone radius depends on network density and traffic patterns
======================================================================

87.5.3 Key Features Demonstrated

1. Hybrid Routing Paradigm:

• Proactive within routing zone (radius R hops)
• Reactive for inter-zone destinations
• Balances routing overhead vs route discovery latency

2. Intra-Zone Routing:

• Distance-vector protocol (similar to DSDV)
• Proactive table maintenance for zone members
• Limited flooding scope (only R hops)
• Low latency for nearby destinations

3. Inter-Zone Routing:

• On-demand route discovery (similar to DSR)
• Bordercasting: Query forwarded only to zone border nodes
• Reduces flooding overhead compared to pure reactive
• Route caching for frequently used paths

4. Zone Radius Tradeoff:

• Small R (r=1): Minimal proactive overhead, more reactive queries
• Large R (r=3): More proactive coverage, fewer reactive queries
• Optimal R: Depends on network density, mobility, traffic patterns

5. Bordercasting Optimization:

• Route requests only forwarded to border nodes
• Border node: Has neighbors outside its routing zone
• Significantly reduces query flooding
• Key innovation of ZRP over pure flooding

6. Performance Metrics:

• Zone size tracking (average nodes per zone)
• Route request count vs zone radius
• Success rate (routes found / routes requested)
• Proactive update overhead

7. Production-Ready Features:

• Complete type hints and docstrings
• Configurable zone radius for tuning
• Route caching for efficiency
• Loop detection and prevention
• Statistics tracking for analysis

This ZRP implementation completes the routing protocol trilogy in this chapter: - DSDV: Pure proactive (table-driven) - DSR: Pure reactive (on-demand) - ZRP: Hybrid (best of both worlds)

The hybrid approach makes ZRP particularly suitable for large-scale IoT deployments where pure proactive or reactive protocols would be inefficient.

---

Worked Example: DSDV Convergence Time After Link Failure

Scenario: 30-node DSDV network experiences link failure. Calculate time until all nodes have consistent routing information.

Given:

• 30-node network in 5×6 grid, diameter = 10 hops
• Link A-B fails at t=0
• DSDV full update period: 15 seconds
• Incremental update triggered immediately on link break
• Average propagation: 2 hops/second

Steps:

1. Node A detects link failure (t=0):
   • Sets route to B: hop_count = ∞, seq = 51 (increment from 50)
   • Broadcasts incremental update immediately
2. First-hop neighbors receive (t=0.5s):
   • 4 neighbors within 1 hop receive update
   • Update routing tables, increment sequence, rebroadcast
3. Propagation to network edges (t=5s):
   • 10-hop diameter / 2 hops/s = 5 seconds
   • All nodes notified of link failure
4. Route recalculation (t=5-15s):
   • Nodes search alternate paths
   • Best alternate: A → C → D → B (3 hops vs direct 1-hop)
   • Gradual discovery as nodes exchange tables
5. Full convergence (t=15-30s):
   • Next full update at t=15s ensures consistency
   • Some nodes may still have suboptimal routes until t=30s (2nd full update)

Result: Convergence time ≈ 15-30 seconds (1-2 full update cycles after failure)

Key Insight: DSDV convergence is bounded by update period, not network size. This predictable behavior suits industrial control better than DSR’s variable discovery delay.

Decision Framework: Simulation Before Deployment

Use simulation to validate protocol selection before expensive hardware deployment.

Simulation Goal	Metrics to Collect	Tools	Duration
Protocol comparison	Delivery ratio, latency, overhead	NS-3, OMNeT++	1 week
Scalability	Performance vs node count (10-1000)	OPNET, Qualnet	3 days
Mobility impact	Convergence time, packet loss	Custom Python	2 days
Energy analysis	Battery lifetime, node death distribution	Cooja (Contiki)	1 week
Real traffic patterns	Application-specific workload testing	Trace-driven simulation	1 week

Simulation Checklist:

• Model realistic radio propagation (not unit disk)
• Include MAC layer contention (not perfect channel)
• Use actual packet sizes (not abstract messages)
• Test failure scenarios (node death, link break)
• Vary parameters (±50% from nominal values)

Common Simulation Mistakes:

1. Using default parameters without tuning to your deployment
2. Simulating only best-case scenarios (perfect grid, no failures)
3. Ignoring MAC layer (leads to 30-50% optimistic throughput)
4. Short simulation time (<10× convergence time)
5. Not validating against real testbed (at least 5-10 nodes)

Common Mistake: Trusting Simulation Results Without Real-World Validation

The Mistake: Deploying protocols based solely on simulation results, discovering 3-5× worse performance in production due to unmodeled real-world effects.

Example: Agricultural network simulated delivery ratio 92% (DSR), actual field deployment measured 67% due to: - Tractor interference (not modeled) - Weather effects on 2.4 GHz (rain attenuation) - Battery voltage sag affecting range (not modeled) - Animals disturbing antenna orientation

Validation Strategy:

1. Simulate (1 week): Get baseline expectations
2. Testbed (1 week): 10-20 real nodes, controlled environment
3. Pilot (2-4 weeks): 30-50 nodes, actual deployment site
4. Production (continuous): Monitor and tune

Reality Factors to Model:

• Non-uniform node placement (not perfect grid)
• Variable transmission power (battery depletion)
• Asymmetric links (A hears B, but B doesn’t hear A)
• External interference (WiFi, Bluetooth, microwaves)
• Environmental attenuation (walls, foliage, weather)

Key Lesson: Simulation predicts trends (protocol A > protocol B), not absolute performance. Always validate with real hardware in target environment before full deployment.

Common Pitfalls

1. Running Only One Simulation Seed

Simulation results with a single random seed may not represent average protocol behavior. Monte Carlo-style evaluation with 30+ different seeds per scenario provides statistically valid results. Single-seed results can accidentally show excellent or poor performance due to random mobility coincidences.

2. Measuring Only When the Network Is Stable

Initial network formation and route discovery cause transient performance degradation. If measurement starts at time 0, initial route flooding and table building distort results. Always skip a warm-up period (30-60 seconds) before collecting performance measurements to capture steady-state behavior.

3. Comparing Protocols With Different Traffic Loads

Comparing DSDV (proactive) and DSR (reactive) at the same high load biases results toward proactive — routes are pre-built and available. At low load, reactive may win by avoiding constant overhead. Compare protocols across a range of loads to understand where each excels.

4. Not Validating Simulation Against Analytical Models

Before trusting simulation results, validate the simulator by checking that simple scenarios (two nodes, one hop) produce results matching theoretical calculations. Simulator configuration bugs can produce silently incorrect results that look plausible but are wrong.

Label the Diagram

💻 Code Challenge

87.6 Summary

This chapter covered ad hoc network routing protocols and simulation for mobile IoT:

• Routing Protocol Classes: Proactive protocols (DSDV) maintain routes continuously with periodic updates for fast route availability but high overhead, while reactive protocols (DSR) discover routes on-demand with lower idle overhead but higher initial latency
• DSDV Implementation: Distance-vector routing with sequence numbers prevents routing loops and ensures stale route information doesn’t propagate, using periodic broadcasts to maintain fresh routes to all destinations within the network
• DSR Source Routing: Complete path embedded in packet headers eliminates routing table requirements at intermediate nodes, enables route caching through overhearing, but creates header overhead proportional to path length (20 bytes for 10-hop path with 2-byte node IDs)
• Epidemic Routing for DTN: Store-and-forward approach floods packet replicas throughout disconnected networks achieving 95-99% delivery ratio but with 800-1200% overhead, making it suitable only when delivery is critical and energy is abundant
• Zone Routing Protocol (ZRP): Hybrid approach uses proactive routing within zone radius (2-3 hops typically) and reactive discovery for distant destinations, with bordercasting reducing query flooding compared to pure reactive protocols
• Context-Aware Routing: Exploits predictable mobility patterns to selectively forward packets only to high-utility neighbors, achieving 85-90% delivery with 200-350% overhead (3-5x more efficient than epidemic) for battery-limited mobile IoT devices with regular movement routines

Interactive Quiz: Match Concepts

Interactive Quiz: Sequence the Steps

87.7 Knowledge Check

Auto-Gradable Quick Check

Related Chapters

Fundamentals:

• Ad-hoc Fundamentals - Core ad-hoc networking concepts
• Multi-hop Fundamentals - Path discovery and routing basics

Protocol Details:

• Ad Hoc Routing: Proactive (DSDV) - Table-driven routing
• Ad Hoc Routing: Reactive (DSR) - On-demand source routing
• Ad Hoc Routing: Hybrid (ZRP) - Zone-based routing

Production:

• Ad-hoc Production and Review - Real-world implementation frameworks

Learning:

• Simulations Hub - Network simulation tools
• Quizzes Hub - Additional routing protocol quizzes

Alternative View: Protocol Selection Decision Flow

This variant presents ad-hoc routing protocol selection as a decision flow based on network characteristics, helping practitioners match protocols to deployment scenarios.

Figure 87.3: Alternative view: Protocol selection depends on multiple factors. Stable networks benefit from proactive routing (always-ready routes). Mobile networks need reactive or hybrid approaches. Disconnected networks require DTN with multi-copy replication or intelligent utility-based forwarding.

Alternative View: Overhead vs Delivery Trade-off Spectrum

This variant shows ad-hoc protocols positioned on a continuous spectrum between overhead and delivery ratio, illustrating the fundamental trade-off.

Figure 87.4: Alternative view: All routing protocols exist on a spectrum trading overhead for delivery reliability. Single-copy protocols minimize resources but risk message loss. Epidemic protocols maximize delivery at extreme overhead costs. Practical deployments choose protocols in the middle zones based on application requirements.

87.8 Visual Reference Gallery

Visual: Ad Hoc Network Schematic

Schematic visualization of an ad hoc network topology

This diagram illustrates the basic ad hoc network structure that forms the foundation for the routing protocol simulations in this lab chapter.

Visual: Ad Hoc Routing Protocols Overview

Classification of ad hoc routing protocols

This visualization shows the taxonomy of routing protocols covered in the lab exercises, helping contextualize DSDV, DSR, and ZRP comparisons.

Visual: Flying Ad Hoc Networks (FANETs)

FANET architecture and UAV ad hoc networking

FANETs represent a specialized ad hoc network scenario where the lab concepts apply to highly mobile UAV networks with unique routing challenges.

87.9 What’s Next

If you want to…	Read this
Review ad hoc routing protocols	Ad-Hoc Multi-Hop Routing
Study DSDV performance evaluation	DSDV Evaluation
Learn DSR routing in depth	DSR Fundamentals and Route Discovery
Explore hybrid ZRP approach	Ad Hoc Routing: Hybrid (ZRP)
Review production ad hoc patterns	Ad Hoc Networks Review