Chapter 9: Mobile Ad Hoc Network (Part I) Jiandong Li

Transcription

1 Chapter 9: Mobile Ad Hoc Network (Part I) Jiandong Li

2 Required Reading ( Part I) 1. Zygmunt J. Haas, et al, Wireless Ad Hoc Networks, Encyclopedia of Telecommunications, John Proakis, editor, John Wiley, C.E. Perkins, Ad Hoc Network, Addison-Wesley, C.E. Perkins, et, al, Performance Comparison of Two On- Demand Routing Protocols for Ad Hoc Networks, IEEE Personal Communications February 2001,pp Ram Bamanathan and Jason Redi, A Brief Overview of Ad Hoc Network: Chanllenges and Directions, IEEE Communications Magazine, 50 th Anniversary Commemorative Issue, May 2002

3 Cellular(Star) Network Infrastructure Central Access Point (CAP or BS) responses to the transmission scheduling. Each node may have complete channel usage information. MAC is affected by traffic model, user number in a cell and intercell interferences.

4 Definition of Ad Hoc Network Mobile Ad Hoc Networks (MANETs) are an emerging technology that allows establishing instant communication infrastructures for civilian and military applications. MANET is a network architecture that can be rapidly deployed without relying on pre-existing fixed network infrastructure. The nodes in a MANET can dynamically join and leave the network, frequently, often without warning, and possibly without disruption to other nodes communication. The nodes in the network can be highly mobile, thus the network topology is rapidly changing.

5 Multihop Ad Hoc Network Dynamic Topology A B E C D F Multi-hop Any architecture G H

6 Examples of MANET tactical operation - for fast establishment of military communication during the deployment of forces in unknown and hostile( 敌方 ) terrain; rescue missions - for communication in areas without adequate wireless coverage; national security - for communication in times of national crisis, where the existing communication infrastructure is nonoperational due to a natural disaster or a global war;

7 Examples of MANET law enforcement( 强制执行 ) - for fast establishment of communication infrastructure during law enforcement operations; commercial use - for setting up communication in exhibitions, conferences, or sales presentations; education - for operation of wall-free (virtual) classrooms; and sensor networks - for communication between intelligent sensors (e.g., MEMS=Micro-Electro-Mechanical-System) mounted on mobile platforms.

8 Characters of MANET Nodes in the MANET exhibit nomadic behavior by freely migrating within some area, dynamically creating and tearing down associations with other nodes. Groups of nodes that have a common goal can create formations (clusters) and migrate together, similarly to military units on missions or to guided tours on excursions( 游览 ). MANETs are intended to provide a data network that is immediately deployable in arbitrary communication environments and is responsive to changes in network topology. MANETs are distinguished from other ad-hoc networks by rapidly changing network topologies, influenced by the network size and node mobility. Such networks typically have a large span and contain hundreds to thousands of nodes.

9 MANET Model Nodes are equipped with portable communication devices. Lightweight batteries may power these devices. Limited battery life can impose restrictions on the transmission range, communication activity (both transmitting and receiving) and computational power of these devices. All the network nodes have equal capabilities. This means that all nodes are equipped with identical communication devices and are capable of performing functions from a common set of networking services. However, all nodes do not necessarily perform the same functions at the same time. In particular, nodes may be assigned specific functions in the network, and these roles may change over time.

10 MANET Model A MANET is a peer-to-peer network that allows direct communication between any two nodes, when adequate radio propagation conditions exist between these two nodes and subject to transmission power limitations of the nodes. If there is no direct link between the source and the destination nodes, multi-hop routing is used.

11 Robust network architecture to avoid susceptibility( 敏感之处 ) to network failures, congestion around high-level nodes, and the penalty due to inefficient routing. Features needed for MANET Robust routing and mobility management algorithms to increase the network s reliability and availability; e.g., to reduce the chances that any network component is isolated from the rest of the network; Adaptive algorithms and protocols to adjust to frequently changing radio propagation, network, and traffic conditions; Low-overhead algorithms and protocols to preserve the radio communication resource Multiple (distinct) routes between a source and a destination - to reduce congestion in the vicinity of certain nodes, and to increase reliability and survivability;

12 Basic Problems Multiple Access Protocols Hidden terminal problem Exposed terminal problem New technologies to increase transmission capacity Routing Algorithms (Unicasting & Multicasting) Find the optimum route to destination Maintain the optimum route Balance between the availability and cost

13 Open problems: Now used by the US Army, NDTR is the only real (non-prototypical) ad hoc network. (JTIDS?) Open Problems: Scalability; Energy-efficiency Quality-of-service; Security Take advantage of the properties of new hardware technologies. (smart antennas) Lack of well defined and widely accepted models for RF attenuation, mobility and traffic.

14 Hidden terminal problem A B E C F G For node C, B and D are mutually hidden terminal. D H

15 Exposed terminal problem A E->F will block the transmission of B->A B E C D F G H

16 Directional Antenna Application (TX mode, RX mode) (o, o) (d, o) (o, d) (o, o)

17 Clustering architecture Gateway nodes f F3.How gateway nodes work in the cluster b d e.how gateway nodes work between clusters F1 k g c l j a h i F2

18 Routing Algorithms Criteria for Routing (e.g. shortest path ) Who computes the routing (Central or distributed) One hop or whole path? How and when to collect what kind of topology information? topology information (Distance, Link state) update range (local or global) of topology information update methods (full or incremental information) update rate (instant, periodical,on-demand )

19 The early protocols that were proposed for routing in ad hoc networks were proactive Distance Vector protocols based on the Distributed Bellman-Ford (DBF) algorithm [Ber92]. To address the problems of the DBF algorithm - convergence and excessive control traffic, which are especially an issue in resource-poor ad hoc networks - modifications were considered. Another approach taken to address the convergence problem is the application of the Link State protocols to the ad hoc environment. An example of the latter is the Optimized Link State Routing protocol (OLSR). Routing Algorithms Traditionally, the network routing protocols could be divided into proactive protocols and reactive protocols. Proactive protocols continuously learn the topology of the network by exchanging topological information among the network nodes. Thus, when there is a need for a route to a destination, such route information is available immediately.

20 Routing Algorithms On the other "end of the spectrum" are the reactive routing protocols, which are based on some type of "query-reply" dialog. Reactive protocols do not attempt to continuously maintain the up-to-date topology of the network. Rather, when the need arises, a reactive protocol invokes a procedure to find a route to the destination; such a procedure involves some sort of flooding the network with the route query. As such, such protocols are often also referred to as on demand. Examples of reactive protocols include the Temporally Ordered Routing Algorithm (TORA) [Par97], the Dynamic Source Routing (DSR) [Joh96], and Ad hoc On Demand Distance Vector (AODV).

21 Routing Algorithms So, both of the routing "extremes," the proactive and the reactive schemes, may not perform best in a highly dynamic networking environment, such as in ad hoc networks. Although proactive protocols can produce the required route immediately, they may waste too much of the network resources in the attempt to always maintain the updated network topology. The reactive protocol, on the other hand, may reduce the amount of used network resources, but may encounter excessive delay in the flooding of the network with routing queries.

22 Routing Algorithms Another approach to address the routing problem was through the hybrid protocols, which incorporate some aspects of the proactive and some aspects of the reactive protocols. The Zone Routing Protocol (ZRP) [Pea99] is an example of the hybrid approach. In ZRP, each node proactively maintains the topology of its close neighborhood only, thus reducing the amount of control traffic relative to the proactive approach. To discover routes outside its neighborhood, the node reactively invokes a generalized form of controlled flooding, which reduces the route discovery delay, as compared with purely reactive schemes. The size of the neighborhood is a single parameter that allows optimizing the behavior of the protocol based on the degree of nodal mobility and the degree of network activity.

23 Proactive routing-dsdv

24 Proactive routing-dsdv Destination-Sequenced Distance-Vector Routing (DSDV) provides improvements over the conventional Bellman-Ford distance-vector protocol. It eliminates route looping, increases convergence speed, and reduces control message overhead. In DSDV, each node maintains a next-hop table, which it exchanges with its neighbors. There are two types of nexthop table exchanges: periodic full-table broadcast and event-driven incremental updating. The relative frequency of the full-table broadcast and the incremental updating is determined by the node mobility.

25 Proactive routing-dsdv Route Advertisements Route Table Entry Structure Responding to Topology Changes Route Selection Criteria

26 Only use links that are bi-directional. Route Table Entry Structure The destination s address The number of hops to the destination The sequence number of the information received regarding that destination, as originally stamped by the destination Note: Routes with more recent sequence numbers are always preferred. Of the paths with the same sequence number, those with the smallest metric will be used. Routes received in broadcasts are also advertised by the receiver when it subsequently broadcasts its routing information; the receiver adds an increment to the metric before advertising the route, an incoming packets will require one more hop to reach the destination.

27 Route Advertisements The DSDV protocol requires each mobile node to advertise, to each of its current neighbors, its own route table. The entries in this table may change fairly dynamically over time, so that the advertisement must be made often enough to ensure that every mobile node can also always locate every other mobile node in the network. One of the most important parameters to be chosen is the time between broadcasting the routing information packets. However, when any new or substantially modified route information is received by a mobile node, the new information will be retransmitted soon (subject to constraints imposed for damping ( 抑制 ) route fluctuations), effecting the most rapid as possible dissemination of routing information among all of the cooperating mobile node.

28 Responding to Topology Changes The broken link may be detected by the layer-2 protocol. When a link to a next hop has broken, any route through that next hop is immediately assigned an metric and an updated sequence number. Since this qualifies as a substantial route change, such modified routes are immediately disclosed in a broadcast routing information packet. When a node receives an metric, and it has an equal or later sequence number with a finite metric, it triggers a route update broadcast to disseminate the important news about that destination. Building information to describe broken links is the only situation in which the sequence number is generated by any mobile node other than the destination node. Sequence numbers generated to indicate hops to a destination will be one greater than the last sequence number received from the destination.

29 Responding to Topology Changes To reduce the amount of information in routing packets, two types of routing packets will be defined. A full dump( 卸货场 ) will call all of the available routing information, which most likely require multiple network protocol data unit(npdu) and be transmitted relatively infrequently. An incremental will carry only information changed since last full dump, which should fit in one NPDU. Mobile node will implement some means for determining which route changes are significant enough to be sent out with each incremental advertisement.

30 Route Selection Criteria Comparing the newly received routing information packet with previous routing information packets, any route with a more recent sequence number is used; routes with older sequence numbers are discarded. A route with a sequence number equal to an existing route is chosen if it has a better metric, and the existing route is discarded or stored as less preferable. The metrics for routes chosen from the newly received broadcast information are each incremented by one hop.

31 Example of DSDV MH3 MH2 MH4 MH6 MH5 MH8 MH1 MH7 MH1

32 Example of DSDV Dest Next hop Metric Sequence Number Install Stable _Data MH1 MH2 MH3 MH4 MH5 MH6 MH7 MH8 MH2 MH2 MH2 MH4 MH6 MH6 MH6 MH S406_MH1 S128_MH2 S564_MH3 S710_MH4 S392_MH5 S076_MH6 S128_MH7 S050_MH8 T001_MH4 T001_MH4 T001_MH4 T001_MH4 T002_MH4 T001_MH4 T002_MH4 T002_MH4 Ptr1_MH1 Ptr1_MH2 Ptr1_MH3 Ptr1_MH4 Ptr1_MH5 Ptr1_MH6 Ptr1_MH7 Ptr1_MH8 MH5 MH4 Forwarding Table MH4 MH3 MH1 MH2 MH6 MH7 MH8 MHi specifies the node that created the sequence. MH1

33 Example of DSDV MH4 MH5 Dest Metric Sequence Number MH1 MH3 MH2 MH6 MH7 MH8 MH1 MH1 MH2 MH3 MH4 MH5 MH6 MH7 MH S406_MH1 S128_MH2 S564_MH3 S710_MH4 S392_MH5 S076_MH6 S128_MH7 S050_MH8 MH4 advertised route table

34 Example of DSDV Dest Next hop Metric Sequence Number Install Stable _Data MH1 MH2 MH3 MH4 MH5 MH6 MH7 MH8 MH6 MH2 MH2 MH4 MH6 MH6 MH6 MH S516_MH1 S128_MH2 S564_MH3 S710_MH4 S392_MH5 S076_MH6 S128_MH7 S050_MH8 T108_MH4 T001_MH4 T001_MH4 T001_MH4 T002_MH4 T001_MH4 T002_MH4 T002_MH4 Ptr1_MH1 Ptr1_MH2 Ptr1_MH3 Ptr1_MH4 Ptr1_MH5 Ptr1_MH6 Ptr1_MH7 Ptr1_MH8 MH1 MH3 MH2 MH4 MH6 MH5 MH7 MH8 MH4 Forwarding Table (Updated) after MH1 moves MHi specifies the node that created the sequence. MH1

35 Example of DSDV When MH1 moves into the vicinity of MH8 and MH7, it triggers an immediate incremental routing information update to MH6. MH6, having determined that significant new routing information has been received, also triggers an immediate update, which carries along the new routing information for MH4. MH4, upon receiving this information, then broadcasts it at every interval until the next full routing information dump. At MH4, the incremental advertised routing update has the form shown in Table 3.4

36 Example of DSDV MH1 MH3 MH2 MH4 MH6 MH5 MH7 MH8 MH1 The first line indicates who broadcast the table. The second line indicate who has any significant routing change. The remaining space to include those routes whose sequence numbers have changed. Dest Metric Sequence Number MH4 MH1 MH2 MH3 MH5 MH6 MH7 MH S820_MH4 S516_MH1 S238_MH2 S674_MH3 S502_MH5 S186_MH6 S238_MH7 S160_MH8 Table 3.4 MH4 advertised route table (Updated)

37 Damping Fluctuations MH9 All mobile node are transmitting updates approximately every 15 seconds. Mobile host Collection 1 12 hops MH2 MH4 Mobile host Collection 2 MH6 11 hops Moreover, suppose that the routing information update from MH2, issued by MH9, arrives at MH4 approximately 10 seconds before the routing information update from MH6.

38 Damping Fluctuations Fluctuations happen because route updates are selected according to one of the following criteria: Routes are always preferred if the sequence numbers are newer. Routes are preferred if the sequence numbers are the same and yet the metric is better. To damping fluctuation, the settling time data is stored in a table with the following fields: Destination Last settling time Average settling time

39 Damping Fluctuations The settling time is calculated by maintaining, for each destination, a running, weighted average over the most recent updates of the routes. Suppose that a new routing information update arrives at MH4, and the sequence number in the new entry is newer than the sequence number in the currently used entry but has a worse (i.e., higher) metric. The MH4 must use the new entry in make subsequent forwarding decisions. However, MH4 does not have to advertise the new route immediately and can consult its route settling time table to decide how long to wait before advertising. The average settling time is used for this determination. For instance, MH4 may decide to delay (Average Settling_Time x 2) before advertising a route

40 Damping Fluctuations This can be quit beneficial because if the possible unstable route were advertised immediately, the effects would ripple ( 波及 ) through the network.

41 Properties of DSDV At all instance, the DSDV protocol guarantees loop-free paths to each destination. Routing Looping Space complexity Bellman-Ford s / l Link-State s RIP s / l o(nd) o(n+e) o(n) DSDV Loop-free o(n) s-short-term loop; l-long-term loop, n- number of nodes, d- maximum degree of a node.

42 Wireless Routing Protocol (WRP) The Wireless Routing Protocol (WRP) provides improvements over the Bellman-Ford distance-vector protocol. It reduces the amount of route looping, and to ensure the reliable exchange of update messages. In WRP, each node maintains a distance-table matrix. Also recorded is the predecessor, the last node along a route before the destination node. S P D Each node neighbor broadcasts its current best route to selected destinations on an event driven incremental basis. A node, after receiving the route updating packets from a neighbor, updates its own routing table only if the consistency of the new information is checked against the predecessor information from all its neighbors.

43 Dynamic Source Routing (DSR)

44 Dynamic Source Routing (DSR) DSR is a source routing on-demand protocol with various efficiency improvements. In DSR, each node keeps a route cache that contains full paths to known destinations. If a source has no route to a destination, it broadcasts a route request packet to its neighbors. Any node receiving the route request packet and without a route to the destination appends it's own ID to the packet and re-broadcasts the packet. If a node receiving the route request packet has a route to the destination, the node replies to the source with a concatenation of the path from the source to itself and the path from itself to the destination. If the node already has a route to the source, the route reply packet will be sent over that route. Otherwise, depending on the underlining assumption of the directionality of links, the route reply packet can be sent over the reversed source-to-node path, or piggy-backed in the node's route request packet for the source.

45 Dynamic Source Routing (DSR) When an intermediate node discovers a broken link in an active route, it sends a route error packet to the source, which may reinitiate route discovery if an alternate route is not available. DSR has efficiency improving features. One of such features is the promiscuous mode, in which a node listens to route request, reply, or error messages not intended to itself and updates its route cache correspondingly. Another DSR feature is the expanding ring search procedure, in which the route request packets are sent with a maximum hop count, which can be increased if the destination is not found within the hop-count limit. Finally, adding jitter in sending the route reply messages to prevent route reply storms and packet salvaging to extract correct routes from route error packets are yet two other features that improve DSR performance.

46 DSR Route Discovery A A B A,B C D A,B,C,D ID=2 ID=2 ID=2 ID=2 E A is attempting to discover a route to node E. A broadcast a ROUTE REQUEST message, which identifies the initiator and target and also contain a unique request ID. Each ROUTE REQUEST message also contains a record listing the address of each immediate node through which this particular copy of the ROUTE REQUEST message has been forward.

47 DSR Route Discovery When another node receives a ROUTE REQUEST, if it is the target it returns a ROUTE REPLY message to the Route Discovery initiator, giving a copy of the accumulated route record from the ROUTE REQUEST; when the initiator receives this ROUTE REPLY, it caches this route in its Route Cache for use in sending subsequent packets to this destination. A A B A,B C A,B,C D A,B,C,D E ID=2 ID=2 ID=2 ID=2?? E typically examines its own Route Cache for a route back to A and, if found, uses it for the source route for delivery of the packet containing the ROUTE REPLY. Otherwise, E may perform its own Route Discovery for target node A, but to avoid possible infinite recursion of Route Discoveries it must piggyback this ROUTE REPLY on its own ROUTE REQUEST message for A.

48 DSR Route Discovery (For immediate nodes:)if the node ROUTE REQUEST recently saw another ROUTE REQUEST message from this initiator bearing this same request ID or if it finds that its own address is already listed in the route record in the ROUTE REQUEST message, it discards the REQUEST. If not, this node appends its own address to the route record in the ROUTE REQUEST message and propagates it by transmitting it as a local broadcast packet (with the same request ID).

49 DSR Route Discovery At the sending node initiating a Route Discovery, the Send Buffer contains a copy of each packet that cannot be transmitted by this node because it does not yet have a source route to the packet s destination. Each packet in the Send Buffer is stamped with the time it was placed there and is discarded for some time-out period. While a packet remains in the Send Buffer, the node should occasionally initiate a new Route Discovery for the packet s destination address. To reduce the overhead of a large number of unproductive ROUTE REQUEST packets, we use exponential backoff to limit the rate at which Route Discoveries may initiated by any node for the same target.

50 DSR Route Maintenance When originating or forwarding a packet using a source route, each node transmitting the packet is responsible for confirming that the packet has been received by the next hop along the source route. If the packet is retransmitted by some hop (C) the maximum number of times and no receipt confirmation is received, this node (C) return a ROUTE ERROR message to original sender of the packet, identifying the link over which the packet could not be forwarded. If the sender (A) has in its Route Cache another route to target, it can send the packet using the new route immediately. Otherwise, it may perform a new Route Discovery for this target (subject to the exponential backoff). New route A B C D E ROUTE ERROR

51 Additional Route Discovery Features Caching Overheard Routing Information A node forwarding or otherwise overhearing (in promiscuous mode) any packet may add the routing information from that packet to its own Route Cache. In particular, the source route used in a data packet, the accumulated route record in a ROUTE REQUEST, or the route being returned in a ROUTE REPLY may all be cached by any node. However, one limitation on caching of such overheard routing information is the possible presence of unidirectional link in the ad hoc network. A B C D E???

52 Additional Route Discovery Features Replying to Route Requests Using Cached Routes A node receiving a ROUTE REQUEST for which it is not the target searches its own Route Cache for a route to the REQUEST target. If a route is found, the node generally returns a ROUTE REPLY to the initiator itself rather than forwarding the ROUTE REQUEST. In the ROUTE REPLY, it sets the route record to list the sequence of hops over which this copy of the ROUTE REQUEST was forwarded to it, concatenated with its own idea of the route from itself to the target from its Route Cache. However, before transmitting a ROUTE REPLY packet, the node must verify that the resulting route, after this concatenation, contains no duplicate nodes listed in the route record.

53 Additional Route Discovery Features Preventing Route Reply Storms D C B G C B G A B G A B G G A ROUTE REPLY Storm E F B G A node should delay sending its own ROUTE REPLY for a random period d = H x ( h-1 + r ), where h is the length in number of network hops for the route to be returned in this node s ROUTE REPLY, r is a random number between 0 and 1, and H is a small constant delay (at least twice the maximum wireless link propagation delay) to be introduced per hop. ( May not send its ROUTE REPLY. )

54 Additional Route Discovery Features Route Request Hop Limits Each ROUTE REQUEST message contains a hop limit that may be used to limit the number of intermediate nodes allowed to forward that copy of the ROUTE REQUEST. As the REQUEST is forwarded, this limit is decreased, and the REQUEST packet is discarded if the limit reaches zero before finding the target. Non-propagating ROUTE REQUEST (with hop limit 0) propagating ROUTE REQUEST (with no hop limit) Expanding ring search for target (with hop limit =0,1,2,4, )

55 Additional Route Maintenance Features Packet Salvaging After sending a ROUTE ERROR message, a node may attempt to salvage the data packet that caused the ROUTE ERROR rather than discard it. To salvage the data packet, the node sending a ROUTE ERROR searches its own Route Cache for a route from itself to destination of the packet causing the ERROR. If found, the node replaces the original source route on the packet with the route from its Route Cache. The packet is also marked as having been salvaged to prevent a single packet being salvaged multiple times and entering a route loop. Our current salvaging mechanism allows backtracking but prevents a packet from being salvaged more than once.

56 Additional Route Maintenance Features Automatic Route Shortening Source route may be automatically shortened if one or more of their intermediate hops become unnecessary. If a node found that it is not intended next hop but is named in the later unused port of the packet s source route, it can infer that the intermediate nodes before itself in the source route is no long needed. A B,C,D B B,C,D C B,C,D D In this case, this node (C) returns a gratuitous( 无偿的 ) ROUTE REPLY message to the original sender of the packet (A). The ROUTE REPLY gives the shorter route with A-->C-->D

57 Additional Route Maintenance Features Increased Spreading of Route Error Message When a source node receives a ROUTE ERROR for a data packet that it originated, it propagates it to its neighbors by piggybacking it on its next ROUTE REQUEST. In this way, stale information in the caches of nodes around this source node will not generate ROUTE REPLYs that contain the same invalid link for which this source node received the ROUTE ERROR. A further improvement: A node that receives a ROUTE ERROR forwards it along the same source route that resulted in it. This will almost guarantee that the ROUTE ERROR reaches the node that generated the ROUTE REPLY containing the broken link, which prevents that node from contaminating( 污染 ) a future Route Discovery with the same broken link

58 Additional Route Maintenance Features Caching Negative Information (A broken link, problematic link) If node A caches the fact that the link from C to D is currently broken (rather than simple removing this hop from its Route Cache), it can guarantee that no ROUTE REPLY that utilizes this broken link, which it receives in response to its new Route Discovery, will be accepted. (A short expiration period must be placed on this negative cached information) A B C D E

59 Ad Hoc On-Demand Distance Vector Routing (AODV)

60 AODV Each node keeps a next-hop routing table containing the destinations to which it currently has a route. A route expires if it is not used or reactivated for a threshold amount of time. If a source has no route to a destination, it broadcasts a route request (RREQ) packet using an expanding ring search procedure, starting from a small Time-To-Live value (maximum hop count) for the RREQ, and increasing it if the destination is not found. The RREQ contains the last seen sequence number of the destination, as well as the source node's current sequence number. Any node that receives the RREQ updates its next-hop table entries with respect to the source node.

61 When an intermediate node discovers a broken link in an active route, it broadcasts a route error (RERR) packet to its neighbors, which in turn propagate the RERR packet upstream towards all nodes that have an active route using the broken link. The affected source can then re-initiate route discovery if the route is still needed. AODV A node that has a route to the destination with a higher sequence number than the one specified in the RREQ unicasts a route reply (RREP) packet back to the source. Upon receiving the RREP packet, each intermediate node along the RREP routes updates its next-hop table entries with respect to the destination node, dropping the redundant RREP packets and those RREP packets with a lower destination sequence number than one previously seen.

62 AODV Properties AODV does not attempt to maintain routes from every node to every other node in the network, Routes are discovered on an as-needed basis and maintained only as long as necessary. AODV is loop free at all times, even while repairing broken link. AODV is able to provide unicast, multicast, and broadcast communication ability. AODV currently utilizes only symmetric links between neighboring nodes. AODV is capable of operating on both wired and wireless media. Route tables are used by AODV to store pertinent routing information. AODV is able to maintain both unicast and multicast routes even for nodes in constant movement.

63 AODV Unicast Route The basic outline of the route discovery process is as follows: 1. When a node needed a route, it broadcast a RREQ(Route Request). 2. Any node with a current route to that destination can unicast a RREP (Route Reply) back to the source node. 3. Route information is maintained by each node in its route table. 4. Information obtained through RREQ and RREP messages is kept with other routing information in the route table. 5. Sequence numbers are used to eliminate stale route. 6. Route with old sequence numbers are aged out of the system.

64 AODV Unicast Route Discovery To begin a route discovery, when a node wishes to send a packet to some destination without a route, the source node create a RREQ packet, which contains the source node s IP and current sequence number as well as the destination s IP address and last known sequence number. The RREQ also contains a broadcast ID, which incremented each time the source node initiates a RREQ. After broadcasting the RREQ packet, the node sets a timer to wait for a reply. When a node receives a RREQ, it first checks whether it has seen it before (for a specified length of time) by noting the source IP address and broadcast ID pair. If so, discards the packet.

65 Source AODV Unicast Route Discovery To process the RREQ, the node sets up a reverse route entry for the source node in its route table. This reverse route entry contains the source node s IP address and sequence number as well as the number of hops to the source node and the IP address of the neighbor from which the RREQ was received. In this way, the node knows how to forward a RREP to the source if one is received. Associated with the reverse Destination route entry is lifetime. Propagation of RREQ Reverse Route Entry

66 AODV Unicast Route Discovery To respond to the RREQ, the node must have an unexpired entry for the destination in its route table. Furthermore, the sequence number associated with that destination must be at least as great as that indicated in RREQ. This prevents the information of routing loops by ensuring that the route returned is never old enough to point to a previous intermediate node. Otherwise, the previous node would have responded the RREQ. If the node is able to satisfy these two requirements, it responds by unicasting a RREP back to the source. If it is unable to satisfy the RREQ, it increments the RREQ s hop count and then broadcasts the packet to its neighbors. If the RREQ is lost, the source node is allowed to retry the broadcast route discovery mechanism. (Additional attempts = rreq_retries)

67 AODV Unicast Expanding Ring Search To use the expanding ring search, the source node sets the Time to Live (TTL) value of the RREQ to an initial ttl_start value. If no reply is received within the discovery period, the next RREQ is broadcast with a TTL value increased by an increment value. This process of increasing the TTL value continues until a threshold value is reached, beyond which the RREQ is broadcast across the entire network up to rreq_retries more times. When a new route is established, the distance to the destination is recorded in the route table. If route discovery must be initiated to this same destination later, the initial TTL value for the new RREQ is set to this distance plus the increment value. In this way, the source node can first search the area where the destination was last seen or to which it is likely to have moved.

68 AODV Unicast Forward Path Setup The RREP sent in response to the RREQ contains the IP address of both source and destination. If the destination node is responding, it places its current sequence number in the packet, initializes the hop count to zero, and places the length of time this route is valid in the RREP s Lifetime field. However, if an intermediate node is responding, it places its record of the destination s sequence number on the packet, sets the hop count equal to its distance from the destination and calculates the amount of time from which its route table entry for the destination will still be valid. It then unicast the RREP toward the source node, using the node from which it receives the RREQ as the next hop.

69 AODV Unicast Forward Path Setup When an intermediate node receives the RREP, it sets up a forward path entry to the destination in its route table. This forward path entry contains the IP address of the destination, the IP address of the neighbor from which the RREP arrived, and the hop count, or distance, to the destination. Associated with this entry is a lifetime, which is set to the lifetime contained in the RREP. Each time the route is used, its associated lifetime is updated. If the route is not used within the specified lifetime, it is deleted. After processing the RREP, the node forwards it toward the source. Source Destination

70 AODV Unicast Forward Path Setup It is likely that a node will receive a RREP for a given destination from more than one neighbor. In this case, it forwards the first RREP it receives and forwards a later RREP only if that RREP contains a greater destination sequence number or a smaller hop count. Otherwise, the node discards the packet.

71 AODV Unicast Route Maintenance Movement of nodes within the ad hoc network affects only the routes containing those nodes; such a path is called an active path. If the source node moves during an active session, it can reinitiate route discovery to establish a new route to the destination. When either the destination or some intermediate node moves, however, a Route Error (RERR) message is sent to the affected source nodes. This RERR is initiated by the node upstream of the break (i.e., closer to the source nodes). The RERR lists each of the destinations that are now unreachable because of the lost of the link.if one or more nodes route through the node upstream of the break, the node broadcast the RERR to these neighbors. When a source node receives the RERR, it can reinitiate route discovery if the route is still needed.

72 AODV Unicast Route Maintenance Destination 3 3 Destination Source Source (a) Route RERR (b)

73 AODV Unicast Route Maintenance When the neighbors receive the RERR, they mark their route to the destination as invalid by setting the distance to the destination equal to infinity. Route entries with an metric are not immediately deleted because they contain useful routing information with a recent destination timestamp. Discarding current route information, even of the negative variety, is especially to be avoided for algorithms that depend on local repair mechanisms for reducing system-wide broadcast.

74 The failure to receive any transmissions from a neighbor in the time defined by the periodic transmission of several Hello message is an indication that the local connectivity has changed and that the route information for this neighbor should be updated. AODV Unicast Local Connectivity Management Neighborhood information is obtained from broadcasts sent by neighboring nodes. Each time a node receives a broadcast from a given neighbor, it updates the Lifetime field associated with that neighbor in its route table. In the event that a node has not broadcast anything within the last hello_interval, it can broadcast a Hello packet to inform its neighbors that it is still in vicinity. The Hello message is a special unsolicited RREP that contains the node s IP and current sequence number. It is prevented from being rebroadcast outside the neighborhood of the node because it contains a TTL value of 1.

75 AODV Unicast Actions after Reboot After reboot, it will have lost its prior sequence number as well as its last known sequence numbers for various other destinations. Additionally, neighboring nodes may be using this node as an active next hop, which can create routing loops. To prevent this possibility, each node on reboot waits for delete_period, during which it does not respond to any routing packets. However, if it receives a data packet, it broadcasts a RERR, and resets the waiting timer (lifetime) to expire after the current time plus delete_period. By the time the rebooted node comes out of the waiting phase and becomes an active router again, none of its neighbors will still be using it as an active next hop. Its own sequence number is updated once it receives a RREQ from any other node, as the RREQ always carriers the maximum destination sequence number seen en route ( 在途中 ).

76 AODV Multicast Multicast group membership is dynamic; nodes are able to join and leave the group at any time. As nodes join the group, a bidirectional multicast tree composed of group members and nodes used to connect them (relay or tree node) is created. Each multicast group has associated with it a multicast group leader. That node is responsible for maintaining the multicast group sequence number and is in no way a central point of failure.

77 AODV Multicast Route Discovery Multicast route discovery begins either when a node wishes to join a multicast group or when it has data to send to multicast group and does not have a current route to it. This source node create a RREQ with destination address set to the IP address of the multicast group and that contains the group s last known sequence number. The node indicates in the RREQ whether it wishes to join the multicast group (through a join flag). It then broadcasts the RREQ to its neighbors. If the RREQ is a join request, only a node that is a member of the desired multicast tree (i.e., a router for the group ) may respond. Otherwise, any node with current route to the multicast group may reply.

78 AODV Multicast Route Discovery Group Leader? Prospective group member Multicast group member R R R Multicast tree member Nontree member Multicast tree link (a) RREQ message propagation?

79 AODV Multicast Route Discovery If a node receives a join RREQ for a multicast group of which it is not a member, or if it receives a RREQ and does not have a route to that group, it creates a reverse route entry to the source and then broadcast the RREQ to its neighbors. When a node receives a join RREQ for multicast group, it adds an unactivated entry for the source node in its multicast route table. Each next-hop entry in the multicast route table has an associated Active flag. If this flag is false, the node does not forward any data packets for the multicast group along that link. Only after the link is enabled can it be used to send data packets.

80 AODV Multicast Forward Path Setup If a node receives a join RREQ for a multicast group, it may reply if it is a router for the multicast group s tree and if its recorded sequence number for the multicast group is at least as great as that contained in the RREQ. Naturally, the group leader can always reply to a join RREQ for its multicast group. The responding node updates its multicast route table by placing the requesting node s next-hop information in the table and then generates a RREP. The node unicasts the RREP back to the node indicated in the RREQ. As nodes along the path to the source node receive the RREP, they set up a forward path entry for the multicast group in their multicast route table by adding the node from which they received the RREP as a next hop. Then they increment the Hop Count Field and forward the RREP to the next node.

81 AODV Multicast Route Group Leader? Prospective group member Multicast group member R R R Multicast tree member Nontree member Multicast tree link? (b) RREPs sent back to source

82 AODV Multicast Route Activation/Deactivation The source node must wait the length of the route discovery interval before using the route. If the request is to join the tree, the RREPs set up potential branches. The selected path to the tree must be explicitly activated at the end of the discovery interval so that one of these paths may be grafted ( 嫁接 ) onto tree.similarly, RREPs for a nonjoin request set up paths to the multicast tree. During the discovery interval, the source node keeps track of the route with the greatest multicast group sequence number and the smallest hop count to the multicast tree. At the end of the discovery interval, it activates that route by unicasting a multicast activation (MACT) message to its selected next hop and by setting the Activated flag for that entry in its multicast route table.

83 AODV Multicast Route Activation/Deactivation Once the next hop receives this message, it activates the route and, if it was not the originator of the RREP, then sends its own MACT message to its next hop. This continues until the originator of the RREP is reached. At that point, the new path to multicast tree has been determined.

84 AODV Multicast Route Group Leader? Prospective group member Multicast group member R R R Multicast tree member Nontree member Multicast tree link (c)multicast tree branch addition

85 AODV Multicast Route Activation/Deactivation The MACT message is also used when a node wishes to revoke( 取消 ) its member status and leave the multicast group. A leaf node that wishes to revoke its member status unicast a MACT message with the Prune ( 修剪 ) flag set to its next hop. It then deletes the multicast group information from its multicast route table.

86 AODV Multicast Route Activation/Deactivation Group Leader Group Leader R R R (a) Pruning of multicast group member Group member initiating prune (b) Multicast tree after pruning Path of MACT with set Prune flag

87 AODV Multicast Tree Maintenance Unlike in the unicast scenario, however, a link break necessarily triggers route reconstruction because the multicast members must remain connected during the group s lifetime. Multicast tree maintenance takes two forms: repairing a broken tree branch following a link break, and reconnecting the tree after a network partition. Link Breaks Node may notice a link break on the multicast tree in one of two ways. If no data packets have been sent recently, a node must receive a broadcast from each of its next hops at every hello_interval.

88 When a link break occurs, the (member) node downstream of the break (i.e., the node that is father from the multicast group leader) is responsible for repairing it (to avoid the loop ). The downstream node initiates the repair by broadcasting a join RREQ (expanding ring search may be used here) for the multicast group which includes an Extension field indicating the sending node s distance from the group leader. Only nodes on the multicast tree that are at least this close to the multicast group leader may reply to the RREQ. This prevents nodes on the same side of the break as the initiating node from responding, thereby ensuring that a new route to the group leader is found. AODV Multicast Tree Maintenance Failure to receive any broadcasts from a next hop on the multicast tree for hello_life = (1+ allowed_hello_loss) * hello_interval indicates that the next hop is out of transmission range and so the link must be repaired.

89 AODV Multicast Tree Maintenance Any node can respond to a RREQ by sending a RREP as long as it satisfies the following conditions: It is a part of the multicast tree. It has a fresh enough multicast group sequence number. Its hop count to the multicast group leader is smaller than that indicated by the Extension field of the RREQ. After the end of discovery period, the node selects its next hop and unicasts a MACT message to it to activate the link. If the distance from the group leader is different than that before link broken, it must inform its downstream next hops of their new distance from the group leader by broadcasting a MACT message with the Update flag set and the Hop Count filed set to the node s new distance.

90 AODV Multicast Tree Maintenance If the node initiating the repair does not receive a RREP after rreq_retries additional attempts, it can be assumed that the network has become partitioned and that this time the tree cannot be repaired. Because this side of the partition is then left without a group leader, a new leader must be selected and can be in number of ways. R R Newly selected group leader

91 AODV Multicast Tree Maintenance Reconnecting Partitioned Trees A multicast tree member from one partition will know that it has new connectivity to another partition if it receives a Group Hello (GRPH) for the multicast group that contains group leader information difference from its own records. For this purpose, the GRPH message is periodically broadcast by the multicast group leader across the network. It contains the IP address of the group leader and the IP address and current sequence number of the multicast group for which it is the group leader. A repair of the multicast tree is initiated by the group leader with the lower IP address (to avoid the loop).

92 AODV Multicast Tree Maintenance The group leader with lower IP address (GL1) unicasts a RREQ with Repair flag set to the other group leader (GL2). The RREQ also contains GL1 s record of the multicast group sequence number. When GL2 receives the RREQ, it takes the larger of its record of the multicast group sequence number and that indicated in the RREQ; it then increments this value by 1 and unicasts a RREP with Repair flag set to GL1. When GL1 receives the RREP, the tree is reconnected.

93 AODV Multicast Tree Maintenance Group Leader 1 R R Group Leader 2 R GRPH Network Partition Group Leader R R (a) Partitioned network (b) Reconnected network

94 AODV Broadcast When a node wishes to generate a broadcast, it sends the broadcast packet to the well-known broadcast address Every node maintains a list of those broadcast packets that have already been received and retransmitted. This list contains the source IP address and the 16 bit IP ident value from the IP header of each broadcast packet it receives. It stores these values for broadcast_record_time. When a node receives a broadcast packet, it checks its broadcast list entries to determine whether the packet has already been received and thus whether it has already been retransmitted. If there is no such matching entry, the node processes and retransmits the broadcast packet. If there is such an entry, the node silently discard the packet.