Đang tải... (xem toàn văn)
Tài liệu tham khảo công nghệ thông tin Efficient core selection for multicast routing in mobile ad hoc networks
HANOI NATIONAL UNIVERSITY UNIVERSITY OF TECHNOLOGY AND ENGINEERING Binh Minh Nguyen EFFICIENT CORE SELECTION FOR MULTICAST ROUTING IN MOBILE AD HOC NETWORKS GRADUATION THESIS Faculty of Information Technology HA NOI - 2010 -1- HANOI NATIONAL UNIVERSITY UNIVERSITY OF TECHNOLOGY AND ENGINEERING Binh Minh Nguyen EFFICIENT CORE SELECTION FOR MULTICAST ROUTING IN MOBILE AD HOC NETWORKS GRADUATION THESIS Faculty of Information Technology Supervisor: Dr Dai Tho Nguyen HA NOI - 2010 -2- ABSTRACT There are many multicast routing protocols that use the notion of group-shared trees, for example: Protocol Independent Multicast (PIM), Core-Based Tree As constructing of a minimal-cost spanning tree to all members of the network is nearly impossible due to its excessive cost in terms of convergence time and network overhead, the core-based approach is chosen as a heuristic method to cope with multicast routing The core node, which is also referred as center node or rendezvous point, is chosen from a selective group by different algorithm However, most of protocols for core election in static networks are not suitable for mobile ad hoc network, since these algorithms require the knowledge of the whole network, the total number of nodes participating, the network topology, link state, Which are not available or too expensive to acquire in mobile ad hoc networks There are many proposed protocol for multicast routing in mobile ad hoc networks, such as PUMA, ODMRP or MAODV In those protocols, PUMA (Protocol for unified multicasting through announcements) has shown to outperform others PUMA uses a single multicast announcement to establish and maintain the mesh However, there is still a serious drawback, PUMA elects core by selecting the node with the highest ID and the core remains fixed afterwards In this thesis, we present an improvement of PUMA by integrating an adaptive core selection mechanism into it The result show that the new PUMA achieves higher packet delivery ratios, lower delivery times than the old one, while incurring only a little control overhead increment -3- ACKNOWLEDGMENT This thesis would not have been possible without the support of many people Firstly, I am heartily thankful to my supervisor, Dr Dai Tho Nguyen, whose encouragement, guidance and support from the initial to the final step enabled me to develop a throughout understanding of the subject I also would like to convey my thanks to the University of Technology and Engineering Hanoi National University for providing me the knowledge and experience in these four years Lastly, I offer my regards and gratitude to all of those who supported me in any respect during my studies Binh Minh Nguyen Hanoi, May 2010 -4- TABLE OF CONTENT Binh Minh Nguyen HA NOI - 2010 HA NOI - 2010 Binh Minh Nguyen HA NOI - 2010 -5- TABLE OF FIGURES Figure 1: Multicast .5 Figure 2: Multicast group Figure 3: Connectivity List 20 Figure 4: Mesh Creation 23 Figure 5: Multicast tree .33 Figure 6: Core Migration 41 Figure 7: Control overhead x Senders .46 Figure 8: Control overhead x Traffic Load .47 Figure 9: Packet loss ratio x Senders 48 Figure 10: Packet loss ratio x Traffic Load .48 Figure 11: Delivery time x Content Size 49 Figure 12: Delivery time x Number of concurrent requesting nodes .50 Figure 13: Delivery time x Mobility .51 -6- TABLE OF ABBREVIATIONS ADMR BGP CBT DM DVMRP ICMP IGMP IOS IP LAN LSA MANET MAODV MOSPF MRT NS ODMRP OSPF OTcl P2MAN PIM PUMA RFC RPF SM SPF SPT TTL Adaptive Demand-driven Multicast Routing Border Gateway Protocol Core-based Tree Dense Mode Distance Vector Multicast Routing Protocol Internet Control Message Protocol Internet Grouping Management Protocol Internetwork Operating System Internet Protocol Local Area Network Link-State Advertisement Mobile Ad Hoc Networks Multicast Ad hoc On Demand Distance Vector Multicast Open Shortest Path First Maximum Response Time Network Simulator On Demand Multicast Routing Protocol Open Shortest Path First Object-oriented Tool Command Language Peer-to-MANET Protocol Independent Multicast Protocol for unified multicasting through announcement Requests for Comments Reverse Path Forwarding Sparse Mode Shortest Path First Shortest Path Tree Time to Live -7- CHAPTER 1: INTRODUCTION 1.1 Overview Multipoint communications have been existed for quite a long time According to researches, the idea of one or more nodes sending data packet to many receivers simultaneously has been available since at least the early of 1980 The term multicasting only became widely known after Deering established the first internet request-forcomments on the field (aka RFC) [4] After being proposed by Deering as the model to be followed by groups of users or computers to communicate among themselves simultaneously, IP Multicasting has been developed Since then, a world-wide multicast backbone testbed also known as MBONE has been constructed to test many protocols and applications Multicast communication has been implemented for a large number of applications Some of these applications are video-conferencing, whiteboard, group communication tools, and software and information distribution Initially, almost all of these applications were being used in intranets or in MBONE, and now, there are some Internet service providers providing supports for these multicast applications in their backbone 1.2 Problem’s description However, most of the research and development being done so far only consider physically connected networks, where devices are connected together by the use of cables and wires Due to the wired connections among them, the locations of nodes are fixed and the only dynamic aspect in the networks is node and link failures Wireless networks are a very attractive and promising way of computing due to computer and infrastructure devices and computers are not cabled together These networks constitute an environment where everyone is free to move beyond the scope of his place He can take his devices such as computer, cell phone to anywhere and still be able to communicate, exchange information with his colleagues The core of the thesis’s approach and contribution is multicasting over wireless network, which consists of enabling the propagation of multicast data packets over connected meshes Multicasting over meshes is a significant departure for multicasting over mobile ad hoc network Meshes have a high tolerance toward faults of node or link failures Moreover, the algorithm used to build meshes is rather simpler and easy to deploy Among most representative multicast routing protocols, PUMA [5] has shown to be the most stable and efficient protocol due to its performance compare with other protocols such as MAODV or ADMR [10] … The most noticeable aspect of PUMA is that it uses a very simple and effective method to establish and maintain the mesh, this results in a low control overhead PUMA uses a single control message, a multicast announcement to be precise, to maintain the mesh All transmissions are broadcast and no unicast protocol is needed PUMA uses a core-based approach to build the mesh However, the method of selecting core in PUMA has a serious drawback: PUMA selects the node with the highest core id to become the core of the multicast group Furthermore, core changes only happen when the mesh undergoes partition or the old core leaves the mesh In this thesis, we will concentrate on improving PUMA in two aspects: Firstly, create a function to determine which nodes should be the core node of the multicast group The core node should be able to reach every receiving node as quickly as possible Secondly, due to the mobility of the mobile ad hoc networks, the core node could malfunction unexpectedly and no longer fit to be the core of the group As a result, a core change to cope with these exceptions should be implemented Inspired by the idea of core selection from [9], we propose an improvement of PUMA with an adaptive core selection mechanism our own algorithm Our work has made PUMA perform approximately twenty percent better in term of delivery time than the old one The new implementation suffers from roughly two to five percent increase in total control overhead, which we consider can be compensated by its superior delivery time and packet delivery ratio As an addition contribution, we also implement the algorithm for core selection, which is described in [9] to compare with our algorithm Still, our implementation has shown to have lower control overhead, better packet delivery ratio, and better delivery time 1.3 Disposition The rest of this thesis is organized as follows: Multicast is presented in chapter 2, and in chapter 3, an in-depth description of PUMA is presented Chapter describes the -2- CHAPTER 5: OUR PROPOSITION AND RESULTS 5.1 Motivation As we mention earlier, PUMA has shown to be the most stable and efficient protocol However, the method of selecting core in PUMA has a serious drawback: PUMA selects the node with the highest core id to become the core of the multicast group Furthermore, core changes only happen when the mesh undergoes partition or the old core leaves the mesh Inspired by the idea of core selection from [9], we propose an improvement of PUMA with an adaptive core selection mechanism our own algorithm The core selection method, which we have described in chapter 4, has a drawback The core move hop by hop, then announces that it is the new core and then repeats the process This process ensures the core is moved to the closest possible node to the centroid However, if we implement it on PUMA, this kind of approach will lead to noticeable control overhead’s increment 5.2 Protocol description PUMA uses a single control message to maintain the mesh, which is called the MULTICAST ANNOUNCEMENT This control message is first originated from the core node and then is sent to the core’s neighbors Every time a node v receives a MULTICAST ANNOUCEMENT, v uses the message’s information to update its connectivity list The connectivity list helps v to discern which the shortest way to reach the core node is V then sends its own MULTICAST ANNOUNCEMENT to its neighbors To reduce the control overhead when implement the core migration method We decide to make use of the MULTICAST ANNOUNCEMENT to help each node calculate its weight First, we add a weight field to the MULTICAST ANNOUNCEMENT message When v receives the message from u, v first checks if u is one of its child member If yes, v uses the weight field to update u’s weight in v’s connectivity list When v wants to send a MULTICAST ANNOUNCEMENT message, it set the weight field in its message equal to the sum of all of its child weight About the core migration process, the first step is similar to what we have described in 4.6 However, we want the core to be moved directly to the new core, not hop by hop - 40 - Therefore, our method is as follows Every time a node v receives a Become_core() message from node u: Node v determines whether a centroid is in one of any of its sub-tree, if so, it forwards the message to Become_Core the root node of that sub-tree Otherwise, node v determines if a node is centroid If yes, then it considers itself to be the centroid node and send NewCore() message to the network, claim itself to be the core of the group If v is a forwarding node, then it means the centroid is u v then sends a Response() message back to u Upon receiving Response() from v, u knows that it is the centroid and broad cast Become_core message accordingly This approaches still ensures that the core is move to the nearest multicast group node However, core change happens only once in order to avoid packet loss and control overhead increment Example: Figure 6: Core Migration In Fig 6.a, the core node (node 0) determines that subtree rooted at has a node which deserves to be the core of the group Therefore it send a multicast_annoucement( type = become_core, dest = 1) and set the confirm_wait to to imply that it has sent a message to 1 receives the message and repeats the process and send a multicast announcement to When receives the message, it then determines that’s it fits to be the core, however, is a forwarding node, so it send a - 41 - multicast_announcement(type = become_core, dest = 1) back to When receive the message, by checking the confirm_wait, it knows the core node cannot move any further, so it becomes the core of the group In Fig 6.b, the new core node is node 8, and is a receiver, so it simple becomes the core of the group 5.3 Pseudo code Handle Multicast announcement procedure at node “this” Input: N - Numbers of nodes Ma – Multicast announcement Begin If this.id = core_id { If this.maxChildWeight > N/2 { bestChild = this.get_best_children(); Send a BecomeCore(this.id, bestChild); } } If (ma.type == BECOME_CORE){ If ma.destination == this.id{ bestChild = this.get_best_children(); If (confirm_wait == bestChild) {Send a NewCore(this.id); confirm_wait = null;} Else if this.weight > N/2{ Send a BecomeCore(this.id, bestChild); Confirm_wait = bestChild; } Else if (this.is_receiver){ Send a NewCore(this.id); } Else {Send a BecomeCore(this.id, ma.source);} } Else { Update_weight_table(); } } End Get_best_child procedure: Begin - 42 - For every child c of this{ If c.weight > CurrentBestChild.weight { CurrentBestChild = c;} } Return CurrentBestChild; End Update_weight_table() procedure: Input: id, _weight Begin For every child c of this{ If c == id{ c.weight = _weight; } } End - 43 - 5.4 Network Simulator (NS2) NS (Network simulator) [2] is a network simulation software which controls separate event object-oriented, and was developed at UC Berkeley, NS2 [12] was written in C++ and OTcl NS is useful for simulating wide area network (WAN) and local network (LAN) The four prominent benefit of NS-2 are as follow: • Ability to check the stability of the existing network protocols • Ability to evaluate new network protocols in use before • Ability to execute large network model that is almost impossible to implement in practice • Ability to simulate a variety of different network NS-2 (Network Simulator version 2.xx) is a open source, free, network emulator NS-2 is used widely used in universities (which study computer network and communication) NS-2 is extremely effective in simulation, which serve studying the network protocols, from the MAC layer to the Transport layer Using NS-2, anyone can simulate a Wired networks, Wireless Networks, Mobile ad hoc networks - MANETs, combined networks, etc The events occur in the network and simulation parameters are usually written in the "trace files” or a text file To get the desired results, we need to process these files and simulate the results, usually in the form of graphs A short overview of NS-3: NS-3 is a new open source software which is developed recently, version 3.1 was released in June 2008, the latest version is 3.6 released in October 10/2009 NS-3 is independent software, and is not compatible with NS-2 NS-3 offers features superior network simulator NS-2, for example: IPv6 extension, wifi improvements, new test framework 5.5 Peer-to-Peer content distribution in MANETs P2MAN [8] is chosen to test and analysis the delivery time of the edited PUMA versions A short description, P2MAN leverages on the PUMA protocol, its function is to deliver content at application layer Sidney Doria developed both P2MAN and PUMA Both program’s source code are publicly available [7] [8] 5.6 Experimental result and analysis 5.6.1 Simulation environment - 44 - Control overhead, packet delivery ratio Simulator Delivery time NS2 Number of rounds 10 Total nodes 30 Simulation Time 400 seconds Simulation Area 500m x 500m Node placement Fixed Radio range 250m Simulator Pause time 0s Number of rounds 10 Bandwidth Mbps Data packet size 512 bytes MAC Protocol 802.11 DCF NS2 Total nodes 100 Simulation Time 600 seconds Simulation Area 1000m x 1000m Node placement Random Radio range 250m Pause time 0s Bandwidth Mbps Data packet size 512 bytes MAC Protocol 802.11 DCF 5.6.2 Control overhead Figure 6: Senders varied across {5, 20, 30}, members = 30, mobility = m/s, Traffic Load = 10 pkts/s, Multicast groups = Figure 7: Senders = 5, members = 25, mobility = m/s, Traffic Load varied across {2, 5, 10, 20} pkts/s, Multicast groups = - 45 - Figure 7: Control overhead x Senders - 46 - Figure 8: Control overhead x Traffic Load As we can see, the total control overhead does increases, but only a very slight amount The reason is that we integrate the calculating node weight process into the Multicast_announcement message Therefore, the control message for maintaining the mesh and for calculating node weight is in the same control message, which results in a slight increase in control overhead 5.6.3 Packet delivery ratio Figure 8: Senders varied across {5, 10, 15, 20}, member = 25, mobility = m/s, Traffic Load = 10 pkts/s, Multicast groups = Figure 9: Senders = 5, members = 25, mobility = m/s, Traffic Load varied across {5, 10, 20, 40} pkts/s, Multicast groups = - 47 - Figure 9: Packet loss ratio x Senders Figure 10: Packet loss ratio x Traffic Load - 48 - In both graph, PUMA v2 show to be a better protocol by its lower packet loss ratio PUMA v1 does decrease packet loss ratio a bit, however, it still cannot compensate to its control overhead increment Furthermore, as shown in figure 8, the packet loss ratio of PUMA v1 and PUMA come closer and closer to each other as the senders grows 5.6.4 Delivery time Senders = 1, receivers = 20, mobility = 0-1 m/s, Content size varied across {50, 100, 200, 400} KB Figure 11: Delivery time x Content Size At first, with the content size are 50kb and 100kb, the result show only a slight different However, when the content size became larger, resulting longer delivery time, the mesh itself finds the best core in the whole process As a result, the difference in delivery time between these three versions of PUMA became more and more vividly, as shown in the figure PUMA v2 outperforms PUMA v1 due to its better core migrating method Senders = 1, receivers varied across {5, 10, 15, 20} mobility = 0-1 m/s, - 49 - content size = 100 KB Figure 12: Delivery time x Number of concurrent requesting nodes Similar to the previous graph, as the network operate, the mesh become more and more stable overtime As a result, the differences in delivery time between PUMA and PUMA v1, PUMA v2 grow larger PUMA v2 and PUMA v1 perform closely to each other in this scenario - 50 - Senders = 1, receivers = 20, mobility varied across {0, 2, 5, 10, 30} m/s, Content size = 100 KB Figure 13: Delivery time x Mobility One significant feature of P2MAN is that the delivery time does not depend on the mobility of the network To put it simpler, no matter how fast each node move, it does not affect the content delivery time We have run tests to compare the average delivery time between three versions of PUMA As illustrated, even though delivery time does not depend on the mobility of each node, PUMA v2 still prove itself more effective in delivery content throughout the network - 51 - CHAPTER 6: CONCLUSION In this thesis we have present a particular method to improve the PUMA multicast routing protocol, which result in a slightly increase of total control overhead, but a good improvement in the packet delivery ratio and content delivery time The primitive ideas are to choose the most appropriate node to become the core of the node, by using a simple yet effective function to calculate the weight of each node, and then move the core the closest possible true core node Core is not move hop by hop, but directly to the new core This idea minimizes the control overhead yet results better packet delivery ratio than the former one Based on extensive experimental simulation, our improved version of PUMA routing protocol has shown to provide good performance results We intend to separate multicast announcement with weight request function in PUMA, which might lead to unpredictable increase in control overhead However, the core node would be selected faster and the mesh is well organized in the fastest possible time Another direction we want to focus on is to improve the weight calculating method by implementing a link delay function In this thesis, the weight of each node only considers whether it is a mesh member or a forwarding node, but does not consider the delay characteristics - 52 - REFERENCE [1] C Perkins and P Bhagwat, “Routing Over Multihop Wireless Network of Mobile Computers,” Mobile Computing, T Imielinski and H.F Korth, eds., pp 182-205, Kluwer Academic Publisher, 1996 [2] Eitan Altman and Tania Jimenez, “NS Simulator for beginners”, Univ de Los Andes, Merida, Venezuela and ESSI, Sophia-Antipolis, France, 2003 [3] E.L Madruga, “Multicasting in Ad-hoc Networks”, University of California, 2002 [4] F.K James and W.R Keith, “Computer networking: A Top-down Approach Featuring the Internet”, 2000 [5] R Vaishampayan and J J Garcia-Luna-Aceves, "Efficient and robust multicast routing in mobile ad hoc networks", IEEE International Conference on Mobile Ad-hoc and Sensor Systems, pp 304-313, 2004 [6] S Doria and M A Spohn, "Puma multicast routing protocol source code for ns-2," http://sourceforge.net/projects/puma-ad hoc [7] S Doria and M A Spohn, "Peer-to-manet source code for ns-2," http://sourceforge.net/ projects/p2man [8] S Doria and M A Spohn , “A multicast approach for peer-to-peer content distribution in mobile ad hoc networks”, IEEE conference on Wireless Communications & Networking, pp 2920-2925, 2009 [9] S.K.S Gupta and P.K Srimani, “Adaptive Core Selection and Migration Method for Multicast Routing in Mobile Ad Hoc Networks”, IEEE transactions on parallel and distributed systems, vol 14, no 1, January 2003 [10] T.A Dewan, “Multicasting in Ad-hoc Networks”, University of Ottawa, 2005 [11] T Ballardie, P Francis, and J Crowcroft, “Core Based Trees (CBT): An Architecture for Scalable Inter Domain Multicast Routing,” Proc ACM SIGCOMM, pp 85-95, 1993 [12] "The network simulator," http://www.isi.edu/nsnam/ns/ - 53 - ... UNIVERSITY OF TECHNOLOGY AND ENGINEERING Binh Minh Nguyen EFFICIENT CORE SELECTION FOR MULTICAST ROUTING IN MOBILE AD HOC NETWORKS GRADUATION THESIS Faculty of Information Technology Supervisor:... all nodes in the multicast group Routing protocols designed for mobile ad hoc networks maintain only approximate and minimal topology information, and therefore designing a center selection heuristics... participating, the network topology, link state, Which are not available or too expensive to acquire in mobile ad hoc networks There are many proposed protocol for multicast routing in mobile ad hoc networks,