Introduction to wireless ad-hoc network routing protocols Speaker: 張簡稜剛 碩二專 N 成醫資訊室 應用系統 A 組 程式設計師

References INTERNET-DRAFT, Dynamic Source Routing protocol, 1999 Source:.J. GARCIA-LUNA, M. SPOHN Source Tree Adaptive Routing Internet Draft, draft-ietf-manet-star-00.txt, work in progress, October 1999

Ad hoc routing environment Nodes do not have a priori knowledge of topology of network around them, they have to discover it.a priori Network topology changes rapid and frequently The power supply is not permanent

Routing algorithms design considerations keep routing table reasonably small keep table up-to-date when nodes die, move or join require small amount of messages/time to converge save energy

Routing algorithm types Classify by how router obtain control information Pro-active (Table-driven) – These algorithms maintain fresh list of destinations and their routes. Reactive (On-demand) – When no designed route is found, protocol finds one. Route is not so fresh as pro-active

Reactive (On-demand) parameters All on-demand protocols differ on the following mechanisms – How to flood-search packet and their response? – How to cache information heard from node search? – How to determine the cost of a link? – How to determine the existence of a neighbor? You will see this in the following DSR protocol introduction

Routing algorithm types (cont) Classify by what information router use Distance-vector – Exchanges (target, distance) – Exchanging routing table directly, and computing optimum path – RIP, BGR Link-stat – Exchanges (link (u, v), status) – Exchanges link status and stores into topological database then compute optimum path on topological database – OSPF, ad-hoc table driven protocols

Routing algorithm design approach ORA (Optimum routing approach) – Almost all wired routing algorithms, – table driven ad-hoc routing algorithms LORA (Least-overhead routing approach) – Limit the routing control information bandwidth (overhead) – On-demand ad-hoc routing algorithms

Dynamic Source Routing Protocol Reactive (On-demand) Source Route protocol INTERNET-DRAFT – Expires 19 January 2005 Simple to demonstrate the reactive protocol – The reason that I choose it to presentation to u

DSR is based on source routing each data packet sent carries in its header the complete, ordered list of nodes through which the packet will pass – Header[ source->b->c->..->destination] WHY? – allows the sender to select and control the routes used for its own packets

DSR protocol algorithm Does route to destination is in route cache? – Yes, send data. – No, execute Route Discovery. A problem? – The route information may be not be newest status of the current topology

DSR Route Discovery procedure Send RREQ packet, Route Request RREQ will floods to neighbors recursively until destination RREQ will records the node it have passed Destination will compute a better route and put it with RREP, Route Reply Destination replies RREP to source, and now source knows the route to destination

Flooding Algorithm

Nodes receive the RREQ Does target in RREQ is me? – Yes, reply RREP to initiator (sender) – No, next question. Does initiator, route id and target is the same as the prior packet received Yes, discard the packet. No, append my address to the route records in RREQ and boradcast RREQ to neighbors

Target replay RREP Does route to initiator is in route cache? – Yes, send RREP to initiator – No, execute Route Discovery for initiator but piggyback RREP on the RREQ to initiator (avoid route discover recursively) Why not reverse the route in route record as the route to initiator? – It assumes the route is not bidirectional, this is common status in wireless transmission

Send Buffer Packet will be stored in send buffer if its destination address is not discovered Packet will be stamped a stored time that it was placed in this buffer Packet will be discarded when the stored time is expired after send buffer timeout Buffer is FIFO Queue

Send Buffer(2) If packet remains in the send buffer, the node will occasionally initiate new Route Discovery for the packet’s destination address exponential back-off algorithm to limit the rate to initiate new route discovery – Doubling timeout between two successive discovery initiated

Exponential back-off After i collisions, a random number of slot times between 0 and 2^i − 1 is chosen – 1st collision, the wait time may be 0, 1 – 2nd collision, wait time may be choose from 0,1,2 and 3 – 3nd collision?

Route maintenance In source route, each node transmitting the packet is responsible for confirming the data can flow over the link from the node to the next hop Acknowledgement is simple in wireless network, passive acknowledgement – B can confirms receipt at C by overhearing C transmit the packet forwarding to D

Software Acknowledgement network has no acknowledgement foundation the node transmitting the packet can explicitly requests a DSR-specific software acknowledgement be returned by the next node along the route When sender receives an SA, it will not send SA request for a period of time

Software Acknowledgement(2) Node retransmitted SA request to a node C for a maximum times and has not been received any SA reply, it marks the node C broken link and return Route Error Flooding the Route Error to the source and node passed Source choose or discovery another route to destination node

Source-Tree adaptive routing (STAR) Table-driven Source:.J. GARCIA-LUNA, M. SPOHN Source Tree Adaptive Routing Internet Draft, draft-ietf-manet-star-00.txt, work in progress, October 1999

Features Routing approach can be adaptive between ORA and LORA Using Source-Tree to compute the route path

Route information router had Neighbor set Topology graph=adjacent links + source trees of neighbors Topology graph  router’s source tree Source tree  route-selection algorithm  route table

Source Tree The set of links to destinations – Each destination has only one route – source tree can be viewed as set consist of route to each destination Derived route path from source tree is simple and quickly

In Tree, there is only one route between any two nodes

Topology Graph cached available routes In Graph, there is one or more routes between any two nodes Topology Graph  Source Tree Source tree stores active route set Topology Graph stores partial available route set

In Graph, there is one or more routes between any two nodes

Link information is obtained by exchange source trees Result: – When report a link to destination failed also indicates the new link to the destination – Not send a LSU for failed link explicitly

Exchange fail links comparison Exchange fail links info by LSU – A discover L(B, W) failed – A  LSU(B, W, failed) (explicitly report failed) – A  LSU(C, W, new) Exchange fail links info by Source Tree – A discover L(B, W) failed – Compute new ST from TG – A  LSU(ST) (update implicitly failed link)

LSU structure LSU=(u, v, l, t) – u denotes the link head – v denotes the link tail – l denotes the cost of the link – t denotes the timestamp assigned to the LSU

LSU exchange Valid LSU – u, link head is the source of the LSU – Timestamp of LSU is greater than timestamp in TG with the same source Remove link in TG – If the link is not in any source tree reported by neighbors, then delete it from TG

ORA Send LSU under these conditions – Source tree changes – Neighbor report a outdated LSU

LORA Keep a route as long as it leads to the destination Not keep the optimum route Send LSU under these conditions – Unreachable destination – New destination – Possible permanent routing loops – Cost of routes exceeding the threshold

Finished thanks!! HAVE any question?