8 DSR Worked Examples
8.1 Start Simple
Follow One Packet From Search to Repair
Picture a rescue tracker discovering a route, using it twice, then losing a relay as the team moves. A protocol means the agreed rules and message order devices use to exchange routing information.
Name the request, reply, source route, cache entry, failed link, error, and repair choice. Step through discovery, forwarding, cache reuse, break detection, and rediscovery.
Keep every packet path, identifier, cache change, delay, and delivery result. This proves one worked lifecycle, not every mobility pattern; the deeper examples compare good reuse with stale knowledge and repair costs.
Start with devices that have to pass useful data before any fixed network is guaranteed. In DSR Worked Examples, the first question is not the protocol name; it is which neighbors, routes, failure signals, and degraded behaviors you would trust in the field.
8.2 Start With the Route Lifecycle
A worked DSR example is easiest to read as a lifecycle: discover a route, use it, cache it, notice when it breaks, and repair or rediscover it. Each packet carries part of that story.
Start with one source route in the header and follow how the network treats it. The example matters because it shows when cached knowledge saves airtime and when that same knowledge becomes a liability.
8.3 Overview: Read DSR as a Route Lifecycle
Dynamic Source Routing examples are useful only when they show the whole route lifecycle. A source broadcasts a Route Request, relays append themselves to the route record, the destination returns a Route Reply, and the source then sends packets with the complete source route in the header.
That lifecycle lets you trace why DSR can be efficient for sparse traffic and why it can stumble in mobile networks. The same cache that saves a flood on one packet can become stale after nodes move, causing a route error and a fresh discovery.
A worked trace should separate the first route that reaches the destination from the total work done by the network. The first route is governed by hop count, per-hop delay, contention on the chosen path, and the reply path back to the source. The wider flood cost is different: many other nodes may hear, forward, and then suppress duplicate copies even though only one route becomes the first usable answer.
That split is the reason DSR examples can look deceptively simple. A three-hop path in a large network may be found quickly, while the surrounding flood still consumes enough airtime to matter for battery and channel occupancy. The example is complete only when it names both values: first-packet delay for the application and aggregate discovery overhead for the mesh.
Use a worked example to answer four questions: which route was learned, how old that route is, how much airtime the discovery used, and what happens when the next hop is no longer reachable.
Before overview: Read DSR as a Route Lifecycle, inspect Figure 8.1 to compare “Path 1” with “Path 2”. Their juxtaposition makes A DSR Route Request spreads outward and accumulates a path record. Duplicate filtering keeps each relay from forwarding the same source and request ID repeatedly visible.
Read Figure 8.1 from “Path 1” to “Path 2”. Taken together, “Path 1” and “Path 2” express A DSR Route Request spreads outward and accumulates a path record. Duplicate filtering keeps each relay from forwarding the same source and request ID repeatedly. For overview: Read DSR as a Route Lifecycle, the observed relationship between “Path 1” and “Path 2” is evidence that “Path 1” carries into the next decision.
8.3.1 Route Discovery Walkthrough
- 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.
- 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.
- Destination replies: the destination returns a RREP along the selected route, commonly the first valid route it receives unless the implementation keeps evaluating alternatives.
- 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 is mainly path length times per-hop delay. More nodes increase flood overhead and contention, but the fastest successful path is still hop-bound.
8.3.4 Duplicate Guard
The source and request ID pair lets relays drop repeated RREQ copies. Without this guard, the flood can multiply through loops and burn shared airtime.
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 Tune Cache Age to Mobility
DSR cache settings should be chosen from deployment behavior, not from a generic default. A cached route is valuable when traffic reuses it before the topology changes. It is harmful when it points through a relay that has moved, powered down, or become unreachable.
The field measurement should therefore pair route-cache decisions with the events that made them good or bad. Record the reporting interval, the observed time between useful neighbor changes, route-error frequency, and the cost of one new discovery. Those four values turn “short cache” or “long cache” from a guess into an engineering decision that can be defended after a mobility test.
Before tune Cache Age to Mobility, inspect Figure 8.2 to compare “[B,D,F]” with “Yes”. Their juxtaposition makes the practical DSR decision is a balance among route discovery cost, cache freshness, traffic interval, and the route-error behavior expected after movement visible.
Read Figure 8.2 from “[B,D,F]” to “Yes”. Taken together, “[B,D,F]” and “Yes” express the practical DSR decision is a balance among route discovery cost, cache freshness, traffic interval, and the route-error behavior expected after movement. For tune Cache Age to Mobility, the observed relationship between “[B,D,F]” and “Yes” is evidence that “[B,D,F]” carries into the next decision.
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.
| Setting | Operational meaning | Likely result | When to use it |
|---|---|---|---|
| Very short cache | Expire routes after only a few seconds. | Fresh routes, but frequent discovery floods. | Fast-moving vehicles or high route-error rates. |
| Mobility-aligned cache | Keep routes for about half to one mobility interval. | Balanced freshness and discovery overhead. | Moderate movement with repeated traffic on the same flow. |
| Long cache | Keep routes for many minutes. | Low discovery overhead if topology is stable; stale-route failures if it is not. | Slow-moving or fixed deployments with sparse but repeated traffic. |
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
Best freshness, worst discovery overhead. Use this only when stale routes are more costly than flooding, or when traffic is so rare that reuse is unlikely.
8.4.4 Fixed Cache Window
Set the timeout from measured movement and reporting intervals. A 45-minute route should not be reused blindly in a vehicle-speed topology.
8.4.5 Adaptive Cache
Shorten the timeout when Route Errors rise. Lengthen it when routes remain stable and repeated discovery is wasting battery.
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.
Do not tune cache timeout from a static testbed alone. Measure route-error rate, movement interval, reporting interval, and the cost of delayed first packets in the actual deployment environment.
8.5 DSR Header, State, and Repair
The mechanics behind DSR examples are small enough to audit, but each one has a scaling consequence. Source routes grow with path length, duplicate filters consume state, route caches can become asymmetric, and route repair is triggered only after a forwarding failure is detected.
Before DSR Header, State, and Repair, inspect Figure 8.3 to compare “Route List” with “Hop Index”. Their juxtaposition makes DSR packets carry the ordered route, which removes per-hop route-table lookup but adds header bytes to every packet on that path visible.
Read Figure 8.3 from “Route List” to “Hop Index”. Taken together, “Route List” and “Hop Index” express DSR packets carry the ordered route, which removes per-hop route-table lookup but adds header bytes to every packet on that path. For DSR Header, State, and Repair, the observed relationship between “Route List” and “Hop Index” is evidence that “Route List” carries into the next decision.
8.5.1 Audit the Packet Math
| Mechanic | What to calculate | Why it matters | Design response |
|---|---|---|---|
| Discovery delay | RREQ hops outward plus RREP hops back, multiplied by per-hop delay. | Controls first-packet latency on a cache miss. | Pre-warm critical routes or use proactive routing for hard latency limits. |
| Source-route header | Route entries times bytes per node ID, compared with payload size. | Small telemetry payloads can become mostly route header on long paths. | Limit path length, compress route identifiers, or use hop-by-hop routing. |
| Duplicate filter | Recent source and request ID pairs held by each relay. | Prevents broadcast multiplication but requires enough memory for active discoveries. | Expire duplicate state after the discovery window, not immediately after forwarding. |
| Repair delay | Ack timeout, RERR propagation, cache lookup, and possible new discovery. | Stale routes turn one packet into a delay spike and extra airtime. | Track route-error rate and maintain alternates for critical destinations. |
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 from its cache. The source learns the returned route, but it does not automatically learn every route known elsewhere in the network.
8.5.5 False Confidence
A route that worked once is not proof of current reachability. Cache age, route-error history, and mobility observations all matter.
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 DSR Caching and Route Maintenance
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.
Start with devices that have to pass useful data before any fixed network is guaranteed. In DSR Caching and Route Maintenance, the first question is not the protocol name; it is which neighbors, routes, failure signals, and degraded behaviors you would trust in the field.
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.
Think of DSR caching as a short-lived operational record: it is useful only while the path, link quality, and application tolerance still match the route that was learned.
Before cached DSR Routes Expire, inspect Figure 8.4 to compare “Relay” with “Source”. Their juxtaposition makes A DSR node can learn route information by overhearing packets that carry a source route, then reuse that route when it is still valid visible.
Read Figure 8.4 from “Relay” to “Source”. Taken together, “Relay” and “Source” express A DSR node can learn route information by overhearing packets that carry a source route, then reuse that route when it is still valid. For cached DSR Routes Expire, the observed relationship between “Relay” and “Source” is evidence that “Relay” carries into the next decision.
8.6.3.1 What to Remember
- Cache hit: a valid cached route can skip discovery delay and reduce control traffic for repeated sparse communication.
- Cache age: the acceptable lifetime depends on link churn. Faster movement or more variable links require shorter trust windows.
- Broken link: when a relay cannot reach the next hop in the source route, the route must be invalidated instead of retried blindly.
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.
Before bind Cache to Field Signals, inspect Figure 8.5 to compare “Dest” with “data”. Their juxtaposition makes when a forwarding link breaks, DSR route maintenance sends a Route Error back toward the source and removes routes that contain the failed hop visible.
Read Figure 8.5 from “Dest” to “data”. Taken together, “Dest” and “data” express when a forwarding link breaks, DSR route maintenance sends a Route Error back toward the source and removes routes that contain the failed hop. For bind Cache to Field Signals, the observed relationship between “Dest” and “data” is evidence that “Dest” carries into the next decision.
8.6.4.1 Cache Maintenance Ledger
| Decision | Record | Why it matters | Failure signal |
|---|---|---|---|
| Cache admission | Which learned or overheard routes may be stored, and whether partial or overheard routes are trusted. | Unfiltered caching can fill memory with routes that will never be reused. | Many entries age out unused or crowd out the route actually needed. |
| Cache lifetime | Expiration rule tied to observed mobility, link churn, traffic cadence, and device sleep behavior. | A route that is safe in a stable sensor mesh may be stale in a moving robot or vehicle scenario. | Packets repeatedly fail on routes that are old but still accepted. |
| Route Error handling | How the source receives a Route Error and removes every cached route containing the failed hop. | Targeted invalidation preserves good alternatives while removing known-bad paths. | The source keeps retrying the same broken relay sequence. |
| Salvage policy | Whether an intermediate relay may replace a broken route with another cached path, and how that action is logged. | Salvage can save a packet, but hidden rerouting can make debugging difficult if it is not bounded. | Packets arrive by unexpected paths with no record of the repair. |
8.6.4.2 Operational Flow
- Learn the route: store routes from successful discovery or trusted overhearing with a timestamp and destination.
- Reuse deliberately: use a cached source route only if its age and link history still fit the deployment.
- Detect the break: treat failed next-hop delivery, link-layer feedback, or missing acknowledgement as a route-maintenance event.
- Purge narrowly: remove routes containing the failed hop, then use a valid alternate or begin fresh discovery.
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.5.1 Cache States
- Usable: the route is young enough, the destination is still needed, and no known failed hop appears in the sequence.
- Suspect: the route is aging, a relay has weak recent delivery, or mobility suggests that a fresh discovery may be cheaper than repeated failure.
- Invalidated: a Route Error or delivery failure has identified a broken hop. All entries containing that hop are removed or marked unusable.
Do not let salvage hide failure. If an intermediate relay substitutes another cached path, the source still needs a record that the original hop failed, otherwise the same stale route may be reused later.
8.6.5.2 Implementation Checks
- Cache lookup rejects expired routes before packet transmission.
- Route Error processing removes every route containing the failed adjacent-hop pair.
- Alternate cached routes are checked for the same failed hop before reuse.
- Discovery backoff prevents rapid repeated floods for the same unreachable destination.
- Logs expose the route used, the cache age, the invalidation trigger, and the final retry action.
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
A DSR cache entry is not proof of a current path. It is a temporary route promise that must expire, be invalidated by Route Errors, or be replaced by fresh discovery when the topology changes.
8.6.8 See Also
8.7 Summary
DSR worked examples should trace the protocol from discovery to repair. The route request and reply explain first-packet latency. The cache explains why sparse traffic can save energy. Route errors explain why stale entries become delay spikes. Source-route headers explain why long paths and small payloads can make DSR expensive even when discovery itself succeeds.
8.8 Key Takeaway
DSR is strongest when traffic is sparse, routes are short enough for source headers to stay modest, and cache lifetimes are matched to measured mobility. The practical skill is not memorizing one timeout or path rule; it is reading each trace for freshness, overhead, and repair cost before trusting the route.