48 Link Quality and Route Repair

iot

wireless-sensor-networks

routing

48.1 Start With the Field Story

Imagine three sensors sending an alarm to one sink. The path with the fewest hops drops half the messages. A longer path gets the alarm through. Hop count alone chose the wrong route.

Received signal strength is a radio reading that hints at received power. It is often shown as received signal strength indicator (RSSI). It is not a delivery promise. Start with packets sent and received. Check replies in the reverse direction. Record retries, route age, and parent changes. Keep the traffic type and test time with the result. A strong reading from one moment may hide motion, noise, or a weak return path.

Review one route with plain questions:

Did the message arrive?
Did the reply get back?
How many tries were needed?
How old is the route state?
Did one relay carry too much work?
What changed before the path failed?
Was missing data shown as missing?
How did repair begin?
Which path took over?
When must the test run again?

No single radio score proves field service. Practitioner compares delivery, link windows, path cost, and repair traces. Under the Hood explains estimators, moving signals, reverse links, and cost updates. Those details can improve the route choice. They do not make a fresh signal sample proof of future delivery.

Retell the route from evidence. A packet leaves the source. The next hop receives it. A reply may return. A retry shows extra work. A relay may carry too much. Route state can grow old. One link can work in one direction. Motion can change the path. Repair needs a clear trigger. The next test uses the same traffic.

A short route is not always a good route. Link-quality review starts with delivery evidence, reverse acknowledgments, sample age, traffic type, and repair behavior so hop count does not hide an unreliable path.

48.2 In 60 Seconds

WSN link quality routing is not just “choose the strongest signal” or “choose the shortest path.” A reviewer needs evidence that the selected path actually supports the monitoring claim: packet delivery, reverse acknowledgment behavior, retries, parent changes, route-state age, relay pressure, freshness, missing-data visibility, and repair behavior.

This chapter reviews link quality as a routing evidence process. ETX, MIN-T, WMEWMA, RSSI, LQI, and packet reception ratios are useful vocabulary, but the review question is broader: what did the route observe, what did it ignore, what assumptions made the metric meaningful, and what deployment change would force retesting?

Phoebe’s Field Notes: Where the Log-Distance Model Comes From

The mathematical gist. At 2.4 GHz, the 1 m free-space reference is 40.05 dB. Extending it to 50 m gives 74.02 dB at $n=2$ but 91.02 dB at the chapter’s obstructed $n=3$ example—16.99 dB more loss. With 0 dBm transmit power and −95 dBm sensitivity, the obstructed ideal margin is only 3.98 dB before shadowing or a required reserve.

48.3 Learning Objectives

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

explain why hop count and signal strength alone are weak routing evidence in WSNs
distinguish delivery evidence, reverse acknowledgment evidence, signal indicators, and route-state evidence
use ETX, MIN-T, WMEWMA, RSSI, LQI, and probe results as bounded review inputs
review link-quality route traces for stale state, relay pressure, repair behavior, and missing-data visibility
build a link-quality routing evidence record with accepted limits, owner, fallback action, and retest trigger

48.4 WSN Link Quality Review

48.5 Prerequisites

This chapter builds on WSN Routing Fundamentals Review, WSN Routing Introduction Review, WSN Routing Challenge Review, WSN Routing Protocol Classification Review, WSN Routing Data Aggregation Review, and WSN Routing Labs and Exercises Review.

If a learner cannot describe source nodes, relay nodes, sinks, parent or next-hop state, acknowledgments, retries, freshness, and route repair, review those chapters before using link-quality metrics.

48.6 Link Quality Review Scope

Link quality review starts with the application decision, not with a metric formula.

Monitoring claim State what the WSN must support: trend, alarm, event query, command delivery, inventory, coverage, or maintenance status.

Delivery evidence Record whether packets, summaries, or query responses arrive with the freshness and completeness the decision requires.

Reverse evidence Check whether acknowledgments, replies, probes, or route-control traffic can travel back reliably enough to avoid false repairs.

Route state Record parent, next hop, gradient, rank, neighbor table, expiry, probe age, and repair timer assumptions.

Relay pressure Identify nodes that carry repeated forwarding work near sinks, gateways, bridges, corridors, or aggregation roles.

Operations loop Name owner, monitoring signals, fallback action, accepted limits, and retest trigger.

48.7 Evidence Map

The Evidence Map claim needs a visual check. In Figure 48.1, Monitoring sits with claim and to clarify the sequence behind Evidence Map.

Figure 48.1: WSN routing link quality evidence map connecting monitoring claim, traffic, link observation, reverse evidence, route state, path choice, repair evidence, and operations review.

Within Figure 48.1, compare Monitoring—which names a responsibility—with claim and, which names a responsibility. Then inspect decision use because it states the supported result. From Monitoring to decision use, the dependency expresses WSN routing link quality evidence map connecting monitoring claim, traffic, link observation, reverse evidence, route state, path choice, repair evidence, and operations review. The Evidence Map evidence record should retain claim and.

48.8 Measurement Proof Limits

RSSI Signal strength can indicate whether a received packet arrived strongly or weakly. It does not prove future delivery, reverse-link quality, or route freshness by itself.

LQI and radio indicators Hardware indicators can help detect link health, but their meaning depends on radio, firmware, channel, and environment.

Packet reception evidence Probe or data delivery history is closer to routing reality, but it needs age, sample scope, traffic type, and failure context.

ETX or MIN-T Expected-transmission style metrics help compare links and paths when forward and reverse delivery evidence is current and representative.

WMEWMA-style estimation Blending recent delivery evidence with longer-term smoothing can reduce noise, but the window, decay, and expiry rules must be visible.

Route trace The trace shows what the protocol chose. It must be reviewed with missing-data, freshness, relay-pressure, and repair evidence.

48.9 Evidence Record

Treat the map at Figure 48.2 as the evidence boundary for evidence record. Its Workload and Traffic pattern, labels identify the conditions that must be checked together.

Figure 48.2: WSN routing link quality evidence record tying workload, assumptions, forward and reverse observations, path evidence, failure exercise, accepted limits, owner action, fallback, and retest trigger to one routing decision.

The evidence changes character across the diagram at Figure 48.2: Workload adds a distinct review condition, Traffic pattern, adds a distinct review condition, then sink boundary adds a distinct review condition. The transition explains the caption’s core point — wSN routing link quality evidence record tying workload, assumptions, forward and reverse observations, path evidence, failure exercise, accepted limits, owner action, fallback, and retest trigger to one routing decision. That point is the next premise in evidence record.

Workload: State traffic pattern, urgency, freshness, completeness, and sink boundary.

Assumptions: Record node roles, radio channel, route-state age, probe behavior, and whether acknowledgments matter.

Observations: Record delivery evidence, reverse evidence, retries, parent changes, route repairs, missing data, and relay pressure.

Decision: Accept, revise, or reject the route choice; record rejected alternatives and accepted limits.

Operations: Name owner, monitoring signal, fallback action, and retest trigger.

48.10 Reviewing Hop Count Against Link Quality

Hop count is a topology clue, not a routing acceptance test. A path with fewer hops can be worse when a link is lossy, asymmetric, stale, overloaded, or hard to repair. A path with more hops can be better when each hop has current delivery evidence, reverse evidence, and repair visibility.

Use this review question: Does the chosen path reduce route risk for this workload, or did the metric simply hide the risky link inside a shorter route?

Use the visual in Figure 48.3 to test Reviewing Hop Count Against Link Quality. Its Sensor and packet labels anchor the comparison behind Reviewing Hop Count Against Link Quality in named system parts.

Figure 48.3: Routing metric comparison where Path A uses more hops with steadier links, Path B uses fewer hops with poorer evidence, and the border-router review checks hop count, ETX, policy, and return route.

Begin the visual walk-through in Figure 48.3 at Sensor, which marks information entry. Then packet marks preserved information, whereas steady names a responsibility. With Sensor against steady, the contrast makes Routing metric comparison where Path A uses more hops with steadier links, Path B uses fewer hops with poorer evidence, and the border-router review checks hop count, ETX, policy, and return route explicit. The Reviewing Hop Count Against Link Quality evidence record should retain packet.

Acceptable evidence: The trace shows why the chosen parent or next hop is better for the workload, including retry behavior and current probe age.

Weak evidence: The trace names a shorter route but does not show delivery, reverse acknowledgment, or repair behavior.

Retest trigger: New interference, moved gateway, channel change, firmware change, traffic change, or repeated parent changes.

48.11 Reverse Links and ACKs

Many routing decisions fail because the forward path looks healthy while the reverse path is weak. If acknowledgments, route replies, control messages, or downlink commands matter, the review must include reverse evidence.

Forward evidence: Did data or probe packets arrive at the next hop or sink?

Reverse evidence: Did acknowledgments, route replies, or control responses return reliably enough to avoid false retransmission or false repair?

Failure clue: Frequent retransmission with apparently good forward delivery can indicate reverse-link weakness or stale state.

Decision output: Revise if the path cannot show both directions needed by the workload and routing protocol.

48.12 Reviewing Estimation Windows

Link estimation needs a memory of recent behavior, but stale memory can keep bad links in service. The review should make estimator behavior visible without overfitting to one fixed parameter.

Recent evidence Does the estimate respond when recent packets fail, route replies stop, or parent changes accelerate?

Longer-term stability Does the estimate avoid route churn when a short disturbance clears and the route remains acceptable?

Expiry How old can link evidence become before the route must probe, expire, repair, or escalate?

Traffic match Are probes representative of the actual data size, timing, direction, and channel conditions?

Hysteresis Does the route avoid switching back and forth when candidates are close or evidence is noisy?

Operations signal Which log, counter, or alert tells the owner that link estimates are stale or unstable?

A WMEWMA-style estimator is a concrete example of the “recent evidence versus longer-term stability” trade named above, not just a name to drop. It snoops the sequence numbers of packets a node already hears from a neighbor, counts how many arrived in the last window, and blends that count into a running estimate rather than trusting either the newest window or the long-run average alone:

EWMA(t_x) = a * MA(t_x) + (1 - a) * EWMA(t_{x-1})

The reason to inspect Figure 48.4 is Reviewing Estimation Windows. Its WMEWMA smooths a noisy link trace and Reception probability elements locate the evidence behind Reviewing Estimation Windows precisely.

Line chart comparing a raw, noisy empirical reception-probability trace to a smoothed WMEWMA estimator over 30 minutes. The empirical trace jumps and dips sharply; the WMEWMA estimate follows the same general trend with a lag, reacting to real shifts while damping short-lived noise. — Figure 48.4: A noisy empirical reception-probability trace against a smoothed WMEWMA estimate over 30 minutes: the estimate follows real shifts with a lag while damping short-lived noise.

Begin the visual walk-through in Figure 48.4 at WMEWMA smooths a noisy link trace, which identifies the measured path. Then Reception probability names a responsibility, whereas Time (minutes) names a responsibility. Using WMEWMA smooths a noisy link trace with Time (minutes), the labels make A noisy empirical reception-probability trace against a smoothed WMEWMA estimate over 30 minutes: the estimate follows real shifts with a lag while damping short-lived noise reviewable. This ties Reception probability back to the Reviewing Estimation Windows claim.

The matched synthetic traces in Figure 48.5 show the timescale shift before an estimator window is chosen.

Matched RSSI axes compare synthetic stationary and moving links. Short smoothing is stable for the stationary link; long smoothing hides fast fades under motion. — Figure 48.5: Matched RSSI axes compare a stable stationary link with a moving link that suffers rapid fades and recoveries.

Compare STATIONARY LINK and MOVING LINK in Figure 48.5 on the same RSSI dBm scale. The left trace shows why one sample is noisy but short smoothing can work; the right trace shows why long smoothing hides fast fades under motion, so mobility evidence must govern the estimator window.

48.12.1 Stationary and Mobile RSSI Are Different Signals

A stationary RSSI trace can occupy a usable band for minutes while a driving trace crosses that same band rapidly and repeatedly. Motion changes distance, orientation, obstruction, multipath phase, and the set of interferers within one estimator window. The contrast matters because an average calibrated on the stationary trace can stay reassuring long after the mobile link has entered a fade.

Consider a windowed estimator

\bar r_k=\frac{1}{W}\sum_{i=k-W+1}^{k} r_i.

Increasing $W$ reduces random variation in a stationary trace, but it also increases response lag. If samples arrive every $\Delta t$ , the oldest evidence is about $(W-1)\Delta t$ old. A vehicle travelling at speed $v$ can move roughly $v(W-1)\Delta t$ while that evidence remains in the average. At 10 m/s, 20 samples spaced 100 ms apart span 19 m—enough to move behind a wall or through several multipath regions.

Use two timescales rather than one unexplained average. Keep a slow estimate for baseline stability, and a fast estimate or innovation term for sudden motion-induced change:

e_k=|r_k-\hat r_{k-1}|, \qquad \alpha_k=\operatorname{clip}(\alpha_{\min}+K e_k,\alpha_{\min},\alpha_{\max}),

\hat r_k=\alpha_k r_k+(1-\alpha_k)\hat r_{k-1}.

Large innovations raise $\alpha_k$ , so the estimate follows a new fade; calm periods lower it, so the estimate rejects short noise. Do not choose $K$ from RSSI appearance alone. Tune it against packet delivery, acknowledgements, speed or mobility state, parent churn, and the cost of a late repair. Record stationary and mobile traces separately, including sampling interval, device orientation, route, speed, packet size, and channel.

The same neighbor table that feeds an estimator like this has its own sizing decision in a dense deployment. A node can snoop or receive packets from far more neighbors than it can usefully keep route state for, so the table needs a rule for which entries survive: keep the neighbors with the strongest current delivery evidence, not simply the first ones heard or the most recent ones heard. A neighbor table with no such rule tends to fill with weak or stale entries that then get chosen as parents on a technicality, which is the same failure this chapter’s repair states already guard against — it just starts one step earlier, at table admission instead of at route selection.

Use a link-evidence ledger when the route compares candidate parents or next hops. The ledger should be one row per candidate transition, not one row for the whole route, so the reviewer can see where the risk lives: a marginal child-to-parent hop, a stressed relay near the sink, an old neighbor-table entry, or a reverse-link problem that appears only during acknowledgment or query traffic.

Ledger field	What to record	What weak evidence hides
Sample scope	Probe or data traffic, packet size, direction, channel, and measurement age.	A link that looked healthy only during setup.
Forward evidence	Delivered packets, retries, missing sources, and whether probes match the workload.	RSSI that is strong while delivery is unstable.
Reverse evidence	Acknowledgments, replies, downlink commands, or route-control responses.	A path that receives data but cannot confirm, repair, or answer.
Estimator rule	ETX or similar score, smoothing window, expiry, and hysteresis threshold.	Old evidence that keeps a failing parent selected.
Repair observation	Parent changes, blacklisted links, retries during repair, and fallback route.	A route that looks accepted but has no tested recovery behavior.
: Link-evidence ledger fields for candidate parent or next-hop review. {#tbl-wsn-routing-link-quality-ledger .wsn-routing-link-quality-table}

Use the visual in Figure 48.6 to test Reviewing Estimation Windows. Its A worked link-cost example and Routing table on D labels anchor the sequence behind Reviewing Estimation Windows in named system parts.

A weighted node graph with sink S connected to A, B, and C, and A and B each connected onward to D and E, with each edge labeled by its link cost. A routing table at D shows the cost and next hop for reaching A, B, and S, where the cheapest path to S runs through A at a summed cost of 0.5 rather than directly through B at 0.7. — Figure 48.6: A worked graph with sink S, candidates A, B, C, D, E, and edge costs, showing D’s routing table choosing the cheaper two-hop path through A over the direct, costlier link through B.

Begin the visual walk-through in Figure 48.6 at A worked link-cost example, which identifies the measured path. Then Routing table on D names a responsibility, whereas Cost names a responsibility. Placing A worked link-cost example before Cost reveals the dependency in A worked graph with sink S, candidates A, B, C, D, E, and edge costs, showing D’s routing table choosing the cheaper two-hop path through A over the direct, costlier link through B. A later Reviewing Estimation Windows review can recheck Routing table on D.

The worked probabilities in Figure 48.7 turn forward and reverse delivery into a route choice rather than a metric name.

Two candidate routes from sensor S to root R show link forward and reverse delivery probabilities, per-link expected transmission calculations, and path totals of 4.58 for two hops and 3.36 for three reliable hops. — Figure 48.7: MIN-T compares a lossy two-hop route with a reliable three-hop route using forward and reverse delivery probabilities on every link.

In Figure 48.7, the DIRECTER · 2 HOPS path pays 1/(.70×.60) and 1/(.65×.70), producing PATH = 4.58. The RELIABLE · 3 HOPS path sums to PATH = 3.36, so the extra hop wins because every cost includes both forward data and reverse acknowledgement delivery.

Now test that comparison as a route decision rather than accepting the totals on sight. The workbench opens with the same two chapter routes: step through the link calculations, observe the per-link success and expected-attempt readouts, and then use the parent-flip preset to isolate reverse delivery as the only changed control.

In the interactive walk-through, begin at Path A, Link 1 and read forward delivery, reverse delivery, their joint success probability, and expected attempts as one evidence chain. Continue through both additive path totals before checking the selected parent; then use Parent flip to show why an unchanged forward value cannot rescue a weak reverse control path.

48.13 Reviewing Path Cost

Minimum-transmission cost makes the forward and reverse evidence explicit. Let $d_f$ be the probability that a data frame arrives in the forward direction and $d_b$ the probability that its acknowledgement arrives back. One attempt succeeds only when both events occur, so—under the usual independence approximation—the success probability is $d_f d_b$ . The number of attempts until success is geometric, giving

MT_{ij}=\mathbb{E}[K]=\frac{1}{d_f d_b} =\frac{1}{d_f}\frac{1}{d_b}.

The reverse term is not optional bookkeeping. If data arrives but the ACK does not, the sender cannot distinguish that outcome from failed delivery and retransmits. For $d_f=0.9$ and $d_b=0.5$ , the link costs $1/(0.9\times0.5)=2.22$ expected attempts, not the $1/0.9=1.11$ suggested by forward delivery alone.

Distance-vector routing adds link costs along a candidate path:

C(i\rightarrow s)=\min_{j\in N(i)}\left(MT_{ij}+C(j\rightarrow s)\right).

This can prefer a longer reliable route. A two-hop route whose links each have $(d_f,d_b)=(0.95,0.95)$ costs

2\times\frac{1}{0.95^2}=2.22,

whereas a direct hop with $(0.55,0.70)$ costs $1/(0.55\times0.70)=2.60$ . Hop count chooses the direct path; MT chooses two dependable hops because their expected total transmissions are lower.

The derivation has boundaries. Delivery samples must match frame size, transmit power, channel, and traffic timing; burst losses violate the independent-trial simplification; retries have energy and delay costs that can differ by node; and stale estimates can create loops or churn. Carry metric sequence/version, estimate age, hysteresis, and parent advertisement with every distance-vector update. Then verify predicted cost against observed transmissions, delay, and loss instead of treating a low numeric metric as proof.

Low-power radio coverage also has a transitional region where links work intermittently. A route estimator should keep those links out of a simple good/bad bucket and move them through visible repair states.

Repair state	Evidence that moves the link	Review question
Healthy	Fresh forward and required reverse evidence stay within accepted limits.	Is the sample representative of the actual workload?
Suspect	Retries rise, acknowledgments become inconsistent, or parent churn begins.	Does hysteresis prevent noise from causing route flapping?
Repairing	The node probes or chooses another parent from a current neighbor table.	Are missing packets and duplicate effects visible during repair?
Quarantined	The link is avoided until fresh evidence proves it has recovered.	What prevents immediate reuse of the same marginal link?
Retesting	A deployment change or incident invalidates old route evidence.	Who owns the retest and fallback decision?
: Gray-link repair states for route acceptance review. {#tbl-wsn-routing-link-quality-repair-states .wsn-routing-link-quality-table}

Local repair is acceptable only when the repair state is observable. If the node silently switches parent while the application loses sources or freshness, the routing layer has hidden the failure instead of repairing the decision path. During repair, the application-level effect still matters: aggregated traffic can hide which source was lost, duplicate packets can inflate an event count, and an alternate parent can move relay pressure to a node that was already close to its duty-cycle or energy limit.

48.14 Worked Review: Building Sensor Route

Scenario: Room sensors report regular environmental readings to a building gateway. Trend visibility and missing-room detection matter more than immediate control.

Workload: Regular source-to-gateway readings with missing-room visibility and maintenance review.

Evidence: Parent changes, retry evidence, probe age, acknowledgments, missing-source evidence, and relay pressure near the gateway.

Decision: Accept a link-quality route only if it distinguishes quiet rooms from failed links and exposes repeated relay stress.

Retest trigger: Gateway relocation, channel change, new obstruction, firmware change, or repeated parent churn.

48.15 Worked Review: Event Query Route

Scenario: A gateway occasionally asks whether a region crossed a condition. The response must show which sources matched, which were missing, and whether results were fresh.

Workload: Event or query traffic with freshness, matching-source, and missing-region visibility.

Evidence: Interest or query scope, source matching, response freshness, duplicate handling, reverse replies, and route expiry.

Decision: Revise if link quality looks acceptable for probes but late responses, missing sources, or stale route state change the decision.

Fallback: Rerun query through an alternate route, widen the evidence window, or mark the region as uncertain until retested.

48.16 Common Mistakes

Signal strength as proof RSSI or a hardware indicator can support review, but it does not replace delivery, reverse, freshness, and repair evidence.

Forward-only review Ignoring acknowledgments or route replies can make a weak reverse path look like a healthy forward path.

Stale estimates Old probe history can keep a failing route alive after topology, traffic, channel, or interference changes.

Metric-only decision An ETX or MIN-T score is not deployment acceptance unless assumptions, sample age, repair behavior, and limits are recorded.

Ignoring relay pressure A reliable link can still be a poor route if it pushes too much forwarding work onto a stressed relay.

No retest trigger Link quality is environmental. The record should say what change invalidates the route evidence.

48.17 Review Checklist

Before accepting link-quality routing evidence, verify that the record includes:

monitoring claim, traffic pattern, freshness need, and sink boundary. chosen route, rejected alternatives, route-state age, and route repair rule. forward delivery evidence, reverse acknowledgment evidence, retries, and parent changes. probe or data sample scope, estimator window, expiry rule, and hysteresis behavior. relay pressure, missing-data visibility, aggregation effect, and exception path. accepted limits, owner, fallback action, monitoring signal, and retest trigger.

48.18 Knowledge Check: Link Quality Evidence

48.19 Knowledge Check: Reverse Link Risk

48.20 Knowledge Check: Repair Evidence

48.21 Match Link Evidence to Review Meaning

48.22 Order a Link Quality Route Review

48.23 Summary

WSN routing link quality is a review discipline, not a single number. Strong review connects signal indicators, delivery evidence, reverse acknowledgments, route-state age, relay pressure, freshness, repair behavior, and operations ownership. Metrics such as ETX, MIN-T, and WMEWMA are useful only when their assumptions and limits are visible.

48.24 Key Takeaway

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

48.25 Concept Relationships

Routing challenges Explains why weak links, stale state, relay pressure, and repair cost make hop count insufficient.

Protocol classification Uses link evidence to compare tree, reactive, geographic, quality-aware, and data-centric family assumptions.

Data aggregation Requires link evidence that summaries preserve source coverage, freshness, missing-member visibility, and exception paths.

Routing labs Turns link-quality review into repeatable lab runbooks, failure exercises, and evidence records.

48.26 What’s Next

Continue with WSN Routing: Trickle Algorithm to review dissemination and repair behavior, then revisit WSN Routing Labs and Exercises Review, WSN Routing Data Aggregation Review, and WSN Routing Protocol Classification Review when a route choice needs stronger evidence.