544 IEEE TRANSACTIONS ON MOBILE COMPUTING, VOL. 10, NO....

Supporting Efficient and Scalable Multicastingover Mobile Ad Hoc Networks

X. Xiang, Member, IEEE, X. Wang, Member, IEEE, and Y. Yang, Fellow, IEEE

Abstract—Group communications are important in Mobile Ad hoc Networks (MANETs). Multicast is an efficient method for

implementing group communications. However, it is challenging to implement efficient and scalable multicast in MANET due to the

difficulty in group membership management and multicast packet forwarding over a dynamic topology. We propose a novel Efficient

Geographic Multicast Protocol (EGMP). EGMP uses a virtual-zone-based structure to implement scalable and efficient group

membership management. A networkwide zone-based bidirectional tree is constructed to achieve more efficient membership

management and multicast delivery. The position information is used to guide the zone structure building, multicast tree construction,

and multicast packet forwarding, which efficiently reduces the overhead for route searching and tree structure maintenance. Several

strategies have been proposed to further improve the efficiency of the protocol, for example, introducing the concept of zone depth for

building an optimal tree structure and integrating the location search of group members with the hierarchical group membership

management. Finally, we design a scheme to handle empty zone problem faced by most routing protocols using a zone structure. The

scalability and the efficiency of EGMP are evaluated through simulations and quantitative analysis. Our simulation results demonstrate

that EGMP has high packet delivery ratio, and low control overhead and multicast group joining delay under all test scenarios, and is

scalable to both group size and network size. Compared to Scalable Position-Based Multicast (SPBM) [20], EGMP has significantly

lower control overhead, data transmission overhead, and multicast group joining delay.

Index Terms—Routing, wireless networks, mobile ad hoc networks, multicast, protocol.

Ç

1 INTRODUCTION

THERE are increasing interests and importance in support-ing group communications over Mobile Ad Hoc Net-

works (MANETs). Example applications include theexchange of messages among a group of soldiers in abattlefield, communications among the firemen in a disasterarea, and the support of multimedia games and teleconfer-ences. With a one-to-many or many-to-many transmissionpattern, multicast is an efficient method to realize groupcommunications. However, there is a big challenge inenabling efficient multicasting over a MANET whosetopology may change constantly.

Conventional MANET multicast protocols [3], [4], [5], [6],[7], [8], [28] can be ascribed into two main categories, tree-based and mesh-based. However, due to the constantmovement as well as frequent network joining and leavingfrom individual nodes, it is very difficult to maintain thetree structure using these conventional tree-based protocols(e.g., MAODV [3], AMRIS [4], MZRP [5], and MZR [28]).The mesh-based protocols (e.g., FGMP [6], Core-AssistedMesh protocol [7], and ODMRP [8]) are proposed toenhance the robustness with the use of redundant pathsbetween the source and the destination pairs. Conventionalmulticast protocols generally do not have good scalabilitydue to the overhead incurred for route searching, group

membership management, and creation and maintenance ofthe tree/mesh structure over the dynamic MANET.

For MANET unicast routing, geographic routing proto-cols [11], [12], [13], [14] have been proposed in recent yearsfor more scalable and robust packet transmissions. Theexisting geographic routing protocols generally assumemobile nodes are aware of their own positions throughcertain positioning system (e.g., GPS), and a source canobtain the destination position through some type of locationservice [15] [16]. In [13], an intermediate node makes itsforwarding decisions based on the destination positioninserted in the packet header by the source and the positionsof its one-hop neighbors learned from the periodic beaconingof the neighbors. By default, the packets are greedilyforwarded to the neighbor that allows for the greatestgeographic progress to the destination. When no such aneighbor exists, perimeter forwarding is used to recoverfrom the local void, where a packet traverses the face of theplanarized local topology subgraph by applying the right-hand rule until the greedy forwarding can be resumed.

Similarly, to reduce the topology maintenance overheadand support more reliable multicasting, an option is to makeuse of the position information to guide multicast routing.However, there are many challenges in implementing anefficient and scalable geographic multicast scheme inMANET. For example, in unicast geographic routing,the destination position is carried in the packet header toguide the packet forwarding, while in multicast routing, thedestination is a group of members. A straightforward way toextend the geography-based transmission from unicast tomulticast is to put the addresses and positions of all themembers into the packet header, however, the headeroverhead will increase significantly as the group sizeincreases, which constrains the application of geographic

544 IEEE TRANSACTIONS ON MOBILE COMPUTING, VOL. 10, NO. 5, APRIL 2011

. X. Xiang is with Microsoft Corporation, Redmond, Washington 98052.E-mail: [email protected].

. X. Wang and Y. Yang are with the Department of Electrical and ComputerEngineering, Stony Brook University, Stony Brook, New York 11794.E-mail: {xwang, yang}@ece.sunysb.edu.

Manuscript received 20 Nov. 2009; revised 3 Mar. 2010; accepted 31 Mar.2010; published online 7 Sept. 2010.For information on obtaining reprints of this article, please send e-mail to:[email protected], and reference IEEECS Log Number TMC-2009-11-0508.Digital Object Identifier no. 10.1109/TMC.2010.176.

1536-1233/11/$26.00 � 2011 IEEE Published by the IEEE CS, CASS, ComSoc, IES, & SPS

multicasting only to a small group [17], [18], [19]. Besidesrequiring efficient packet forwarding, a scalable geographicmulticast protocol also needs to efficiently manage themembership of a possibly large group, obtain the positionsof the members and build routing paths to reach the membersdistributed in a possibly large network terrain. The existingsmall-group-based geographic multicast protocols [17], [18],[19] normally address only part of these problems.

In this work, we propose an efficient geographic multi-cast protocol, EGMP, which can scale to a large group sizeand large network size. The protocol is designed to becomprehensive and self-contained, yet simple and efficientfor more reliable operation. Instead of addressing only aspecific part of the problem, it includes a zone-based schemeto efficiently handle the group membership management,and takes advantage of the membership managementstructure to efficiently track the locations of all the groupmembers without resorting to an external location server.The zone structure is formed virtually and the zone where anode is located can be calculated based on the position of thenode and a reference origin. In topology-based clusterconstruction, a cluster is normally formed around a clusterleader with nodes one hop or k-hop away, and the clusterwill constantly change as network topology changes. Incontrast, there is no need to involve a big overhead to createand maintain the geographic zones proposed in this work,which is critical to support more efficient and reliablecommunications over a dynamic MANET. By making use ofthe location information, EGMP could quickly and effi-ciently build packet distribution paths, and reliably main-tain the forwarding paths in the presence of networkdynamics due to unstable wireless channels or frequentnode movements.

In summary, our contributions in this work include:

1. Making use of the position information to design ascalable virtual-zone-based scheme for efficientmembership management, which allows a node tojoin and leave a group quickly. Geographic unicast isenhanced to handle the routing failure due to the useof estimated destination position with reference to azone and applied for sending control and datapackets between two entities so that transmissionsare more robust in the dynamic environment.

2. Supporting efficient location search of the multicastgroup members, by combining the location servicewith the membership management to avoid the needand overhead of using a separate location server.

3. Introducing an important concept zone depth, whichis efficient in guiding the tree branch building andtree structure maintenance, especially in the pre-sence of node mobility. With nodes self-organizinginto zones, zone-based bidirectional-tree-based dis-tribution paths can be built quickly for efficientmulticast packet forwarding.

4. Addressing the empty zone problem, which is criticalin a zone-based protocol, through the adaption oftree structure.

5. Evaluating the performance of the protocol throughquantitative analysis and extensive simulations. Ouranalysis results indicate that the cost of the protocoldefined as the per node control overhead remainsconstant regardless of the network size and the

group size. Our simulation studies confirm thescalability and efficiency of the proposed protocol.

We organize the rest of this paper as follows: In Section 2,we discuss some related work. We present a detailed designof the EGMP protocol in Section 3, and quantitativelyanalyze the per node cost of EGMP in Section 4. Finally, wegive our simulation results in Section 5 and conclude thepaper in Section 6.

2 RELATED WORK

In this section, we first summarize the basic proceduresassumed in conventional multicast protocols, and thenintroduce a few geographic multicast algorithms proposedin the literature.

Conventional topology-based multicast protocols includetree-based protocols (e.g., [3], [4], [5], [28]) and mesh-basedprotocols (e.g., [6], [8]). Tree-based protocols construct a treestructure for more efficient forwarding of packets to all thegroup members. Mesh-based protocols expand a multicasttree with additional paths which can be used to forwardpackets when some of the links break. Although efforts weremade to develop more scalable topology-aware protocols[7], the topology-based multicast protocols are generallydifficult to scale to a large network size, as the constructionand maintenance of the conventional tree or mesh structureinvolve high control overhead over a dynamic network. Thework in [26], [27] attempts to improve the stateless multicastprotocol [2], which allows it a better scalability to group size.In contrast, EGMP uses a location-aware approach for morereliable membership management and packet transmis-sions, and supports scalability for both group size andnetwork size. As the focus of our paper is to improve thescalability of location-based multicast, a comparison withtopology-based protocols is out of the scope of this work.However, we note that at the similar mobility and systemsetup, the delivery ratio of [26] is much lower than that ofEGMP, and the delivery ratio in [27] varies significantly asthe group size changes. In addition, topology-based routingby nature is more vulnerable to mobility and long pathtransmission, which prevents topology-based protocolsfrom scaling to a large network size.

Besides the need of managing group membership as wellas constructing and maintaining a multicast structure, ageographic multicast protocol also requires a locationservice [15], [16] to obtain the positions of the members.The geographic multicast protocols presented in [17], [18],and [19] need to put the information of the entire tree or allthe destinations into packet headers, which would create abig header overhead when the group size is large andconstrain these protocols to be used only for small groups. InDSM [17], each node floods its location in the network. Asource constructs a Steiner tree and encodes the multicasttree into each packet, and delivers the packet by using sourcerouting. LGT [18] requires each group member to know thelocations of all other group members, and proposes twooverlay multicast trees: a bandwidth-minimizing LGS treeand a delay-minimizing LGK tree. In PBM [19], a multicastsource node finds a set of neighboring, next hop nodes andassigns each packet destination to one next hop node. Thenext hop nodes, in turn, repeat the process. Thus, no globaldistribution structure is necessary. GMP in [29] attempts tobuild a more efficient multicast tree through a centralized

XIANG ET AL.: SUPPORTING EFFICIENT AND SCALABLE MULTICASTING OVER MOBILE AD HOC NETWORKS 545

calculation for tree construction, and is also more applicablefor a smaller group. The focus of EGMP, however, is toimprove the scalability and efficiency of geometric multicast.

The HRPM [30] and SPBM [20] are more related to ourwork, as they also support hierarchical group management.HRPM consists of two key design ideas: 1) hierarchicaldecomposition of a large group into a hierarchy ofrecursively organized manageable-sized subgroups, and2) the use of distributed geographic hashing to constructand maintain such a hierarchy. Although it is interesting toapply hashing to find the rendezvous point (RP) for thenetwork to store and retrieve state information, the hashedlocation is obtained with the assumption of the networksize, which is difficult for a dynamic network. Also, as thehashed location is virtual, it is possible that the nodes couldnot find the (consistent) RP. This can happen when amessage (e.g., Join) reaches a node whose transmissionrange covers the virtual point, but the node is neither theone closest to the RP, nor aware of the node (which may beout of its transmission range) closest to the RP. The mobilityof nodes will introduce additional challenge to the protocol,which may not only result in frequent RP handoff, but alsoincrease the chance of RP search inconsistency and failure.Additionally, requiring a node to contact RP first for a Joinwill increase joining delay. In contrast, EGMP does notmake any assumption of the network size in advance, andthe change of the membership of a zone does not need to besent to a faraway RP but only needs to be updated locally.Instead of using one RP as a core for group membershipmanagement, which may lead to a point of failure, EGMPintroduces the root zone which is much more stable than asingle point, and manages group membership moreefficiently within the local range. Instead of using theoverlay-based multiple unicast transmissions, EGMP takesadvantage of the promiscuous mode transmission toforward packets along more efficient transmission paths.We did not directly compare our work with HRPM, as wedo not know the hashing algorithm used and a different RPdistribution scheme would lead to different performance.However, we evaluated the performance of EGMP using amuch larger default network size, which is known to havemuch more challenge to ensure reliable multicast transmis-sions than a smaller network.

In SPBM [20], the network terrain is divided into a quad-tree with L levels. The top level is the whole network andthe bottom level is constructed by basic squares. Eachhigher level is constructed by larger squares with eachsquare covering four smaller squares at the next lower level.All the nodes in a basic square are within each other’stransmission range. At each level, every square needs toperiodically flood its membership into its upper levelsquare. Such periodic flooding is repeated for every twoneighboring levels and the top level is the whole networkregion. Significant control overhead will be generated whenthe network size increases as a result of membershipflooding. With this proactive and periodic membershipupdating scheme, the membership change of a node mayneed to go through L levels to make it known to the wholenetwork, which leads to a long multicast group joining time.Instead of using multiple levels of flooding for groupmembership management, EGMP uses more efficient zone-based tree structure to allow nodes to quickly join and leavethe group. EGMP introduces root zone and zone depth to

facilitate simple and more reliable group membershipmanagement. EGMP does not use any periodic network-wide flooding, thus it can be scalable to both the group sizeand network size.

Finally, a lot of work have been done on geocasting [31],[32], [34]. Different from general multicasting, in which thedestinations are a group of receivers, the destination ofgeocasting is one or multiple geographic regions (squaresare normally defined). When packets reach the destinedregion, they will be sent to the nodes in the region throughflooding or other methods. There is no need of formingmulticast infrastructure to deliver packets to group mem-bers that may distribute widely in the whole networkdomain and change their positions as nodes move.

In [33], we proposed an efficient and robust geographicmulticast protocol for MANET. In this paper, we furtherintroduce zone-supported geographic forwarding to reduce therouting failure, and provide mechanism to handle zonepartitioning. In addition, we introduce a path optimizationprocess to handle multiple paths, and provide a detailedcost analysis to demonstrate the scalability of the proposedrouting scheme.

3 EFFICIENT GEOGRAPHIC MULTICAST PROTOCOL

In this section, we will describe the EGMP protocol indetails. We first give an overview of the protocol andintroduce the notations to be used in the rest of the paper inSection 3.1. In Sections 3.2 and 3.3, we present our designsfor the construction of zone structure and the zone-basedgeographic forwarding. Finally, in Sections 3.4, 3.5, and 3.6,we introduce our mechanisms for multicast tree creation,maintenance, and multicast packet delivery.

3.1 Protocol Overview

EGMP supports scalable and reliable membership manage-ment and multicast forwarding through a two-tier virtual-zone-based structure. At the lower layer, in reference to apredetermined virtual origin, the nodes in the network self-organize themselves into a set of zones as shown in Fig. 1,and a leader is elected in a zone to manage the local groupmembership. At the upper layer, the leader serves as arepresentative for its zone to join or leave a multicast groupas required. As a result, a networkwide zone-based multi-cast tree is built. For efficient and reliable management andtransmissions, location information will be integrated withthe design and used to guide the zone construction, groupmembership management, multicast tree construction andmaintenance, and packet forwarding. The zone-based tree isshared for all the multicast sources of a group. To further


Fig. 1. Zone structure and multicast session example.

reduce the forwarding overhead and delay, EGMP supportsbidirectional packet forwarding along the tree structure.That is, instead of sending the packets to the root of the treefirst, a source forwards the multicast packets directly alongthe tree. At the upper layer, the multicast packets will flowalong the multicast tree both upstream to the root zone anddownstream to the leaf zones of the tree. At the lower layer,when an on-tree zone leader receives the packets, it willsend them to the group members in its local zone.

Many issues need to be addressed to make the protocolfully functional and scalable. The issues related to zonemanagement include: the schemes for more efficient androbust zone construction and maintenance, the strategiesfor election and maintenance of a zone leader withminimum overhead, zone partitioning as a result of severewireless channels or signal blocking, potential packet losswhen multicast members move across zones. The issuesrelated to packet forwarding include: the efficient buildingof multicast paths with the zone structure, the handling ofempty zone problem, the efficient tree structure main-tenance during node movements, the reliable transmissionsof control and multicast data packets, and obtaininglocation information to facilitate our geometric designwithout resorting to an external location server.

For the convenience of presentation, we first introducethe terminologies used in the paper. In EGMP, we assumeevery node is aware of its own position through somepositioning system (e.g., GPS [10]) or other localizationschemes. The forwarding of data packets and most controlmessages is based on the geographic unicast routingprotocol GPSR [13] described in Section 1. EGMP, however,does not depend on a specific geographic unicast protocol.

Some of the notations to be used are:

. zone: The network terrain is divided into squarezones as shown in Fig. 1.

. r: Zone size, the length of a side of the zone square.The zone size is set to r � rt=

ffiffiffi2p

, where rt is thetransmission range of the mobile nodes. To reduceintrazone management overhead, the intrazonenodes can communicate directly with each otherwithout the need of any intermediate relays.

. zone ID: The identification of a zone. A node cancalculate its zone ID (a, b) from its positioncoordinates (x, y) as: a ¼ ½x�x0

r �; b ¼ ½y�y0

r �, whereðx0; y0Þ is the position of the virtual origin, whichcan be a known reference location or determined atnetwork setup time. A zone is virtual and formulatedin reference to the virtual origin. For simplicity, weassume all the zone IDs are positive.

. zone center: For a zone with ID (a,b), the position ofits center ðxc; ycÞ can be calculated as: xc ¼ x0 þ ða þ0:5Þ � r; yc ¼ y0 þ ðbþ 0:5Þ � r. A packet destinedto a zone will be forwarded toward the center ofthe zone.

. zLdr: Zone leader. A zLdr is elected in each zone formanaging the local zone group membership andtaking part in the upper tier multicast routing.

. tree zone: The zones on the multicast tree. The treezones are responsible for the multicast packetforwarding. A tree zone may have group membersor just help forward the multicast packets for zoneswith members.

. root zone: The zone where the root of the multicasttree is located.

. zone depth: The depth of a zone is used to reflect itsdistance to the root zone. For a zone with ID ða; bÞ, itsdepth is

depth ¼ maxðja0 � aj; jb0 � bjÞ;

where ða0; b0Þ is the root-zone ID. For example, inFig. 1, the root zone has depth zero, the eight zonesimmediately surrounding the root zone have depthone, and the outer seven zones have depth two.

In EGMP, the zone structure is virtual and calculatedbased on a reference point. Therefore, the construction ofzone structure does not depend on the shape of the networkregion, and it is very simple to locate and maintain a zone.The zone is used in EGMP to provide location reference andsupport lower-level group membership management. Amulticast group can cross multiple zones. With theintroduction of virtual zone, EGMP does not need to trackindividual node movement but only needs to track themembership change of zones, which significantly reducesthe management overhead and increases the robustness ofthe proposed multicast protocol. We choose to design thezone without considering node density so it can providemore reliable location reference and membership manage-ment in a network with constant topology changes.

3.2 Neighbor Table Generation and Zone LeaderElection

For efficient management of states in a zone, a leader iselected with minimum overhead. As a node employsperiodic BEACON broadcast to distribute its position inthe underneath geographic unicast routing [13], to facilitateleader election and reduce overhead, EGMP simply insertsin the BEACON message a flag indicating whether thesender is a zone leader. With zone size r � rt=

ffiffiffi2p

, a broadcastmessage will be received by all the nodes in the zone. Toreduce the beaconing overhead, instead of using fixed-interval beaconing, the beaconing interval for the under-neath unicast protocol will be adaptive. A nonleader nodewill send a beacon every period of Intvalmax or when itmoves to a new zone. A zone leader has to send out a beaconevery period of Intvalmin to announce its leadership role.

A node constructs its neighbor table without extrasignaling. When receiving a beacon from a neighbor, a noderecords the node ID, position, and flag contained in themessage in its neighbor table. Table 1 shows the neighbortable of node 18 in Fig. 1. The zone ID of the sending node canbe calculated from its position, as discussed earlier. To avoidrouting failure due to outdated topology information, anentry will be removed if not refreshed within a periodTimeoutNT or the corresponding neighbor is detectedunreachable by the MAC layer protocol.


TABLE 1The Neighbor Table of Node 18 in Fig. 1

A zone leader is elected through the cooperation of nodesand maintained consistently in a zone. When a nodeappears in the network, it sends out a beacon announcingits existence. Then, it waits for an Intvalmax period for thebeacons from other nodes. Every Intvalmin a node will checkits neighbor table and determine its zone leader underdifferent cases: 1) The neighbor table contains no othernodes in the same zone, it will announce itself as the leader.2) The flags of all the nodes in the same zone are unset,which means that no node in the zone has announced theleadership role. If the node is closer to the zone center thanother nodes, it will announce its leadership role through abeacon message with the leader flag set. 3) More than onenode in the same zone have their leader flags set, the onewith the highest node ID is elected. 4) Only one of the nodesin the zone has its flag set, then the node with the flag set isthe leader.

3.3 Zone-Supported Geographic Forwarding

With a zone structure, the communication processincludes an intrazone transmission and an interzonetransmission. In our zone structure, as nodes from thesame zone are within each other’s transmission range andare aware of each other’s location, only one transmission isrequired for intrazone communications. Transmissionsbetween nodes in different zones may be needed for thenetwork-tier forwarding of control messages and datapackets. As the source and the destination may bemultiple hops away, to ensure reliable transmissions,geographic unicasting is used with the packet forwardingguided by the destination position. However, in normalgeographic unicast routing, location service is required forthe source to obtain the destination position. In EGMP, toavoid the overhead in tracking the exact locations of apotentially large number of group members, locationservice is integrated with zone-based membership man-agement without the need of an external location server.At the network tier, only the ID of the destination zone isneeded. A packet is forwarded toward the center of thedestination zone first. After arriving at the destinationzone, the packet will be forwarded to a specific receivingnode or broadcast depending on the message type.Generally, the messages related to multicast groupmembership management and multicast data will beforwarded to the zone leader to process.

In the above design, for scalability and reliability, thecenter of the destination zone is used as the landmark forsending a packet to the group members in the zonealthough there may be no node located at the centerposition. This, however, may result in the failure ofgeographic forwarding. For example, in Fig. 1, node 7 isthe only node in zone (0, 1), while node 18 in zone (1, 1) isclosest to the center of zone (0, 1). When node 16 sends apacket to zone (0, 1) with its center as the destination, theunderlying geographic unicast protocol (for example, GPSR[13] described in Section 1) will forward the packet to node18 greedily as it is closer to the destination. As node 18cannot find a neighbor closer to the center of zone (0, 1) thanitself, the perimeter mode [13] may be used to continue theforwarding. This still cannot guarantee the packet to arriveat node 7, as the destination is a virtual reference point.Such a problem is neglected by the previous geographicprotocols that use a region as destination (e.g., [20]).

To avoid this problem, we introduce a zone forwardingmode in EGMP when the underlying geographic forwardingfails. Only when the zone mode also fails, the packet will bedropped. In zone mode, a sender node searches for the nexthop to the destination based on its neighbor table, whichcan more accurately track the local network topology. Thenode selects as its next hop the neighboring node whosezone is the closest to the destination zone and closer to thedestination zone than its own zone. If multiple candidatesare available, the neighbor closest to the destination isselected as the next hop. To compare the distances ofdifferent zones to the destination zone, the node cancalculate the distance value disða;bÞ of a zone (a,b) to thedestination zone ðadst; bdstÞ as

disða;bÞ ¼ ða� adstÞ2 þ ðb� bdstÞ2: ð1Þ

A zone with a smaller dis value is closer to thedestination zone. In the above example, if the underlyinggeographic unicast forwarding fails at node 18, it will try tocontinue the forwarding using zone mode. It checks itsneighbor Table 1. Since the dis value of zone (0, 1) has zerovalue to the destination zone (0, 1), node 18 selects itsneighbor node 7 in zone (0, 1) as the next hop and forwardsthe packet to node 7. To avoid possible routing loop, anintermediate node only forwards a packet that is receivedfor the first time.

To validate our zone-supported geographic forwardingstrategy, we compare our scheme (represented as EGMP_forward) with two other schemes through simulations:SPBM [20] (represented as SPBM_forward), in which asender uses the point in the square which is closest toitself as the destination position; a unicast strategy whichalso uses the zone center to estimate the destinationposition (represented as EGMP_non_zonemode) but doesnot use the zone forwarding mode. The settings andprotocol parameters are the same as in Section 5. Wesimulated 30 CBR traffic flows with each flow sent at 8Kbps between a randomly chosen source and a nonemptyzone. A packet is considered to be successfully delivered ifit is received by any node in the destination zone. InFig. 2, when the destination is a zone, the zone center is abetter estimation of the destination position than theclosest point in the destined zone. As the estimated closestpoint in the destined zone could be very close to the zoneborder, compared to the zone center, it is more likely foran out-of-zone node to be closer to the estimated pointand become the forwarder than an intrazone node. Hence,the forwarder may have a higher chance of dropping thepacket when not able to find a next hop node closer to thedestination for forwarding the packet. The simulationresults confirm that using zone forwarding mode can helpreduce the number of undelivered packets.


Fig. 2. Impact of forwarding strategies.

3.4 Multicast Tree Construction

In this section, we present the multicast tree creation andmaintenance schemes. In EGMP, instead of connecting eachgroup member directly to the tree, the tree is formed in thegranularity of zone with the guidance of location informa-tion, which significantly reduces the tree managementoverhead. With a destination location, a control messagecan be transmitted immediately without incurring a highoverhead and delay to find the path first, which enables quickgroup joining and leaving. In the following description, exceptwhen explicitly indicated, we use G, S, and M, respectively, torepresent a multicast group, a source of G and a member of G.

3.4.1 Multicast Session Initiation and Termination

When a multicast session G is initiated, the first source nodeS (or a separate group initiator) announces the existence of Gby flooding a message NEW SESSIONðG; zoneIDSÞ intothe whole network. The message carries G and the ID of thezone where S is located, which is used as the initial root-zoneID of group G. When a node M receives this message and isinterested in G, it will join G using the process described inthe next section. A multicast group member will keep amembership table with an entry ðG; root zID; isAckedÞ,where G is a group of which the node is a member, root_zIDis the root-zone ID, and isAcked is a flag indicating whetherthe node is on the corresponding multicast tree. A zoneleader (zLdr) maintains a multicast table. When a zLdrreceives the NEW_ SESSION message, it will record thegroup ID and the root-zone ID in its multicast table. Table 2is an example of one entry in the multicast table of node 16in Fig. 1. The table contains the group ID, root-zone ID,upstream zone ID, downstream zone list, and downstreamnode list. To end a session G, S floods a messageEND_SESSION(G). When receiving this message, the nodeswill remove all the information about G from theirmembership tables and multicast tables.

3.4.2 Multicast Group Join

When a node M wants to join the multicast group G, if it is nota leader node, it sends a JOIN REQðM;PosM;G; fMoldgÞmessage to its zLdr, carrying its address, position, and groupto join. The address of the old group leader Mold is an optionused when there is a leader handoff and a new leader sendsan updated JOIN_REQ message to its upstream zone. If Mdid not receive the NEW_SESSION message or it just joinedthe network, it can search for the available groups byquerying its neighbors. If a zLdr receives a JOIN_REQmessage or wants to join G itself, it begins the leader joiningprocedure as shown in Fig. 3. If the JOIN_REQ message isreceived from a member M of the same zone, the zLdr adds Mto the downstream node list of its multicast table. If themessage is from another zone, it will compare the depth of therequesting zone and that of its own zone. If its zone depth issmaller, i.e., its zone is closer to the root zone than the

requesting zone, it will add the requesting zone to itsdownstream zone list; otherwise, it simply continuesforwarding the JOIN_REQ message toward the root zone.

If new nodes or zones are added to the downstream list,the leader will check the root-zone ID and the upstream zoneID. If it does not know the root zone, it starts an expandedring search. As the zone leaders in the network cache theroot-zone ID, a result can be quickly obtained. With theknowledge of the root zone, if its upstream zone ID is unset,the leader will represent its zone to send a JOIN_REQmessage toward the root zone; otherwise, the leader willsend back a JOIN_REPLY message to the source of theJOIN_REQ message (which may be multiple hops away andthe geographic unicasting described in Section 3.3 is used forthis transmission). When the source of the JOIN_REQmessage receives the JOIN_REPLY, if it is a node, it sets theisAcked flag in its membership table and the joiningprocedure is completed. If the leader of a requesting zonereceives the JOIN_REPLY message, it will set its upstreamzone ID as the ID of the zone where the JOIN_REPLYmessage is sent, and then send JOIN_REPLY messages tounacknowledged downstream nodes and zones.

An example is given in Fig. 1, in which the root zone of Gis (2, 2), and the double circled nodes are zone leaders.Suppose currently zone (0, 0) and (1, 1) are not on themulticast tree, and their leader nodes 15 and 16 alreadyknow the root-zone ID from the NEW_SESSION message.Now node 15 plans to join G with the leader joiningprocedure. As it finds its upstream zone ID is unset, node 15sends a JOIN_REQ message toward root zone (2, 2). Themessage reaches zone (1, 1) and is intercepted by leadernode 16, which then starts its leader joining procedure.Node 16 compares the depths of zone (0, 0) and its ownzone. Since depthð0;0Þ ¼ 2 and depthð1;1Þ ¼ 1; depthð0;0Þ >depthð1;1Þ, node 16 adds zone ID (0, 0) to its downstreamzone list. As node 16 finds its upstream zone ID is unset, itsends a JOIN_REQ message toward the root zone. This


TABLE 2The Entry of Group G in Multicast Table of Node 16

Fig. 3. The pseudocode of the leader joining procedure.

message is received by the leader of the root zone, node 3,and triggers the joining procedure of node 3. Node 3 addsthe zone ID (1, 1) to its downstream zone list aftercomparing the depth. As the root zone does not have anupstream zone, node 3 sends back a JOIN_REPLY messageto the zone (1, 1). On receiving this message, node 16 setsthe upstream zone ID as (2, 2) and sends a JOIN_REPLYmessage to its unacknowledged downstream zone (0, 0).Node 15 sets its upstream zone as (1, 1) on receiving theJOIN_REPLY message and the joining process is completed,with two multicast branches built between zones (2, 2) and(1, 1), and between zones (1, 1) and (0, 0), respectively.

Through the joining process, the group membershipmanagement is implemented in a distributed manner. Anupstream zone only needs to manage its downstream zones,and the group membership of a local zone is only managedby its leader. The zone depth is used to guide efficient treeconstruction and packet forwarding.

3.4.3 Multicast Group Leave

When a member M wants to leave G, it sends aLEAVEðM;GÞ message to its zone leader. On receiving aLEAVE message, the leader removes the source of theLEAVE message from its downstream node list or zone listdepending on whether the message is sent from anintrazone node or a downstream zone. Besides removinga branch through explicit LEAVE, a leader will remove anode from its downstream list if it does not receive thebeacon from the node exceeding 2� Intervalmax. If itsdownstream zone list and node list of G are both empty andit is not a member of G either, the leader sends aLEAVE(zoneID, G) message to its upstream zone. Throughthe leave process, the unused branches are removed fromthe multicast tree.

3.5 Multicast Packet Delivery

In this section, we explain how the multicast packets areforwarded to the members.

3.5.1 Packet Sending from the Source

After the multicast tree is constructed, all the sources of thegroup could send packets to the tree and the packets will beforwarded along the tree. In most tree-based multicastprotocols, a data source needs to send the packets initially tothe root of the tree. If this scheme is used and node 5 in Fig. 1is a source, node 5 needs to unicast the packets initially toroot zone (2, 2). The sending of packets to the root wouldintroduce extra delay especially when a source is far awayfrom the root. Instead, EGMP assumes a bidirectional-tree-based forwarding strategy [23], with which the multicastpackets can flow not only from an upstream node/zonedown to its downstream nodes/zones, but also from adownstream node/zone up to its upstream node/zone.

A source node is also a member of the multicast groupand will join the multicast tree. When a source S has data tosend and it is not a leader, it checks the isAcked flag in itsmembership table to find out if it is on the tree. If it is, i.e.,its zone has joined the multicast tree, it sends the multicastpackets to its leader. When the leader of an on-tree zonereceives multicast packets, it forwards the packets to itsupstream zone and all its downstream nodes and zonesexcept the incoming one. For example, in Fig. 1, source node1 sends the packets to its leader node 16, which will send

the packets to its upstream zone (2, 2) and its downstreamzones (0, 1) and (0, 0), but not to the downstream node 1which is the incoming node. When the packets are receivedby leader node 3 of the root zone, it continues forwardingthe packets to its downstream zones (1, 3), (3, 3), (2, 1)except the incoming zone (1, 1). The arrows in the figureindicate the directions of the packet flows.

When a source node S is not on the multicast tree, forexample, when it moves to a new zone, the isAcked flagwill remain unset until it finishes the rejoining to G throughthe leader of the new zone. To reduce the impact of thejoining delay, S will send packets directly to the root zoneuntil it finishes the joining process.

3.5.2 Multicast Data Forwarding

In our protocol, only zLdrs maintain the multicast table,and the member zones normally cannot be reached withinone hop from the source. When a node N has a multicastpacket to forward to a list of destinations ðD1; D2; D3; . . .Þ, itdecides the next hop node toward each destination (for azone, its center is used) using the geographic forwardingstrategy described in Section 3.3. After deciding the nexthop nodes, N inserts the list of next hop nodes and thedestinations associated with each next hop node in thepacket header. An example list is ðN1 : D1; D3;N2 : D2; . . .Þ,where N1 is the next hop node for the destinations D1 andD3, and N2 is the next hop node for D2. Then, N broadcaststhe packet promiscuously (for reliability and efficiency).Upon receiving the packet, a neighbor node will keep thepacket if it is one of the next hop nodes or destinations, anddrop the packet otherwise. When the node is associatedwith some downstream destinations, it will continueforwarding packets similarly as done by node N.

For example, in Fig. 1, after node 3 receives the multicastpacket from zone (1, 1), it will forward the packet todownstream zones (2, 1), (1, 3), and (3, 3). It determines thenext hop node for each destination and inserts the list (12:(1,3), (3,3); 14: (2,1)) in the packet header. After broad-casting the packet promiscuously, its one-hop neighborsnodes 12, 14, and 8 will receive the packet. Node 8 will dropthis packet, while nodes 12 and 14 will continue theforwarding. Node 12 replaces the list carried in the packetheader with (17: (1,3); 2: (3,3)) and broadcasts this packet.Node 14 finds group information from its multicast table,and broadcast the packet with a header (9: (1,0); 5:(3,0)).

3.6 Multicast Route Maintenance and Optimization

In a dynamic network, it is critical to maintain theconnection of the multicast tree, and adjust the treestructure upon the topology changes to optimize themulticast routing. In the zone structure, due to the move-ment of nodes between different zones, some zones maybecome empty. It is critical to handle the empty zoneproblem in a zone-based protocol. Compared to managingthe connections of individual nodes, however, there is amuch lower rate of zone membership change and hence amuch lower overhead in maintaining the zone-based tree.As the tree construction is guided by location information, adisconnected zone can quickly reestablish its connection tothe tree. In addition, a zone may be partitioned intomultiple clusters due to fading and signal blocking. In thissection, we discuss our maintenance schemes.


3.6.1 Moving between Different Zones

When a member node moves to a new zone, it must rejointhe multicast tree through the new leader. When a leader ismoving away from its current zone, it must handover itsmulticast table to the new leader in the zone, so that all thedownstream zones and nodes will remain connected to themulticast tree.

Whenever a node M moves into a new zone, it will rejoin amulticast group G by sending a JOIN_REQ message to itsnew leader. During this joining process, to reduce the packetloss, whenever the node broadcasts a BEACON message toupdate its information to the nodes in the new zone, it alsounicasts a copy of the message to the leader of its previouszone to update its position. Since it has not sent the LEAVEmessage to the old leader, the old leader will forward themulticast packets to M. This forwarding process helps reducethe packet loss and facilitates seamless packet transmissionsduring zone crossing. When the rejoining process finishes,M will send a LEAVE message to its old leader.

To handle leader mobility problem, if a leader finds itsdistance to the zone border is less than a threshold or it isalready in a new zone, it assumes it is moving away from thezone where it was the leader, and it starts the handoverprocess. To look for the new leader, it compares the positionsof the nodes in the zone it is leaving from and selects the oneclosest to the zone center as the new leader. It then sends itsmulticast table to the new leader, which will announce itsleadership role immediately through a BEACON message.It will also send a JOIN_REQ message to its upstream zone.During the transition, the old leader may still receivemulticast packets. It will forward all these packets to thenew leader when the handover process is completed. If thereis no other node in the zone and the zone will become empty,it will use the method introduced in the next section todeliver its multicast table. In the case that the leader diessuddenly before handing over its multicast table, the down-stream zones and nodes will reconnect to the multicast treethrough the maintenance process described in Section 3.6.4.

3.6.2 Dealing with Empty Zones

A zone may become empty when all the nodes move away.The probability that a zone is empty is approximately P ¼e��r

2when the node density is � and the zone size is r. Assume

r ¼ 150 m, which is the zone size that allows all the nodes inthe same zone to be within the transmission range, theprobability of the zone being empty is: P ¼ 0:207 ifd ¼ 70 nodes=km2, and P ¼ 0:509 if d ¼ 30 nodes=km2. Wecan see that the probability of a zone becoming empty is notnegligible and it is critical to address the empty zone problem.

In EGMP, if a tree zone becomes empty, the multicasttree will be adjusted correspondingly to keep the multicasttree connected. Because of the importance of the root zone,we will treat it differently. When a leader is moving awayfrom a nonroot tree zone and the zone is becoming empty, itwill send its multicast table to its upstream zone. Theupstream zone leader will then take over all its downstreamzones, and delete this requesting zone from its downstreamzone list. The new upstream zone needs to send JOIN_REPLY messages to all the newly added downstream zonesto notify them the change. When receiving the JOIN_REPLYmessages, these downstream zones will change their up-stream zone ID accordingly.

If the to be empty zone is the root zone, since the root zonehas no upstream zone, the leader will check its neighboringzones and choose the one closest to the root zone as thenew root zone. The leader then forwards its multicast tableto the new root zone, and floods a NEW_ROOT message toannounce the change.

3.6.3 Handling Multiple Clusters per Zone

When there is severe shadowing/fading or a hill/buildingthat prevents the radio communication between nodes in azone, the nodes in the same zone may form multipleclusters as shown in Fig. 4, where the two clusters are notconnected in the zone although they are connected throughsome nodes outside the zone. In this case, two nodes indifferent clusters can communicate with each other byusing unicasting because they are connected on the networktopology graph, but an intrazone flooding message initiatedin one cluster may not reach other clusters. This problem isalso a key problem for zone-based protocols.

EGMP handles the zone partitioning problem as follows:If there are multiple clusters in a zone, because these clustersare not aware of the existence of each other, each cluster willelect a leader. When an upstream zone leader receivesJOIN_REQ messages from multiple leaders of the same zoneand the new message is not sent as a result of leaderhandover (in which case the old leader’s address needs to becarried), it detects that the downstream zone has partitionedinto multiple clusters. It identifies a cluster by its zID and theleader’s address. When sending a packet to the cluster, ituses the leader’s position instead of the zone center (in whichcase the zone ID is carried as the destination) as thetransmission reference. Even though the leader may move,its position carried in JOIN_REQ message can still be used asa reference to forward packets to its cluster. When receivinga packet with the position of the leader as the reference, acluster leader can learn that multiple clusters exist within itszone. In case that not all the clusters of a partitioned zonesend JOIN_REQ messages, the upstream zone leader maynot be aware of the partitioning of the downstream zone.When a cluster leader receives a packet destined to its zonebut does not match its status, it will send an update messageto its upstream zone. For example, when a cluster leaderreceives a JOIN_REPLY message or a multicast packet butdid not send JOIN_REQ message, it will send a LEAVEmessage to the upstream zone. When receiving messagesfrom multiple leaders of the same zone, the upstream leadercan detect zone partitioning. It will resend the previousmessage to the target cluster with the position of the zoneleader as the destination.

When the leader of a cluster changes, if the cluster is on-tree, the new leader sends a JOIN_REQ message to itsupstream zone immediately which also carries the oldleader’s address. With multiple clusters in its upstream zone,


Fig. 4. Multiple clusters in one zone.

the JOIN_REQ message from a zone leader will generally beintercepted by one of the clusters, which will be responsiblefor forwarding the packets to the zone. Some clusters maymerge later into a larger cluster, and through the leaderelection procedure, only one of the leaders will win as thenew cluster’s leader. The new leader will send a JOIN_REQmessage to the upstream zone to refresh the cluster’sinformation. The leaders of the other merged-in clusters willalso send LEAVE messages to the upstream zone, which willremove their information from the multicast table.

3.6.4 Tree Branch Maintenance

To detect the disconnection of tree branches in time, if thereare no multicast packets or messages to deliver for a periodof Intvalactive, the leader of a tree zone will send an ACTIVEmessage to its downstream nodes and zones to announcethe activity of the multicast branches. The message is sentthrough multicast to multiple downstream entities. When amember node or a tree zone fails to receive any packets ormessages from its leader or upstream zone up to a period of2 � Intvalactive, it assumes that it loses the connection to themulticast tree and restarts a joining process.

3.6.5 Route Optimization

Sometimes a zone leader may receive duplicate multicastpackets from different upstream zones. For example, asdescribed in the above section, when failing to receive anydata packets or ACTIVE messages from the upstream zonefor a period of time, a tree zone will start a rejoiningprocess. However, it is possible that the packet andmessage were lost due to collisions, so the old upstreamzone is still active after the rejoining process, and duplicatepackets will be forwarded by two upstream zones to thetree zone. In this case, the one closer to the root zone willbe kept as the upstream zone. If the two upstream zoneshave the same distances to the root zone, one of them israndomly selected.

4 COST ANALYSIS

In this section, we will quantitatively analyze the per node costof the protocol, which is defined as the average number ofcontrol messages transmitted by each node per second. Thenotations to be used in this section are listed in Table 3.The cost of the overall protocol consists of the following threecomponents: zone building and geographic routing, treeconstruction, and tree maintenance.

4.1 Cost for Zone Building and Geographic Routing

The zone is virtual and determined by each node based onits position and the reference origin, without the need of

extra signaling messages. The leader information is dis-tributed with a flag inserted in the beacon messages of theunderlying geographic unicast routing protocol. Therefore,the per node cost of the zone building and geographicrouting is impacted by the beaconing frequency 1=Intvalminintroduced in Section 3.2, and the cost is as follows:

Costunicast �1

Intvalmin¼ Oð1Þ: ð2Þ

4.2 Cost for Tree Construction

The tree construction process is associated with the multi-cast session initiation and termination, and the memberjoining and leaving the multicast tree.

Lemma 1. The per node cost of multicast tree construction isO(1) with respect to the network size and the group size.

Proof. Multicast session initiation and termination include aflooding of a NEW_SESSION message and a flooding ofEND_SESSION message, so the cost for multicast sessioninitiation and termination is

Costinit end ¼1

NTð2�NÞ ¼ Oð1Þ:

To analyze the cost for the joining and leaving process,we consider the worst case that all the zones need to jointhe multicast tree and become tree zone and all themembers to join the tree are not zone leaders. In this case,group members need to first send a JOIN_REQ messageto their leaders in local zones, and each leader needs tosend a JOIN_REQ message toward the root zone to jointhe multicast tree. The JOIN_REQ message from a zonewill be intercepted by an upstream zone leader. Thedistance between an upstream and a downstream zoneleader is shorter than 2

ffiffiffi2p

rþ rt, where rt is the transmis-sion range. According to [22], the average number of hopsof the greedy forwarding path between the source andthe destination is

�d�z , where �d is the average distance

between the source and the destination and �z is theaverage forwarding progress made toward the destina-tion in the course of one transmission. Parameter �zdepends on rt and the average number of nodes withinthe transmission range, and is constant with respect to thegroup size and the network size. Hence,

Costjoin �1

NTMn þMz

2ffiffiffi2p

rþ rt�z

� �;

and as Mn � N and Mz � N;Costjoin � Oð1Þ. Since theJOIN_REPLY message follows the reverse direction ofJOIN_REQ message, and the leaving process is similar tothe joining process, Costreply ¼ Costjoin � Oð1Þ andCostleave ¼ Costjoin � Oð1Þ. Therefore, the cost for multi-cast tree construction is

Costtree ¼ Costinit end þ Costjoin þ Costreply þ Costleave¼ Oð1Þ:

ut

This indicates that the per node control overheadinvolved in multicast tree construction remains relativelyconstant with respect to network size and group size.


TABLE 3Notations Used in the Cost Analysis

4.3 Cost for Tree Maintenance

The cost involved in multicast tree maintenance includesthe handling of zone crossing of multicast members, the treereconstruction when there is an empty zone, and the treebranch maintenance.

Lemma 2. Assume that a node keeps the same moving directionin a zone. The average moving distance of the mobile nodes in azone is �r

4 .

Proof. The moving distance d of a node in a zone is thelength of its moving trail in the zone square. Forexample, in Fig. 5, line a is such a moving trail. Supposethe angle formed by the moving trail and the bottom sideof the zone square is �. Due to the symmetry of thesquare, we only need to consider the case when � 2 ½0; �4�.As illustrated in Fig. 5, all the possible moving trails withangle � are located between two parallel lines b and c,where b and c are tangent to the zone with angle �. Line lis perpendicular to b and c and intersects b at point A. aintersects l at B. Suppose the distance between A and Bis z, the length of a moving trail is decided by its angle �and the distance z. Therefore, we can obtain the averagedistance of a node moving in a zone as

d ¼

R �4

0 2R r sin �

0z

sin � cos � dzþR r

2ðcos ��sin �Þr sin �

rcos � dz

� �d�R �

4

0

R r2ðcos �þsin �Þ0 dzd�

¼ �r4:

ð3Þ

tuLemma 3. The per node cost of multicast tree maintenance is

O(1) with respect to the network size and the group size.

Proof. The cost for the tree maintenance is composed of thecost for handling zone crossing of member nodes, thecost in adapting the tree structure in the presence ofempty zones, and the cost in maintaining tree branches,as presented in Sections 3.6.1, 3.6.2, and 3.6.4. We firstanalyze these costs separately.

The first component includes the cost of handling themoving between different zones due to nonleadermembers and due to leaders. For a nonleader member,it must send a JOIN_REQ message to the new zoneleader, which will send a JOIN_REPLY, and a LEAVEmessage to the old leader. Its distances to the new andthe old zone leaders are shorter than

ffiffiffi2p

r and 2ffiffiffi2p

r,respectively. By Lemma 2, the average frequency of anode moving between different zones is 4v

�r . A leader willsend its multicast table to the new selected leader whenmoving out of the zone. Hence, the cost due to membernodes moving across zones is

Costmoving ¼ Costnon zLdr þ CostzLdr

�Mn

N

4v

�r

ð1þ 1þ 2Þ �ffiffiffi2p

r

�zþMz

N

4v

�r

ffiffiffi2p

r

�z

¼ Oð1Þ:

ð4Þ

Due to node movement, a zone may become empty.The empty zone may be a tree zone or the root zone.When the upstream zone of a tree zone is to be empty, themoving away leader will hand the tree zone over to itsown upstream zone, which will send a JOIN_REPLYmessage to this tree zone. The cost for this process shouldbe less than the cost for the joining process as shown inLemma 1. If the upstream zone is the root zone, besidesthe above cost, a NEW_ROOT message is flooded in thenetwork. The frequency of a zone becoming emptyshould be less than the frequency of a node movingbetween different zones, which is 4v

�r . Hence,

Costemptyzone ¼ CosttreeZone þ CostrootZone

� 4vT

�rðCostjoin þ CostreplyÞ þ

N

N

4v

�r

¼ Oð1Þ:

ð5Þ

The cost for tree branch maintenance should be also lessthan the cost of joining process with frequency 1

Intvalactive.

Costactive �T

IntvalactiveðCostjoin þ CostreplyÞ ¼ Oð1Þ: ð6Þ

Therefore, the total per node cost for tree main-tenance is

Costmaintain ¼ Costmoving þ Costemptyzone þ Costactive� Oð1Þ:

ð7Þ

tu

4.4 Cost for the Protocol

We summarize the per node cost of the protocol andvalidate our quantitative analysis through simulations.

4.4.1 Quantitative Analysis on the Per Node Cost

Theorem 1. The EGMP control overhead as the average numberof control message transmissions per node every second has acomplexity of O(1) with respect to the network size and thegroup size.

Proof. The overhead of the protocol is generated from thetree construction and maintenance and the periodicbeaconing in the underlying geographic unicast routingprotocol. By Lemmas 1 and 3, and (2), the cost of theprotocol, i.e., the number of transmissions of controlmessages per node every second with respect to thenetwork size and the group size is

Costprotocol ¼ Costtree þ Costmaintain þ Costunicast¼ Oð1Þ:

ð8Þ

tu

4.4.2 Validation of the Cost Analysis by Simulation

We validate our quantitative analysis on the protocol costthrough simulations. The simulation settings and protocolparameters were set as those in Section 5. We studied the


Fig. 5. The moving distance of a mobile node in a zone.

protocol cost, i.e., the average number of transmissions ofcontrol messages by each node per second, with networksize varied from 1;500 m� 1;500 m with 156 nodes to3;900 m� 3;900 m with 1,056 nodes and the group sizevaried from 10 to 200 members.

Figs. 6a and 6b validate our quantitative analysis on theprotocol cost. The protocol cost keeps almost constantbetween 0.3 and 0.4 with different network sizes andgroup sizes.

The above analysis results indicate that when thenetwork size and the group size increase, the controloverhead placed on each node per second by the protocolwill remain relatively constant. Next, we will furtherdemonstrate the scalability and efficiency of the protocolby simulation studies.

5 PERFORMANCE EVALUATION

We implemented the EGMP protocol using Global MobileSimulation (GloMoSim) [24] library, and compare it withODMRP [8] which is widely used and considered to be robustover a dynamic network, and the geographic multicastprotocol SPBM [20] which is designed to improve thescalability of position-based multicast. The SPBM is a quad-tree-based protocol as introduced in Section 2. ODMRP is amesh-based on-demand nongeographic multicast protocol,and takes a soft-state approach to maintain multicast groupmembers. A multicast source broadcasts a Join-Querymessages to the entire network periodically. An intermediatenode stores the source ID and the sequence number, andupdates its routing table with the node ID (i.e., backwardlearning) from which the message was received for thereverse path back to the source. A receiver creates andbroadcasts a Join Reply to its neighbors, with the next hopnode ID field filled by extracting information from its routingtable. The neighbor node whose ID matches the next hopnode ID of the message realizes that it is on the path to thesource and is part of the forwarding group. It then broadcastsits own Join Table built upon matched entries. This wholeprocess constructs (or updates) the routes from sources toreceivers and builds a mesh of nodes, the forwarding group.

The simulations were run with 400 nodes randomlydistributed in an area of 2;400 m� 2;400 m. The nodesmoved following the modified random waypoint mobilitymodel [25]. The moving speed of nodes are uniformly setbetween the minimum and maximum speed values whichare set as as 1 m/s (with pause time as 100 seconds) and20 m/s, respectively, except when studying the effect ofmobility. We set the MAC protocol and radio parametersaccording to the Lucent WaveLAN card, which operates at a

data rate 11 Mbps and radio frequency 2.4 GHz with anominal transmission range 250 m. IEEE 802.11b was used asthe MAC layer protocol. Each simulation lasted 500 simu-lation seconds. Each source sends CBR data packets at8 Kbps with packet length 512 bytes. The CBR flows start ataround 30 seconds so that the group membership manage-ment has time to initialize and stop at 480 seconds. Bydefault, there is one source, and one multicast group with100 members. A simulation result was gained by averagingover six runs with different seeds.

5.1 Parameters and Metrics

Table 4 lists the simulation parameters of EGMP withbeacon interval set as [13]. The simulations for ODMRP arebased on the codes carried with the simulator, with theparameters set as in [9]. We fixed several bugs in theGloMoSim codes which would prevent a forwarding groupnode from sending JOIN TABLES. The improvementdoubles the delivery ratio and reduces the control overheadof ODMRP. Additionally, we implemented SPBM inGloMoSim according to [20] and the ns2 codes providedby the authors with the same parameter settings except thatthe square size was set to 150 m so that the nodes in a squareare within each other’s transmission range. The number oflevels of the quad-tree changes accordingly with the squaresize and the network size we used. For packet forwarding inSPBM, different from the scheme described in [20], we usedthe square center as the destination position, whichimproves the delivery ratio of SPBM.

We focus on the studies of the scalability and efficiencyof the protocol under the dynamic environment and thefollowing metrics were used for the multicast perfor-mance evaluation:

1. Packet delivery ratio: The ratio of the number ofpackets received and the number of packets ex-pected to receive. Thus, for multicast packet deliv-ery, the ratio is equal to the total number of receivedpackets over the number of originated packets timesthe group size.

2. Normalized control overhead: The total number ofcontrol message transmissions divided by the totalnumber of received data packets. Each forwarding ofthe control message was counted as one transmis-sion. Different from ODMRP, EGMP, and SPBM arebased on some underlying geographic unicastrouting protocol which involves use of periodicbeacons. To provide more insight on the perfor-mance of different protocols, we measured both thetotal overhead (including multicast overhead andunicast overhead) and multicast overhead for EGMPand SPBM (represented as EGMP-multicast andSPBM-multicast).


Fig. 6. Cost analysis: (a) Protocol cost versus network size. (b) Protocolcost versus group size.

TABLE 4The Parameter Values for EGMP Simulations

3. Normalized data packet transmission overhead: The ratioof the total number of data packet transmissions andthe number of received data packets.

4. Joining delay: The average time interval between amember joining a group and its first receiving of thedata packet from that group. To obtain the joiningdelay, the simulations were rerun with the samesettings except that all the members joined groupsafter the source began sending data packets.

5.2 Simulation Results

We first compare the performance of ODMRP, SPBM, andEGMP with the variation of moving speed and nodedensity, we then study the scalability of the three protocolswith the change of group size and network size.

5.2.1 Effect of Moving Speed

It is critical and challenging for a multicast routingprotocol to maintain a good performance in the presenceof node mobility in an ad hoc network. We evaluate theprotocol performance by varying maximum moving speedfrom 5 to 40 m/s.

From Fig. 7a, the delivery ratios of all the protocolsreduce as mobility increases, while the delivery ratio ofODMRP drops much faster. At higher moving speed, as it ismore difficult to track the group membership and maintainthe routing path, more packets are lost. Although the meshstructure used in ODMRP is more robust than the generaltree structure, the mesh structure built through backlearning is likely to become invalid as nodes move. In allthe mobility cases, the geographic multicast protocolsEGMP and SPBM have much higher delivery ratios. Thisis as expected. As geographic forwarding only requireslocal topology information and is more robust to thenetwork topology change, both protocols achieve morereliable packet delivery by taking advantage of geographicunicast for data packet transmissions. The use of virtualzone in EGMP further increases its membership manage-ment reliability and stability.

The multicast and the total control overhead of EGMPare seen to be lower than those of ODMRP and SPBM atdifferent moving speeds (Fig. 7b). SPBM is seen to have

more than six times overhead of the other two protocolsdue to its use of periodic local and network-wide floodingin its membership management. In EGMP, the membershipmanagement is based on the efficient local zone structureand networkwide tree structure without involving periodicnetworkwide flooding, which greatly improves the effi-ciency and scalability of the protocol. As expected, thecontrol overheads of all the protocols increase at highermobility. In EGMP, when nodes move faster, there aremore frequent zone leader changes and zone crossings,which triggers more rejoining processes. The increase ofthe normalized control overhead of all the protocols is alsodue to the reduced packet receiving under high mobility.The overhead due to the beacon messages in underlyingunicast is seen to be smaller in SPBM, while the beaconscontribute to most of the control overhead of EGMP. Thereason is as follows: GPSR [13], the underlying unicastprotocol of SPBM and EGMP, adopts promiscuous beaconsto reduce the beaconing overhead, i.e., data packets alsoserve as beacons by carrying the position information ofthe forwarders. The sending of the next beacon messagewill be delayed once a node forwards a packet carrying itsposition. To further reduce beaconing overhead, in oursimulation, some multicast control messages in SPBM andEGMP also carry the positions of the forwarding nodes. AsSPBM has a larger number of multicast control messagesand a higher number of data packet transmissions (Figs. 7band 7c), more beacon messages in its underlying geo-graphic unicast are suppressed.

Both EGMP and SPBM have higher data packet transmis-sion overheads than ODMRP as seen in Fig. 7c. Instead offorwarding packets through hop-by-hop broadcasting asthat in ODMRP, the multicast forwardings in EGMP andSPBM are through hierarchical structures, leading to moredata transmissions. However, between the two geographicmulticast protocols, EGMP has a much lower packettransmission overhead as a result of the stronger aggrega-tion of packet forwardings through the efficient tree-basedtransmissions. On the other hand, the packet transmissionoverhead of SPBM is seen to rise quickly when movingspeed increases. At a higher node moving speed, themembership change of a low-layer square in SPBM cannotbe distributed quickly to the upper layer, and a lot ofpackets are forwarded to the squares with outdatedmembership information, which leads to a higher packettransmission overhead.

In EGMP, when a node wants to join a group, it will startthe joining process immediately, and with the efficient treestructure assumed, the nodes can join the multicast structurevery fast as shown in Fig. 7d. SPBM is seen to have thelargest joining delay most of the time. As described inSection 2, with the use of periodic multilevel membershipupdate mechanism, it may take a long time for a bottom-level square of SPBM to distribute its membership change tothe upmost level. In ODMRP, the mesh structure is built onthe source’s demand, and a source sends out a JOIN QUERYmessage periodically to refresh the mesh structure. If thenodes want to join a group, they need to wait until the nextmesh refreshing period. The refreshing interval is set as 3seconds according to [9]. From the figure, the average joiningdelay of ODMRP drops with the increase of mobility, as thehigher moving speed helps a member to connect to thesource more quickly in the nongeographic mesh structure.


Fig. 7. Performance versus maximum moving speed.

In summary, both geometric multicast protocols EGMPand SPBM have similar delivery ratios and are morerobust to the mobility than ODMRP, and achieve morethan 20 percent higher delivery ratios than ODMRP at thehighest mobility tested. EGMP has the minimum controloverhead and group joining delay under all the mobility.The control overhead of ODMRP and EGMP are compar-able, while the overhead of SPBM is about six times theiroverhead. Similarly, the joining delay of SPBM is also sixtimes that of EGMP. The joining delay of ODMRP reduceswith the increase of mobility, and is still three times that ofEGMP at the highest mobility. The increase of mobilityalso leads to the significant increase of transmissions ofSPBM, as the membership change of a low-layer square inSPBM cannot be distributed quickly to the upper layerwhich results in outdated membership information andhigher packet transmission overhead.

5.2.2 Effect of Node Density

Geographic routing is sensitive to the node density andperforms better in a dense network. Node density is alsoclosely related to the performance of zone-based protocols.When the node density is low, there will be more emptyzones, which will negatively affect the performance. InEGMP, specific design has been made to minimize theimpact of empty zone on the performance of multicasting.

As expected, both EGMP and SPBM have higher deliveryratios at a higher node density (Fig. 8a). The delivery ratios ofall three protocols are lower when the network is sparse andmore group members are disconnected from the networkgraph, while the delivery ratios of EGMP and SPBM go upquickly as the network density increases. However, whenthe node density is higher than 50 nodes=km2, the increase ofdelivery ratio becomes slower, as there are more collisionsamong nodes and hence more packet loss.

In Fig. 8b, the control overhead of SPBM rises quicklywith the increase of node density as more nodes areinvolved in the periodic multilevel flooding for the member-ship management. When the network is sparse, there is asmaller number of periodic beacons and thus a smallerunicast control overhead in both EGMP and SPBM. Whenthe network is very sparse, EGMP has a slightly higher

control overhead than that of ODMRP, as the underlyinggeographic unicast routing more frequently uses recoveryforwarding to recover from the local void when a nodecannot find a neighbor closer to the destination. A zone alsohas a higher probability of being empty, which results in ahigher tree maintenance overhead.

In geographic routing, the likelihood of using recoveryforwarding drops with the increase of network density, andthe data packet transmission overhead in SPBM reducesaccordingly (Fig. 8c). However, the transmission overheadsof both EGMP and ODMRP increase, and the overhead ofODMRP increases faster. In EGMP, the transmissionfollows a zone-based tree structure. Whenever a datapacket reaches an on-tree zone, it will be forwarded to theleader first, and more on-tree zones will lead to more datapacket forwarding and hence a higher packet transmissionoverhead. In a dense network, the number of empty zonesreduces and there is more opportunity for a tree branch tobe built between two neighboring zones, which increasesthe number of on-tree zones and forwarding overhead. Thepacket transmission overhead of ODMRP goes up becausethere are more nodes in the forwarding mesh.

For all the protocols, the disconnected topology graph ina sparse network leads to a longer joining delay (Fig. 8d).The followed slight increase of the joining delay at highnode density is due to more transmission collisions. Suchincrease is more obvious for SPBM since its higher controloverhead results in more collisions.

Overall, all the protocols perform better in a densernetwork. EGMP and SPBM have consistently higherdelivery ratios than that of ODMRP. SPBM has a signifi-cantly higher control overhead and joining delay in a densenetwork as a result of its periodic multilevel flooding ofmembership management message, while EGMP remainsto have the lowest delay as it allows group members to joinand leave the group immediately on demand. SPBM hasmore transmissions in a sparse network due to the morefrequent use of recovery forwarding of the underlyinggeometric unicast protocol, while the transmissions of bothEGMP and ODMRP increase at a higher node density, asEGMP has more on-tree zones and ODMRP has more nodesin the forwarding mesh.

5.2.3 Effect of the Group Size

Next, we evaluate the protocol performance with the groupsize varied from 10 to 200 members.

Fig. 9 demonstrates that EGMP can scale to a large groupsize and perform well with various group sizes. When thegroup size increases, the delivery ratios of ODMRP andSPBM rise. When more nodes join the multicast group, thehigher redundancy in the mesh structure of ODMRP willprovide more robust delivery paths, while the membershipof the squares in SPBM becomes more stable. In EGMP,when having a larger group size, a temporary disconnectionof the tree structure may affect a larger number of memberswith more packet losses, resulting in a slight reduction inthe delivery ratio. Overall, EGMP shows a more stableperformance with different group sizes, while ODMRP andSPBM rely on a higher number of group members tomaintain more stable multicast infrastructure and canperform poorly at a small group size.

In Fig. 9b, ODMRP and SPBM are seen to have very highmulticast control overheads when the group size is small, as


Fig. 8. Performance versus node density.

in ODMRP all the mobile nodes are involved in the periodicflooding of JOIN QUERY message while in SPBM theproactive control message flooding causes more unneces-sary overhead. While in EGMP, the multicast overheadremains very low at different group sizes and reduces as thegroup size increases. When more group members join themulticast group, there will be more control state aggrega-tion for membership management by a zone leader andmore member zones can share a tree branch. This confirmsthe efficiency of our zone-based tree structure. When thegroup size increases, the normalized control overheads ofall the protocols drop accordingly with more data packetsdelivered. When the group size of EGMP is smaller, theratio of the multicast overhead to the total control overheadis also smaller.

In Fig. 9c, the data packet transmission overheads of allthe protocols reduce when the group size increases as aresult of the higher aggregations of packet transmissions.ODMRP has a high packet transmission overhead when thegroup size is small, since as mentioned above its periodicnetworkwide flooding of data packets generates relativelyhigh normalized packet transmission overhead.

In Fig. 9d, the change of group size has different impactson the joining delay of the three protocols. For EGMP, as thegroup size increases, the later joined group members couldconnect to a closer multicast tree branch, which results inthe initial decrease of joining delay. The followed increaseof joining delay is due to more data packet transmissionsand collisions, and therefore it will take a longer time for amember to receive the first packet from the group. Thejoining delay of SPBM drops as the group size goes up,because the memberships of the squares become morestable when the group size is larger and the joining processof a node will trigger fewer levels of membership changesin the quad-tree. Relying on the periodic JOIN QUERYmessage to refresh the mesh structure for a node to join agroup, the group size does not have a significant impact onthe joining delay of ODMRP.

In summary, EGMP has high delivery ratios for all thegroup sizes, and it does not incur unnecessary controloverhead when there is no member management need in azone. In contrast, SPBM and ODMRP have much lowerdelivery ratios when the group sizes are small because SPBM

has less stable membership and ODMRP has less robustmesh paths. SPBM and ODMRP also have much highernormalized control overheads at smaller group sizes due totheir uses of periodic flooding messages regardless of thegroup size. The data transmission overheads for all the proto-cols reduce as the group size increases due to the aggrega-tions of packet transmissions. The group size has little impacton the joining delay of EGMP, while SPBM has a significantlyhigher joining delay when the network is sparse.

5.2.4 Effect of the Network Size

To study the scalability of the protocol with network size,we varied the network range from 1;500 m� 1;500 m to3;900 m� 3;900 m. The node density is kept as before, thusthe total number of nodes is varied from 156 nodes to1,056 nodes. Since the periodic local and networkwidemessage flooding in SPBM saturates the memory faster,we run simulations on SPBM with the network sizeincreasing up to only 3;300 m� 3;300 m with 756 nodes.

EGMP has a better scalability to the network size thanODMRP and SPBM as demonstrated in Fig. 10. The deliveryratios of ODMRP and SPBM drop faster than that of EGMPwith the increase of network size. When the network sizereaches 3;900 m� 3;900 m with 1,056 nodes, the differencebetween the delivery ratios of ODMRP and EGMP is morethan 55 percent.

As expected, all the protocols have higher controloverheads at a larger network size (Fig. 10b). For ODMRP,more nodes are involved in the periodic JOIN QUERYmessage flooding. For EGMP, a larger network range leadsto longer paths for the control messages at the upper tier.For the geographic-based unicast routing, more beaconswill be generated with a larger number of network nodes.The control overhead of SPBM, however, is seen to risemuch more sharply than those of EGMP and ODMRP, as aresult of the increase of quad-tree levels in SPBM and thecorresponding increase of periodic multilevel messageflooding. As the network size increases, due to the longerpacket forwarding paths, the total number of data packettransmissions of all the protocols also goes up (Fig. 10c).Compared to EGMP, SPBM has more than double thepacket transmissions in all the network sizes, and thedifference becomes more evident at larger network sizes.


Fig. 9. Performance versus group size.Fig. 10. Performance versus network size.

All three protocols also have longer joining delay whenthe network size increases as in Fig. 10d. The joining delayof ODMRP is significantly impacted by the network size, asboth its periodic networkwide flooding of JOIN QUERYand its broadcast-based packet forwarding will not per-form well. More data collisions during the flooding willresult in a longer waiting time for a group member toreceive the first data packet from the source, and a largernumber of packet loss as confirmed by the low deliveryratio in Fig. 10a. For SPBM, with the increase of the numberof the quad-tree levels, the membership change of a nodemay need to go through more levels to send out leading toa longer joining delay. The joining delay of EGMP onlyrises slightly, as a new member may need to connect to afarther away tree branch.

In summary, EGMP performs much better than SPBMand ODMRP in a large network, and has a significantlyhigher delivery ratio, lower control overhead, and lowerjoining delay due to its virtual-zone-based geometricmembership management and transmission infrastructures.

6 CONCLUSIONS

There is an increasing demand and a big challenge to designmore scalable and reliable multicast protocol over adynamic ad hoc network (MANET). In this paper, wepropose an efficient and scalable geographic multicastprotocol, EGMP, for MANET. The scalability of EGMP isachieved through a two-tier virtual-zone-based structure,which takes advantage of the geometric information togreatly simplify the zone management and packet forward-ing. A zone-based bidirectional multicast tree is built at theupper tier for more efficient multicast membership manage-ment and data delivery, while the intrazone management isperformed at the lower tier to realize the local membershipmanagement. The position information is used in theprotocol to guide the zone structure building, multicasttree construction, maintenance, and multicast packetforwarding. Compared to conventional topology-basedmulticast protocols, the use of location information inEGMP significantly reduces the tree construction andmaintenance overhead, and enables quicker tree structureadaptation to the network topology change. We alsodevelop a scheme to handle the empty zone problem,which is challenging for the zone-based protocols. Addi-tionally, EGMP makes use of geographic forwarding forreliable packet transmissions, and efficiently tracks thepositions of multicast group members without resorting toan external location server.

We make a quantitative analysis on the control overheadof the proposed EGMP protocol and our results indicatethat the per node cost of EGMP keeps relatively constantwith respect to the network size and the group size. We alsoperformed extensive simulations to evaluate the perfor-mance of EGMP. Compared to the classical protocolODMRP, both geometric multicast protocols SPBM andEGMP could achieve much higher delivery ratio in allcircumstances, with respect to the variation of mobility,node density, group size, and network range. However,compared to EGMP, SPBM incurs several times of controloverhead, redundant packet transmissions, and multicastgroup joining delay. Although SPBM is designed to bescalable to the group size, it has very low packet delivery

ratio when the group size is small without a stablemembership in each level of quad-tree square, and cannot

perform well under a large network size due to the use ofmultilevel networkwide flooding of control messages.

ODMRP takes advantage of broadcasting to achieve moreefficient packet forwarding, but the transmissions are muchmore unreliable due to its difficulty of maintaining

forwarding mesh under mobility, which leads to a lowerpacket delivery ratio. The multicast group joining delay ofODMRP is also much higher than that of EGMP.

Our results indicate that geometric information can beused to more efficiently construct and maintain multicaststructure, and to achieve more scalable and reliable multicast

transmissions in the presence of constant topology change ofMANET. Our simulation results demonstrate that EGMP has

high packet delivery ratio, and low control overhead andmulticast group joining delay under all cases studied, and isscalable to both the group size and the network size.

Compared to the geographic multicast protocol SPBM, ithas significantly lower control overhead, data transmission

overhead, and multicast group joining delay.

ACKNOWLEDGMENTS

Xin Wang’s research was supported by the US NationalScience Foundation (NSF) under grant numbers CNS-0751121 and CNS-0628093. Yuanyuan Yang’s research was

supported by the US NSF under grant numbers ECCS-0801438 and ECS-0427345 and US ARO under grant number

W911NF-09-1-0154.

REFERENCES

[1] H. Kopka and P.W. Daly, A Guide to LaTeX, third ed. Addison-Wesley, 1999.

[2] L. Ji and M.S. Corson, “Differential Destination Multicast: AMANET Multicast Routing Protocol for Small Groups,” Proc. IEEEINFOCOM, Apr. 2001.

[3] E.M. Royer and C.E. Perkins, “Multicast Operation of the Ad HocOn-Demand Distance Vector Routing Protocol,” Proc. ACM/IEEEMobiCom, pp. 207-218, Aug. 1999.

[4] C. Wu, Y. Tay, and C.-K. Toh, “Ad Hoc Multicast Routing ProtocolUtilizing Increasing Id-Numbers (AMRIS) Functional Specifica-tion,” Internet draft, Nov. 1998.

[5] X. Zhang and L. Jacob, “Multicast Zone Routing Protocol inMobile Ad Hoc Wireless Networks,” Proc. Local Computer Networks(LCN ’03), Oct. 2003.

[6] C.-C. Chiang, M. Gerla, and L. Zhang, “Forwarding GroupMulticast Protocol (FGMP) for Multihop Mobile Wireless Net-works,” ACM J. Cluster Computing, special issue on mobilecomputing, vol. 1, no. 2, pp. 187-196, 1998.

[7] J.J. Garcia-Luna-Aceves and E. Madruga, “The Core-AssistedMesh Protocol,” IEEE J. Selected Areas in Comm., vol. 17, no. 8,pp. 1380-1394, Aug. 1999.

[8] M. Gerla, S.J. Lee, and W. Su, “On-Demand Multicast RoutingProtocol (ODMRP) for Ad Hoc Networks,” Internet draft, draft-ietf-manet-odmrp-02.txt, 2000.

[9] S. Lee, W. Su, J. Hsu, M. Gerla, and R. Bagrodia, “A PerformanceComparison Study of Ad Hoc Wireless Multicast Protocols,” Proc.IEEE INFOCOM, 2000.

[10] E. Kaplan, Understanding GPS. Artech House, 1996.[11] X. Xiang, Z. Zhou, and X. Wang, “Self-Adaptive On Demand

Geographic Routing Protocols for Mobile Ad Hoc Networks,”Proc. IEEE INFOCOM, May 2007.

[12] P. Bose, P. Morin, I. Stojmenovic, and J. Urrutia, “Routing withGuaranteed Delivery in Ad Hoc Wireless Networks,” Proc.Workshop Discrete Algorithms and Methods for Mobile Computingand Comm. (DialM ’99), Aug. 1999.


[13] B. Karp and H.T. Kung, “Greedy Perimeter Stateless Routing forWireless Networks,” Proc. ACM/IEEE MobiCom, pp. 243-254, Aug.2000.

[14] F. Kuhn, R. Wattenhofer, Y. Zhang, and A. Zollinger, “GeometricAd-Hoc Routing: Of Theory and Practice,” Proc. Int’l Symp.Principles of Distributed Computing (PODC), 2003.

[15] J. Li et al., “A Scalable Location Service for Geographic Ad HocRouting,” Proc. ACM/IEEE MobiCom, pp. 120-130, 2000.

[16] S. Giordano and M. Hamdi, “Mobility Management: The VirtualHome Region,” technical report, Oct. 1999.

[17] S. Basagni, I. Chlamtac, and V.R. Syrotiuk, “Location Aware,Dependable Multicast for Mobile Ad Hoc Networks,” ComputerNetworks, vol. 36, nos. 5-6, pp. 659-670, Aug. 2001.

[18] K. Chen and K. Nahrstedt, “Effective Location-Guided TreeConstruction Algorithms for Small Group Multicast in MANET,”Proc. IEEE INFOCOM, pp. 1180-1189, 2002.

[19] M. Mauve, H. Fubler, J. Widmer, and T. Lang, “Position-BasedMulticast Routing for Mobile Ad-Hoc Networks,” Proc. ACMMobiHoc, poster section, June 2003.

[20] M. Transier, H. Fubler, J. Widmer, M. Mauve, and W. Effelsberg,“A Hierarchical Approach to Position-Based Multicast for MobileAd-Hoc Networks,” Wireless Networks, vol. 13, no. 4, pp. 447-460,Aug. 2007.

[21] B. Karp, “Greedy Perimeter Stateless Routing (GPSR),” http://www.icir.org/bkarp/gpsr/gpsr.html, 2010.

[22] S.-C. M. Woo and S. Singh, “Scalable Routing Protocol for Ad HocNetworks,” Wireless Networks, vol. 7, pp. 513-529, 2001.

[23] A. Ballardie, “Core Based Trees (CBT) Multicast RoutingArchitecture,” RFC 2201, Sept. 1997.

[24] University of California, Los Angeles Mobile Systems Laboratory,“GloMoSim,” http://pcl.cs.ucla.edu/projects/glomosim, 2010.

[25] J. Yoon, M. Liu, and B. Noble, “Random Waypoint ConsideredHarmful,” Proc. IEEE INFOCOM, vol. 2, no. 4, Apr. 2003.

[26] C. Gui and P. Mohapatra, “Scalable Multicasting for MobileAd Hoc Networks,” Proc. IEEE INFOCOM, Mar. 2004.

[27] C. Gui and P. Mohapatra, “Overlay Multicast for MANETs UsingDynamic Virtual Mesh,” Wireless Networks, vol. 13, pp. 77-91, Jan.2007.

[28] V. Devarapalli and D. Sidhu, “MZR: A Multicast Protocol forMobile Ad Hoc Networks,” Proc. IEEE Int’l Conf. Comm. (ICC ’01),2001.

[29] S. Wu and K.S. Candan, “GMP: Distributed Geographic MulticastRouting in Wireless Sensor Networks,” Proc. 26th IEEE Int’l Conf.Distributed Computing Systems (ICDCS ’06), 2006.

[30] S.M. Das, H. Pucha, and Y.C. Hu, “Distributed Hashing forScalable Multicast in Wireless Ad Hoc Network,” IEEE Trans.Parallel and Distributed Systems, vol. 19, no. 3, pp. 347-362, Mar.2008.

[31] Y.B. Ko and N. Vaidya, “Geocasting in Mobile Ad Hoc Networks:Location Based Multicast Algorithms,” Proc. Second IEEE WorkshopMobile Computing Systems and Applications (WMCSA), 1999.

[32] W. Liao, Y. Tseng, K.-L. Lo, and J. Sheu, “Geogrid: A GeocastingProtocol for Mobile Ad Hoc Networks Based on Grid,” J. InternetTechnology, vol. 1, no. 2, pp. 23-32, 2000.

[33] X. Xiang and X. Wang, “An Efficient Geographic MulticastProtocol for Mobile Ad Hoc Networks,” Proc. IEEE Int’l Symp.World of Wireless, Mobile and Multimedia Networks (WoWMoM),June 2006.

[34] T. Camp and Y. Liu, “An Adaptive Mesh-Based Protocol forGeocast Routing,” J. Parallel and Distributed Computing, vol. 63,no. 2, pp. 196-213, 2003.

Xiaojing Xiang received the BS and MSdegrees in computer science from NanjingUniversity, China, and the PhD degree incomputer science and engineering from theState University of New York at Buffalo, NewYork. She is currently with Microsoft Corpora-tion, Redmond, Washington. Her research inter-ests include protocol design and analysis inmobile ad hoc networks, architecture design forservice provisioning, routing and cross-layer

protocol design in computer networks, pervasive computing andcommunications, as well as next generation Internet technologies. Sheis a member of the IEEE.

Xin Wang received the BS and MS degrees intelecommunications engineering and wirelesscommunications engineering from the BeijingUniversity of Posts and Telecommunications,China, and the PhD degree in electrical andcomputer engineering from Columbia University,New York. She is currently an assistant profes-sor in the Department of Electrical and ComputerEngineering with the State University of NewYork at Stony Brook. Before joining Stony Brook

University, she was a member of technical staff with Bell Labs Research,Lucent Technologies, New Jersey, and an assistant professor in theDepartment of Computer Science and Engineering at the StateUniversity of New York at Buffalo. Her research interests includewireless networks and communications, mobile and distributed comput-ing, and wireless services. She is a member of the IEEE.

Yuanyuan Yang received the BEng and MSdegrees in computer science and engineeringfrom Tsinghua University, Beijing, China, andthe MSE and PhD degrees in computer sciencefrom Johns Hopkins University, Baltimore, Mary-land. She is a professor of computer engineeringand computer science at Stony Brook University,New York, and the director of Communicationsand Devices Division at New York State Centerof Excellence in Wireless and Information

Technology (CEWIT). Her research interests include wireless networks,optical networks, high-speed networks, and parallel and distributedcomputing systems. She has published more than 200 papers in majorjournals and refereed conference proceedings and holds six US patentsin these areas. She is currently an associate editor for the IEEETransactions on Computers and is a subject area editor for the Journalof Parallel and Distributed Computing. She has served as an associateeditor for the IEEE Transactions on Parallel and Distributed Systems.She is a fellow of the IEEE.

. For more information on this or any other computing topic,please visit our Digital Library at www.computer.org/publications/dlib.


Date post:	19-Aug-2019
Category:	Documents
Upload:	lamminh
View:	214 times
Download:	0 times

544 IEEE TRANSACTIONS ON MOBILE COMPUTING, VOL. 10, NO....

Documents