8 DSR Worked Examples

8.3.1 Selection Workflow: Route Discovery Walkthrough

1. Source asks: the incident commander has no cached path to firefighter F3, so it broadcasts a RREQ containing the source, destination, request ID, and an initial route record.
2. Relays append: neighboring relays add their node IDs before forwarding. A relay that has already seen the same source and request ID drops the duplicate.
3. Destination replies: the destination returns a RREP along the selected route, commonly the first valid route it receives unless the implementation keeps evaluating alternatives.
4. Source sends: the source caches the route and places the ordered hop list in each data packet so relays know exactly which next hop to use.

8.3.2 Emergency Route Example

In a small response network, IC can reach F3 through IC-R1-R3-F3 or IC-R2-R4-F3. If the IC-R1-R3-F3 request reaches the destination first, F3 can send a RREP for that path. With a 3-hop route and a modeled 10 ms per-hop processing plus airtime budget, discovery is roughly 3 hops outward plus 3 hops back, or about 60 ms before the first data packet can use the route.

8.3.3 Latency Driver

First-route latency depends mainly on the number of hops traversed and the delay at each hop. On a cache miss, the timing includes the Route Request traveling towards the destination and the Route Reply returning to the source. Per-hop processing, airtime and contention on those paths contribute to the wait before data can use the learned route. Network size affects a different measure: the aggregate work of discovery. More nodes may receive and forward requests, increasing shared airtime use and contention even when the first successful route is short. Assess discovery by recording both the delay until a usable reply arrives and the wider flood overhead.

8.3.4 Duplicate Guard

Relays recognize repeated Route Request copies using the combination of source identity and request ID. When a relay has already seen that pair, it drops the duplicate rather than forwarding it again. This matters because requests spread along different paths, and repeated forwarding through loops can multiply transmissions and consume shared airtime. The guard requires each relay to retain recent source and request ID pairs, so duplicate suppression also has a memory cost. Those records should remain available through the discovery window rather than expiring immediately after forwarding. In a trace, distinguish a request being forwarded from a repeated copy being suppressed: both contribute to understanding the flood’s behavior.

8.3.5 Route Knowledge

The source should trust routes that reach it through a RREP or a valid cache entry. It should not assume every path observed somewhere in the flood is ready to use.

8.4.1 Cache Timeout Example

Consider a port-yard exercise where container trackers move often and report every 60 seconds. If movement changes useful paths about every 90 seconds, a 300-second cache timeout is too long. The source is likely to reuse a path after the physical neighbor relationships that made it valid have changed.

8.4.2 Energy Example

In a wildlife tracking exercise, collars report periodically and move slowly relative to the reporting interval. A fresh discovery before every report would flood the network repeatedly. If the route remains usable for about 45 minutes, caching across several reports can cut discovery energy substantially while preserving a workable stale-route risk.

8.4.3 Fresh Every Time

Starting a fresh discovery before each report favors route freshness but incurs repeated discovery overhead. Each discovery uses shared airtime, consumes energy and adds a wait for the request and reply before data can use the returned route. This policy is appropriate when the cost of attempting stale routes outweighs the cost of flooding, or when reports are so infrequent that useful route reuse is unlikely. Where paths remain usable across several reporting intervals, repeated discovery gives up the energy savings available from caching. Choose this approach using measured movement, reporting intervals, route-error frequency and discovery cost, including the effect of delayed first packets on the application.

8.4.4 Fixed Cache Window

A fixed timeout gives cached routes a defined reuse window chosen from measured movement and reporting intervals. The useful relationship is whether another report is likely to occur while the stored relay sequence remains valid. A longer window can reduce discovery floods when paths are stable, while a window extending beyond useful topology changes can lead to stale-route failures. A route lifetime observed in a slowly moving deployment should therefore be reassessed before use in a vehicle-speed topology. Expiry and failure feedback serve separate purposes: reaching the timeout ends age-based trust, while a Route Error identifies a failed hop that can invalidate a younger entry. Evaluate the setting against field measurements and discovery costs.

8.4.5 Adaptive Cache

Adjust the cache timeout using evidence from route reuse and failure. Rising Route Error frequency is a reason to shorten the period for which stored routes are trusted, because cached relay sequences may no longer match reachable links. When routes remain stable and repeated discovery consumes battery unnecessarily, a longer timeout can allow more reuse between floods. Assess these changes alongside reporting intervals, observed movement, discovery cost and delays caused by stale routes. Timeout adjustment complements targeted invalidation: a Route Error still requires affected cached paths to be removed or marked unusable. Record cache age, failure feedback and the resulting repair or discovery action so the policy can be assessed against deployment behavior.

8.4.6 Route Error Recovery Example

When W1 can no longer reach W2 on a cached path TL-W1-W2-W3-CP, W1 reports the broken link with a Route Error. The source removes affected cached routes and either uses a known alternate path or starts a new RREQ. For urgent traffic, backup route records or lightweight route checks reduce the time spent discovering after a failure.

8.5.1 Audit the Packet Math

8.5.2 Source Routing Overhead Example

If a packet carries an 8-hop route and each compact node ID takes 2 bytes, the route list alone is 16 bytes. With a 20-byte sensor payload, the route list is 16 / (16 + 20), or about 44 percent of the packet before other headers. That is acceptable for some sparse traces and too expensive for many high-rate flows.

8.5.3 Repair Timing Example

A stale cached route fails only after a relay tries to use it and cannot reach the next hop. If detection takes 100 ms, the RERR takes 15 ms to reach the source, and a new discovery takes 200 ms, the source spends roughly 315 ms before it can send on a new route. A valid alternate cached route can skip the discovery part, but only if the source actually has that alternate route record.

8.5.4 Asymmetric Knowledge

An intermediate relay can answer a Route Request using a cached route. The reply gives the source a route record it can store and use, but it does not transfer the relay’s wider cache contents. Nodes can therefore hold different route knowledge within the same network.

This distinction matters during repair. An alternate path known by another node is not automatically available to the source. The source can skip rediscovery only when it holds a valid alternate route record itself. When reading a trace, separate the route returned in the reply from other paths observed or cached elsewhere. Then check the source’s actual cache before deciding whether recovery can use an alternate.

8.5.5 False Confidence

A successful transmission shows that a route carried traffic at that time. Movement, sleeping devices, or changed radio links can make the stored hop sequence unusable before the next packet. Keeping the entry in a cache does not establish current reachability.

Assess reuse through cache age, route-error history, and observed mobility. Age and failure evidence have different meanings: an old route may still work, while a recently learned route may already contain a reported broken hop. Expiry limits how long an entry remains trusted; a Route Error identifies a specific link failure. Remove affected routes and check alternates for that failed hop before reuse. Otherwise, confidence based on earlier delivery can become repeated failure and additional repair delay.

8.5.6 Protocol Boundary

Standard DSR repairs after failure. Applications with strict alert deadlines may need route probes, backup routes, or a different routing family.

8.6.1 Start Simple

Reject the Route That Worked Yesterday

Picture a mobile sensor reusing a saved path after one relay has moved away. A protocol means the agreed rules and message order devices use to exchange routing information.

Name the source route, cache entry, relay, link-failure signal, expiry rule, and rediscovery action. Test a fresh route, a broken link, a stale alternate, and repeated movement.

Keep cache age, packet path, failure notice, repair choice, delay, and traffic cost. This proves one maintenance rule and movement pattern, not every network; the deeper sections cover caching, errors, salvage, expiry, and rediscovery.

8.6.2 Start With a Cached Route That Might Be Wrong

A DSR cache is helpful until it becomes stale. The node remembers a route so it can avoid rediscovery, but mobility, failed links, and changing traffic can turn that memory into a bad forwarding decision.

Start with one cached route and ask what evidence would make you trust it today. Maintenance is the discipline of detecting broken links, removing bad assumptions, and deciding when discovery must run again.

8.6.3 Cached DSR Routes Expire

Dynamic Source Routing can reuse paths it has discovered or overheard. That reuse is valuable in quiet ad-hoc IoT networks because a sender can avoid another Route Request flood when the same destination is needed again.

The cache is not a permanent map. A cached source route names specific relays, so a moving node, a sleeping device, or a changed radio link can make the route wrong even though it is still stored locally. DSR route maintenance is the discipline that removes broken promises before they become repeated packet loss.

The practical question is therefore not “does the node have a route?” but “can this particular hop list still be defended?” A route learned seconds ago from a stable rack of sensors may be safe enough for another burst, while a route learned before a robot turned a corner may be stale. The cache policy has to match the deployment’s movement, duty cycle, and traffic pattern.

Maintenance also needs the right fault scope. If one adjacent hop fails, every cached source route containing that hop is suspect, but unrelated routes do not have to be discarded. That distinction matters in constrained IoT devices: clearing too little repeats the same broken path, while clearing too much forces avoidable floods, latency, and battery cost. Good DSR operation keeps those two mistakes visible in logs and tests.

For a learner, the mental model is a route notebook with expiration and correction marks. The notebook speeds up forwarding only when each entry has a source, an age, a recent success signal, and a rule for what happens when a relay reports that part of the path no longer works.

Inspect Figure 8.4 and look for the event that lets a relay learn without originating another route request.

+

Follow Figure 8.4 from the packet’s source route to the overhearing relay and its cache. Because DSR carries the route inside the packet, a node that hears the transmission can learn a path even when it was not the intended receiver. A later cache hit lets the source reuse that knowledge and avoid another route-request flood. The validity guard is the critical final element: movement, sleep, interference, or a changed link can invalidate the stored sequence. This supports the chapter’s trade-off between discovery overhead and stale state. Overhearing is useful only when cache age, failure feedback, and route revalidation keep an old shortcut from becoming repeated packet loss.

8.6.4 Bind Cache to Field Signals

A field-ready DSR cache policy needs more than a fixed timeout. The team should record how routes enter the cache, which destinations are worth caching, when a route is too old to trust, what happens after a forwarding failure, and whether a relay is allowed to salvage a packet with an alternate cached route.

+

8.6.5 Maintenance as State Transition

Inside a DSR node, a cache entry is not just a list of hops. It has a destination, a source-route sequence, a time learned, a confidence boundary, and a removal trigger. Route maintenance moves entries between usable, suspect, invalidated, and replaced states as link observations arrive.

The invalidation key is usually more precise than the destination. A Route Error identifies an adjacent-hop pair that failed, so cache maintenance should search for every stored source route containing that pair and mark only those entries unusable. This keeps unrelated paths available while preventing the failed hop from reappearing through a different cached route for the same destination.

Age is a separate signal. A route can be old without being proven broken, and a route can be young but already invalid because a relay reported a failed next hop. Robust implementations keep those reasons distinct: timeout removes entries because confidence has decayed, while a Route Error removes entries because evidence says a specific link no longer carries traffic.

Salvage adds another state transition. If an intermediate relay has an alternate cached path, it may forward the packet without sending it all the way back to the source first. That can reduce delay, but it must still generate maintenance evidence: which route was replaced, which hop failed, which alternate was used, and whether the source cache should be corrected. Without that record, a successful salvage can hide the original fault and let the sender reuse the bad path later.

Backoff closes the loop. When no valid cached path remains, the node returns to route discovery, but repeated discovery floods for the same unreachable destination should be paced. The implementation state machine should therefore connect cache lookup, expiration, Route Error processing, salvage, and discovery backoff rather than treating them as isolated helper functions.

8.6.6 Summary

DSR route caching reduces route discovery overhead when cached source routes remain valid. The same mechanism becomes a liability when mobility, sleep cycles, or link churn make cached relay sequences stale. Route maintenance keeps the cache trustworthy by expiring old entries, reacting to forwarding failures, sending Route Error information back toward the source, and purging only the routes affected by the failed hop.

The practical rule is qualitative: trust cached DSR routes only for as long as the deployment can defend them. Stable, sparse sensor traffic can benefit from longer reuse windows; moving nodes and unstable radio links need shorter trust windows, targeted invalidation, and clear retry behavior.

8.6.7 Key Takeaway

8.6.8 See Also