Efficient core selection for multicast routing in mobile ad hoc networks

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 on

in Mobile Ad Hoc Networks

Dai Tho Nguyen1,2,, Thanh Le Dinh2, and Binh Minh Nguyen2

1 UMI 209 UMMISCO IRD/UPMC nguyendaitho@vnu.edu.vn

2 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 deliv-ery 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

Net-works, Performance

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 gen-eral concept of multicasting is called IP multicast Concerns regarding billing, bandwidth management and security have caused the operators of most Inter-net 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 imple-mented for a large number of applications, including video conferencing, white-board, 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 capa-bilities in their backbones

 Corresponding author.

T.V Do et al (eds.), Advanced Computational Methods for Knowledge Engineering, 415 Advances in Intelligent Systems and Computing 282,

DOI: 10.1007/978-3-319-06569-4 _31, c Springer International Publishing Switzerland 2014

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 inter-ference 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 as-pect 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 2 to 5 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 2 with an in-depth description of PUMA [10] and the core selection procedure in [7] Section 3 describes our improvements to PUMA

Simulation results are shown in Section 4 Section 5 presents our conclusion and future works

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 shared-tree 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, dur-ing which multicastdur-ing is not possible Examples of tree-based multicast routdur-ing 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 short-est 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 com-munication among nodes It does not require the use of any unicast protocol to work Each multicast announcement contains a sequence number, the groups ad-dress (group ID), the cores adad-dress (core ID), the distance to the core, a mesh mem-ber flag which is set when the sending node is a memmem-ber of the mesh and lastly,

a parent preferred by the neighbor to reach the core With information retrieved

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 mul-ticast group, firstly, it determines whether it has received a mulmul-ticast announce-ment 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

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 communica-tion overhead is resulted Inspired by the idea of core seleccommunica-tion 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 nodeV 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 NodeV then sends its own multicast announcement to its

neighbours

Table 1 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

Fig 1 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 nodeV

receives a multicast announcement from nodeU, V first checks if U is one of its

children If so,V uses the weight included in the message to update Us weight

inV 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 nodeV receives a BECOME-CORE

message from node U, V determines whether the centroid is in one of its

sub-trees 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 IfV is a forwarding node, i.e the centroid is U, then V sends a

RESPONSE message back toU 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 1

An example of the core movement is given in Figure 1 In this example, each node is labelled with its identifier In Figure 1.a, the core node 0 determines that the centroid belongs to the sub-tree rooted at node 1 Therefore it sends a BECOME-CORE message whose destination is node 1, and sets the CONFIRM-WAIT for node 1 to true to imply that it has sent a message to node 1 Node 1 receives the message and then repeats the process to send the message to node

6 When node 6 receives the message, it determines that it is suitable to be the core However, node 6 is a forwarding node, so it sends the message back to node 1 When node 1 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 8 is the centroid, and at the same time is a receiver,

so it becomes the core of the group

4 Simulation

P2MAN [2] is chosen to test and analyze the performances of the different ver-sions 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 migra-tion 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 de-livery ratio is given in Table 2 and those for evaluation of dede-livery time is given

in Table 3

Table 2 Simulation Settings for Evaluation of Communications Overhead and Packet

Delivery Ratio

Number of rounds 10

Simulation duration 400 time units Simulation area 500m x 500m Node placement Fixed

Data packet size 512 bytes MAC Protocol 802.11 DCF The number of senders Varies

Table 3 Simulation Settings for Evaluation of Delivery Time

Number of rounds 10 Total nodes 100 Simulation duration 600 time units Simulation area 1000m x 1000m Node placement Random

Data packet size 512 bytes MAC Protocol 802.11 DCF Content size Varies

4.2 Communication Overhead

Figure 2 shows the communication overhead with a 30-member multicast group, the traffic load of 10 pkts/s, the velocity of 0 m/s, and a varying number of senders Figure 3 shows the communication overhead with a 25-member multi-cast group, 5 senders, the velocity of 0 m/s, and a varying traffic load

Fig 2 Communication overhead with varying the number of senders

Fig 3 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 4 shows the packet loss ratio in simulation settings with a 25-member multicast group, the traffic load of 10 pkts/s, the velocity of 0 m/s, and a vary-ing number of senders Figure 5 shows the packet loss ratio with a 25-member multicast group, 5 senders, the velocity of 0 m/s, and a varying traffic load

Fig 4 Packet loss ratio with varying the number of senders

Fig 5 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

Figure 6 shows delivery time in simulation settings with 1 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 7 shows the delivery time in simulation settings with 1 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,

Fig 6 Delivery time with varying content sizes

Fig 7 Delivery time with varying the number of concurrent requesting nodes

Fig 8 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 8 shows the delivery time in simulation settings with 1 sender, 20 receivers, the content size of 100 KB, and a varying velocity One significant