Introduction to wireless ad-hoc network routing protocols

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

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

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

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

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

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

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

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

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

10. 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 routesusedfor its own packets

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

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

13. Flooding Algorithm

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

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

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

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

18. 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?

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

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

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

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

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

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

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

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

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

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

29. Link information is obtained by exchange source trees • 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

30. 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)

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

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

33. ORA • Send LSU under these conditions • Source tree changes • Neighbor report a outdated LSU

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

35. Finished thanks!! • HAVE any question?