44 WSN Routing Fundamentals

iot

wireless-sensor-networks

routing

44.1 Start With the Field Story

Follow One Reading Through Every Relay

Picture soil sensors spread across a farm. A reading from the far row must cross three battery nodes before it reaches the sink. The network planner must deliver useful data without making the same relays carry every packet until their batteries fail.

Write the route claim for one reading. Name the source, sink, traffic direction, allowed delay, relay choices, link evidence, stored route state, and repair owner. Mark where readings may be combined and which identity, event time, unit, and quality must survive that step.

Send normal, burst, alarm, and command traffic. Weaken one link, remove a relay, drain a busy node, move the sink, restart route state, and repeat an old packet. Check delivery, delay, energy, duplicates, loops, repair time, and whether combined data can still be explained.

Keep urgent field protection local when a multi-hop path can miss the safe deadline. A short route is not always the best route, and a formed route does not prove trusted or fresh data. Keep a fallback for loss and expose stale state to the operator.

This opening does not pick one routing family. Practitioner builds the path, load, and repair record. Under the Hood examines route state, link cost, energy balance, aggregation, many-to-one pressure, mobility, and recovery.

Use this route check:

Trace one full path.
Lose one relay once.
Time the route repair.
Check the source facts.
Reopen when load shifts.

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 Field Notes: Why Multi-Hop Beats One Long Hop

The mathematical gist. For a total route length of 200 m, splitting one hop into four equal 50 m hops changes the ideal transmit-power ratio to $4^{1-n}$ . That is 0.250, or a 6.02 dB saving, in free space where $n=2$ ; at the chapter’s obstructed example $n=3$ , it is 0.0625, or a 12.04 dB saving. Relay receive, forwarding, and retry energy still have to be added.

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 the visual in Figure 44.1 to test Route Anatomy. Its Multi-Hop Relay Architecture and Source labels anchor the sequence behind Route Anatomy in named system parts.

Multi-hop WSN relay architecture: source nodes forward readings through relay nodes to a sink, with in-network aggregation reducing four flows to two and then to one. — Figure 44.1: A WSN route relays readings from source nodes through relays to the sink, aggregating data along the way to cut traffic.

Read Figure 44.1 through three markers. First, Multi-Hop Relay Architecture identifies the measured path; next, Source marks information entry; finally, Relay 1 identifies the measured path. Placing Multi-Hop Relay Architecture before Relay 1 reveals the dependency in A WSN route relays readings from source nodes through relays to the sink, aggregating data along the way to cut traffic. Carry Source into the next Route Anatomy decision.

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 Scalability and QoS Bounds

Adding nodes expands sensing coverage, but it does not create radio capacity. In a shared multihop channel, more sources also create more contenders, relay work, interference, route state, and traffic near the sink. A useful first-order scaling model is

T_{\text{node}}(N) \propto \frac{1}{\sqrt{N}},

where $T_{\text{node}}$ is the sustainable throughput available to one node and $N$ is the node population. This is a planning law, not a guarantee for every topology. Its value is the warning it provides: if the population grows by a factor of four, the per-node share is expected to fall to roughly one half unless the design adds spatial reuse, channels, sinks, aggregation, scheduling, or another capacity change.

Walk that implication through a concrete deployment. Suppose 100 nodes each have a defensible budget of 8 kbit/s. Growing to 400 nodes without changing the radio plan gives the estimate

8\ \text{kbit/s}\sqrt{\frac{100}{400}}=4\ \text{kbit/s per node}.

The result does not say every node will measure exactly 4 kbit/s. It says a design review cannot multiply the original per-node rate by 400 and call the network scalable. The new population must be tested under the new contention, relay, and interference pattern.

Throughput is only one quality-of-service dimension. Review the four dimensions together:

QoS dimension	What to measure	Why an average can mislead
Bandwidth	useful application bits delivered per second, per flow and at the sink	Aggregate capacity can look healthy while edge nodes are starved.
Delay	time from sensing or enqueue to accepted delivery	A packet can arrive successfully but too late for the decision.
Jitter	variation in delay between successive packets	Mean delay can pass while bursty arrival breaks sampling, playback, or control timing.
Packet-loss probability	missing packets divided by attempted packets for the stated traffic and time window	A quiet-period result hides loss during alarms, interference, or route repair.
: QoS evidence required when a WSN population or RF environment changes.

Changing RF conditions couple these quantities. A fade raises retransmissions; retransmissions consume bandwidth and energy; queueing raises delay and jitter; exhausted retry limits raise loss. Therefore a QoS claim needs a workload, percentile, observation window, topology, channel, and failure condition. For example, “95th-percentile alarm delay below 2 s with packet-loss probability below $10^{-2}$ during the interference test” is reviewable. “Good QoS” is not.

Scale tests should increase offered load and node count separately, then together. Record where queue depth, retry rate, duty-cycle limit, or sink-adjacent relay load becomes the first bottleneck. That breakpoint tells the team whether to aggregate, add another sink, split channels, schedule critical traffic, narrow the reporting rate, or revise the service claim.

44.11 Evidence Record

Before the evidence record argument advances, use Figure 44.2 to reconcile Traffic Use with Reading, alert, query,. The diagram turns that reconciliation into something the team can inspect.

Figure 44.2: WSN route introduction evidence record linking traffic purpose, path roles, link evidence, relay pressure, route state, acceptance, owner, and retest trigger.

At Traffic Use, Figure 44.2 adds a distinct review condition. The visual next names Reading, alert, query, to show where the review identifies the field observation; maintenance message finally assigns operational responsibility. Those concrete stages express the following claim: WSN route introduction evidence record linking traffic purpose, path roles, link evidence, relay pressure, route state, acceptance, owner, and retest trigger. They keep evidence record tied to observable evidence.

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.12 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.13 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.14 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.15 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.16 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.

A list cannot settle Routing Monitoring and Family Fit alone. Inspect Figure 44.3, where Three Routing Metrics and Hop Count make the comparison behind Routing Monitoring and Family Fit concrete.

Figure 44.3: Routing metric comparison showing the same graph choosing different paths under hop count, ETX link quality, and energy-aware routing metrics.

Within Figure 44.3, compare Three Routing Metrics—which names a responsibility—with Hop Count, which identifies the measured path. Then inspect Best: S → B → D because it names a responsibility. With Three Routing Metrics against Best: S → B → D, the contrast makes Routing metric comparison showing the same graph choosing different paths under hop count, ETX link quality, and energy-aware routing metrics explicit. Carry Hop Count into the next Routing Monitoring and Family Fit decision.

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.17 Knowledge Check: Route Metric Aging

44.18 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.19 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.20 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.21 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.22 Knowledge Check: Route Evidence

44.23 Knowledge Check: Relay Pressure

44.24 Match Routing Terms to Evidence

44.25 Order the Introductory Routing Review

44.26 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.27 Key Takeaway

WSN Routing Introduction Review should balance path reliability, link quality, energy cost, latency, aggregation, topology change, control overhead, and deployment evidence.

44.28 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.29 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.