(AODV) Ad-hoc On-Demand Distance Vector Routing.pdf

发布时间：2022-06-08 发布人：admin 分类：说明书资料大小：0.21M 资料格式：pdf 举报版权申诉

boyew_gavin-3461674-4744302542986551949.pdf-第1页.png

第1页 / 共11页

boyew_gavin-3461674-4744302542986551949.pdf-第2页.png

第2页 / 共11页

boyew_gavin-3461674-4744302542986551949.pdf-第3页.png

第3页 / 共11页

boyew_gavin-3461674-4744302542986551949.pdf-第4页.png

第4页 / 共11页

boyew_gavin-3461674-4744302542986551949.pdf-第5页.png

第5页 / 共11页

boyew_gavin-3461674-4744302542986551949.pdf-第6页.png

第6页 / 共11页

boyew_gavin-3461674-4744302542986551949.pdf-第7页.png

第7页 / 共11页

boyew_gavin-3461674-4744302542986551949.pdf-第8页.png

第8页 / 共11页

文本预览

Ad-hoc On-Demand Distance Vector Routing Charles E. Perkins Elizabeth M. Royer Sun Microsystems Laboratories Advanced Development Group Dept. of Electrical and Computer Engineering University of California, Santa Barbara Menlo Park, CA cperkins@eng.sun.com Santa Barbara, CA eroyer@alpha.ece.ucsb.edu Abstract An ad-hoc network is the cooperative engagement of a collection of mobile nodes without the required inter- vention of any centralized access point or existing in- frastructure. In this paper we present Ad-hoc On De- mand Distance Vector Routing AODV, a novel algo- rithm for the operation of such ad-hoc networks. Each Mobile Host operates as a specialized router, and routes are obtained as needed i.e., on-demand with little or no reliance on periodic advertisements. Our new routing algorithm is quite suitable for a dynamic self- starting network, as required by users wishing to utilize ad-hoc networks. AODV provides loop-free routes even while repairing broken links. Because the protocol does not require global periodic routing advertisements, the demand on the overall bandwidth available to the mo- bile nodes is substantially less than in those protocols that do necessitate such advertisements. Nevertheless we can still maintain most of the advantages of basic distance-vector routing mechanisms. We show that our algorithm scales to large populations of mobile nodes wishing to form ad-hoc networks. We also include an evaluation methodology and simulation results to verify the operation of our algorithm. Keywords: Ad-hoc Networking, Distance Vector Routing, Dynamic Routing, Mobile Networking, Wire- less Networks . Introduction Laptop computers continue to show improvements in convenience, mobility, memory capacity, and avail- ability of disk storage. These smaller computers can be equipped with gigabytes of disk storage, high res- olution color displays, pointing devices, and wireless communications adapters. Moreover, because many of these small in size only computers operate with bat- tery power, users are free to move about at their con- venience without being constrained by wires. The idea of forming an on-the-y ad-hoc network of mobile nodes dates back to DARPA packet radio net- work days , . More recently the interest in this subject has grown due to availability of license-free, wireless communication devices that users of laptop computers can use to communicate with each other. Several recent papers on this topic have focused on the algorithmic complexity of choosing the optimal set of ad-hoc routers , , , while others have proposed new routing solutions , , , , , leverag- ing features from the existing Internet routing algo- rithms. Interest within the Internet Engineering Task Force IETF is also growing as is evidenced by the for- mation of a new working group manet , whose charter is to develop a solution framework for rout- ing in ad-hoc networks. The manet working group has goals that are quite distinct from the goals of the IETF mobileip working group, and make little or no use of Mobile IP or any of its forerunners e.g., , . The Destination-Sequenced Distance Vector DSDV algorithm has been proposed as a variant of the distance vector routing method by which mobile nodes cooperate to form an ad-hoc network. DSDV is eective for creating ad-hoc networks for small popu- lations of mobile nodes, but it is a fairly brute force approach because it depends for its correct operation on the periodic advertisement and global dissemina- tion of connectivity information. Frequent system-wide broadcasts limit the size of ad-hoc networks that can eectively use DSDV because the control message over- head grows as On. DSDV also requires each mobile node to maintain a complete list of routes, one for each destination within the ad-hoc network. This almost al- ways exceeds the needs of any particular mobile node. Keeping a complete routing table does reduce route ac- quisition latency before transmission of the rst packet to a destination. It is, however, possible to design a sys-

tem whereby routes are created on-demand e.g., . Such systems must take steps to limit the time used for route acquisition; otherwise, users of the ad-hoc nodes might experience unacceptably long waits before trans- mitting urgent information. The advantage here is that a smoothly functioning ad-hoc system with on-demand routes could largely eliminate the need for periodic broadcast of route advertisements. With the goals of minimizing broadcasts and transmission latency when new routes are needed, we designed a protocol to im- prove upon the performance characteristics of DSDV in the creation and maintenance of ad-hoc networks. Although AODV does not depend specically on particular aspects of the physical medium across which packets are disseminated, its development has been largely motivated by limited range broadcast media such as those utilized by infrared or radio frequency wireless communications adapters. Using such media, a mobile node can have neighbors which hear its broad- casts and yet do not detect each other the hidden ter- minal problem . We do not make any attempt to use specic characteristics of the physical medium in our algorithm, nor to handle specic problems posed by channelization needs of radio frequency transmit- ters. Nodes that need to operate over multiple chan- nels are presumed to be able to do so. The algorithm works on wired media as well as wireless media, as long as links along which packets may be transmitted are available. The only requirement placed on the broad- cast medium is that neighboring nodes can detect each others’ broadcasts. AODV uses symmetric links between neighboring nodes. It does not attempt to follow paths between nodes when one of the nodes cannot hear the other one; however we may include the use of such links in future enhancements. Steps to prevent use of such asymmet- ric links between nodes are described briey in Sec- tion .. The remainder of this paper is organized as follows. In Section , the protocol details for AODV are given. Section presents the simulations, input parameters, and results obtained. Section describes our plans for future work, and nally Section concludes the paper. . The Ad-hoc On-Demand Distance Vector Algorithm Our basic proposal can be called a pure on-demand route acquisition system; nodes that do not lie on ac- tive paths neither maintain any routing information nor participate in any periodic routing table exchanges. Further, a node does not have to discover and maintain a route to another node until the two need to commu- nicate, unless the former node is oering its services as an intermediate forwarding station to maintain con- nectivity between two other nodes. When the local connectivity of the mobile node is of interest, each mobile node can become aware of the other nodes in its neighborhood by the use of several techniques, including local not system-wide broad- casts known as hello messages. The routing tables of the nodes within the neighborhood are organized to op- timize response time to local movements and provide quick response time for requests for establishment of new routes. The algorithm’s primary objectives are: To broadcast discovery packets only when neces- sary To distinguish between local connectivity manage- ment neighborhood detection and general topol- ogy maintenance To disseminate information about changes in lo- cal connectivity to those neighboring mobile nodes that are likely to need the information. AODV uses a broadcast route discovery mecha- nism , as is also used with modications in the Dy- namic Source Routing DSR algorithm . Instead of source routing, however, AODV relies on dynam- ically establishing route table entries at intermediate nodes. This dierence pays o in networks with many nodes, where a larger overhead is incurred by carry- ing source routes in each data packet. To maintain the most recent routing information between nodes, we borrow the concept of destination sequence num- bers from DSDV . Unlike in DSDV, however, each ad-hoc node maintains a monotonically increasing se- quence number counter which is used to supersede stale cached routes. The combination of these techniques yields an algorithm that uses bandwidth eciently by minimizing the network load for control and data traf- c, is responsive to changes in topology, and ensures loop-free routing. 2.1. Path Discovery The Path Discovery process is initiated whenever a source node needs to communicate with another node for which it has no routing information in its table. Every node maintains two separate counters: a node sequence number and a broadcast id. The source node initiates path discovery by broadcasting a route request RREQ packet to its neighbors. The RREQ contains the following elds: source addr; source sequence ; broadcast id; dest addr; dest sequence ; hop cnt

The pair source addr; broadcast id uniquely identies a RREQ. broadcast id is incremented when- ever the source issues a new RREQ. Each neighbor either satises the RREQ by sending a route reply RREP back to the source see Section .., or re- broadcasts the RREQ to its own neighbors after in- creasing the hop cnt. Notice that a node may receive multiple copies of the same route broadcast packet from various neighbors. When an intermediate node receives a RREQ, if it has already received a RREQ with the same broadcast id and source address, it drops the re- dundant RREQ and does not rebroadcast it. If a node cannot satisfy the RREQ, it keeps track of the follow- ing information in order to implement the reverse path setup, as well as the forward path setup that will ac- company the transmission of the eventual RREP: Destination IP address Source IP address Broadcast id Expiration time for reverse path route entry Source node’s sequence number. D D S timeout S Figure 1. Reverse Path Formation Figure 2. Forward Path Formation 2.1.1. Reverse Path Setup There are two sequence numbers in addition to the broadcast id included in a RREQ: the source se- quence number and the last destination sequence num- ber known to the source. The source sequence number is used to maintain freshness information about the re- verse route to the source, and the destination sequence number species how fresh a route to the destination must be before it can be accepted by the source. As the RREQ travels from a source to various desti- nations, it automatically sets up the reverse path from all nodes back to the source , as illustrated in Fig- ure . To set up a reverse path, a node records the address of the neighbor from which it received the rst copy of the RREQ. These reverse path route entries are maintained for at least enough time for the RREQ to traverse the network and produce a reply to the sender. 2.1.2. Forward Path Setup Eventually, a RREQ will arrive at a node possibly the destination itself that possesses a current route to the destination. The receiving node rst checks that the RREQ was received over a bi-directional link. If an intermediate node has a route entry for the desired destination, it determines whether the route is current by comparing the destination sequence number in its own route entry to the destination sequence number in the RREQ. If the RREQ’s sequence number for the destination is greater than that recorded by the inter- mediate node, the intermediate node must not use its recorded route to respond to the RREQ. Instead, the intermediate node rebroadcasts the RREQ. The inter- mediate node can reply only when it has a route with a sequence number that is greater than or equal to that contained in the RREQ. If it does have a current route to the destination, and if the RREQ has not been processed previously, the node then unicasts a route re- ply packet RREP back to its neighbor from which it received the RREQ. A RREP contains the following information: source addr; dest addr; dest sequence ; hop cnt; lif etime By the time a broadcast packet arrives at a node that can supply a route to the destination, a re- verse path has been established to the source of the RREQ Section ... As the RREP travels back to the source, each node along the path sets up a forward pointer to the node from which the RREP came, updates its timeout information for route en- tries to the source and destination, and records the latest destination sequence number for the requested destination. Figure represents the forward path setup as the RREP travels from the destination D to the source node S. Nodes that are not along the path determined by the RREP will timeout after AC- TIVE ROUTE TIMEOUT msec and will delete the reverse pointers. A node receiving an RREP propagates the rst RREP for a given source node towards that source. If it receives further RREPs, it updates its routing in- formation and propagates the RREP only if the RREP

contains either a greater destination sequence number than the previous RREP, or the same destination se- quence number with a smaller hopcount. It suppresses all other RREPs it receives. This decreases the num- ber of RREPs propagating towards the source while also ensuring the most up-to-date and quickest routing information. The source node can begin data trans- mission as soon as the rst RREP is received, and can later update its routing information if it learns of a better route. 2.2. Route Table Management Each time a route entry is used to transmit data from a source toward a destination, the timeout for the entry is reset to the current time plus ac- tive route timeout. If a new route is oered to a mobile node, the mo- bile node compares the destination sequence number of the new route to the destination sequence number for the current route. The route with the greater se- quence number is chosen. If the sequence numbers are the same, then the new route is selected only if it has a smaller metric fewer number of hops to the desti- nation. In addition to the source and destination sequence numbers, other useful information is also stored in the route table entries, and is called the soft-state asso- ciated with the entry. Associated with reverse path routing entries is a timer, called the route request ex- piration timer. The purpose of this timer is to purge reverse path routing entries from those nodes that do not lie on the path from the source to the destination. The expiration time depends upon the size of the ad- hoc network. Another important parameter associated with routing entries is the route caching timeout, or the time after which the route is considered to be invalid. In each routing table entry, the address of active neighbors through which packets for the given desti- nation are received is also maintained. A neighbor is considered active for that destination if it origi- nates or relays at least one packet for that destination within the most recent active timeout period. This in- formation is maintained so that all active source nodes can be notied when a link along a path to the des- tination breaks. A route entry is considered active if it is in use by any active neighbors. The path from a source to a destination, which is followed by pack- ets along active route entries, is called an active path. Note that, as with DSDV, all routes in the route table are tagged with destination sequence numbers, which guarantee that no routing loops can form, even under extreme conditions of out-of-order packet delivery and high node mobility see Appendix A. A mobile node maintains a route table entry for each destination of interest. Each route table entry contains the following information: Destination Next Hop Number of hops metric Sequence number for the destination Active neighbors for this route Expiration time for the route table entry 2.3. Path Maintenance Movement of nodes not lying along an active path does not aect the routing to that path’s destination. If the source node moves during an active session, it can reinitiate the route discovery procedure to estab- lish a new route to the destination. When either the destination or some intermediate node moves, a special RREP is sent to the aected source nodes. Periodic hello messages can be used to ensure symmetric links, as well as to detect link failures, as described in Sec- tion .. Alternatively, and with far less latency, such failures could be detected by using link-layer acknowl- edgments LLACKS. A link failure is also indicated if attempts to forward a packet to the next hop fail. Once the next hop becomes unreachable, the node upstream of the break propagates an unsolicited RREP with a fresh sequence number i.e., a sequence number that is one greater than the previously known sequence number and hop count of to all active upstream neighbors. Those nodes subsequently relay that mes- sage to their active neighbors and so on. This pro- cess continues until all active source nodes are notied; it terminates because AODV maintains only loop-free routes and there are only a nite number of nodes in the ad-hoc network. Upon receiving notication of a broken link, source nodes can restart the discovery process if they still re- quire a route to the destination. To determine whether a route is still needed, a node may check whether the route has been used recently, as well as inspect upper- level protocol control blocks to see whether connec- tions remain open using the indicated destination. If the source node or any other node along the previ- ous route decides it would like to rebuild the route to the destination, it sends out an RREQ with a desti- nation sequence number of one greater than the previ- ously known sequence number, to ensure that it builds a new, viable route, and that no nodes reply if they still regard the previous route as valid.

Simulated protocol Packet size bytes Packet count Inter-arrival time of data packets Session interval sec S DATA UDP Exponential-mean Exponential-mean msec Geometric-mean msec Geometric-mean VOICE UDP Table 1. Session-Dependent Trafﬁc Parameters. 2.4. Local Connectivity Management Nodes learn of their neighbors in one of two ways. Whenever a node receives a broadcast from a neigh- bor, it updates its local connectivity information to ensure that it includes this neighbor. In the event that a node has not sent any packets to all of its ac- tive downstream neighbors within hello interval, it broadcasts to its neighbors a hello message a spe- cial unsolicited RREP, containing its identity and sequence number. The node’s sequence number is not changed for hello message transmissions. This hello message is prevented from being rebroadcast out- side the neighborhood of the node because it con- tains a time to live TTL value of . Neighbors that receive this packet update their local connectiv- ity information to the node. Receiving a broadcast or a hello from a new neighbor, or failing to receive allowed hello loss consecutive hello messages from a node previously in the neighborhood, is an indica- tion that the local connectivity has changed. Fail- ing to receive hello messages from inactive neighbors does not trigger any protocol action. If hello mes- sages are not received from the next hop along an ac- tive path, the active neighbors using that next hop are sent notication of link failure as described in Section .. We have determined the optimal value for allowed hello loss is two, as is shown in Sec- tion .. The local connectivity management with hello mes- sages can also be used to ensure that only nodes with bidirectional connectivity are considered to be neigh- bors. For this purpose, each hello sent by a node lists the nodes from which it has heard. Each node checks to make sure that it uses only routes to neighbors that have heard the node’s hello message. To save local bandwidth, such checking should be performed only if explicitly congured into the nodes. . Simulations and Results We have simulated AODV using an event-driven, packet-level simulator called PARSEC, which was developed at UCLA as the successor to Maisie. The PARSEC language is suited to the simulation of dy- namic topologies and routing algorithms. The main objective of our simulations is to show that on-demand route establishment with AODV is both quick and accurate. Additional objectives include showing that AODV scales well to large networks, and determining the optimal value for each of the necessary parameters. 3.1. Simulation Environment Our simulations were run using networks of , , , and nodes. The movement algorithm for all network sizes is the same. Nodes are initially placed randomly within a xed-size L L area. During the simulation, nodes are free to move anywhere within this area. Each node chooses a speed from a uniform distri- bution between . and . meters per second. It then travels towards a random spot within the L L area. The node moves until it reaches that spot, then chooses a rest period from a uniform distribution between and seconds. After the rest period, the node travels towards another randomly selected spot. This process repeats throughout the simulation, causing continuous changes in the topology of the underlying network. Each of the simulations also uses the same channel model. Before beginning a transmission, carrier sens- ing is performed by a node to determine whether any of its neighbors is transmitting. If the node detects an ongoing transmission by a neighbor, it calculates an ex- ponential backo based on the number of times it has attempted the retransmission and waits this amount of time before listening to the channel again. A node at- tempts to transmit a packet max retrans times before dropping the packet. Nodes in the simulation frequently suer from the hidden terminal problem. If node A transmits to node B, and node C, unable to hear node A’s transmission, simultaneously transmits to node B, we assume the packets collide at node B and both packets are dropped. Each node creates a session to another node selected at random. The sessions created for each simulation

Hello Interval Route Discovery Timeout Route Expiration Reverse Route Life Maximum of Retransmissions msec msec msec msec Table 2. Simulated Parameter Values are of homogeneous type; they are either small data S DATA packets or voice data. The parameters for each of the session types are given in Table . We chose to use the small data packet sessions for most of our simulations because the larger size of the voice packets and the greater number of sessions generated tended to congest the network and hence decrease the goodput ratio. Nevertheless, we include the results from these simulations to oer a contrast to the lighter demands of the small data packets and to place a greater stress on the protocol. A session sends data segments until either it has sent the desired number of segments or it receives a timeout message from the network layer. Timeouts are triggered when a node has sent a RREQ for a particular destination and has not received a valid route within route discovery timeout. Any time a route is not available during a session, packets are dropped by the network layer. The data rate for both session types is . Mbitsec. Each simulation is run for seconds, and new ses- sions are generated throughout the simulation. Hence, we keep track of, and account for, any uncompleted sessions and data packets in transit at the end of the simulation. The interconnection pattern of an ad-hoc network is determined in part by the communication range Rmax. For our simulations, we held Rmax constant at m. Two nodes can communicate directly, and are thus considered each other’s neighbors, if they are less than Rmax distance apart. The room size for the and nodes networks is mm. For nodes, we found mm to be too small, so we increased the dimensions to mm. Similarly, for nodes we used a room size of mm. Table gives the values of the essential parameters for AODV. The parameter values were chosen because they minimize network congestion while allowing the algorithm to operate as quickly and as accurately as possible. 3.2. Results and Discussion Our rst objective was to show that AODV can nd routes quickly and accurately. Since we did not at this time know an optimal value for rreq retries and allowed hello loss, we varied rreq retries be- tween and and set allowed hello loss to , a value we intuitively guessed would be reasonable. Fig- ure shows the goodput ratios for and nodes using the S DATA session type. For nodes, the goodput ratio is consistently above . For nodes, the goodput ratio for rreq retries= is ap- proximately , but then it decreases to for rreq retries= and then increases with increasing values of rreq retries. Broch et al. simulated AODV over a network of nodes and achieved good- put ratios between and , depending on the amount of time the nodes were stationary during the simulation. Note that our S DATA simulation uses the same size data packets as they did. Hence, our ) % ( t u p d o o G 100 99 98 97 96 95 94 93 92 91 90 50 Nodes 100 Nodes 0 0.5 1 1.5 2 2.5 3 RREQ_RETRIES ) % ( t u p d o o G 100 99 98 97 96 95 94 93 92 91 90 50 Nodes 100 Nodes 0 0.5 1 2 ALLOWED_HELLO_LOSS 1.5 2.5 3 Figure 3. Achieved Goodput for Varying rreq retries Figure 4. Achieved Goodput for Varying allowed hello loss

50 Nodes 100 Nodes 300 250 200 150 ) c e s m ( y c n e t a L n o 600 500 400 300 ) c e s m ( y c n e t a L n o 50 Nodes 100 Nodes i i t i s u q c A e i i t i s u q c A e 100 t u o R 50 0 0 0.5 1 1.5 2 2.5 3 RREQ_RETRIES 200 t u o R 100 0 0 0.5 1 2 ALLOWED_HELLO_LOSS 1.5 2.5 3 Figure 5. Route Acquisition Latency for Figure 6. Route Acquisition Latency for Varying rreq retries Varying allowed hello loss achieved goodput ratio for a node network roughly corresponds with their results for the same size net- work, with our results being slightly better. We disre- gard the articially high goodput ratio for nodes and rreq retries= because more of the ses- sions aborted in this simulation than in the simulations with larger rreq retries values. Given the remaining goodput ratios for and nodes, we set the optimal rreq retries value to . We then simulated and nodes networks with rreq retries= and varied the allowed hello loss parameter. The results of these simu- lations are shown in Figure . Here, for nodes, allowed hello loss= produced the best results, while for nodes allowed hello loss= was the best. Again, because is an unrealistic value, and because allowed hello loss= produced the second best results, we chose allowed hello loss = to be the optimal value. This contradicts Broch et al.’s nding that allowed hello loss = produces bet- ter performance. In their simulations they also used rreq retries = . The combination of the two pa- rameters may account for the slightly decreased good- put that their AODV simulations produced. Another signicant dierence between their simulation and ours is that they set ROUTE DISCOVERY TIMEOUT to msec, whereas we found the optimal value to be msec. To show that AODV nds routes in a timely man- ner, we examined the route acquisition latency. The route acquisition latency was computed by noting the simulation time when an initial RREQ was broadcast for a given destination, and then noting the time when the rst RREP was received at the source. For suc- cessive RREQ retries for the same route, the start time for the route was held at the time at which the rst RREQ was sent. If a route to a destination was never found, this time lapse was not taken into account in the computation. Figure shows the computed route acquisition latencies for varying rreq retries values, and Figure shows the corresponding values for varying allowed hello loss values. With the exception of rreq retries = , the minimum route acquisition latency was attained for the combination rreq retries=, allowed hello loss=, giving fur- ther credence to our choice of parameter values. Table gives the essential results of our simulations for networks of , , , and nodes. The re- sults were obtained using the S DATA session type, and setting rreq retries= and allowed hello loss=. The bandwidth overhead ratio is a metric taken from although there it is called bandwidth utilization, and is computed by dividing the total number of bits transmitted by the total number of data bits trans- mitted. We include this calculation because it gives a good representation of the amount of control over- head associated with a protocol. We also report both the instantaneous goodput ratio at the simulation end, as well as the average goodput ratio throughout the simulation, because these numbers can vary due to a sudden increase in link breakages or session cre- ations at the end of the simulation. The node simulation was run for a shorter period of time be- cause of the diculty of running such a large simu- lation. Also, the and node simulations had a slightly larger session generation interval than the and nodes networks in order to keep the to- tal number of sessions more manageable. We note that the results of the and node networks are not as good as we would have desired. Reasons for the decreased goodput ratio are a much greater collision rate, due to the increase in the number of

of Nodes Goodput Ratio at sim end Goodput Ratio avg Bandwidth Overhead Ratio Avg Rte Acq Latency msec Avg Path Length hops Loss to Collision Room Size m Simulation Length sec Generated Sessions Completed Sessions Aborted Sessions . . . . . . . . . . . . . . . . . . x x x x . . Table 3. Summary of S DATA Results nodes and the longer paths causing a greater like- lihood for collisions during the hop-by-hop forward- ing of the message, and the added interference of all the hello messages. Also, the route acquisition la- tency increased due to the larger average path length and the additional delay in control message trans- mission because of increased competition for channel access. However, regardless of the decreased perfor- mance values, AODV is currently one of the most scalable ad-hoc routing protocols. We feel that with networks this large we are pushing the current capa- bilities of mobile networks, as we are not aware of any other attempts to model networks of such a large size. We also ran simulations of the and node net- works using the voice session type described in Sec- tion .. We used this session type to stress the abil- ities of AODV. The results of these simulations, to- gether with the comparable results from the S DATA session type, are given in Table . The two im- portant results from these simulations are the good- put ratio and the bandwidth overhead ratio. The goodput ratio for the voice session type was lower than that of the S DATA sessions. This is due to the fact that there were signicantly more collisions due to the longer data packet lengths. Also, be- cause the data packets were larger and took longer to transmit, we found that the queues of the nodes frequently backed up because they had to wait for channel access for possibly lengthy periods of time, causing delays in sending RREQs and RREPs. On the other hand, if we compare the bandwidth over- head ratio between the two session types, we nd that the voice sessions had more optimal results than the S DATA sessions. This is because for virtually the same amount of control overhead i.e. the same number of RREQs and RREPs, the voice sessions send many more data bits because of the increased data packet size. . Current Status and Future Work Currently, AODV has been specied in an Inter- net Draft submitted to the IETF manet working group. There are a number of further improvements which may support larger populations of ad-hoc users, or improve response time to route queries, or increase the capabilities of the protocol. 4.1. Multicast Multicast, as a basic tool for conferencing applica- tions, must be considered when designing routing al- gorithms for ad-hoc networks. We have already en- hanced AODV to provide multicast capability. Mul- ticast using AODV follows directly from the Route RequestRoute Reply message cycle and requires only one additional message type, the Multicast Validation Message. Nodes in the network that are members of the same multicast group, together with the nodes used as routers to connect group members, form a bi- directional multicast tree across which multicast data packets are relayed. The MACT message is used to select the node which a source node chooses as its next hop for the multicast tree. Additionally, there is a mul- ticast group leader that is responsible for incrementing the multicast group sequence number. More details of the multicast portion of AODV can be found in .

分享到：

赞收藏

资料库

(AODV) Ad-hoc On-Demand Distance Vector Routing.pdf

相关推荐

课程资源

热门标签

最新资料