44 WSN Routing Fundamentals
WSN routing introduction, wireless sensor network routing, WSN sink routing, WSN relay pressure, WSN route state, WSN routing evidence
44.1 Start With the Field Story
Routing starts with a reading that must reach a sink without exhausting the nodes that help it. Follow one packet through source, relay, aggregation, link choice, repair, and monitoring before choosing a protocol family.
44.2 In 60 Seconds
WSN routing is the evidence-backed process of moving sensor readings, alerts, queries, and control traffic between source nodes and a sink or gateway. It is not only a shortest-path problem. A useful WSN route must match the traffic direction, node roles, relay pressure, link quality, route state, aggregation boundary, and monitoring evidence that the application depends on.
Use this chapter as the entry point for the routing sequence. The goal is to learn the routing vocabulary and review record before choosing a protocol family. A good routing introduction answer should explain what moves, where it moves, which nodes relay it, what state is stored, what can fail, and what evidence proves the path is still acceptable.
Phoebe’s Why
A WSN does not relay because a mesh diagram looks resilient; it relays because path loss punishes distance so steeply that splitting one long radio hop into several short ones can cost less total transmit energy than one direct shot – even though every relay adds its own receive-and-forward energy tax. Free-space power falls as the inverse square of distance, and real cluttered environments fall even faster. That is the physics behind this chapter’s own warning that “relay work can dominate energy” near a sink: the geometry favors many short hops, and the relay nodes are exactly where that favor’s hidden cost lands.
The Derivation
Power spreads over a sphere of radius \(d\):
\[S = \frac{P_t}{4\pi d^2} \quad\Rightarrow\quad \mathrm{FSPL} = \left(\frac{4\pi d}{\lambda}\right)^2\]
The log-distance model generalizes the exponent to real environments:
\[\mathrm{FSPL}(d) = \mathrm{FSPL}(d_0) + 10n\log_{10}(d/d_0)\]
with \(n = 2\) in free space and higher with obstacles. Since required transmit power to hold a fixed received power scales the same way, \(P_t \propto d^{\,n}\). Splitting one hop of length \(D\) into \(k\) equal hops of length \(D/k\) changes the total transmit-power budget by:
\[\frac{k \times (D/k)^{n}}{D^{n}} = k^{\,1-n}\]
Worked Numbers: One Long Hop Versus Four Short Ones
Illustrative corridor scenario, since this chapter names no specific hop distance: one \(D = 200\) m hop split into \(k = 4\) hops of 50 m each.
- Free space (\(n = 2\)): power ratio \(= 4^{1-2} = 0.250\), a \(10\log_{10}(1/0.250) = 6.02\) dB reduction in total transmit-power budget from geometry alone
- Cluttered/obstructed path (\(n = 3\), typical indoor or industrial exponent): power ratio \(= 4^{1-3} = 0.0625\), a \(10\log_{10}(1/0.0625) = 12.0\) dB reduction – the multi-hop advantage grows as the environment gets harder, which is why cluttered deployments lean even more on mesh relaying than open-field ones
Neither number includes the relay’s own receive-and-retransmit energy, or a fade margin above the nominal path-loss figure – both real costs this chapter’s “relay pressure” and route-repair evidence are built to catch. The 6-12 dB win is the reason to relay at all; the relay-node energy ledger is the reason not to relay through the same few nodes forever.
44.3 Learning Objectives
By the end of this chapter, you will be able to:
- define WSN routing in terms of sources, relays, sinks, gateways, paths, and route state
- explain why WSN routing review starts with traffic direction and monitoring evidence
- separate path reachability from link quality, relay pressure, route repair, and aggregation meaning
- describe the evidence a beginner should collect before naming a routing protocol family
- build a routing introduction record with assumptions, accepted limits, owner, and retest triggers
44.4 WSN Routing Introduction
44.5 Prerequisites
This chapter builds on Wireless Sensor Networks Overview and prepares learners for WSN Routing Protocol Classification Review. If the learner cannot identify sensor nodes, relay nodes, sinks, gateways, and many-to-one reporting, review the overview chapter first.
44.6 What Routing Means in a WSN
Routing describes how data and control messages move across the sensor network. In many WSN deployments, several source nodes report toward one sink, and some nodes forward data for others.
Source node A node that creates a reading, alarm, status update, or response to a query.
Relay node A node that forwards another node’s packet. Relay work can dominate energy and reliability near sinks, cluster heads, or corridors.
Sink or gateway The collection point that receives sensor data or sends queries, commands, schedules, and maintenance traffic.
Path The sequence of wireless hops used by a packet. A path can be short and still weak if links are lossy or unstable.
Route state The parent, neighbor, rank, gradient, cluster, sequence, or repair information a node stores to decide the next hop.
Traffic direction The movement pattern: sensor-to-sink readings, sink-to-node queries, local neighbor exchange, firmware distribution, or alarm priority traffic.
The routing review begins by naming these pieces. Without them, a route diagram is just a picture of connectivity, not evidence that the monitoring application will work.
44.7 Routing Introduction Scope
An introductory routing review should answer six questions before protocol names appear.
What must move? Periodic readings, rare alarms, queries, commands, status reports, time sync, or firmware updates have different route needs.
Where must it move? Most traffic may move toward one sink, but some designs also need local exchange, downlink commands, or multiple gateways.
Who carries relay load? Nodes near a sink or bridge may spend much of their work forwarding other nodes’ data. That load must be visible.
Which evidence defines a good link? RSSI alone is not enough. Delivery, retries, asymmetry, parent changes, and measurement age matter.
What state must be stored? Parents, neighbors, gradients, cluster roles, caches, and repair timers all consume resources and can become stale.
When should the route be retested? Gateway movement, enclosure changes, sampling changes, firmware changes, traffic mix, battery state, or site conditions can invalidate earlier evidence.
44.8 Route Anatomy
Use Figure 44.1 to describe a WSN route without jumping directly to a protocol label.
The diagram separates roles from protocol names. The same source, relay, and sink pattern can later be implemented by tree, data-centric, hierarchical, geographic, reactive, or quality-aware behavior. The introductory review only asks whether the route evidence is complete enough to support a later classification.
44.9 Why WSN Routing Is Different
WSN routing differs from ordinary network routing because the application decision often depends on data meaning, not just destination reachability.
Many-to-one traffic is common Many nodes may report toward one sink. The edge can look quiet while relays near the sink are overloaded or failing.
Energy is a review constraint Battery limits matter, but an introductory review should avoid fixed lifetime promises unless they come from measured workload and device evidence.
Wireless links change Walls, enclosures, moisture, interference, movement, antennas, and gateway placement can change delivery quality after a route is first accepted.
Data meaning matters Combining readings can reduce traffic only when the aggregate preserves identity, freshness, missing-member evidence, and decision meaning.
Route state can age A parent, neighbor, gradient, or cluster role may be correct during setup and stale during operation.
Operations must see failures Missing nodes, weak links, repeated repairs, duplicate packets, gateway outages, and stale data need visible monitoring signals.
44.10 Evidence Record
Use Figure 44.2 to turn a routing explanation into an auditable record.
Traffic claim: State the reading, alarm, query, command, or update the route must carry.
Path evidence: Record source, relay, sink, direction, alternate path, and gateway boundary.
Link evidence: Record delivery, retries, asymmetry, parent changes, and measurement age.
Relay evidence: Record which nodes forward other nodes’ traffic and what monitoring shows about their health.
State evidence: Record the route state each node stores and how stale state is detected or repaired.
Decision: Accept, revise, or reject the route; name the owner, fallback action, and retest trigger.
44.11 Path and Role Evidence
Route evidence is strongest when every important role is visible.
Source evidence Identify which nodes create data, how often they report, how urgent the data is, and what missing data means to the application.
Relay evidence Identify nodes that receive and forward other nodes’ packets. Check whether relay work is concentrated near the sink or a bottleneck.
Sink evidence Record where the sink or gateway sits, what it receives, what it sends back, and how the route behaves during gateway maintenance or loss.
Boundary evidence Name where the WSN route ends and where IP, cloud, local storage, or operator workflow begins.
An introductory routing answer should avoid saying “the network is connected” as the final claim. It should say which traffic was tested, which roles carried it, and which failures remain visible.
44.12 Link Quality and Relay Pressure
The first route a packet uses may not be the route the system should keep using. A short path with weak links can create repeated retries and repairs. A longer path through stable links may be easier to operate. A relay close to the sink may also carry a much heavier workload than edge nodes.
Useful link signals Delivery ratio, retry count, parent changes, neighbor stability, asymmetry checks, stale measurements, and route-repair events.
Useful relay signals Forwarded packet share, queue pressure, missed reports, repeated retransmissions, duty-cycle pressure, and health compared with nearby non-relay nodes.
Unsafe shortcuts Accepting one successful packet, one signal-strength reading, one path trace, or one lab result as proof that the route will hold in the deployment.
The beginner-level habit is simple: a route is not only a line on a diagram. It is a set of measured behaviors that must stay within accepted limits.
44.13 Route State and Repair
Every routing method stores or infers some state. The introductory review should ask what state exists, where it is stored, and what happens when it becomes wrong.
Parent or next-hop state A node may remember a preferred relay toward the sink. The review should show how that parent was chosen and when it changes.
Neighbor state Nodes may maintain a view of nearby nodes and link quality. The review should include measurement freshness and missing-neighbor behavior.
Interest or gradient state Query-driven routing may store reverse paths or content interests. The review should show scope, lifetime, duplicate handling, and expiry.
Cluster or role state Hierarchical routing may assign cluster heads or aggregation roles. The review should show role load, rotation, member visibility, and repair.
Repair is part of routing, not an afterthought. A route design that works only until the first weak link, dead relay, moved gateway, or stale parent is not ready for acceptance.
44.14 Aggregation Boundaries
WSNs often reduce traffic by filtering, suppressing duplicates, or combining readings. That can be useful, but it changes the evidence that reaches the sink.
Aggregation is acceptable when The aggregate preserves the decision meaning, source coverage, freshness, missing-member evidence, and outlier policy.
Aggregation is risky when The summary hides a failed node, a local outlier, a stale reading, an overloaded relay, or a sensor region that the decision depends on.
Introductory review question Ask whether the sink can still tell which data was measured, which data was missing, and when the route or aggregation rule should be retested.
This chapter does not require learners to choose a data aggregation protocol. It only prepares them to ask whether the route preserves enough evidence for the later data-aggregation chapter.
44.15 Routing Monitoring and Family Fit
Protocol-family names are useful vocabulary only after the route evidence is visible. A beginner review can compare tree or proactive collection, data-centric queries, reactive repair, geographic hints, hierarchical clusters, and dissemination behavior without treating any label as automatic approval.
Family fit Match the traffic pattern, state lifetime, repair need, relay burden, and sink boundary before naming a preferred routing family.
Monitoring baseline Record normal delivery, retry, parent-change, relay-load, queue, missing-node, and freshness signals before alert thresholds are accepted.
Alert discipline Set alerts from measured behavior and operational impact, not from universal packet-loss or signal-strength numbers copied from a different deployment.
Failure response Name who investigates weak links, stale parents, gateway loss, overloaded relays, duplicate traffic, and missing sources, plus the fallback action.
The routing introduction should leave learners with an operations habit: choose routing behavior from the evidence record, monitor the evidence after deployment, and reopen the route decision when the signals drift.
A routing metric is a contract about what the route may optimize and what it may sacrifice. A hop-count metric sacrifices link quality and relay balance for short paths. A link-quality metric may spend more energy to avoid lossy hops. An energy-aware metric may accept delay or longer paths to protect a critical relay.
Use Figure 44.3 to make the metric contract visible. The same network can produce different accepted paths when the metric changes. A route introduction should therefore state which metric made the path best, which candidate paths were rejected, and which evidence could make the decision expire.
A parent-choice ledger is the practical record behind that claim:
| Ledger field | What to record | Failure it exposes |
|---|---|---|
| Candidate next hops | Visible neighbors, gateway reachability, role, parent history, rejected candidates, and alternate path. | The route looks deterministic even though the node had no acceptable backup. |
| Link evidence | Delivery ratio, retries, ETX, asymmetry check, sample age, parent changes, and repair events. | A strong-looking parent was selected from stale or one-way link evidence. |
| Relay cost | Forwarded packet share, queue pressure, battery trend, duty-cycle pressure, and downstream dependency. | The selected relay becomes the hidden bottleneck for many sources. |
| Data meaning | Freshness need, alarm priority, aggregation boundary, missing-member visibility, and fallback data path. | A route preserves packets but loses the evidence needed for the decision. |
| Expiry and owner | Metric lifetime, retest trigger, alert threshold, route owner, and manual recovery action. | The path remains accepted after the conditions that justified it have changed. |
Separate path existence, path quality, and path meaning. Path existence means a packet can traverse the hops. Path quality means delivery, retries, repair, and relay load are within accepted limits. Path meaning means the delivered data is still fresh, attributable, complete enough, and visible to the decision owner. A route can pass the first test and fail the other two.
Most practical WSN routing decisions combine imperfect signals: ETX, remaining energy, queue pressure, measurement freshness, recent repairs, and traffic priority. Those signals age while routes continue to use them. A parent that was good during commissioning can become weak after moisture, interference, enclosure changes, gateway movement, battery decline, or a traffic burst.
Two companion rules keep the route from drifting. Expiry says how long each measurement can justify a route. Hysteresis says how much better a candidate must be before a node changes parent. Without expiry, stale routes persist. Without hysteresis, tiny measurement noise can cause parent churn, duplicate traffic, routing loops, or repeated repair overhead.
| Signal | Expiry question | Repair risk |
|---|---|---|
| Link quality | How recent are delivery, retry, asymmetry, and parent-change measurements? | Stale ETX keeps a weak parent or triggers needless churn. |
| Relay load | How current are queue, forwarded-share, duty-cycle, and battery observations? | A relay is accepted after it has become the bottleneck. |
| Data freshness | How old can a reading be before the route no longer supports the claim? | Packets arrive, but too late for the monitoring decision. |
| Aggregation state | How long can a summary hide missing members, outliers, or stale inputs? | The sink receives a clean aggregate that no longer proves coverage. |
The introductory standard is not a full routing equation. It is a route decision that says which measurements drove the path, when those measurements expire, what threshold prevents noise-driven churn, and what fallback protects the monitoring claim when no candidate remains acceptable.
44.16 Knowledge Check: Route Metric Aging
44.17 Worked Review: Building Monitoring
Scenario: Battery sensors report room temperature and door-state changes to a building gateway. Most readings are routine, but missing rooms must be visible because they affect maintenance decisions.
Traffic claim: Routine readings and occasional door-state events move toward one building gateway.
Route roles: Some hallway nodes may relay room-node traffic, so their health must be compared with non-relay nodes.
Evidence needed: Parent changes, retry counts, missing-room visibility, gateway maintenance behavior, and whether local summaries preserve room identity.
Decision: Accept the introduction record only if route-health monitoring can distinguish a quiet room from a failed node or stale route.
44.18 Worked Review: Remote Field Gateway
Scenario: Field sensors report soil and equipment status to a gateway at the edge of the deployment. The site has changing moisture, seasonal plant growth, and limited maintenance visits.
Traffic claim: Periodic status readings and rare alerts move across multiple hops to an edge gateway.
Route roles: Nodes between the field and gateway may become long-term relays, so relay pressure and link quality must be reviewed separately.
Evidence needed: Link measurements across site conditions, alternate path behavior, stale-neighbor detection, repair events, and gateway outage handling.
Decision: Revise the route if evidence depends on a single season, a single gateway placement, or a single successful test pass.
44.19 Common Mistakes
Starting with a protocol name Directed Diffusion, LEACH, GPSR, RPL, and similar names are useful later. They do not replace traffic, role, link, and state evidence.
Calling one packet a route test A single delivered packet proves only that one packet arrived. It does not prove sustained delivery, repair, relay health, or missing-node visibility.
Ignoring relay nodes Relays may fail before source nodes because they carry other nodes’ traffic. A route review must make that load visible.
Trusting signal strength alone Signal strength can help diagnosis, but delivery, retries, asymmetry, and route changes are closer to the routing question.
Hiding missing data with summaries Aggregation is not acceptable when it hides failed nodes, stale readings, outliers, or coverage gaps that the decision needs.
No retest trigger A route accepted before gateway movement, enclosure changes, sampling changes, or firmware updates may no longer represent the deployed system.
44.20 Review Checklist
Before accepting an introductory WSN routing explanation, verify that it records:
- traffic type, direction, urgency, and decision use
- source, relay, sink, gateway, and boundary roles
- link-quality evidence beyond one signal or one packet
- relay-pressure evidence near sinks, bridges, cluster heads, or corridors
- route-state evidence and repair behavior
- aggregation boundaries and missing-data visibility
- accepted limits, owner, fallback action, and retest trigger
44.21 Knowledge Check: Route Evidence
44.22 Knowledge Check: Relay Pressure
44.23 Match Routing Terms to Evidence
44.24 Order the Introductory Routing Review
44.25 Summary
WSN routing introduction is about evidence, not memorizing a protocol. A useful routing explanation names the traffic, source nodes, relay nodes, sink or gateway, route state, link evidence, relay pressure, aggregation boundary, monitoring signals, and retest triggers. Once those pieces are visible, later chapters can review routing challenges, protocol classification, data aggregation, link quality, Directed Diffusion, and related WSN routing families without drifting into unsupported claims.
44.26 Key Takeaway
WSN Routing Introduction Review should balance path reliability, link quality, energy cost, latency, aggregation, topology change, control overhead, and deployment evidence.
44.27 Concept Relationships
Routing challenges The challenge chapter expands relay pressure, lossy links, repair cost, and aggregation risk.
Protocol classification The classification chapter maps evidence patterns to routing families without treating protocol names as automatic answers.
Data aggregation The aggregation chapter reviews when summaries preserve meaning and when they hide missing or stale data.
Link quality The link-quality chapter reviews delivery, retries, asymmetry, route changes, and measurement freshness.
44.28 What’s Next
Continue with WSN Routing Protocol Classification Review to map evidence to routing families. After that, review WSN Routing Data Aggregation, WSN Routing Directed Diffusion, and WSN Routing Link Quality for deeper route-design patterns.