Octopus A Fault-Tolerant and Efficient Ad-hoc Routing Protocol

1. Octopus A Fault-Tolerant and Efficient Ad-hoc Routing Protocol Idit Keidar, Technion Joint work with Roie Melamed Intel Academic Seminars, February 2005

2. Ad-Hoc Networks • A collection of mobile wireless nodes • No pre-existing infrastructure • Peer-to-peer routing: nodes relay each other's packets toward their ultimate destinations Intel Academic Seminars, February 2005

3. Applications of Ad-Hoc Networks • Military: tactical communications • Rescue missions: without adequate wireless coverage • Commercial use: sales presentations • Local Area Networks (LANs): in limited-coverage areas Intel Academic Seminars, February 2005

4. Challenges in Ad-Hoc Networks • Lack of Infrastructure • Limited wireless transmission range • Rapid movement • constantly changing topology • Battery constrains • Intermittent node disconnections Intel Academic Seminars, February 2005

5. Multi-Hop Routing A B C D Intel Academic Seminars, February 2005

6. Position-Based Ad-Hoc Routing • Each node knows its location • e.g., using GPS • To send a packet– • source discovers target location • packets forwarded to this location Knowing location can eliminate flooding, improve scalability Intel Academic Seminars, February 2005

7. Location Severs • Location servers for node n: • nodes storing n’s location • need to be updated whenever n moves • To lookup t’s location– • discover a location server of t • All-for-some: • each node has some location servers • no flooding for update or lookup • each node acts as location server for some nodes • e.g., Grid Location Service (GLS) [Li et al.] Intel Academic Seminars, February 2005

8. Goals and Tradeoffs • Low location update overhead • want to send few update packets • do not want to send many far away (many hops) • Fault-tolerance (overcome disconnections) • need many location servers • need information to be fresh (frequently updated) • Challenge: have many fresh location servers without inducing high load Intel Academic Seminars, February 2005

9. Observation • In most protocols, each location update packet contains the location of a single node, and updates a single location server • The key to a better fault-tolerance/overhead tradeoff is aggregation • Challenge: locate location servers as to allow efficient aggregation and cheap location discovery Intel Academic Seminars, February 2005

10. Octopus Intel Academic Seminars, February 2005

11. Octopus in a Nutshell • Space divided into horizontal and vertical strips • Nodes in same strip store each other’s locations • Location updates aggregated in each strip • Grid can change over time (unlike GLS) Intel Academic Seminars, February 2005

12. Octopus: Key Features • Fault tolerant • many fresh location servers • Efficient • aggregation reduces location update overhead • Simple • Supports dynamically changing area • Improved forwarding Intel Academic Seminars, February 2005

13. Three Sub-Protocols • Location update • maintains each node’s location at its designated location servers as well as at its radio range neighbors • Location discovery • discovers a target location (at an appropriate location server) • Forwarding • forward data packets to this location Intel Academic Seminars, February 2005

14. Location Update I – Neighbor List • Periodically, each node broadcasts HELLO message with its identity and location • to radio-range neighbors Intel Academic Seminars, February 2005

15. Location Update II – End Nodes • A north/south end node has no neighbors in direction north/south that reside in its vertical strip • Same for east/west horizontal Intel Academic Seminars, February 2005

16. Location Update II – Strip Update A-C A-F A-K A-M A-S A-W A-I A-P #messages per node- constant # bits- sqrt Intel Academic Seminars, February 2005

17. Location Discovery Take I Intel Academic Seminars, February 2005

18. Location Discovery Take II Forwarding Hole Quadratic reduction of failure rate Intel Academic Seminars, February 2005

19. Location Discovery Alternatives • Two opposite directions at a time • north and south concurrently, • if fails, west and east concurrently • One direction at a time • try short direction first (use estimate of grid area) • Tradeoff between overhead and latency Intel Academic Seminars, February 2005

20. Forwarding: Geographic • Greedy • Forward packet to neighbor that is closest to target Intel Academic Seminars, February 2005

21. Forwarding: Local Maxima • Geographic forwarding fails • Octopus uses redundant information about strip nodes • Forward to strip node closest to target Intel Academic Seminars, February 2005

22. Evaluation Intel Academic Seminars, February 2005

23. NS-2 Simulations • Scalability • increasing the network size with fixed density • increasing the node density • Fault-tolerance • Data forwarding • Comparison with GLS Intel Academic Seminars, February 2005

24. Reliability: Query Success Rate Intel Academic Seminars, February 2005

25. Message Complexity Scalable! Intel Academic Seminars, February 2005

26. Byte Complexity Intel Academic Seminars, February 2005

27. Node Density & Reliability Intel Academic Seminars, February 2005

28. Node Density & Message Complexity Scalable! Intel Academic Seminars, February 2005

29. Node Density & Byte Complexity Scalable! Intel Academic Seminars, February 2005

30. Fault-Tolerance Intel Academic Seminars, February 2005

31. Data Forwarding Reliability Intel Academic Seminars, February 2005

32. Comparison with GLS • Leading solution to date • Compare: • Reliability • Message and byte complexity • Fault-tolerance • Data forwarding reliability and overhead Intel Academic Seminars, February 2005

33. Reliability Intel Academic Seminars, February 2005

34. Message Complexity Intel Academic Seminars, February 2005

35. Byte Complexity Intel Academic Seminars, February 2005

36. Fault-Tolerance Intel Academic Seminars, February 2005

37. Data Overhead Intel Academic Seminars, February 2005

38. Octopus: Conclusions • Highly fault tolerant • reliable when all nodes intermittently disconnect • many fresh location servers • Efficient • aggregates: sends much fewer messages • saves MACs, hence sends fewer bytes • Simple • Supports dynamically changing area • Forwarding uses location information Intel Academic Seminars, February 2005