Algorithmic Foundations of Ad-hoc Networks

1. Algorithmic Foundations of Ad-hoc Networks Andrea W. Richa, Arizona State U. Rajmohan Rajaraman, Northeastern U. ETH Zurich, Summer Tutorial 2004

2. Thanks! • I would like to thank Roger Wattenhoffer, ETH Zurich, and Rajmohan Rajaraman, Northeastern U., for some of the slides / figures used in this presentation ETH Summer 04 2

3. A B C What are ad-hoc networks? • Sometimes there is no infrastructure • remote areas, ad-hoc meetings, disaster areas • cost can also be an argument against an infrastructure • Wireless communication (why?) • Sometimes not every station can hear every other station • Data needs to be forwarded in a “multihop” manner ETH Summer 04 3

4. An ad-hoc network as a graph • A node is a mobile station • All nodes are equal (are they?) • Edge (u,v) in the graph iff node v can “hear” node u • These arcs can have weights that represent the signal strength • Directed X undirected graphs • Multi-hop N1 N3 N2 N4 N5 N1 N3 N2 N4 N5 ETH Summer 04 4

5. An ad-hoc network as a graph • Close-by nodes have MAC issues such as hidden/exposed terminal problems • Optional: links are symmetric (undirected graph) • Optional: the graph is Euclidian, i.e., there is a link between two nodes iff the distance of the nodes is less than a certain distance threshold r ETH Summer 04 5

6. What is a Hop? • Broadcast within a certain range • Variable range depending on power control capabilities • Interference among contending transmissions • MAC layer contention resolution protocols, e.g., IEEE 802.11, Bluetooth • Packet radio network model (PRN) • Model each hop as a “broadcast hop” and consider interference in analysis • Multihop network model • Assume an underlying MAC layer protocol • The network is a dynamic interconnection network • In practice, both views important ETH Summer 04 6

7. N1 N1 N2 N3 N2 N3 N4 N4 N5 N5 good link weak link time = t1 time = t2 Mobile (and Multihop) Ad-Hoc Networks (MANET) • Nodes move • First and foremost issue: Routing • Mobility: dynamic network ETH Summer 04 7

8. Overview: Part I • General overview • Models • Ad-hoc network models; mobility models • Routing paradigms • Some basic tricks to improve routing • Clustering • Dominating sets, connected dominating sets, clustering under mobility • Geometric Routing Algorithms ETH Summer 04 8

9. Overview: Part II • MAC protocols • Power and Topology Control • connectivity, energy efficiency and interference • Algorithms for Sensor Networks • MAC protocols, synchronization, and query/stream processing ETH Summer 04 9

10. Literature • Wireless Networking work • - often heuristic in nature • - few provable bounds • - experimental evaluations in (realistic) settings • Distributed Computing work • - provable bounds • - often worst-case assumptions and general graphs • - often complicated algorithms • - assumptions not always applicable to wireless ETH Summer 04 10

11. Performance Measures • Time • Communication • Memory requirements • Adaptability • Energy consumption • Other QoS measures { path length (# of hops) number of messages } correlation ETH Summer 04 11

12. What is different from wired networks? • Mobility: highly dynamic scenario • Distance no longer matters, number of hops does • Omnidirectional communication • Next generation: unidirectional antennas? • Interference • Collisions • Energy considerations ETH Summer 04 12

13. Degrees of Mobility/Adaptability • Static • Limited mobility • a few nodes may fail, recover, or be moved (sensor networks) • tough example: “throw a million nodes out of an airplane” • Highly adaptive/mobile • tough example: “a hundred airplanes/vehicles moving at high speed” • impossible (?): “a million mosquitoes with wireless links” • “Nomadic/viral” model: • disconnected network of highly mobile users • example: “virus transmission in a population of bluetooth users” ETH Summer 04 13

14. Unit-disk Graph Model • We are given a set V of nodes in the plane (points with coordinates). • The unit disk graph UDG(V) is defined as an undirected graph (with E being a set of undirected edges). There is an edge between two nodes u,v iff the Euclidian distance between u and v is at most 1. • Think of the unit distance as the maximum transmission range. • All nodes are assumed to have the same communication range ETH Summer 04 14

15. Fading Channel Model • Signal strength decreases quadraticaly with distance (assuming free space) • “noise” (i.e., signal being transmitted from other nearby processors) may reduce the strength of a signal • No sharp threshold for communication range (or interference range) ETH Summer 04 15

16. Variations of the Unit-disk Model • Quasi-unit disk graph model: • All nodes can receive a transmission from another node within distance αr • All nodes cannot receive a message from another node within distance >r • A node may or may not receive a message from another node within distance in (αr,r] ? r ? ? α r ? ? ETH Summer 04 16

17. Interference Models • Basic Model: • Each node v has a communication range r and an interference range which is given by (1+c)r, where c is a positive constant • If node u is within r distance from node v, then v can receive a message from u • If node u is within distance d in (r,(1+c)r] from v, then if u sends a message it can interfere with other messages being received at node v, but v cannot “hear” the message from node u (1+c)r r ETH Summer 04 17

18. Mobility Models • Random Walk (including its many derivatives): A simple mobility model based on random directions and speeds. • Random Waypoint: A model that includes pause times between changes in destination and speed. • Probabilistic Version of the Random Walk: A model that utilizes a set of probabilities to determine the next position of an MN. • Random Direction: A model that forces MNs to travel to the edge of the simulation area before changing direction and speed. • Boundless Simulation Area: A model that converts a 2D rectangular simulation area into a torus-shaped simulation area. • Gauss-Markov: A model that uses one tuning parameter to vary the degree of randomness in the mobility pattern. • City Section: A simulation area that represents streets within a city. • All of the models above fail to capture some intrinsic characteristics of mobiliy (e.g., group movement). What is a good mobility model? ETH Summer 04 18

19. Routing Paradigms • We will spend the next few slides reviewing some of the “classic” routing algorithms that have been proposed for ad-hoc networks ETH Summer 04 19

20. Routing in (Mobile) Ad-hoc Networks destination source • changing, arbitrary topology • nodes are not 100% reliable • may need routing tables to find path to destination • related problem:name resolution (finding “closest” item of certain type) ETH Summer 04 20

21. Basic Routing Schemes • Proactive Routing: • “keep routing information current at all times” • good for static networks • examples: distance vector (DV), link state (LS) algorithms, link reversal (e.g., TORA) algorithms • Reactive Routing: • “find a route to the destination only after a request comes in” • good for more dynamic networks and low communication • examples: AODV, dynamic source routing (DSR) • Hybrid Schemes: • “keep some information current” • example: Zone Routing Protocol (ZRP) ETH Summer 04 21

22. s c b a t Reactive Routing: Flooding • What is Routing? • “Routing is the act of moving information across an internetwork from a source to a destination.“ (CISCO) ETH Summer 04 22

23. Reactive Routing: Flooding • The simplest form of routing is “flooding”: a source s sends the message to all its neighbors; when a node other than destination t receives the message the first time it re-sends it to all its neighbors. + simple – a node might see the same message more than once. (How often?) – what if the network is huge but the target t sits just next to the source s? • We need a smarter routing algorithm ETH Summer 04 23

24. Reactive Routing: Other algorithms • Ad-Hoc On Demand Distance Vector (AODV) [Perkins-Royer 99] • Dynamic Source Routing (DSR) [Johnson-Maltz 96] • Temporally Ordered Routing Algorithm [Park-Corson 97] • If source does not know path to destination, issues discovery request • DSR caches route to destination • Easier to avoid routing loops source destination ETH Summer 04 24

25. Proactive Routing 1: Link-State Routing Protocols • Link-state routing protocols are a preferred iBGP method (within an autonomous system – think: service provider) in the Internet • Idea: periodic notification of all nodes about the complete graph s c b a t ETH Summer 04 25

26. Proactive Routing 1: Link-State Routing Protocols • Routers then forward a message along (for example) the shortest path in the graph + message follows shortest path – every node needs to store whole graph,even links that are not on any path – every node needs to send and receivemessages that describe the wholegraph regularly ETH Summer 04 26

27. Proactive Routing 2: Distance Vector Routing Protocols • The predominant method for wired networks • Idea: each node stores a routing table that has an entry to each destination (destination, distance, neighbor); each node maintains distance to every other node t? t=1 s c b a t t=2 ETH Summer 04 27

28. Proactive Routing 2: Distance Vector • If a router notices a change in its neighborhood or receives an update message from a neighbor, it updates its routing table accordingly and sends an update to all its neighbors + message follows shortest path + only send updates when topology changes – most topology changes are irrelevant for a given source/destination pair – Single edge/node failure may require most nodes to change most of their entries – every node needs to store a big table: bits – temporary loops ETH Summer 04 28

29. Proactive Routing 2: Distance Vector • Single edge/node failure may require most nodes to change most of their entries half of the nodes half of the nodes ETH Summer 04 29

30. Discussion of Classic Routing Protocols • There is no “optimal”routing protocol; the choice of the routing protocol depends on the circumstances. Of particular importance is the mobility/data ratio. • On the other hand, designing a protocol whose complexity (number of messages, elapsed time) is proportional on the distance between source and destination nodes would be desirable ETH Summer 04 30

31. Trick 1: Radius Growth • Problem of flooding (and similarly other algorithms): The destination is in two hops but we flood the whole network • Idea: Flood with growing radius; use time-to-live (TTL) tag that is decreased at every node, for the first flood initialize TTL with 1, then 2, then 3 (really?), …when destination is found, how do we stop? • Alternative idea: Flood very slowly (nodes wait some time before they forward the message) – when the destination is found a quick flood is initiated that stops the previous flood + Tradeoff time vs. number of messages ETH Summer 04 31

32. Trick 2: Source Routing • Problem: nodes have to store routing information for others • Idea: Source node stores the whole path to the destination; source stores path with every message, so nodes on the path simply chop off themselves and send the message to the next node. • “Dynamic Source Routing” discovers a new path with flooding (message stores history, if it arrives at the destination it is sent back to the source through the same path) ETH Summer 04 32

33. Trick 2: Source Routing + Nodes only store the paths they need – Not efficient if mobility/data ratio is high – Asymmetric Links? ETH Summer 04 33

34. Trick 3: Asymmetric Links • Problem: The destination cannot send the newly found path to the source because at least one of the links used was unidirectional. s c b a t ETH Summer 04 34

35. Trick 3: Asymmetric Links • Idea: The destination needs to find the source by flooding again, the path is attached to the flooded message. The destination has information about the source (approximate distance, maybe even direction), which can be used. ETH Summer 04 35

36. Trick 4: Re-use/cache routes • This idea comes in many flavors: • Clearly a source s that has already found a route “s-a-b-c-t” does not need to flood again in order to find a route to node c. • Also, if node u receives a flooding message that searches for node v, and node u knows how to reach v, u might answer to the flooding initiator directly. ETH Summer 04 36

37. Trick 5: Local search • Problem: When trying to forward a message on path “s-a-u-c-t” node u recognizes that node c is not a neighbor anymore. • Idea: Instead of not delivering the message and sending a NAK to s, node u could try to search for t itself; maybe even by flooding. • Some algorithms hope that node t is still within the same distance as before, so they can do a flooding with TTL being set to the original distance (plus one) ETH Summer 04 37

38. Trick 5: Local search • If u does not find t, maybe the predecessor of u (a) does? – One can construct examples where this works, but of course also examples where this does not work. ETH Summer 04 38

39. Trick 6: Hierarchy • Problem: Especially proactive algorithms do not scale with the number of nodes. Each node needs to store big tables • Idea: In the Internet there is a hierarchy of nodes; i.e. all nodes with the same IP prefix are in the same direction. One could do the same trick in ad-hoc networks + Well, if it happens that the ad-hoc nodes with the same numbers are in the same area are together, hierarchical routing is a good idea. – There are not too many applications where this is the case. Nodes are mobile after all. ETH Summer 04 39

40. Internet cluster super cluster Trick 7: Clustering • Idea: Group the ad-hoc nodes into clusters (if you want hierarchically). One node is the head of the cluster. If a node in the cluster sends a message it sends it to the head which sends it to the head of the destination cluster which sends it to the destination ETH Summer 04 40

41. Trick 7: Clustering + Simplifies operation for most nodes (that are not cluster heads); this is particularly useful if the nodes are heterogeneous and the cluster heads are “stronger” than others. + Brings network density down to constant, if implemented properly (e.g., no two cluster heads can communicate directly with each other) – A level of indirection adds overhead. – There will be more contention at the cluster heads. ETH Summer 04 41

42. Trick 8: Implicit Acknowledgement • Problem: Node u only knows that neighbor node v has received a message if node v sends an acknowledgement. • Idea: If v is not the destination, v needs to forward the message to the next node w on the path. If links are symmetric (and they need to be in order to send acknowledgements anyway), node u will automatically hear the transmission from v to w (unless node u has interference with another message). ETH Summer 04 42

43. Trick 8: Implicit Acknowledgement • Can we set up the MAC layer such that interference is impossible? + Finally a good trick ETH Summer 04 43

44. Trick 9: Smarter updates • Sequence numbers for all routing updates + Avoids loops and inconsistencies + Assures in-order execution of all updates • Decrease of update frequency • Store time between first and best announcement of a path ETH Summer 04 44

45. Trick 9: Smarter updates • Inhibit update if it seems to be unstable (based on the stored time values) + Less traffic • Implemented in Destination Sequenced Distance Vector (DSDV) ETH Summer 04 45

46. N1 N2 R1 S1 N3 N4 N5 N6 R2 S2 N9 N8 N7 Trick 10: Use other distance metrics • Problem: The number of hops is fine for some applications, but for ad-hoc networks other metrics might be better, for example: Energy, Congestion, Successful transmission probability, Interference*, etc. – ETH Summer 04 46

47. Trick 10: Use other distance metrics How do we compute interference in an online manner?*Interference: a receiving node is also in the receiving area of another transmission. ETH Summer 04 47

48. Routing in Ad-Hoc Networks • 10 Tricks  210 routing algorithms • In reality there are almost that many! • Q: How good are these routing algorithms?!? Any hard results? • A: Almost none! Method-of-choice is simulation… • Perkins: “if you simulate three times, you get three different results” ETH Summer 04 48

49. Clustering • disjoint or overlapping • flat or hierarchical • internal and border nodes/edges Flat Clustering ETH Summer 04 49

50. Hierarchical Clustering Hierarchical Clustering ETH Summer 04 50