Start with devices that have to pass useful data before any fixed network is guaranteed. In Lab: Ad-Hoc Networks and Quiz, the first question is not the protocol name; it is which neighbors, routes, failure signals, and degraded behaviors you would trust in the field.
The lab becomes easier when you follow one packet instead of trying to understand the whole network at once. Ask who created it, which neighbor heard it, why that neighbor forwarded it, and what evidence shows the route worked.
That packet story connects simulation, measurement, and quiz questions. Start with one route trace, then change traffic, topology, or mobility and explain why the proof changes.
Use this lab chapter as a sequence:
Checkpoints recap what you have covered; collapsed sections are deeper references.
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.
The lab’s “shrink radio range” fault injection and the “Battery voltage sag affecting range (not modeled)” limitation noted later in this chapter are the same physics wearing two names. A radio’s range comes from a link budget: transmit power minus path loss must still clear the receiver’s sensitivity. Path loss itself grows two ways – with distance, through spherical spreading (inverse-square, the Friis relationship), and with obstruction, through a log-distance exponent \(n\) that rises as more walls and bodies sit in the path. But transmit power is not fixed either: as a mobile node’s battery sags under load, its internal resistance eats into the voltage actually available to the power amplifier, quietly shrinking the same link budget that \(n\) and distance already spend. A simulator that lets you drag a “range” slider is modeling the outcome of all three effects at once, which is exactly why a fault that shrinks range needs a note about which cause – distance, obstruction, or battery – is intended before the result is trusted.
Spherical spreading gives free-space path loss at reference distance \(d_0\):
\[PL(d_0) = 20\log_{10}\!\frac{4\pi d_0}{\lambda}\]
The log-distance model extends that reference across distance \(d\) with path-loss exponent \(n\) (\(n=2\) free space, higher \(n\) for obstructed indoor paths):
\[PL(d) = PL(d_0) + 10\,n\log_{10}\frac{d}{d_0}\]
The maximum range comes from solving the link budget \(B = P_t - P_{rx,sens}\) for \(d\), after reserving a fade margin \(M\):
\[\log_{10} d = \frac{(B - M) - PL(d_0)}{10\,n}\]
A battery’s internal resistance sags the terminal voltage under load, which caps the power actually reaching the antenna:
\[V_{term} = V_{oc} - I\,R_{int}\]
Roadmap stop one is the scenario contract. Before choosing a protocol, freeze the conditions that make that choice true.
An ad-hoc protocol choice is not proven by a protocol label. It is proven by a scenario record: node count, radio range, movement pattern, traffic cadence, packet lifetime, delivery target, overhead budget, and energy limit. The same protocol can look strong in one record and weak in another.
This lab should therefore treat DSDV, DSR, ZRP, and DTN routing as candidates under test. DSDV pays periodic state cost for quick forwarding. DSR pays discovery and header cost when traffic appears. ZRP pays local proactive cost and bordercast discovery cost based on zone radius. Epidemic DTN pays replication cost to survive disconnection.
The first deliverable is the scenario contract. Freeze the coordinate system, random seed or mobility trace, packet size, offered load, radio range model, queue capacity, run duration, warm-up interval, and stopping condition before looking at results. If those inputs move between protocols, the lab is testing configuration drift instead of routing behavior.
Separate protocol correctness from deployment fit. A dense, connected mesh may let every candidate deliver packets, but the right result still depends on first-packet delay, control bytes per data byte, delivery before packet expiry, route repair time, and the energy proxy attached to each relay. The lab recommendation should name the scenario where it is valid and the change that would make the result expire.
Keep one evidence pack per test run. Include the random seed or mobility trace, traffic schedule, radio range, initial topology, protocol settings, measured outputs, and a short interpretation. That makes the result repeatable and prevents a single chart from becoming a general recommendation.
For ZRP, record zone radius and network diameter together. For DSR, record route-cache timeout and average path length. For DSDV, record update period and invalidation behavior. For DTN, record TTL, replica limit, buffer occupancy, and contact assumptions. Those parameters explain the trade-off more clearly than the protocol names alone.
Start with sanity tests before the comparison run. A one-hop topology should deliver without discovery noise, a deliberately disconnected graph should fail or store packets in the expected way, and a replayed mobility trace should produce the same result when the seed and code revision are unchanged. If using a simple NetworkX model, state that MAC contention, propagation loss, and queueing are approximations. If using ns-3 or OMNeT++, record the propagation, PHY, MAC, and queue models because those choices change the measured overhead.
Report the evidence as a scenario-by-protocol table, not as one winner chart. Include packet delivery ratio, median and tail latency, normalized routing load, route discoveries, route errors, buffer drops, average hop count, and a relay-energy proxy. If confidence intervals overlap, the honest recommendation is "no clear winner under this scenario" or "rerun with a longer trace," not a forced protocol label.
End the pack with an operator-facing decision record: selected protocol, rejected alternatives, parameter values, confidence limits, and the field condition that triggers retesting.
Ad-hoc routing protocols move state cost between tables, packet headers, control floods, local zones, and buffers. There is no free choice. A proactive table can reduce first-packet delay while consuming periodic airtime. A source route can reduce intermediate table state while adding header bytes. A DTN replica can raise delivery probability while consuming energy and buffer space.
The hidden risk is stale state. Mobility changes neighbor sets, cached paths, zone membership, delivery utility, and buffer contents. A strong lab result shows how the selected protocol notices stale state, withdraws or repairs it, and limits the cost of that repair.
Measurement state can bias the result as much as routing state. DSDV may look excellent if tables are fully warmed before the first application packet; DSR may look worse if every run begins with an empty route cache; DTN may look better if buffers are already populated before the measured window. Reset state consistently, record warm-up policy, and separate formation transients from steady-state delivery.
Add one explicit fault injection to the lab: break a link, pause a carrier, shrink radio range, or move a gateway out of contact. Then inspect the mechanism that follows. DSDV should advertise fresh invalidation, DSR should emit route errors and purge bad cache entries, ZRP should bound bordercast scope, and DTN should expire or drop replicas according to policy. The acceptance test is bounded recovery without loops, black holes, uncontrolled floods, or hidden buffer growth.
That acceptance proof should be visible in the trace, not only in aggregate metrics: a route table update, route error, bordercast count, or buffer-drop event should explain the final chart.
Checkpoint: Scenario Evidence
You now know:
“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!
By the end of this chapter, you will be able to:
What is this chapter? Practical exercises for ad-hoc networking protocols (DSDV, DSR, ZRP, DTN).
When to use:
Protocols Covered:
Prerequisites:
Recommended Path:
You have the vocabulary and evidence checklist. Next, make the packet move through a repeatable lab.
Simulate and compare DSDV, DSR, and Epidemic routing protocols for IoT scenarios.
Enhance your learning with these hub resources:
Related lab tools:
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.
Example comparison data:
Scenario: 30-node tactical network, 500m×500m area, random waypoint mobility
Why This Happens:
DSDV Overhead:
DSR Overhead:
The Math:
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.
We’ll use Python with NetworkX to simulate a mobile ad hoc network:
Checkpoint: Lab Setup
You now know:
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:
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 (7.4% 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.
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:
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.
The quiz sections name the trade-offs. The implementation turns ZRP into a small graph experiment you can inspect line by line.
This comprehensive implementation demonstrates the hybrid routing paradigm that combines proactive intra-zone routing with reactive inter-zone route discovery.
The implementation below keeps the graph model small enough for a notebook while preserving the main ZRP behavior: proactive lookup inside the local zone and reactive border search when the destination is outside that zone.
from collections import deque
def shortest_path(graph, source, target):
"""Return a hop-by-hop path in an unweighted adjacency-list graph."""
queue = deque([(source, [source])])
seen = {source}
while queue:
node, path = queue.popleft()
if node == target:
return path
for neighbor in graph.get(node, []):
if neighbor not in seen:
seen.add(neighbor)
queue.append((neighbor, path + [neighbor]))
return None
def routing_zone(graph, source, radius):
"""Return all nodes within the configured ZRP zone radius."""
queue = deque([(source, 0)])
zone = {source}
while queue:
node, distance = queue.popleft()
if distance == radius:
continue
for neighbor in graph.get(node, []):
if neighbor not in zone:
zone.add(neighbor)
queue.append((neighbor, distance + 1))
return zone
def border_nodes(graph, source, radius):
"""Return zone-edge nodes that should receive bordercast queries."""
zone = routing_zone(graph, source, radius)
return {
node
for node in zone
if any(neighbor not in zone for neighbor in graph.get(node, []))
}
def zrp_route(graph, source, target, radius):
"""Find a route using local proactive lookup, then reactive bordercast."""
local_zone = routing_zone(graph, source, radius)
if target in local_zone:
return {
"mode": "IARP local",
"path": shortest_path(graph, source, target),
"queries": 0,
}
frontier = deque(border_nodes(graph, source, radius))
visited = set(local_zone)
queries = len(frontier)
while frontier:
border = frontier.popleft()
path_to_border = shortest_path(graph, source, border)
border_zone = routing_zone(graph, border, radius)
if target in border_zone:
path_to_target = shortest_path(graph, border, target)
return {
"mode": "IERP bordercast",
"path": path_to_border + path_to_target[1:],
"queries": queries,
}
for next_border in border_nodes(graph, border, radius):
if next_border not in visited:
visited.add(next_border)
frontier.append(next_border)
queries += 1
return {"mode": "unreachable", "path": None, "queries": queries}
graph = {
0: [1, 5],
1: [0, 2, 6],
2: [1, 3, 7],
3: [2, 4, 8],
4: [3, 9],
5: [0, 6, 10],
6: [1, 5, 7, 11],
7: [2, 6, 8, 12],
8: [3, 7, 9, 13],
9: [4, 8, 14],
10: [5, 11],
11: [6, 10, 12],
12: [7, 11, 13],
13: [8, 12, 14],
14: [9, 13],
}
for radius in (1, 2, 3):
result = zrp_route(graph, source=0, target=14, radius=radius)
print(radius, result["mode"], result["path"], result["queries"])1 IERP bordercast [0, 1, 2, 3, 4, 9, 14] 13
2 IERP bordercast [0, 1, 2, 3, 4, 9, 14] 6
3 IERP bordercast [0, 1, 6, 11, 12, 13, 14] 3The route remains six hops in this toy topology, but the number of bordercast queries falls as the zone radius increases. In a full simulation, that query count should be combined with the proactive table-maintenance cost for each radius.
1. Hybrid Routing Paradigm:
2. Intra-Zone Routing:
3. Inter-Zone Routing:
4. Zone Radius Tradeoff:
5. Bordercasting Optimization:
6. Performance Metrics:
7. Notebook-Ready Features:
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.
Checkpoint: ZRP Mechanics
You now know:
Scenario: 30-node DSDV network experiences link failure. Calculate time until all nodes have consistent routing information.
Given:
Steps:
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.
Use simulation to validate protocol selection before expensive hardware deployment.
Simulation Checklist:
Common Simulation Mistakes:
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:
Reality Factors to Model:
Key Lesson: Simulation predicts trends (protocol A > protocol B), not absolute performance. Always validate with real hardware in target environment before full deployment.
Once the simulation works, the risk shifts to trusting weak evidence. These pitfalls keep the recommendation from overfitting one clean run.
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.
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.
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.
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.
Checkpoint: Validation Discipline
You now know:
The remaining sections turn the same ideas into quick review: match the protocol concepts, sequence the simulation workflow, and answer the core trade-off questions before moving to adjacent routing chapters.
This chapter covered ad hoc network routing protocols and simulation for mobile IoT:
Fundamentals:
Protocol Details:
Production:
Learning:
This variant presents ad-hoc routing protocol selection as a decision flow based on network characteristics, helping practitioners match protocols to deployment scenarios.
This variant shows ad-hoc protocols positioned on a continuous spectrum between overhead and delivery ratio, illustrating the fundamental trade-off.
This diagram illustrates the basic ad hoc network structure that forms the foundation for the routing protocol simulations in this lab chapter.
This visualization shows the taxonomy of routing protocols covered in the lab exercises, helping contextualize DSDV, DSR, and ZRP comparisons.
FANETs represent a specialized ad hoc network scenario where the lab concepts apply to highly mobile UAV networks with unique routing challenges.
Ad hoc labs should measure behavior under mobility, failures, traffic load, and route changes. The goal is to explain routing evidence, not just produce a successful packet trace.