CPSC 689: Discrete Algorithms for Mobile and Wireless Systems

CPSC 689: Discrete Algorithms for Mobile and Wireless Systems

Spring 2009

Prof. Jennifer Welch

Discrete Algs for Mobile Wireless Sys 2

Lecture 14 Topic:

Routing in Mobile Wireless Networks Sources:

Karp. Multi-hop wireless networks. Vaidya, Chapter 6. Schiller, Chapter 8. Johnson, Maltz. Dynamic source routing in ad hoc wireless

networks. Perkins, Royer. Ad hoc on-demand distance-vector routing. Chen, Murphy. Disconnected transitive communication. MIT 6.885 Fall 2008 slides


Point-to-Point Routing New problem: Deliver messages from a particular source node

S to a particular destination node D, in a mobile ad hoc network.

Main issue: S, and other nodes, don’t (initially) know where D is.

Similar to the basic IP routing service provided in the Internet: send message to a particular IP address.

Easier in Internet: fixed infrastructure, with wires, routers, backbone networks,…

But still important in wireless setting. Very widely studied, proposals currently being put forth for

practical routing methods.


Overview of Routing Internet-style approaches, not taking advantage of the wireless setting:

Destination-Sequenced Distance Vector (DSDV) Dynamic Source Routing (DSR) Ad-Hoc On-Demand Distance Vector Routing (AODV)

A simple algorithm that tries to take advantage of mobility. Link-reversal algorithms

[Gafni, Bertsekas 81] Temporally-Ordered Routing Algorithm (TORA)

Location-free routing Routing using some substitute for geography. Geographical routing without location information, Gradient Routing

(GLIDER), Beacon Vector Routing Location services

Keeping track of geographical locations of mobile nodes. [Awerbuch, Peleg 91], GRID, LLS

Location-based routing Routing using actual geography. Geocasting, location-aided routing (LAR), compass routing, GPSR,…


The Setting Wireless networks, no infrastructure, no

hierarchical structure. Dynamic:

Stationary and/or mobile nodes. Failure/recoveries

Scale: Small or large, even Internet-scale. Typical examples:

Rooftop networks, of customer-owned radios; stationary, large-scale.

Floating sensors: mobile, large-scale. Ad-hoc meetings, rescue workers in disaster

areas, soldiers in battle…


The Routing Problem Sender S anywhere in the network wants to send a

message to a particular node D somewhere else in the network.

Doesn’t know where D is. Subproblem: Set up a route (end-to-end path) to

that node. Routes may need to change, in response to

network changes. Some routing strategies don't set up routes, just

send messages one step at a time. Real goal is delivering messages, not setting up

routes.


Criteria Criteria:

Accommodate large scale, mobility Minimize communication overhead for sending data

messages Maximize packet delivery success rate Minimize latency of packet delivery Minimize route length (e.g., number of hops) Minimize amount of state that must be maintained at each

node Usual strategies for coping with scale:

Hierarchy: Good when level boundaries are relatively fixed, can be chosen by administrative authority.

Caching (e.g., for routes) But these don't work so well for dynamic or unstructured

networks.


Reuse? Could use traditional protocols for wired networks in

wireless networks: Establish abstract network with point-to-point links. Define links using Neighbor Discovery protocol, based on

periodic Hello messages. Run traditional protocols over the abstract network.

But resulting protocols may not perform very well: “Links” may be unreliable, failing and recovering often. May cause routes to break frequently, hurting performance. Point-to-point link abstraction doesn’t fit wireless networks

well, since they use local broadcast with interference. Need to adapt protocols, design new protocols.


Proactive vs. Reactive Protocols Proactive:

Maintain routes in the background, regardless of current data-sending activity.

High overhead. Low latency for message forwarding.

Reactive: Establish and maintain routes only when needed for

data-sending. Low overhead, if not too much data activity. May have high latency for message forwarding.


Proactive Protocols Main methods: Link-State Routing, Distance-

Vector Routing Adaptations of wired protocols, treating every node

as a router. Try to establish and maintain routes with fewest

hops (“shortest paths”). Use O(n) local state per node = router. Require that, periodically, or in response to link

changes, information must be propagated to all nodes.


Link-State Routing

Used in Open Shortest Path First (OSPF) Internet protocol.

Can adapt to use in wireless network, using local broadcast.

Each node periodically broadcasts information about the status of its adjacent links, throughout the network.

Every node maintains a complete picture of the network, to use for message routing.


Link-State Routing, More Details Each node periodically constructs a link state packet

describing the status of all its adjacent links, up or down. Attaches sequence numbers, to keep track of which packets

are more recent. Broadcasts the link state packets throughout the network,

using a network-wide flooding algorithm. Each node collects all this information, assembles a complete

picture of the network locally. Uses a centralized algorithm, e.g., Dijkstra’s algorithm, to

determine shortest paths. Uses these shortest paths to fill in a next-hop routing table,

indicating the next hop for a message for each destination D.


Link-State Routing, Optimizations

Limit dissemination of link state packets (LSPs). Hazy-sighted LSP dissemination:

Propagate LSPs more frequently to shorter distances, less frequently to longer distances.

Nodes keep more up-to-date about nearby links. Uncoordinated selective forwarding:

Propagate LSPs with some probability p. Don’t propagate LSPs if overhear someone else sending it.

Unreliable, since some neighbors might not have received it. Coordinated selective forwarding:

Decide cooperatively who should propagate. E.g., each node identifies a Relay Set, a subset of its neighbors such that

each 2-hop neighbor is a neighbor of some node in the Relay Set. Propagate LSP to Relay Set nodes only. Requires Neighbor Discovery protocol to learn about 2-hop neighbors.


Distance-Vector Routing Bellman-Ford style Each node keeps track, for each possible destination D, of the

shortest distance (number of hops) to D that it knows, R[D].cost, together with the first hop along a shortest path, R[D].nexthop.

Each node periodically broadcasts to its neighboring nodes its distance vector, giving its current distances to all nodes. R[D].cost for all D.

Each node adjusts its distance estimates and first hops, based on information from its neighbors:

When Z receives distance d for D Z from neighbor X: if R[D].nexthop = X then R[D].cost := d + costZX else if d + costZX < R[D].cost then

R[D].cost := d + costZX R[D].nexthop := X


Distance-Vector Routing

When Z receives distance d for D Z from X: if R[D].nexthop = X then R[D].cost := d + costZX

Update the cost estimate with newer information.

else if d + costZX < R[D].cost then R[D].cost := d + costZX

R[D].nexthop := X If a different neighbor provides a better path, update both the cost

estimate and the nexthop.

In addition, if Z does not hear from R[D].nexthop for a while:

R[D].cost := R[D].nexthop :=


Counting to Infinity Basic Distance-Vector algorithm allows “counting

to ”, if links fail: With all links up, RA[D].cost and RB[D].cost

stabilize to 1 and 2, respectively. Then link AD fails, setting RA[D].cost := . Then A hears from B, so RA[D].cost := 2 + 3 = 5,

RA[D].nexthop := B (correct). Then link BD fails, setting RB[D].cost := . Then B hears from A, so RB[D].cost := 5 + 3 = 8,

RB[D].nexthop := A (not correct). A hears from B, RA[D].cost := 8 + 3 = 11. B hears from A, RB[D].cost := 11 + 3 = 14. Etc.

A

D

B

2

3

5 2

A

D

B

1 2

31 2

A

D

B

35 8


DSDV Destination-Sequenced Distance-Vector [Perkins, Bhagwat 94]. Add mechanism to DV to prevent counting to . Source of problem in example:

A’s estimate of 5 was based on B’s old estimate of 2. B’s estimate is now . But B accepts A’s estimate.

Mechanism to avoid using stale information in determining routes: Associate a (destination sequence number, distance) tag with each routing table entry and each distance vector entry.

(seqno1, dist1) better than (seqno2, dist2) if either: seqno1 > seqno2 (newer information), or seqno1 = seqno2 and dist1 < dist2 (better distance).


Some DSDV Details Somewhat complicated rules for manipulating tags,

see [Vaidya, Section 6.2.2]. Roughly: Node Z increases its own seqno (for Z itself) by 2

each time it sends out a new distance vector. When node Z detects that a link to X has failed, Z

increases its sequence number for X by 1. When processing a received distance vector from X,

Z accepts new information for D only if its associated tag is better than the tag stored in RZ[D]. Larger seqno, or same seqno and shorter distance.


DSDV Guarantees

Valid route information is always associated with even seqnos.

Tags are monotonic: Starting from any node, and following nexthop entries for a particular D, the tags in the R tables increase monotonically until we either reach D or find R[D].nexhop = .

Implies no routing loops. Avoids counting to : In example, B would not

accept the info from A because the tag is not better than the entry in RB[D].


Proactive Algorithms, Summary Link-State Routing, Distance-Vector Routing Adaptations of wired protocols, treat every node as a router. Try to establish and maintain routes with fewest hops. High overhead:

Maintain routes in the background, regardless of current data-sending activity.

O(n) local state per node. Require that, periodically, or in response to link changes,

information must be propagated throughout the network. Frequent network changes result in instability, global updates.

Suggests reactive algorithms might work better, in dynamic mobile ad hoc networks: Establish and maintain routes only when needed for data-sending. Low overhead, if not too much data activity.


Reactive approaches

Dynamic Source Routing (DSR) [Johnson, Maltz 96]

Ad-Hoc On-Demand Distance Vector Routing (AODV) [Perkins, Royer 99]


DSR Overview Reactive, uses on-demand routing. When S has a message for D, it tries to find a good

route to D. Performs route discovery, by flooding a query packet to

find a route to D. S learns the entire route. Attaches the entire route to each data packet it

sends (source routing). Caches the route so it doesn't have to search for

new routes for each message (or each packet). But, if the network is large and or/changes rapidly, the

routes tend to break frequently, which makes caching less effective.


DSR Performance Highlights

Claim good performance: Low communication overhead, high reliability

and low latency of message delivery, and nearly-optimal routes, under a variety of conditions.

During stable periods: Little overhead, can reuse already-determined routes. Yields low-latency, low-communication reliable message delivery.

When network changes: Adapts reasonably quickly. Diagnoses broken routes and finds new ones.


DSR Assumptions Nodes are willing to “participate fully”: forward traffic on

behalf of others, etc. Network diameter:

Examples in paper are fairly small. Suggests that this may not scale well.

Mobility: Hosts may move at any time Speed much lower than time for packet transmission and

local processing. Don't move so fast as to make route computation useless.

Hosts have a “promiscuous receive mode”, that allows them to receive every packet they hear, not filtered by destination address.


DSR, Basic Operation Message forwarding: Source routing

Sender puts entire route in packet header, forwards packet to first host in the route, successive hosts forward.

Each host maintains a route cache, caching some source routes it has learned, each with an expiration time.

When sender S wants to send a packet to destination D: S first checks its route cache for a route to D. If it finds one, it uses it. If not, uses route discovery protocol to try to find one. Processes other packets in the meantime.

Route maintenance: Source S monitors correct operation of its cached routes; if a

route isn't working, removes it from cache. If a currently-used route is discovered not to be working, then S

may do route discovery again, resend on the new route.


DSR Route Discovery S broadcasts “route request” (RREQ) packet, containing id pair (S,D). Should result in “route reply” (RREP) containing full path. Route discovery works by simply flooding the packet, looking for a path

that works. RREQ packet contains:

(S,D) request id, unique id for the request, allows pruning out duplicates route record, accumulates a record of the sequence of hops the packet

takes during discovery Processing a RREQ:

Duplicate detection: Discard if duplicate, according to request id. Loop detection: If your own address already appears in the route record,

this is a loop, discard. If you are D, the route has been found; send RREP with the final route

record back to S. Otherwise, append your own address and re-broadcast.


Sending the RREP from D to S If D has a route to S in its cache, sends the RREP on that. Else, if communication is bidirectional, D sends the RREP along

the reverse of the route in the RREQ packet. Else, D initiates a route discovery for (D,S), flooding a new RREQ

message, with the RREP piggybacked on it. We're not counting on this second route discovery to provide D

with a route from D to S---just using the flooding facilities to send the RREP back to S.

When S receives this new RREQ, it puts into its route cache the route from S to D that appears in the piggybacked RREP.

This wouldn’t work without piggybacking: If D just did route discovery for (D,S) without piggybacking the RREP on the new RREQ message, then S would not have a path to use to return the new RREP to D!


DSR Route Maintenance Since DSR is reactive, it does not send routing updates continually Instead, while a route is actually being used to send a message, a

route maintenance protocol monitors the operation of the route, informs sender of any problems.

Some mechanisms used to diagnose the failure of individual hops along the path:

Link-level acks, with non-occurrence reported to higher layers. Passive acks, trying to overhear the next transmission by the next node

along the path. Some application-level ack information, if available. Explicit acks added to the message-forwarding protocol.

A node discovering such a local failure then sends a Route Error (RERR) message to the sender S of the current message, indicating the particular hop that failed.

When S receives the RERR, it truncates all the paths in its cache at the failed hop.


DSR Route Maintenance Q: How does the diagnosing node X get the RERR message back

to the sender S? A: As for the RREP:

If X has a route to S in its cache, sends the RERR on that. Or, reverse the route from the packet (if communication is bidirectional). Or piggyback RERR on a new route discovery.

Another option: X performs an entire new route discovery for (X,S), with no piggybacking, before sending the RERR message.

Q: Why is this not circular? A: Because S should have a route to X in its cache.

End-to-end route maintenance: Use explicit ack for data packet, from destination D to source S. Gives “coarser” information---source could delete only one route, not

truncate many routes as for single-hop diagnosis.


DSR Optimizations Storing routes in the route cache:

List of routes, indexed by destination. Tree of routes, to different destinations.

When to add a route to the cache? As a result of a successful route discovery (of course). Maybe also:

When forwarding a data packet along a route, add the rest of the route. When forwarding an RREP containing a route, add the relevant portion. Some overheard routes.

Use route cache to avoid propagating an RREQ: If you already have a route to the intended target D of the RREQ (that would not

introduce a loop), then just append your route to the route that already appears in the RREQ, to obtain a candidate route from S to D, and send this in a special RREP message back to S.

Could also gather route info from neighbors’ caches. Set bound on route length, truncate search at that bound.


DSR Performance Packet-level simulation. Varied parameters in the protocol, number of nodes, pattern/speed of

movement, distribution of nodes in space. Typically: Mobile hosts in a large room, moving at walking speeds,

with 3-meter transmission/reception range. Claim the results are also valid for vehicles, which move faster, over

a larger region, because parameters scale appropriately (?). Random initial placements, random pause, random new locations,

random speed. Results:

For all but the shortest pause times, the total number of packets transmitted is very close to optimal (for communicating actual data).

Nearly all data packets are successfully delivered, (because route maintenance detects when routes are no longer working).

The protocol finds and uses close to optimal routes.


Ad Hoc On-Demand Distance Vector (AODV) Routing

Another reactive protocol, like DSR. But not a source routing algorithm:

Does not maintain the entire route anywhere, but distributes its representation among the nodes on the route.

Like distance-vector algorithms. Nodes maintain distance-vector routing tables, route messages

according to these tables. Tables populated on-demand: Next hops added only as routes are

needed, time out if not used, or if detected as broken. Gives usual advantages of reactive strategies:

Low communication overhead, small storage Lower local storage requirements than DSR, since only next hop

information is stored, not full routes. Combination of performance advantages makes AODV more

scalable than DSR and DSDV.


AODV Assumptions Basically the same as DSR: Nodes are willing to “participate fully”. Mobility is slower than routing. Nodes in promiscuous receive mode.

However, unlike for DSR, the network is not assumed to be small.

AODV is intended to be scalable.


AODV, Basic Operation

S wants to send a message to D, but has no entry for D in its routing table.

S initiates route discovery by locally broadcasting a RREQ, containing: (S,D) request_id source_seqno, dest_seqno hop_count

(S, request_id) uniquely identify RREQ.

S

B

A

I

H

G

F

E

C D


AODV, Basic Operation

S

B

A

I

H

G

F

E

C D

When a node receives an RREQ: If has already seen it (same S,

request_id), discard. If have relevant information,

then reply. Else, increment hop_count,

rebroadcast, and record: (S,D), request_id,

source_seqno Who forwarded the RREQ to

you, Expiration time


AODV, Route Discovery Relevant information:

If you are the destination D, or have a route to D with the same or greater destination sequence number.

Reply: Next slide… For now, assume no node knows any

route to D. As the RREQ propagates through the

network, the information nodes record about whom they received it from sets up temporary reverse pointers. Temporary because they get discarded

after expiration time.

S

B

A

I

H

G

F

E

C D


Replying to RREQs Node X with relevant information replies to an RREQ by generating a

RREP, containing: (S,D), dest_seqno hop_count, number of hops in route from X to D. lifetime

This gets passed back along the reverse pointers, unicast fashion. RREP's handled separately from RREQs, no request_id. For a given (S,D), X passes RREP along the reverse pointer iff X

hasn't already passed along such an RREP for a larger dest_seqno, or for the same dest_seqno with the same or smaller hop_count.

Requires keeping track of RREPs handled for each (S,D). Assumes X has at most one reverse link for each (S,D):

A reverse link should mean X is on an active path from S to D. Two reverse links would mean two active paths. If S sends out a new RREQ for D, it means the previous route was broken.

So X should discard the old reverse link in favor of the new one.


Forward Path Setup As the RREP is passed back,

each node that handles it sets up the appropriate forward pointer in its routing table entry for D.

Each routing table entry holds, for each D: Number of hops to D Next hop dest_seqno Active neighbors for this route

(neighbors who have sent a message recently that used it)

Expiration time for the route table entry (if not used for a while)

S

B

A

I

H

G

F

E

C D


Local Connectivity Management Suppose D moves. Suppose A wants to send a

message to D, broadcasts RREQ.

A gets RREP's from S, B, and D; chooses D’s because it has the largest dest_seqno.

B overhears D’s RREP, changes its route table entry because this RREP has a larger dest_seqno.

S

B

A

I

H

G

F

E

C

D


Local Connectivity Management Q: How does C determine its path to D is

broken? A: D is supposed to send Hello messages to C

periodically. In general:

Nodes on active paths send Hello messages to their prececessors.

If a predecessor doesn’t receive one for a while, it assumes the successor is gone, propagates back a special RREP with hop_count = and one greater dest_seqno.

The effect: Anyone who has not found a more recent route to the destination removes the route from its table.

S

B

A

I

H

G

F

E

C

D


Local Connectivity Management

Here, C removes its entries for this route, propagates RREP back to B, who already has a better route.

If D had moved far away, then C's infinite RREP might have propagated all the way back to S, forcing S to rediscover from scratch.

S

B

A

I

H

G

F

E

C

D


AODV Simulation Results Simulated AODV using PARSEC event-driven, packet-level simulator. Not very realistic:

Strict range cut-off. Perfect physical carrier sensing. Always a collision (losing both messages) if two neighbors broadcast

at the same time. Ran experiments with 50, 100, 500, and 1000 nodes, to test

scalability. 1000 is very large compared to most MANET simulations.

Delivery success rate: For few nodes, very high success rate. For more nodes: About 25% of messages lost.

Main reason is collisions. Collisions are very important factor with MANET routing protocols.


AODV Real-World Experiments Dartmouth experiments:

Approximately 40 students carrying laptops, moving randomly. Playing field, 225 x 365m. Traffic generation: 1200 byte packets, 5.5 packets per stream, 3 seconds

between packets, 15 seconds between streams (numbers derived from a military application prototype).

Around 425 bytes per second – modest. Message delivery success rate: 50% Good latency, best compared to other algorithms tested (ODMRP,

APRL, STARA). Second best for route costs (hop count). Smallest amount of overhead. Issues:

Collisions. Fluctuating links: you might think you are somone’s neighbor because you

got a message, but the link quality is bad. Control traffic: Aggressively seeking new routes can make things worse.


Disconnected Transitive Communication [Chen, Murphy] Routing algorithms we’ve discussed assume a network that

stays connected, though the network topology can change. Now assume the network may not always be connected. Nodes in clusters, clusters intermittently connected. For applications that can tolerate highly asynchronous

communication. Minutes or hours delay, not milliseconds or seconds. Don't use to run a ssh connection. But perhaps to update two military camps about a change in

the plans for a battle coming up in a few days.

F

E

D

B

AC


Disconnected Transitive Communication [Chen, Murphy] Routing algorithms we’ve discussed assume a network that

stays connected, though the network topology can change. Now assume the network may not always be connected. Nodes in clusters, clusters intermittently connected. For applications that can tolerate highly asynchronous

communication. Minutes or hours delay, not milliseconds or seconds. Don't use to run a ssh connection. But perhaps to update two military camps about a change in

the plans for a battle coming up in a few days.

F

E

DC

B

A


The Basic Idea

Algorithm maintains no long-term or medium-term state, not even on-demand routes.

Just pass the message on, hop-by-hop. Pass it to the node in your current cluster

that is “closest” to the destination. Figuring out who is closest is the main trick;

might require application-layer information.


More Detail

If X has a message to send or pass on to D: X broadcasts probe throughout its component

(multi-hop). Recipients test their utility for D; respond if high

enough. Both broadcasting and response use low-level

protocol like DSR or AODV, within the cluster. X passes message on to node with highest utility.


Utility Measures History-based utility measures:

Most Recently Noticed: Higher utility if you have noticed (encountered) D recently.

Most Frequently Noticed: Higher utility if you have noticed D frequently.

Future-based: Future Plans: Assumes the application at your node will tell you

next time it expects to see D (e.g., by reading a calendar). Status-based:

Power: More power, better utility. Rediscovery Interval: Smaller RDI means a better chance of

discovering D or someone closer to D. Weighted combinations of these. Sender can choose its own metric, based on special scenario-

specific information.


Rediscovery Choosing a good rediscovery interval (RDI) is

important. If it’s too big, you may miss potential connections. Too small leads to too much traffic.

Their solution: Double RDI after each unsuccessful probe for new

connections. If new node discovered, reset RDI to initial value.

Discover new nodes using Hello messages.

CPSC 689: Discrete Algorithms for Mobile and Wireless Systems

Documents

mobile wireless syslecture

mobile wireless syspoint

geographical routing

compass routing

wireless setting

wireless systemsspring

routing strategies dont

demand distancevector