50 Lab: WSN Routing
WSN routing labs, WSN routing exercises, WSN lab runbook, route trace evidence, WSN routing instrumentation, routing failure exercises
50.1 Start With the Field Story
Routing labs should make invisible path choices visible. Begin with a topology and a question, then collect route traces, link measurements, failures, comparisons, and notes about what the lab cannot prove in the field.
50.2 In 60 Seconds
Advanced WSN routing labs are not validated by a simulator screenshot, a single score, or a fixed protocol ranking. A good lab runbook defines the question, topology, traffic, instrumentation, candidate behavior, failure exercise, route trace, metric record, and deployment limit before any result is accepted.
This chapter turns the routing labs page into a lab-quality review process. Learners still practice route discovery, link-quality reasoning, aggregation decisions, Trickle-style dissemination, and failure recovery. The difference is that every exercise must produce evidence that another reviewer can inspect, repeat, challenge, and connect to operations.
50.3 Learning Objectives
By the end of this chapter, you will be able to:
- design WSN routing lab runbooks with clear questions, assumptions, instrumentation, and acceptance limits
- collect route traces, link evidence, relay-pressure observations, freshness evidence, and repair records without overclaiming
- compare routing families using identical traffic and failure exercises
- convert lab outcomes into deployment limits, fallback actions, ownership, and retest triggers
- identify lab evidence that is too narrow, too idealized, stale, or unrepeatable
50.4 WSN Routing Labs Review
50.5 Prerequisites
This advanced lab review assumes familiarity with WSN Routing Introduction Review, WSN Routing Protocol Classification Review, WSN Directed Diffusion Routing Review, WSN Routing Data Aggregation Review, WSN Routing Link Quality, and WSN Routing: Trickle Algorithm.
If the learner cannot explain route state, parent or next-hop choice, link-quality evidence, aggregation boundaries, and repair triggers, pause the lab and review those topics first.
50.6 Lab Review Scope
An advanced lab should be framed as a decision-support exercise, not as a demonstration that one protocol name always wins.
Lab question State the decision being tested: collection route, query route, aggregation boundary, repair behavior, dissemination behavior, or link-quality metric.
Assumptions Record node roles, topology, sink boundary, traffic pattern, route-state limits, coordinate assumptions, and failure model.
Instrumentation Name what will be observed: route trace, parent changes, retries, link probes, missing members, freshness, repair events, and relay pressure.
Candidate behavior Compare family behavior such as data-centric, tree/proactive, reactive, hierarchical, geographic, quality-aware, or dissemination logic.
Exercise variation Run at least one change: weak link, failed relay, stale state, missing source, overloaded cluster role, or version inconsistency.
Review output Record accepted limits, rejected alternatives, monitoring owner, fallback action, and retest trigger.
50.7 Lab Runbook Flow
Use Figure 50.1 to keep the lab reproducible.
The runbook prevents a common lab failure: changing traffic, topology, and metrics at the same time and then treating the result as a fair comparison. A reviewer should be able to rerun the same question, see the same assumptions, and understand why the result does or does not support a deployment decision.
50.8 Game-Style Practice Boundary
Routing games and tabletop exercises are useful when they force learners to expose assumptions, not when they turn protocols into scores. Keep the activity close to the same evidence record used for labs.
Scenario card State the application goal, node roles, sink boundary, traffic direction, and failure exercise before players choose routes.
Visible board state Make link quality, relay load, route state, missing sources, aggregation rules, and repair events visible enough to challenge.
Candidate choice Ask learners to justify the routing family or behavior from evidence, then record the rejected alternatives and why they failed.
Decision record End with accepted limits, operations signal, owner, fallback action, and retest trigger, not only a winning route.
If the practice activity cannot produce a reproducible evidence record, treat it as vocabulary practice rather than deployment support.
50.9 Instrumentation Checklist
Route trace Record parent, next hop, gradient, source route, cluster membership, or dissemination state at the same grain as the lab question.
Link evidence Capture forward and reverse quality when acknowledgments matter, and record retry behavior rather than only a single signal value.
Freshness and completeness Show which sources contributed, which were missing, and whether the result still supports the monitoring claim.
Relay pressure Identify nodes near sinks, bridges, cluster roles, or corridor paths that carry more forwarding work than edge sources.
Repair behavior Record how stale state is detected, repaired, expired, or escalated when a link, relay, source, or sink assumption changes.
Operations signal Name the dashboard, log, alert, or field check that would expose the same issue outside the lab.
50.10 Evidence Record
Use Figure 50.2 as the lab result structure.
The record is intentionally more important than the tool used to produce it. A worksheet, simulator, browser activity, or field test can all be useful when the evidence is clear and bounded.
50.11 Forwarding Evidence Harness
Use Figure 50.3 when the lab needs packet-level explanation, not only a run-level score.
The figure uses generic forwarding labels. In a WSN lab, read them as the available parent, next-hop, gradient, route age, link metric, route expiry, aggregation, repair, or suppression state at the moment a packet is handled. The event log should keep the reason attached to the action: forwarded, delivered, dropped, duplicated, repaired, suppressed, aggregated, or escalated.
That harness prevents false comparison. If one candidate drops a packet because route state expired and another drops it because a policy forbids the path, the same loss count means different things. Accept the lab only for the boundary it tested: topology, traffic pattern, failure exercise, instrumentation, owner, fallback action, and retest trigger.
50.12 Evidence Ledger Fields
Write the lab ledger before any candidate is run. That keeps the team from choosing metrics after seeing which protocol looked better.
| Ledger field | What to record | What it prevents |
|---|---|---|
| Case id | Packet, query, aggregate, repair, or dissemination event being evaluated. | Mixing unlike traffic into one average. |
| Route snapshot | Parent, next hop, route age, link metric, gradient, membership, or fallback path at decision time. | Explaining a result with route state that did not exist yet. |
| Decision rule | Metric, policy, expiry, suppression, aggregation, or repair rule used by the candidate. | Ranking a protocol without knowing which rule acted. |
| Observed action | Forward, deliver, drop, duplicate, repair, suppress, aggregate, or escalate. | Counting delivery while ignoring hidden drops or duplicates. |
| Review limit | Topology, traffic, link condition, failure timing, owner, fallback, and retest trigger. | Turning one controlled run into a universal claim. |
Run candidates against the same ledger shape. If one run records route age, reverse-link evidence, and relay pressure while another records only delivery count, the comparison is not fair. The result may still be interesting, but the report must say that the evidence strength differed.
When a failure exercise is injected, keep before and after snapshots: baseline route, exact change, first symptom, repair action, temporary loss or duplicate behavior, and stable state after repair. Without that sequence, “recovered” is too vague to support operations.
50.13 Exercise 1: Collection Route Trace
Question: Does a tree or proactive collection behavior support regular sensor-to-gateway readings without hiding missing nodes or stale parents?
Run it: Instead of tracing the static runbook figure, operate the multi-hop workbench below. Flood a route request from the source nodes toward the gateway and watch which candidate path is selected under hop count, link quality, and residual energy. Then fail the stressed relay and watch the repair, noting the parent or next-hop change and the forwarding pressure that builds near the gateway. Fill the record below from what the animation shows rather than from a guessed trace.
Setup: Use a many-to-one traffic pattern with source nodes, relays, a gateway, and at least one relay path that is likely to become stressed.
Instrumentation: Record parent changes, retries, route expiry, delivery evidence, missing-source evidence, and relay pressure near the gateway.
Variation: Weaken one relay link or mark a relay unavailable after the baseline route has formed.
Review: Accept only if the trace shows how stale parents are detected and how missing sources are separated from quiet sources.
- baseline path and hop count from each source to the gateway
- changed link or failed relay, plus the first route-repair symptom
- selected replacement route, retry or delay signal, and stale-source list
- accepted limit: topology and traffic pattern where this collection route evidence applies
50.14 Exercise 2: Data-Centric Query Trace
Question: Does a query or interest-style behavior preserve source matching, freshness, and missing-region visibility?
Run it: Use the ad-hoc routing visualizer below to make the on-demand query path visible. Select a reactive protocol (AODV or DSR) so a route is discovered only when the query needs to reach sources, then press Start Discovery and watch the request propagate until a matching path forms. Switch the Scenario to Partition Risk to expose regions the query can never reach (the missing-source evidence), and toggle Mobility on to drop a source after discovery. Use Compare Protocols to keep the run fair, and record what you observe below; freshness and matching semantics stay on the exercise model.
Setup: Define a query region, candidate sources, a sink, expiry behavior, and a rule for duplicate or delayed responses.
Instrumentation: Record interest scope, matching source evidence, response freshness, duplicate handling, and regions with no evidence.
Variation: Add a late response or remove a source after the query has already been issued.
Review: Revise the result if the lab cannot show which sources matched, which were missing, and when the route state expired.
- query sink, candidate source set, and baseline shortest-path tree
- changed cost or removed link, plus the source nodes whose path changes
- stale or unreachable source evidence instead of one clean score
- accepted limit: query region, freshness window, and route-state assumptions
50.15 Exercise 3: Aggregation Boundary Trace
Question: Does aggregation reduce traffic without changing the meaning of the monitoring decision?
Run it: Use the topology comparison workbench below to see the aggregation boundary as real structure. Choose the Cluster-tree topology with the Aggregated farm scenario so each cluster head becomes the aggregation point for its members, then step through the packet paths to read which sources feed which head (the included-member set). Inject “One cluster head down” and watch an aggregation boundary and its members drop out of the summary. Record the boundary membership and the missing-member effect from the animation; keep the summary-function, freshness, and outlier reasoning on the record below.
Setup: Choose a summary function, source membership rule, freshness limit, and exception rule before the run.
Instrumentation: Record included sources, missing members, outliers, aggregation time, summary meaning, and whether raw exceptions remain visible.
Variation: Remove one source or add an outlier reading before the summary is accepted.
Review: Reject aggregation if it hides a source that would change the operational decision.
- aggregation function, member list, and baseline packet count
- removed source or outlier value and the changed aggregate result
- raw exception path or missing-member marker that keeps the decision honest
- accepted limit: when the summary preserves meaning and when it must be rejected
50.16 Dissemination and Repair Trace
Question: Does a dissemination or repair behavior converge without unnecessary repeated traffic after the network becomes consistent?
Setup: Define version state, consistency rule, reset trigger, suppression behavior, and the nodes that should hear an update.
Instrumentation: Record who heard the update, which nodes suppressed repeated messages, when inconsistent state reset the process, and which nodes stayed stale.
Variation: Introduce one stale node or delayed link after the network appears consistent.
Review: Accept only if the lab shows both rapid repair when inconsistency appears and low chatter when all nodes agree.
- stable interval behavior and suppressed-message count before inconsistency
- stale node or delayed link introduced, plus reset timing
- nodes repaired, nodes still stale, and convergence point
- accepted limit: the version state and failure timing this repair evidence covers
50.17 Comparing Candidate Runs
Use the same scenario, traffic, and failure exercise when comparing candidate behavior.
Fair baseline Do not change topology, traffic, or failure timing between candidates unless the lab question explicitly tests that change.
Shared metric set Compare delivery evidence, freshness, repair events, relay pressure, missing-data visibility, and operations effort together.
Bounded conclusion State where the result applies and where it does not: topology, traffic, node role, link condition, and operational assumptions.
Rejected alternatives Name candidate families that looked attractive but failed because assumptions or evidence were missing.
Repeatability Keep the runbook and evidence record complete enough that another reviewer can reproduce the decision.
Retest trigger Identify the deployment change that invalidates the lab result: new gateway, traffic change, firmware change, moved sources, or interference.
50.18 Read the Tail Before the Mean
Aggregate scores are allowed, but inspect the tails before accepting the mean.
| Hidden tail | Evidence to inspect | Why it matters |
|---|---|---|
| Near-sink relay load | Forwarding count, retry count, queue age, and duty-cycle or energy proxy by node. | A healthy mean can hide a relay that will fail first. |
| Weak region | Per-source delivery, stale-source list, link-quality evidence, and missing-member visibility. | One corner can be invisible inside a high packet-delivery average. |
| Repair churn | Parent changes, route expiry, convergence time, duplicates, drops, and fallback actions. | A route can recover eventually while failing the freshness claim. |
| Aggregation loss | Included sources, exceptions, outliers, freshness labels, and raw escape path. | A summary can preserve traffic savings while changing the decision meaning. |
| Dissemination silence | Suppressed sends, reset causes, stale nodes, partitions, and coverage gaps. | Low chatter can mean health, or it can hide stale state. |
Controlled variation turns those tails into evidence. Remove a relay, weaken a link, delay a query response, drop an aggregate member, or introduce a stale dissemination marker. The question is not whether the lab can be made to fail; it is whether the failure is visible at the grain where operations would need to act. If a tail risk cannot be inspected, mark it as a limitation instead of smoothing it into the mean.
50.19 Common Mistakes
Tool output as proof A simulator screenshot, trace file, or score is not proof unless assumptions, instrumentation, and limits are recorded.
Changing too much Comparing two candidates while changing topology, traffic, and failure timing makes the result hard to interpret.
Ignoring reverse evidence When acknowledgments or repairs matter, forward delivery alone can hide reverse-link weakness and repair cost.
Counting only delivered packets Delivery count can hide stale state, freshness loss, missing sources, relay overload, or excessive repair traffic.
Overclaiming from a lab Do not convert one controlled run into fixed lifetime, savings, cost, delivery, or node-count promises without matching field evidence.
No operations owner A lab result that nobody monitors, repairs, or retests is not ready to support deployment decisions.
50.20 Review Checklist
Before accepting a WSN routing lab result, verify that it includes:
- lab question, monitoring claim, traffic pattern, and sink boundary
- topology, node roles, route-state assumptions, and failure model
- instrumentation plan for route traces, link evidence, relay pressure, freshness, missing data, and repair
- candidate behavior compared under the same baseline and exercise variation
- evidence record with observations, rejected alternatives, limits, owner, fallback action, and retest trigger
- statement of what the lab did not prove
50.21 Knowledge Check: Lab Evidence
50.22 Knowledge Check: Fair Comparison
50.23 Knowledge Check: Tail Evidence
50.24 Match Lab Evidence to Its Review Role
50.25 Order a WSN Routing Lab Runbook
50.26 Summary
WSN routing labs and exercises should teach evidence discipline. A strong lab defines the question, controls the baseline, instruments the right signals, injects meaningful change, compares candidate behavior fairly, and records limits before making a decision. The result should help learners understand route behavior while making clear what the lab did and did not prove.
50.27 Key Takeaway
WSN Routing Labs and Exercises Review should leave deployment evidence for route choice, link quality, aggregation behavior, control overhead, failure recovery, and measured energy impact.
50.28 Concept Relationships
Labs and games Introduces practice activities; this chapter tightens those activities into repeatable advanced lab runbooks.
Link quality Supplies instrumentation for retries, forward and reverse evidence, parent changes, and link-health decisions.
Aggregation Adds completeness, missing-member visibility, freshness, outlier handling, and summary meaning to lab records.
Trickle and dissemination Provides exercises for consistency, suppression, reset triggers, and low-chatter repair after updates.
50.29 What’s Next
Return to WSN Routing Introduction Review for the full routing sequence, then revisit WSN Routing Link Quality, WSN Routing: Trickle Algorithm, and WSN Routing Protocol Classification Review when a lab result needs stronger evidence.