Cache Management of Dynamic Source Routing

for Fault Tolerance in Mobile Ad Hoc Networks

Outline

Review DSR Protocol Simulation Results Conclusions References

Review DSR

Route Cache A packet carries the list of routers in the

path Two main operation

Route Discovery Route Maintenance

No periodic messages

Review DSR

Source Node A

If no route in A’s Cache

Source Node B

Source Node C

Node B or C receives the RREQ packet from A , it check the route from it’s

cache

If the cache have the

route

Node reply the route

information to sender node

Else (the cache have no route about the

RREQ packet)

Add node’s address, and broadcast the RREQ to it’s

neighbors again

Simulation of DSR protocol

The performance is better without using cache. In “Analysis of TCP Performance

over Mobile Ad Hoc Networks” Because DSR has no mechanism to

immediately respond to dynamic network topology change.

Reply from cache introduces more routing error.

Improve DSR Cache

We have a idea from AODV Sending link layer beacons

periodically for get signal strengths. But the idea disobeys the protocol’s

design idea Improve Cache management

Protocol Description

Protocol Overview Signal strength “Confirm” message “Route ok” message “Link broken” message “Host needs recovery” message “Neighbor” message

Protocol Overview

Identify whether a route in the cache is correct or not.

A route marked stale is a route which is likely broken.

Neighbor links’ stability By monitoring the signal strength of

received packets from the neighbor node.

Signal Strength

Signal strength of the received packets

Threshold

“Confirm” and “Route OK”

A B C

BCX(S) CX X

A senses B’s signal strength beyond the threshold and wants to recovery the “stale” route BCX as normal

Node A sends a “confirm” message to node B to ask whether the route BCX can work or not.

B receives A’s “confirm” message

If B has route CX in its cache, then B sends “route ok” message to A with route BCX

If B does not have any match with A’s “confirm” message or the route CX is marked as stale, then B

does not do anything.

“Link Broken”

A B C

BCX CX X(s)

D

If C discards a “stale” route X, then is broadcasts a “link broken” message include node X

Link broken message (X)

Link broken message (X)

B and D receives the “link broken” message, it discard the route and tries to find a route to that destination

If found, then it stop and does nothing further.

If no found, then it broadcasts “link broken” message again

Link broken message (X)

WX

“Host needs recovery” and “Neighbor”

When a node restarts after its failure, it broadcasts “Host needs recovery” message to its neighbors.

When a node receives a “Host needs recovery”, it uses “neighbor” message to show that it is his neighbor now.

Advantages and Disadvantages

Advantage Do not send any periodic information

or signals so that we can keep the advantages of DSR.

Disadvantage We passively wait for packets and

measure their signal strength. A link may be stable but we discard it

since no packets are received form it.

Simulation Environment Network model consists of 30 nodes in

a 1500*300 meter flat rectangular area. Each node picks a random destination

and speed in the area and then travels to he destination in a straight line.

Bandwidth:2Mbps Transmission radius:250m TCP packet size:1460 bytes

Simulation Results of Link Failure

Simulation Results of Link Failure

Simulation Results of Link Failure

Simulation Results of Link Failure

Simulation Results of Host Failure

Simulation Results of Host Failure

Simulation Results of Host Failure

Simulation Results of Host Failure

Conclusions The simulations showed that we have

improved the performance of reply from the cache in DSR significantly, which is almost equivalent to that of no cache reply mechanism.

For future work we suggest that when designing a routing protocol for ad hoc networks, it is important to consider the host failures as well as the link failures.

References

G. Holland and N. Vaidya, “Analysis of TCP Performance over Mobile Ad Hoc Networks” in Proceedings of IEEE Mobicom’99, Seattle, WA, Auguest1999, pp.219~230