Efficient core selection for multicast routing in mobile ad hoc networks

Efficient Core Selection for Multicast Routing in Mobile Ad Hoc Networks Dai Tho Nguyen1,2, , Thanh Le Dinh2 , and Binh Minh Nguyen2 UMI 209 UMMISCO IRD/UPMC nguyendaitho@vnu.edu.vn University of Engineering and Technology Vietnam National University, Hanoi 144 Xuan Thuy Street, Cau Giay District, Hanoi, Vietnam Abstract PUMA (Protocol for Unified Multicasting through Announcements) is a mesh-based multicast routing protocol for mobile ad hoc networks distinguishing from others in its class by the use of only multicast control packets for mesh establishment and maintenance, allowing it to achieve impressive performances in terms of packet delivery ratios and control overhead However, one of the main drawbacks of the PUMA protocol is that the core of the mesh remains fixed during the whole execution process In this paper, we present an improvement of PUMA by introducing to it an adaptive core selection mechanism The improved protocol produces higher packet delivery ratios and lower delivery time while incurring only little additional control overhead Keywords: Mesh-Based Multicast, Core Selection, Mobile Ad Hoc Networks, Performance Introduction Multicasting is a technique of communication that enables one or more network nodes to send data to many intended destinations simultaneously in an efficient manner by avoiding redundant data delivery The IP-specific version of the general concept of multicasting is called IP multicast Concerns regarding billing, bandwidth management and security have caused the operators of most Internet routers to disable IP multicast Therefore, a world-wide backbone testbed for carrying IP multicast traffic on the Internet, known as MBONE, has been built It allows researchers to deploy and test their experimental multicast protocols and applications In parallel to research activities, multicast communication has been implemented for a large number of applications, including video conferencing, whiteboard, desktop sharing, and content distribution Initially, multicast applications could only be used in intranets or the MBONE multicast network Recently, a number of Internet service providers began to offer support for multicast capabilities in their backbones Corresponding author T.V Do et al (eds.), Advanced Computational Methods for Knowledge Engineering, Advances in Intelligent Systems and Computing 282, DOI: 10.1007/978-3-319-06569-4_31, c Springer International Publishing Switzerland 2014 415 416 D.T Nguyen, T Le Dinh, and B.M Nguyen In the early years, the research and development efforts were concerned with wired networks with the only dynamic effects coming from infrequent occurrence of node or link failures As the emergence of wireless technology has bought a new dimension to the world of network services and applications, the focus of multicast routing has almost shifted to the area of wireless networks Wireless networks provide a convenient way of communicating because they eliminate the barriers of distance, cost, and location Mobile ad hoc networks (MANETs) are one of the kinds of wireless networks that attract the most research attention The nodes in such networks are free to move and organize themselves arbitrarily This inherent characteristic, among others, makes designing communication protocols in MANETs very challenging Multicasting is an important communication primitive in MANETs Many ad hoc network applications, such as searches and rescues, military battlefields, and mobile conferencing typically involve communication between one and many other people There have been a number of multicast routing protocols proposed for MANETs Traditionally, multicast protocols set up trees for the delivery of data packets The use of meshes is a significant departure for multicasting over wireless networks Meshes have a high tolerance towards failures of nodes or links due to interference or mobility Among most representative mesh-based multicast routing protocols, PUMA [10] has been shown to be the most stable and efficient one, compared to others such as MAODV [5] or ADMR [1] 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 type, called multicast announcement, to maintain the mesh in a core-based approach All transmissions are broadcast and no unicast protocol is needed However, the method of core selection in PUMA has a serious drawback: The node with the highest identifier is selected as 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 [7], in this paper we introduce improvements to PUMA in two aspects First, we create a function to determine which nodes should be the core of the multicast group The core node should be able to reach every receiving node as quickly as possible Next, we propose a core migration procedure to cope with the mobility of the mobile ad hoc networks so that the core remains fit to the group Our work has made PUMAs performances approximately 20 percent better in term of delivery time The new implementation suffers from roughly to percent increase in total control overhead, which can be considered as the compensation for its superior delivery time and packet delivery ratio We implement and evaluate our improved PUMA via simulations with ns-2 [13] The rest of this paper is organized as follows Multicast routing in MANETs is reviewed in Section with an in-depth description of PUMA [10] and the core selection procedure in [7] Section describes our improvements to PUMA Efficient Core Selection for Multicast Routing in Mobile Ad Hoc Networks 417 Simulation results are shown in Section Section presents our conclusion and future works Related Work There are two main approaches to multicast routing in MANETs: tree-based and mesh-based In the tree-based approach, either multiple source-trees or a single sharedtree is constructed This approach is bandwidth efficient since only a minimum number of copies per packet are sent along the paths of the tree However, trees can easily break with the failure of a single wireless link due to interference or mobility The reconstruction of the tree will take a certain a mount of time, during which multicasting is not possible Examples of tree-based multicast routing protocols include AMRIS [11], MAODV [5], and TBMk [9] On the other hand, the mesh-based approach may construct numerous paths between a pair of source and destination The structure is thus more resilient to frequent link failures In exchange, there may be multiple redundant copies of a same packet disseminated throughout the mesh Examples of mesh-based multicast routing protocols include ODMRP [12], CAMP [6], PUMA [10], and LSMRM [8] In ODMRP [12], advertising packets are periodically generated by source nodes and then flooded in the network Each receiver uses backward learning to responds to these packets The paths from the receivers to the sources form a mesh ODMRP produces high packet delivery ratio and throughput even under high mobility Its disadvantage is that the control overhead grows fast with large network size CAMP [6] creates a mesh for each multicast group and ensures that the shortest paths from receivers to sources are part of the mesh However, it requires a naming service to obtain multicast group addresses, and assumes the availability of routing information from a unicast routing protocol In LSMRM [8], the mesh is constructed by using route request and route reply packets Link stability is also concerned when building the mesh Paths are found based on selection of nodes that have high stability of link connectivity PUMA [10] uses a receiver-initiated mesh-based approach Each receiver joins a multicast group by using the address of a special core node without having to perform a network-wide flooding of control and data packets from every source of the group Each receiver is connected to the elected core along all of the shortest paths between the receiver and the core All nodes on shortest paths between any receiver and the core form the mesh collectively PUMA uses solely broadcasting with multicast announcement messages for communication among nodes It does not require the use of any unicast protocol to work Each multicast announcement contains a sequence number, the groups address (group ID), the cores address (core ID), the distance to the core, a mesh member flag which is set when the sending node is a member of the mesh and lastly, a parent preferred by the neighbor to reach the core With information retrieved 418 D.T Nguyen, T Le Dinh, and B.M Nguyen from multicast announcements, nodes elect the core for the mesh, select the best routes to reach the core from outside of a multicast group, maintain the mesh, and notify other nodes about the meshs state When a receiver wants to join a multicast group, firstly, it determines whether it has received a multicast announcement for that group or not If the node has, then it uses the core indicated in the message, specify the same core group, and start sending multicast announcement message Otherwise, it considers itself as the core of the group, and start sending multicast announcement indicating itself as the core group and zero distance to core from itself A multicast announcement whose core ID is higher is considered better Nodes broadcast the best multicast announcement they have received from their neighbours If a receiver joins the group before other receivers, then it becomes the group’s core If multiple receivers at the same time join the group then the node with maximal ID becomes the core The core stability is significant for the effectiveness in performance of PUMA Frequent core changes lead to high communication overhead, and would lead to a dramatic rise in the number of packet drops Nodes might detect a partition if they repeatedly fail to receive multicast announcements from the groups core Gupta et al [7] presented an adaptive core selection and migration method for multicast routing in MANETs They introduced the concept of median and centroid of a tree and make use of these to migrate the core Their method ensures that the core is moved hop-by-hop to the multicast group node the nearest to the centroid node However, it might lead to the increase in control overhead and packet loss because the mesh need to be reorganized during the core movement 3.1 Our Proposition Motivation As we mentioned earlier, PUMA [10] has been shown to be stable and efficient However, its core selection method has some disadvantages First, it selects the node with the highest identifier to become the core of the multicast group Second, core changes only happen when the mesh undergoes partition or the old core leaves the mesh Third, the core is migrated hop-by-hop so that noticeable communication overhead is resulted Inspired by the idea of core selection from [7], we propose an improvement to PUMA with an adaptive core selection mechanism 3.2 Protocol Description PUMA [10] uses only one type of control message, multicast announcement, to maintain the mesh A multicast announcement is first originated from the core node and then is sent to its neighbours Every time a node V receives a multicast announcement, it uses this message to update its connectivity list The connectivity list helps each node to discern which is the shortest path to reach the core node Node V then sends its own multicast announcement to its neighbours Efficient Core Selection for Multicast Routing in Mobile Ad Hoc Networks 419 Table Procedure for handling a multicast announcement message at each node Input: N : Number of nodes ma: Multicast announcement message this: This node Begin if this.id = coreId then if this.maxChildW eight > N/2 then bestChild ← this.getBestChild() Send BECOME-CORE(this.id, bestChild) fi fi if ma.type = BECOME-CORE then if ma.destination = this.id then bestChild ← this.getBestChild() if conf irmW ait = bestChild then Send NEW-CORE(this.id) conf irmW ait ← null else if this.weight > N/2 then Send BECOME-CORE(this.id, bestChild) conf irmW ait ← bestChild else if this.isReceiver then Send NEW-CORE(this.id) else Send BECOME-CORE(this.id, ma.source) fi else this.updateW eightT able() fi fi End procedure getBestChild(): Begin for each child c of this if c.weight > CurrentBestChild.weight then CurrentBestChild ← c fi return CurrentBestChild End procedure updateW eightT able(): Input: id, weight Begin for each child c of this if c.id = id then c.weight ← weight fi End 420 D.T Nguyen, T Le Dinh, and B.M Nguyen Fig Example of core migration To reduce the communication overhead when implementing the core migration method, multicast announcements are used to help each node to calculate its weight A weight field is added to each multicast announcement When node V receives a multicast announcement from node U , V first checks if U is one of its children If so, V uses the weight included in the message to update U s weight in V s connectivity list When V wants to send a multicast announcement, it sets the weight of the message to the sum of those of all its children The first step of our core migration process is similar to [7] However, in order to make the core move faster to the new node, improvements are made to the remaining steps as follows Every time node V receives a BECOME-CORE message from node U , V determines whether the centroid is in one of its subtrees If so, it forwards the message to the root node of that sub-tree Otherwise, V determines if it is centroid node If yes, it considers itself as the centroid node and then sends a NEW-CORE message to the network claiming itself to be the core of the group If V is a forwarding node, i.e the centroid is U , then V sends a RESPONSE message back to U Upon receiving RESPONSE from V , U knows that it is the centroid and broadcasts the BECOME-CORE message accordingly This approaches still ensures that the core is moved to the nearest multicast group node However, core change happens only once in order to avoid packet loss and additional communication overhead The pseudo code of our improved PUMA protocol is given in Table An example of the core movement is given in Figure In this example, each node is labelled with its identifier In Figure 1.a, the core node determines that the centroid belongs to the sub-tree rooted at node Therefore it sends a BECOME-CORE message whose destination is node 1, and sets the CONFIRMWAIT for node to true to imply that it has sent a message to node Node receives the message and then repeats the process to send the message to node When node receives the message, it determines that it is suitable to be the core However, node is a forwarding node, so it sends the message back to node When node receives the message, by checking the CONFIRM-WAIT, it knows that the core cannot move any further, so it becomes the core of the group In Figure 1.b, node is the centroid, and at the same time is a receiver, so it becomes the core of the group Efficient Core Selection for Multicast Routing in Mobile Ad Hoc Networks 421 Simulation P2MAN [2] is chosen to test and analyze the performances of the different versions of PUMA P2MAN leverages on the PUMA protocol Its function consists of delivering contents at the application layer Sidney Doria developed both P2MAN and PUMA Both source codes are publicly available [3], [4] We compare the performances of two variants of our improved protocol with the original PUMA protocol In the first variant (PUMA v1), we keep the core migration process as the same as in [7], while the second variant (PUMA v2) corresponds to the final version of our proposed protocol as described in the previous section 4.1 Simulation Settings Simulation settings for evaluation of communications overhead and packet delivery ratio is given in Table and those for evaluation of delivery time is given in Table Table Simulation Settings for Evaluation of Communications Overhead and Packet Delivery Ratio Parameter Value Number of rounds 10 Total nodes 30 Simulation duration 400 time units Simulation area 500m x 500m Node placement Fixed Radio range 250m Pause time 0s Bandwidth Mbps Data packet size 512 bytes MAC Protocol 802.11 DCF The number of senders Varies Traffic load Varies Table Simulation Settings for Evaluation of Delivery Time Parameter Number of rounds Total nodes Simulation duration Simulation area Node placement Radio range Pause time Bandwidth Data packet size MAC Protocol Content size Mobility Value 10 100 600 time units 1000m x 1000m Random 250m 0s Mbps 512 bytes 802.11 DCF Varies Varies 422 4.2 D.T Nguyen, T Le Dinh, and B.M Nguyen Communication Overhead Figure shows the communication overhead with a 30-member multicast group, the traffic load of 10 pkts/s, the velocity of m/s, and a varying number of senders Figure shows the communication overhead with a 25-member multicast group, senders, the velocity of m/s, and a varying traffic load Fig Communication overhead with varying the number of senders Fig Communication overhead with varying traffic load Simulation results show that the communication overhead increases slightly when our improvements are applied The reason is that we integrate the node weight calculation process in multicast announcements Therefore, the control messages contain not only information for maintaining the mesh but also for calculating node weights 4.3 Packet Delivery Ratio Figure shows the packet loss ratio in simulation settings with a 25-member multicast group, the traffic load of 10 pkts/s, the velocity of m/s, and a varying number of senders Figure shows the packet loss ratio with a 25-member multicast group, senders, the velocity of m/s, and a varying traffic load Efficient Core Selection for Multicast Routing in Mobile Ad Hoc Networks 423 Fig Packet loss ratio with varying the number of senders Fig Packet loss ratio with varying traffic load In both series of simulations, PUMA v2 performs better with a lower packet loss ratio PUMA v1 decreases the packet loss ratio a bit, however, it still cannot compensate its control overhead increment Furthermore, as shown in Figure 8, the packet loss ratios of PUMA v1 and PUMA become closer and closer to each other as the number of senders grows 4.4 Delivery Time Figure shows delivery time in simulation settings with sender, 20 receivers, the velocity of 0-1 m/s, and a varying content size With the content sizes of 50 kb and 100 kb, the delivery times are slightly different However, when the content size is larger, the delivery time becomes longer, the difference in delivery times between the three versions of PUMA become more and more vivid, as shown in the figure PUMA v2 outperforms PUMA v1 due to its better core migration method Figure shows the delivery time in simulation settings with sender, the velocity of 0-1 m/s, the content size of 100 KB, and a varying number of receivers Simulation results show that the differences in delivery time between PUMA, 424 D.T Nguyen, T Le Dinh, and B.M Nguyen Fig Delivery time with varying content sizes Fig Delivery time with varying the number of concurrent requesting nodes Fig Delivery time with varying levels of mobility PUMA v1, and PUMA v2 grow larger when the number of receivers increase PUMA v2 and PUMA v1 produce delivery times close to each other Figure shows the delivery time in simulation settings with sender, 20 receivers, the content size of 100 KB, and a varying velocity One significant Efficient Core Selection for Multicast Routing in Mobile Ad Hoc Networks 425 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 nodes, PUMA v2 still proves itself more effective in content distribution throughout the network Conclusion and Future Work In this paper, we have proposed a simple method to improve the PUMA [10] multicast routing protocol The new protocol has a slight increase in total control overhead, but better performances in terms of packet delivery rate and content delivery time The underlying idea is to choose the most appropriate node to become the core of the group, by using a simple yet effective function to calculate the weight of each node, and then move the core the closest possible to the true core node The core is not moved hop by hop, but directly to the new position This latter technique allows to reduce the control overhead yet further improve the packet delivery rate A research perspective to explore is to separate the weight calculation function from multicast announcement messages This might lead to some increase in control overhead However, the core node would be selected faster and the mesh would be better organized in the fastest possible time Acknowledgments This work was partially supported by the VNU Scientist links References Dewan, T.A.: Multicasting in Ad-hoc Networks CSI5140F, University of Ottawa (2005) Doria, S., Spohn, M.A.: A multicast approach for peer-to-peer content distribution in mobile ad hoc networks In: Proc of the IEEE Conference on Wireless Comm and Networking, pp 2920–2925 (2009) Doria, S., Spohn, M.A.: Puma multicast routing protocol source code for ns-2, http://sourceforge.net/projects/puma-adhoc Doria, S., Spohn, M.A.: Peer-to-manet source code for ns-2, http://sourceforge.net/projects/p2man Royer, E.M., Perkins, C.E.: Multicast Ad hoc On-Demand Distance Vector (MAODV) Routing, http://tools.ietf.org/html/draft-ietf-manetmaodv-00.txt Garcia-Luna-Aceves, J.J., Madruga, E.L.: The core-assisted mesh protocol IEEE Journal on Selected Areas in Communications 17(8), 1380–1394 (1999) Gupta, S.K.S., Srimani, P.K.: Adaptive Core Selection and Migration Method for Multicast Routing in Mobile Ad Hoc Networks IEEE Trans on Parallel and Dist Syst 14(1) (2003) 426 D.T Nguyen, T Le Dinh, and B.M Nguyen Rajashekhar, B., Sunilkumar, M., Mylara, R.: Mesh Based Multicast Routing in MANET: Stable Link Based Approach Int Journal of Comp and Elect Eng 2(2), 371–380 (2010) Sangman, M., Sang, J.L., Chansu, Y.: Adaptive multicast on mobile ad hoc networks using tree-based meshes with variable density of redundant paths Wireless Networks 15, 1029–1041 (2009) 10 Vaishampayan, R., Garcia-Luna-Aceves, J.J.: Efficient and robust multicast routing in mobile ad hoc networks In: Proceedings of the IEEE Int Conf on Mobile Ad-Hoc and Sensor Systems, pp 304–313 (2004) 11 Wu, C.W., Tay, Y.C., Toh, C.-K.: Ad hoc Multicast Routing protocol utilizing Increasing id-numberS (AMRIS), http://tools.ietf.org/id/draft-ietfmanet-amris-spec-00.txt 12 Yi, Y., Lee, S.J., Su, W., Gerla, M.: On-Demand Multicast Routing Protocol (ODMRP) for Ad Hoc Networks, http://nrlweb.cs.ucla.edu/publication/ download/693/draft-ietf-manet-odmrp-04.txt 13 The Network Simulator ns-2, http://www.isi.edu/nsnam ... the core node Node V then sends its own multicast announcement to its neighbours Efficient Core Selection for Multicast Routing in Mobile Ad Hoc Networks 419 Table Procedure for handling a multicast. .. mobile ad hoc networks In: Proceedings of the IEEE Int Conf on Mobile Ad- Hoc and Sensor Systems, pp 304–313 (2004) 11 Wu, C.W., Tay, Y.C., Toh, C.-K.: Ad hoc Multicast Routing protocol utilizing Increasing... a varying traffic load Efficient Core Selection for Multicast Routing in Mobile Ad Hoc Networks 423 Fig Packet loss ratio with varying the number of senders Fig Packet loss ratio with varying traffic