9  DSR Worked Examples

emerging-paradigms
adhoc
dsr

9.1 Start Simple

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.

9.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.

9.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.

DSR Route Request flooding from source node A toward destination node F while relay nodes append themselves to the recorded path.
Figure 9.1: 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.

9.3.1 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.

9.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.

9.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.

9.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.

9.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.

9.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.

Decision flow for choosing when DSR route discovery, cached routes, and route repair are appropriate.
Figure 9.2: The practical DSR decision is a balance among route discovery cost, cache freshness, traffic interval, and the route-error behavior expected after movement.

9.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.

9.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.

9.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.

9.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.

9.4.5 Adaptive Cache

Shorten the timeout when Route Errors rise. Lengthen it when routes remain stable and repeated discovery is wasting battery.

9.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.

9.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.

DSR packet structure showing source route information carried with each data packet.
Figure 9.3: DSR packets carry the ordered route, which removes per-hop route-table lookup but adds header bytes to every packet on that path.

9.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.

9.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.

9.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.

9.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.

9.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.

9.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.

9.6 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.

9.7 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.

9.8 See Also