routing two papers: location-aided routing (lar) in mobile ad hoc networks (2000) ad-hoc on-demand...

30
Routing Two papers: •Location-Aided Routing (LAR) in mobile ad hoc networks (2000) •Ad-hoc On-Demand Distance Vector Routing (1999)

Upload: aron-mccormick

Post on 25-Dec-2015

224 views

Category:

Documents


1 download

TRANSCRIPT

Routing

Two papers:

•Location-Aided Routing (LAR) in mobile ad hoc networks (2000)

•Ad-hoc On-Demand Distance Vector Routing (1999)

Location-Aided Routing (LAR) in mobile ad hoc networks (2000)• Mobile ad-hoc networks are wireless networks

that change often• Moving hosts result in changing routes requiring

new routes to be found• This protocol uses location information to

improve performance of new route discovery• The Location Aided Protocol (LAR) limits the

search for a new route to smaller request zones, reducing the number of routing messages

Purpose

• Routes through a mobile network may consist of hops through other mobile hosts causing frequent unpredictable topology changes

• The purpose is to reduce overhead in new route discovery using location information (GPS) using the Location Aided Routing Protocol (LAR) which uses location information to reduce search space

Previous work• Wired routing protocols that use periodic routing

table updates waste a large portion of the wireless bandwidth

• Dynamic Source Routing (DSR) is based on on-demand route discovery

• Ad hoc On demand Distance Vector routing (AODV) uses demand driven route establishment (second part of this presentation)

• Temporally-Ordered Routing Algorithm (TORA) updates only a small set of local nodes

• Zone Routing Protocol (ZRP) uses on demand discovery but limits the scope to neighbors

• None take into account the physical location

Location Routing applied to networks• The use of location information has been used by

Personal Communication Service (PCS), where paging on cell phones is limited to cells close to the last reported mobile host.

• Metricom’s Ricochet uses packet radio to forward packets one hop closer to the destination

• DREAM maintains location information in the routing table, periodically broadcasting location information

• This paper applies the packet radio system route discovery rather than data delivery (two algorithms are discussed)

Improving Flooding• S (sender) needs to send to D (destination), it

broadcasts a route request to all neighbors (neighbors can communicate with each other directly over a wireless link)

• A node receiving the request compares D to itself, if it is a match, it is a route request to itself

• Otherwise the node broadcasts to its neighbors (requests are prevented from being repeatedly sent by sequence numbers)

• As the route progresses, the route so far is included with the request.

• If D receives the request, it sends a reply to S by reversing the route included with the request

• If S does not receive a reply within a timeout period, it sends another request with a new sequence number

• A route request is initiated when either the route is broken or the route is unknown

• S finds that the route is broken only when it attempts to use it and receives an error message from a node indicating that its next hop is not available

• This algorithm will reach every node that is reachable within an ad-hoc network

• This is where location information is useful, to reduce the number of nodes in the ad-hoc network receiving the route request information, i.e.: limited flooding

Location Aided Routing (LAR)

• Location of nodes may be found by GPS• If the previous location at time t0 is known and a

velocity is known, the location at time t1 can be predicted to be in a circle

• If it is known that the node is traveling in a particular direction, the location can be a semicircle.

• Route discovery then can proceed only within the expected location

• If it is not found, due to a higher than expected velocity, then the algorithm reverts to flooding with one modification

Request Zones• The LAR algorithm includes in the request

zone all the nodes in the circle or semi-circle

• Other areas may be included

– An expected zone does not include node S, both S and D must be in the request zone

• Fig a) may be inadequate (route not found within timeout period), the zone must be expanded

a b c

Tradeoff, latency vs message overhead

Determining Membership in a Zone• Nodes not in the request zone do not forward

requests to its neighbors• LAR Scheme 1: Rectangular area || X & Y axis

– At time t0, D is known to be at Xd, Yd with velocity v

– Left: S is outside the Expected zone

– Right: S is inside the Expected zone

– Nodes inside the request zone forward requests, others outside the request zone do not forward requests

• When D receives the route request, it replies with its current location, current time, and possibly current or average speed

• Node S records this information to predict Ds location in the future

• LAR Scheme 2: Instead of including the zone coordinates in the route request, Scheme 2 includes the known Xd and Yd coordinates of node D at time t0, also S includes Dists, the distance from S to D at time t0 in the route request.

• When node I receives the request, it calculates its distance to D and records Disti

• For some parameters and , if ((Dists) + Disti) //they are closer to D

Replace Dists with Disti

Forward the requestElse

Discard the request• Initially =1 and =0; they can be used to trade

off the probability of finding a route on the first attempt with the cost of finding a route, when the location error (for D) is non-zero, or when D will move a significant distance (determined later by simulations)

• Each node that receives the request and is closer to D forwards the request with its Distj replacing the received Disti

• Nodes that receive a duplicate discards the duplicate

Scheme 1: I and K forward the request, they are inside the expected zone, N discards the request, it is outside the expected zone

Scheme 2: assume =1 and =0, N and I forward the quest, they are closer to D than S, K discards the request, it is further from D than I

Location Estimates Error

• Scheme 1: let e be the max error in the coordinates of D, then the expected zone is a circle of radius e + v ( t1 – t0), making the request zone correspondingly larger

• Scheme 2: no change is used, however, there is a higher chance that a path to D will not be included causing a timeout and another route discovery

Improvement

Number of routing packets per Data Packet vs Average Speed

Percentage Improvement vs Average Speed

Suggested other request zones

Ad-hoc On-Demand Distance Vector Routing 1999

• Self starting network routing algorithm

• Loop free routes

• Repairs broken links

• Does not require periodic advertisements substantially lowering the bandwidth requirements for overhead

Related Work

• Destination-Sequenced Distance Vector Routing– Works for small networks [message overhead is

O(n2)]– Each node must maintain a complete list of

routes

• On demand routes could nearly eliminate periodic broadcast of route advertisements

Algorithm Characteristics

• Nodes not on active paths neither maintain any routing information nor participate in any periodic routing table exchanges

• Nodes do not discover and maintain a route to another node until they need to communicate

• Broadcast discovery packets only when necessary• Distinguish between local (neighborhood

detection) and general topology maintenance• Disseminate changes in local connectivity to

neighbors likely to need info

Path Discovery• Initiated whenever a source node needs to

communicate with another node and has no route info in its table

• Every node maintains two counters– node sequence number– boradcast_id

• Source node broadcasts a route request (RREQ) packet to its neighbors– Contains < source_addr, source_sequence_#,

broadcast_id, dest_addr, dest_sequence_#, hop_cnt >– < source_addr, broadcast_id > uniquely identifies a

RREQ• broadcast_id is incremented whenever the source node issues

a new RREQ

Path Discovery cont• Neighbors send a reply (RREP) back to the

source or rebroadcasts to its neighbors and increments hop_cnt– RREQs received a second time are discarded– If a node cannot satisfy the RREQ, it keeps

track of the following to set up a reverse path and forward path for the RREP

• Dest IP address

• Source IP address

• broadcast_id

• Expiration time for reverse path route entry

• Source node sequence no

Reverse Path Setup• Two sequence #s are included in a

RREQ– Source sequence #, used to maintain

freshness info about reverse route to the source

– Destination seq #, specifies how fresh a route to the dest must be before it can be accepted by the source

• As RREQ travels, it automatically sets up the reverse path from all nodes back to the source

Forward Path Setup• The RREQ arrives at a node (possibly D

itself) that has a current route to D• Receiving node (with a current route)

compares dest seq # in its route table to dest seq # received:– if (its dest seq # RREQ sest seq #)

• then it can reply

– else• rebroadcast the RREQ

– if (route is current && !RREQ processed)• unicast a RREP to the neighbor from which it

received the RREQ containing:– < source_addr, dest_addr, dest_sequence_#, hop_cnt,

lifetime >

Forward Path Setup cont• A reverse path has been established by

the time a broadcast packet arrives at a node that can supply a route to D

• As the RREP travels back to S, each node – sets up a forward pointer to the node from

which the RREP came– updates timeout info– records the latest dest seq #for the

requested D

• Nodes not along the path determined by RREP timeout after 3000msec and delete the reverse pointer

Forward Path Setup cont• A node receiving a first RREP propagates the

RREP for S towards S• If a node receives another RREP for S

– if (received dest seq # > old dest seq # || (received dest seq # = old dest seq # && received hop count < old hop count) )

• Update its routing table• Propagates the RREP

– Else• Discard RREP (decreases the number of RREPs propagated

towards the source & insures up-to-date and quickest routing info)

• S can begin data transmission as soon as the first RREP is received & can later update route info if it learns a better route

Route Table Management• Router table contains, for each D

– Destination– Next hop– Number of hops– Sequence # for D– Active neighbors for this route

• A neighbor is active if it originates or relays one packet for that D within the timeout period

– So that active nodes can be notified when a link along the path breaks• A route is active if it is in use by any active neighbor• A path from S to D is active if it is used to send packets from S to D

– Expiration time for the route table entry • Route request expiration timer

– to purge reverse path route entries for nodes that are not in the path from S to D – expiration time depends on the size of the ad-hoc-network

• Route caching timer– Time after which the route is invalid

• Timers are reset to current time + cache timer when a route entry is used

Note: all routes are tagged with Ds seq # so no loops

Route Table Management cont

• If a new route is offered to a node– Node compares new Dest Seq # to current Dest

Seq #• Choose the route with the larger seq no

• If seq no the same– If (new no of hops < current no of hops)

» Choose the new route

Path Maintenance• If a hop becomes unreachable,

– the node upstream (closer to S) sends an unsolicited RREP with seq # one greater than the previously known seq # and hop count of

– Nodes relay this RREP to active neighbors– Process continues until all active nodes are

notified– Terminates because loop free routes are

guaranteed– S starts route discovery process again (if it still

needs the route to D) with a new RREQ with dest seq # incremented

Location Connectivity Management• Nodes learn about neighbors in two ways

– A node receives a broadcast from a neighbor and updates its connectivity info

– If a node has not sent a packet in < hello_interval time, it broadcasts a hello msg to its neighbors containing its id and a seq #

• The node’s seq # is not changed for hello msgs

• Hello msg is not transmitted outside its neighborhood because it has a time to live (TTL) of 1

• Neighbors that receive the hello msg update their connectivity info for that node

– If a hello msg is not received from the next hop along the path, active neighbors along that path are sent link failure msg

– Each node checks to see that it only uses routes to neighbors that have heard the node’s hello msg