48 Link Quality and Route Repair

48.1 Start With the Field Story

This section: Start With the Field Story — Imagine three sensors sending an alarm to one sink.

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

This section: In 60 Seconds — This chapter reviews link quality as a routing evidence process.

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?

Math Bridge · guided foundationsHow does one exponent spend 17 dB of margin?Let Packet Pete connect wavelength, log-distance loss, received power, and the margin left for a route. Learn the maths

48.3 Learning Objectives

This section: 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

This section: WSN Link Quality Review

48.5 Prerequisites

This section: Prerequisites — 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.

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

This section: Link Quality Review Scope — Link quality review starts with the application decision, not with a metric formula.

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

48.7 Evidence Map

This section: Evidence Map — The Evidence Map claim needs a visual check.

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 Figure 48.1 starts with the monitoring claim, then asks for traffic, link observations, reverse acknowledgements, and probe age. Its worked route compares a direct one-hop link with a two-hop path through a relay. The ledger uses forward and reverse delivery together; the relay path totals 2.22 expected transmissions against 2.60 for the direct link. Hop count alone would select the direct route, while this delivery evidence favors the relay. The choice still needs repair and fallback evidence, because a measured link can age or fail. An owner and retest trigger keep the route decision tied to current conditions.

48.8 Measurement Proof Limits

This section: Measurement Proof Limits

48.9 Evidence Record

This section: Evidence Record — Treat the map at Figure 48.2 as the evidence boundary for 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.

+

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.

48.10 Reviewing Hop Count Against Link Quality

This section: Reviewing Hop Count Against Link Quality — Hop count is a topology clue, not a routing acceptance test.

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 Figure 48.3 places two paths between a sensor and border router. Path A has more hops but steadier links; Path B has fewer hops and a lossy link. The return route is shown because acknowledgements and control traffic must work in the reverse direction. The review box asks for hop count, ETX, and policy together. A shorter path can therefore be weaker for this workload if loss, stale measurements, or repair cost hides behind the hop metric. The section’s decision record needs current retry and probe evidence for the chosen parent, not a count of links alone.

48.11 Reverse Links and ACKs

This section: Reverse Links and ACKs — Many routing decisions fail because the forward path looks healthy while the reverse path is weak.

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.

48.12 Reviewing Estimation Windows

This section: Reviewing Estimation Windows — Link estimation needs a memory of recent behavior, but stale memory can keep bad links in service.

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.

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.

+

Figure Figure 48.4 puts a noisy reception trace beside its smoothed estimate over time. The empirical line jumps and dips; WMEWMA follows the broad shifts with a lag while damping short-lived changes. This helps explain the window choice in the section: reacting to every packet can make a route unstable, but smoothing too much can keep a failing parent selected. The trace is illustrative, so the reviewer still needs real probe scope, sample age, forward and reverse delivery, and parent-change logs for a deployed link. The estimator weight should be judged against that evidence and the workload.

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

+

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.

Link-evidence ledger fields for candidate parent or next-hop review.

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.

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.

+

Figure Figure 48.6 shows D choosing a route to sink S by summed edge cost. D reaches A at 0.2 and A reaches S at 0.3, giving 0.5 through A. The route through B costs 0.7 plus 0.2, or 0.9. D’s table therefore lists A as the next hop to S even though B is also a direct neighbor. The worked graph makes the metric choice visible, but it does not prove that these costs stay current. The surrounding ledger asks for probe age, reverse acknowledgements, retry behavior, and repair observations before accepting a live route.

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

+

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

This section: Reviewing Path Cost — The derivation has boundaries.

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

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:

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

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.

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

This section: Worked Review: Building Sensor Route — Scenario: Room sensors report regular environmental readings to a building gateway.

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

48.15 Worked Review: Event Query Route

This section: Worked Review: Event Query Route — Scenario: A gateway occasionally asks whether a region crossed a condition.

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.

48.16 Common Mistakes

This section: Common Mistakes

48.17 Review Checklist

This section: Review Checklist — monitoring claim, traffic pattern, freshness need, and sink boundary.

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

This section: Knowledge Check: Link Quality Evidence

48.19 Knowledge Check: Reverse Link Risk

This section: Knowledge Check: Reverse Link Risk

48.20 Knowledge Check: Repair Evidence

This section: Knowledge Check: Repair Evidence

48.21 Match Link Evidence to Review Meaning

This section: Match Link Evidence to Review Meaning

48.22 Order a Link Quality Route Review

This section: Order a Link Quality Route Review

48.23 Summary

This section: Summary — WSN routing link quality is a review discipline, not a single number.

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

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

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

This section: Concept Relationships

48.26 What’s Next

This section: 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.