Professional Documents
Culture Documents
40
Proceedings of the National Conference on Mobile and Adhoc Networks, 29th & 30th October 2010
The wireless channel has time-varying and asymmetric propagation properties. Hidden-node and exposed-node problems may occur. The rest of this paper is organized as follows. Section 2 & 3 presents the state of the art on routing in MANETs using AODV. Section 4 presents a Mulicast AODV. Section 5 Presents the MAODV algorithm formulation. Section 6 outlines the most important parameters for simulation results and analysis, whereas Section 7 gives some concluding remarks. II.WORKING PRINCIPLE AND RELATED WORK AODV is a relative of the BellmanFord distant vector algorithm, but is adapted to work in a mobile environment. AODV determines a route to a destination only when a node wants to send a packet to that destination. Routes are maintained as long as they are needed by the source. Sequence numbers ensure the freshness of routes and guarantee the loop-free routing. 1.3 Routing tables
uniquely. On receiving a RREQ message each node checks the source address and the request ID. If the node has already received a RREQ with the same pair of parameters the new RREQ packet will be discarded. Otherwise the RREQ will be either forwarded (broadcast) or replied (unicast) with a RREP message. 2.2.2. Routing reply If a node is the destination, or has a valid route to the destination, it unicasts a route reply message (RREP) back to the source. This message has the following format. The reason one can unicast RREP back is that every node forwarding a RREQ message caches a route back to the source node. Table 2.2 RREQ Message Format
Source addres s Reque st ID Sr c se q No . Dest addres s Des t seq No. Hop coun t
Expiration time, also called lifetime, is reset each time the route has been used. The new expiration time is the sum of the current time and a parameter called active route timeout. This parameter, also called route caching timeout, is the time after which the route is considered as invalid, and so the nodes not lying on the route determined by RREPs delete their reverse entries. If active route timeout is big enough route repairs will maintain routes. Table 2.1 Routing Table Information
Desti natio n Nex t hop No. of hops Dest Seq no. Active neighb ors Expirat ion time
2.2.3. Route error All nodes monitor their own neighbourhood. When a node in an active route gets lost, a route error message (RERR) is generated to notify the other nodes on both sides of the link of the loss of this link. 2.2.4. HELLO messages Each node can get to know its neighbourhood by using local broadcasts, socalled HELLO messages. Nodes neighbours are all the nodes that it can directly communicate with. Although AODV is a reactive protocol it uses these periodic HELLO messages to inform the neighbours that the link is still alive[8]. The HELLO messages will never be forwarded because they are broadcasted with TTL = 1. When a node receives a HELLO message it refreshes the corresponding lifetime of the neighbour
1.4
Control messages
2.2.1. Routing request When a route is not available for the destination, a route request packet (RREQ) is flooded throughout the network. The request ID is incremented each time the source node sends a new RREQ, so the pair (source address, request ID) identifies a RREQ
41
Proceedings of the National Conference on Mobile and Adhoc Networks, 29th & 30th October 2010
information in the routing table. This local connectivity management should be distinguished from general topology management to optimize response time to local changes in the network. 2.3. Route discovery Route discovery process starts when a source node does not have routing information for a node to be communicated with. Route discovery is initiated by broadcasting a RREQ message [14]. The route is established when a RREP message is received. A source node may receive multiple RREP messages with different routes. It then updates its routing entries if and only if the RREP has a greater sequence number, i.e. fresh information. 2.3.1. Reverse path setup and Forward path setup While transmitting RREQ messages through the network each node notes the reverse path to the source. When the destination node is found the RREP message will travel along this path, so no more broadcasts will be needed. For this purpose, the node on receiving RREQ packet from neighbour records the address of this neighbour. When a broadcast RREQ packet arrives at a node having a route to the destination, the reverse path will be used for sending a RREP message. While transmitting this RREP message the forward path is setting up. One can say that this forward path is reverse to the reverse path. As soon as the forward path is built the data transmission can be started. Data packets waiting to be transmitted are buffered locally and transmitted in a FIFO-queue when a route is set up. After a RREP was forwarded by a node, it can receive another RREP. This new RREP will be either discarded or forwarded, depending on its destination sequence number [12]: if the new RREP has a greater destination sequence number, then the route should be updated, and RREP is forwarded if the destination sequence numbers in old and new RREPs are the same, but the new RREP has a smaller hop count, this
new RREP should be preferred and forwarded Otherwise all later arriving RREPs will be discarded III. RELATED WORK ON AODV Stephen Walter[1] et al., redesigned AODV methods to address its overhead costs, allow easier integration with existing networks, and increase capacity over the original protocol. He explored the potential of a hybrid AODV protocol that uses the strengths of the existing AODV, its speed and on-demand nature, while addressing the discovery flooding and the issue of ad-hoc networks requiring enough nodes to operate. His proposed hybrid system will need to reduce the overhead of the original protocol produced by its route discovery flooding. He also introduced multi-radio bands to increase capacity. To allow the protocol further scalability, he proposed to introduce a fixed routing node, which changes the protocol from a true ad-hoc system into a mixed structure. Babar S. Kawish et al., [2] analyses the bandwidth utilization and routing delay once MANETs are subjected to prolong static environments and suggests a provision of dynamic route cache in AODV routing protocol. He analyse the behavior of AODV routing protocol for fixed networks and those exhibiting low mobility with a view to highlight the reasons for this shortfall in the performance of AODV and proposed suitable enhancement for making up this deficiency. He enhanced the existing AODV protocol with parameters that reduces the overheads in such conditions but without altering the protocol efficiency for high mobility networks. Routing delay and bandwidth utilization by the control traffic are two major drawbacks once AODV network is subjected to static environments. By introducing user defined parameters for route caching, the cost of overheads in AODV can be reduced drastically which in turn will not only improve the bandwidth utilization factor and routing delay but also save the resources from unnecessary route processing. Clifton Lin et al., [3] implemented the AODV protocol as part of a scalable wireless ad hoc network simulation (SWANS). Since one of the goals is scalability, he strived to make the code as efficient as possible. He
42
Proceedings of the National Conference on Mobile and Adhoc Networks, 29th & 30th October 2010
implemented an expanding ring search algorithm to limit the flood of RREQ messages. He also attempted to keep memory utilization low by doing things like capping buffer sizes, removing expired entries, and by reducing the number of events. By using efficient data structures, such as hash tables, performance has been improved. In most situations, the node uses an expanding-ring search to limit flooding the whole network, but this comes at additional cost to the local area of a node where the same route request is likely to be repeated several times. Hence, it would be highly desirable to limit the number of unnecessary broadcast transmissions. To reduce the signalling overhead on a peer-topeer basis, on-demand routing protocols maintain routes to only those destinations for which traffic exists. Zeyad M. Alfawaer et al., [6] uses Dominant Pruning (DP) [10] as dominating set broadcast distribution mechanism and apply it to AODV, which he use as an example of ondemand routing protocols. He address the process of distributing route requests of an ondemand routing protocol in ways that reduce the overhead incurred by the protocol without incurring a substantial negative impact on the ability of the network to deliver data packets to their destinations. He developed three heuristics to fortify the dominating set process against loss by reintroducing some redundancy using a least-first set cover rather than a greedy set cover. Yu-Doo Kim et al [4] proposed enhanced routing protocol using AODV for MANET for reset a new shortest routing path during sending a packet. Enhanced routing protocol ensures shortest routing path through fixed expire time. So the source packet sends to destination quickly than original AODV routing protocol. If we used enhanced AODV routing protocol for frequent movement state, we can experience improvement of performance. Ian D.Chakeres, Elizabeth M. BeldingRoyer [7] analysed the design possibilities for an AODV implementation. They first identified the unsupported events needed for AODV to perform routing. Then examined the advantages and disadvantages of the strategies for determining this information. This analysis supported our decision to use small kernel modules with a user-space daemon.
Even though many research works are done on AODV protocol still it can be optimized by utilizing the multicast receiving and transmitting capability. In existing design of AODV, the asymmetric links are discarded and route discovery takes place for further transmission of packets where as these asymmetric links can be used as simplex mode of communication. This purport that the link still exists but it may break at any time, so route discovery is initiated when the communication still exists. Thus complete route discovery need not be done. Instead, route repair can be done from the node where the link breakage occurs. Significantly, the routing overhead due to control messages involved in routing discovery and delay inserted due to new route discovery is reduced. Importantly the throughput is increased as the communication does not break between the nodes. IV.MULTICAST AD HOC ON-DEMAND DISTANCE VECTOR (MAODV) ROUTING PROTOCOL The MAODV routing protocol discovers multicast routes on demand using a broadcast route-discovery mechanism. A mobile node originates an RREQ message when it wishes to join a multicast group, or when it has data to send to a multicast group but it does not have a route to that group. Only a member of the desired multicast group may respond to a join RREQ. If the RREQ is not a Join Request, any node with a fresh enough route (based on a group sequence number) to the multicast group may respond. If an intermediate node receives a join RREQ for a multicast group of which it is not a member, or if it receives an RREQ and it does not have a route to that group, it rebroadcasts the RREQ to its neighbours. As the RREQ is broadcast across the network, nodes set up pointers to establish the reverse route in their route tables. A node receiving an RREQ first updates its route table to record the sequence number and the nexthop information for the source node. This reverse route entry may later be used to relay a response back to the source. For join RREQs, an additional entry is added to the multicast route table. This entry is not activated unless the route is selected to be part of the multicast tree.
43
Proceedings of the National Conference on Mobile and Adhoc Networks, 29th & 30th October 2010
If a node receives a join RREQ for a multicast group, it may reply if it is a member of the multicast groups tree and its recorded sequence number for the multicast group is at least as great as that contained in the RREQ. The responding node updates its route and multicast route tables by placing the requesting nodes next-hop information in the tables, and then unicasts an RREP back to the source node. As nodes along the path to the source node receive the RREP, they add both a route table and a multicast route table entry for the node from which they received the RREP, thereby creating the forward path. It stores the upstream node ID (i.e., backward learning) and rebroadcasts the packet.
until the node that originated the RREP (member of the tree) is reached. The activation message ensures that the multicast tree does not have multiple paths to any tree node. Nodes only forward data packets along activated routes in their multicast route tables. The first member of the multicast group becomes the leader for that group. The multicast group leader is responsible for maintaining the multicast group sequence number and broadcasting this number to the multicast group. This is done through a Group Hello message. The Group Hello contains extensions that indicate the multicast groups IP address and the sequence numbers (incremented with every Group Hello) of all multicast groups for which the node is the group leader. Nodes use the Group Hello information to update their request table. Because AODV keeps hard state in its routing table, the protocol has to actively track and react to changes in this tree. If a member terminates its membership with the group, the multicast tree requires pruning. Links in the tree are monitored to detect link breakages. When a link breakage is detected, the node that is further from the multicast group leader (downstream of the break) is responsible for repairing the broken link. If the tree cannot be reconnected, a new leader for the disconnected downstream node is chosen as follows. If the node that initiated the route rebuilding is a multicast group member, it becomes the new multicast group leader. On the other hand, if it was not a group member and has only one next hop for the tree, it prunes itself from the tree by sending its next hop a prune message. This continues until a group member is reached. Once separate partitions reconnect, a node eventually receives a Group Hello for the multicast group that contains group leader information that differs from the information it already has. If this node is a member of the multicast group, and if it is a member of the partition whose group leader has the lower IP address, it can initiate reconnection of the multicast tree. MAODV uses a shared bidirectional multicast tree based on hard state, and any link breakages force actions to repair the tree. A multicast group leader maintains up-to-date
Fig.1 MAODV Path Discovery When the Join Request packet reaches a multicast receiver, the receiver creates or updates the source entry on its member. When a source node broadcasts an RREQ for a multicast group, it often receives more than one reply. The source node keeps the received route with the greatest sequence number and shortest hop count to the nearest member of the multicast tree for a specified period of time and disregards other routes. At the end of this period, it enables the selected next hop in its multicast route table, and unicasts an Activation Message (MACT) to this selected next hop. The next hop, on receiving this message, enables the entry for the source node in its multicast route table. If this node is a member of the multicast tree, it does not propagate the message any further. However, if this node is not a member of the multicast tree, it will have received one or more RREPs from its neighbours. It keeps the best next hop for its route to the multicast group, unicasts a MACT to that next hop, and enables the corresponding entry in its multicast route table. This process continues
44
Proceedings of the National Conference on Mobile and Adhoc Networks, 29th & 30th October 2010
multicast tree information by sending periodic Group Hello messages. Because MAODV unicasts the reply back to the source, if an intermediate node on the path moves away, the reply is lost and the route is lost. In MAODV, a potential multicast receiver must wait for a specified time, allowing for multiple replies to be received before sending an activation message along the multicast route that it selects. V. Devising MAODV for Multimedia Traffic 5.1 Existing AODV Routing Algorithm 1. If source node wants to send a packet Check if route is available If Route available= true { Utilize the route to send the packet} Else Broadcast RREQ(ID, Dest IP, Seq No, Src IP, Seq No, Hop count, Flags) 2. Neighbour nodes receive RREQ request Check RREQ ID with up to that received RREQ packets If RREQ ID match Discard Else If current node is destination Create RREP Set up reverse route to node from where RREQ is received. Destination unicasts RREP to the node that relayed the RREQ (Destination IP & sequence number, Source IP, Lifetime, Hop Count) Else Rebroadcast RREQ with increased hop count 3. Node received RREP message If hop count of RREP < hop count of route table Or destination sequence No. of route table < RREP Seq No. Update route table If node is destination Reunicast RREP (use reverse rout) Increment the hop count 4. If link breakage or host unreachable Broadcast RERR Node received RERR If next hop to unreachable destination is source of RERR Update route table Else if routes to unreachable destinations exists
Broadcast RERR 5.2 Multicast AODV Routing Algorithm 1. If route to multicast not available Join the group Send (RREQ-Join Query) 2. If RREQ != Join Query Reply Update the route table (sequence number, next-hop) Update additional entry to multicast route table Activate entry only if route is part of a tree Else If Received node = Member of multicast group Rebroadcast to neighbors 3. If RREQ = Join Query If (node = member and sequence number > group sequence number) Reply 4. Received reply Update route and multicast table Unicast an RREP to source 5. If multicast receiver receives a join request Create or update source entry While broadcast from source node Update route with max sequence number Update min hop count member for a period of time If time expired Unicast(MACT) Node receives MACT Enable the source node entry If node is a member Break Else Update best route Redo until RREP source is reached 6. If node is first member Node=Head Send Group Hello Update multicast sequence number and broadcast 6. SIMULATION ANALYSIS SETUP AND RESULT
45
Proceedings of the National Conference on Mobile and Adhoc Networks, 29th & 30th October 2010
We have used network simulator ns2 [16] for simulation, most widely used network simulator and freely downloadable. We simulated network for simulation time of 250 sec and area of 700 m * 700 m. Further increase in these values increased the time taken for completing simulation, to a limit which is not feasible due to various constraints. We have used Delay, Throughput and Routing Overload as performance parameters while varying various network parameters such as Pause Time, Mobility and Number of Nodes. Table 4.1 Simulation Environment Number of nodes Simulation area Channel type Radiopropagation model Antenna model Traffic type Interface queue type 10,20,30,40,50 700 x 700 sq.m WirelessChannel Propagation/TwoRayGround
Throughput Vs Nodes
98 97 Throughput 96 95 94 93 92 91 10 20 30 Number of nodes 40 50 MAODV AODV
Fig 3 [Number of nodes Vs Routing Overhead] it can be observed that the routing overhead for MAODV is higher compared to the AODV. Since the route discovery is initiated from the source which increases the routing overhead in MAODV for multicasting. Comparatively in AODV the routing overhead is much lesser, when there is limited resources AODV can be utilised
Even though, simulation is an important tool in the development of mobile ad hoc networks; it provides an excellent environment to experiment and verify routing protocol correctness. However, simulation does not guarantee that the protocol works in practice, because simulators contain assumptions and simplified models that may not actually reflect real network operation. In simulation, the developer controls the whole system, which is in effect only a single component. Fig 2 [Number of nodes Vs Throughput]; the average size of an AODV update packet depends on the number of nodes as the locality increases as network radius increases. In contrast for MAODV the average size of update packets increases with increase in network traffic, however both AODV and MAODV can be expected to have larger update packets with increasing mobility thus from the fig (2) it can be observed that the throughput of MAODV is adequate.
Fig 3. nodes]
Delay vs Nodes
200 180 160 140 120 100 80 60 40 20 0 10 20 30 Number of Nodes 40 50
D e la y
MAODV AODV
46
Proceedings of the National Conference on Mobile and Adhoc Networks, 29th & 30th October 2010
We realize that, in general, the average endto-end delay and the normalized routing load decrease as the node mobility decrease. In particular, low node mobility leads to more stable routes, which generates less overhead packets. As a result, the average end-to-end delay and the normalized routing load are relatively low, whereas the packet delivery ratio is relatively high. On the other hand, high mobility level leads to increase the number of RREQ, RREP and RERR packets. As a result, the end-to-end packet delay and the normalized routing load become relatively high, whereas the packet delivery ratio becomes relatively low which is evident from Fig 4 and Fig 5.
Routing Overhead Vs Delay
100 90 80 70 60 50 40 30 20 10 0 10 20 30 Number of Nodes 40 50
MAODV AODV
Fig 5. [Routing Overhead Vs Delay] 6. CONCLUSION Our paper devises the routing problem in multi-services MANETs, as well as the implementation of an adaptation of MAODV. Services constraints, such as end-to-end delay, packet delivery ratio and normalized routing load, were considered. Simulation results show that MAODV performs well with low mobility and low traffic intensity. However, when considering high traffic intensity, its performance strongly decreases. Future work should be oriented towards the evaluation of MODV in terms of other parameters, such as the jitter. 7. REFERENCES [1]Stephen Walter. Proposal for a Hybrid Implementation of Adhoc On-demand Distance Vectoring (AODV), December, 2008. [2]Babar S. Kawish, Baber Aslam, Shoab A. Khan. Reducing the Overhead Cost in Fixed & Low Mobility AODV Based MANETs, National University of Sciences and Technology, Rawalpindi, Pakistan.
[3]Clifton Lin. AODV Routing Implementation for Scalable Wireless Ad-Hoc Network Simulation (SWANS). [4] Yu-Doo Kim, Young Moon and Sung-Joon Cho. Enhanced AODV Routing Protocol through Fixed Expire-time in MANET, International conference on Network Applications, Protocols and services, 2008. [5] Satoshi Kurosawa, Hidehisa Nakayama, Nei Kato, Abbas Jamalipour, and Yoshiaki Nemoto. Detecting Black hole Attack on AODV-based Mobile Ad Hoc Networks by Dynamic Learning Method, Graduate School of Information Sciences, Tohoku University, 2006. [6] Zeyad M. Alfawaer. Utilization of AODV in Wireless Ad Hoc Networks, Journal of Computer Science 3 (4): 218-222, 2007, ISSN 1549-3636. [7] Ian D. Chakeres, Elizabeth M. BeldingRoyer. AODV Routing Protocol Implementation Design, Dept. of Electrical & Computer Engineering University of California, Santa Barbara. [8] [Perkins99] Charles E. Perkins, Elizabeth M. Royer, Samir R. Das.Ad Hoc Ondemand Distance Vector Routing, October 99 IETF Draft, 33 pages. [9] Elizabeth M. Royer and Chai-Keong Toh. A review of current routing protocols for ad hoc mobile wireless networks. Technical report, University of California and Georgia Institute of Technology, USA, 1999. [10] Amis, A., Prakash, R., Vuong, T. & Huynh, D. 2000, MaxMin D cluster formation in wireless ad hoc networks, in 'IEEE INFOCOM', pp. 32- 41. [11] C. E. Perkins and P. Bhagwat. Highly Dynamic Destination-Sequenced Distance-Vector Routing (DSDV) for Mobile Computers, presented at Proceedings of the SIGCOMM Conference on Communications, Architectures, Protocols and Applications, 1994. [12] S. R Das, C. E Parkins and E. M Royer: Performance Comparison of Two on Demand Routing Protocols for ADHOC Networks, in Proceedings of IEEE INFOCOM 2000, Tel Aviv, Israel, 2630 Mar 2000. [13] David B. Johnson.P: Routing in Ad Hoc Networks of Mobile Hosts, In Proceedings of the IEEE Workshop on Mobile
47
Proceedings of the National Conference on Mobile and Adhoc Networks, 29th & 30th October 2010
Computing Systems and Applications (WMCSA'94), December 1994. [14] C. Perkins, E. Belding-Royer, S. Das. Ad hoc On-Demand Distance Vector (AODV) Routing, Feb. 2003. http://www.ietf.org/internet drafts/draftietfmanet-aodv-13.txt. [15] Rajiv Misra and C.R.Mandal.Performance comparison of AODV/DSR On-demand Routing Protocols for Ad Hoc Networks in Constrained Situation, March 2005 [16]www.topshareware.com/ns2/downloads/1.htm
48