The document proposes a new multicast protocol called Efficient Geographic Multicast Protocol (EGMP) to support efficient and scalable multicasting over mobile ad hoc networks. EGMP uses a virtual zone-based structure for scalable group membership management. It constructs a network-wide zone-based bi-directional tree to achieve more efficient membership management and multicast delivery. Several strategies are introduced to improve efficiency, including using zone depth to build an optimal tree structure and integrating location search with membership management. Simulation results show EGMP has high delivery ratio and low overhead under different scenarios, and is scalable to both group size and network size.

1. IEEE IEEE TRANSACTIONS ON MOBILE COMPUTING,
TRANSACTIONS ON MOBILE COMPUTING VOL. 10, NO. 4, April 2011 1
Supporting Efficient and Scalable Multicasting
over 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 (MANET). 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
network-wide zone-based bi-directional 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 I NTRODUCTION scalability due to the overhead incurred for route searching,
group membership management, and creation and maintenance
There are increasing interests and importance in support-
of the tree/mesh structure over the dynamic MANET.
ing group communications over Mobile Ad Hoc Networks
For MANET unicast routing, geographic routing protocols
(MANETs). Example applications include the exchange of
[11]–[14] have been proposed in recent years for more scalable
messages among a group of soldiers in a battlefield, commu-
and robust packet transmissions. The existing geographic
nications among the firemen in a disaster area, and the support
routing protocols generally assume mobile nodes are aware
of multimedia games and teleconferences. With a one-to-many
of their own positions through certain positioning system
or many-to-many transmission pattern, multicast is an efficient
(e.g., GPS), and a source can obtain the destination position
method to realize group communications. However, there is a
through some type of location service [15] [16]. In [13], an
big challenge in enabling efficient multicasting over a MANET
intermediate node makes its forwarding decisions based on
whose topology may change constantly.
the destination position inserted in the packet header by the
Conventional MANET multicast protocols [3]–[8], [28] can source and the positions of its one-hop neighbors learned
be ascribed into two main categories, tree-based and mesh- from the periodic beaconing of the neighbors. By default, the
based. However, due to the constant movement as well as packets are greedily forwarded to the neighbor that allows for
frequent network joining and leaving from individual nodes, the greatest geographic progress to the destination. When no
it is very difficult to maintain the tree structure using these such a neighbor exists, perimeter forwarding is used to recover
conventional tree-based protocols (e.g., MAODV [3], AMRIS from the local void, where a packet traverses the face of the
[4], MZRP [5], MZR [28]). The mesh-based protocols (e.g., planarized local topology subgraph by applying the right-hand
FGMP [6], Core-Assisted Mesh protocol [7], ODMRP [8]) rule until the greedy forwarding can be resumed.
are proposed to enhance the robustness with the use of Similarly, to reduce the topology maintenance overhead
redundant paths between the source and the destination pairs. and support more reliable multicasting, an option is to make
Conventional multicast protocols generally do not have good use of the position information to guide multicast routing.
However, there are many challenges in implementing an
• Xin Wang’s research was supported by U.S. NSF under grant numbers efficient and scalable geographic multicast scheme in MANET.
CNS-0751121 and CNS-0628093. Yuanyuan Yang’s research was supported
by U.S. NSF under grant numbers ECCS-0801438 and ECS-0427345 and
For example, in unicast geographic routing, the destination
US ARO under grant number W911NF-09-1-0154. position is carried in the packet header to guide the packet
forwarding, while in multicast routing, the destination is a
• Xiaojing Xiang is currently with Microsoft Corporation, Redmond, Wash-
ington, USA; Xin Wang and Yuanyuan Yang are with Stony Brook Uni-
group of members. A straight-forward way to extend the
versity, Stony Brook, New York, USA; email: xwang@ece.sunysb.edu, geography-based transmission from unicast to multicast is to
yang@ece.sunysb.edu put the addresses and positions of all the members into the
packet header, however, the header overhead will increase

2. IEEE TRANSACTIONS ON MOBILE COMPUTING
IEEE TRANSACTIONS ON MOBILE COMPUTING, VOL. 10, NO. 4, April 2011 2
significantly as the group size increases, which constrains the analysis results indicate that the cost of the protocol de-
application of geographic multicasting only to a small group fined as the per-node control overhead remains constant
[17]–[19]. Besides requiring efficient packet forwarding, a regardless of the network size and the group size. Our
scalable geographic multicast protocol also needs to efficiently simulation studies confirm the scalability and efficiency
manage the membership of a possibly large group, obtain the of the proposed protocol.
positions of the members and build routing paths to reach We organize the rest of this paper as follows. In Section 2,
the members distributed in a possibly large network terrain. we discuss some related work. We present a detailed design of
The existing small-group-based geographic multicast proto- the EGMP protocol in Section 3, and quantitatively analyze
cols [17]–[19] normally address only part of these problems. the per-node cost of EGMP in Section 4. Finally, we give
In this work, we propose an efficient geographic multicast our simulation results in Section 5 and conclude the paper in
protocol, EGMP, which can scale to a large group size and Section 6.
large network size. The protocol is designed to be com-
prehensive and self-contained, yet simple and efficient for
more reliable operation. Instead of addressing only a specific 2 R ELATED W ORK
part of the problem, it includes a zone-based scheme to In this section, we first summarize the basic procedures
efficiently handle the group membership management, and assumed in conventional multicast protocols, and then intro-
takes advantage of the membership management structure to duce a few geographic multicast algorithms proposed in the
efficiently track the locations of all the group members without literature.
resorting to an external location server. The zone structure Conventional topology-based multicast protocols include
is formed virtually and the zone where a node is located tree-based protocols (e.g., [3]–[5], [28]) and mesh-based pro-
can be calculated based on the position of the node and tocols (e.g., [6], [8]). Tree-based protocols construct a tree
a reference origin. In topology-based cluster construction, a structure for more efficient forwarding of packets to all the
cluster is normally formed around a cluster leader with nodes group members. Mesh-based protocols expand a multicast
one hop or k-hop away, and the cluster will constantly change tree with additional paths which can be used to forward
as network topology changes. In contrast, there is no need to packets when some of the links break. Although efforts were
involve a big overhead to create and maintain the geographic made to develop more scalable topology-aware protocols [7],
zones proposed in this work, which is critical to support the topology-based multicast protocols are generally difficult
more efficient and reliable communications over a dynamic to scale to a large network size, as the construction and
MANET. By making use of the location information, EGMP maintenance of the conventional tree or mesh structure involve
could quickly and efficiently build packet distribution paths, high control overhead over a dynamic network. The work in
and reliably maintain the forwarding paths in the presence [26], [27] attempts to improve the stateless multicast protocol
of network dynamics due to unstable wireless channels or [2], which allows it a better scalability to group size. In
frequent node movements. contrast, EGMP uses a location-aware approach for more
In summary, our contributions in this work include: reliable membership management and packet transmissions,
1) Making use of the position information to design a and supports scalability for both group size and network size.
scalable virtual-zone-based scheme for efficient mem- As the focus of our paper is to improve the scalability of
bership management, which allows a node to join and location-based multicast, a comparison with topology-based
leave a group quickly. Geographic unicast is enhanced protocols is out of the scope of this work. However, we note
to handle the routing failure due to the use of estimated that at the similar mobility and system set-up, the delivery
destination position with reference to a zone and applied ratio of [26] is much lower than that of EGMP, and the
for sending control and data packets between two entities delivery ratio in [27] varies significantly as the group size
so that transmissions are more robust in the dynamic changes. In addition, topology-based routing by nature is more
environment. vulnerable to mobility and long path transmission, which
2) Supporting efficient location search of the multicast prevents topology-based protocols from scaling to a large
group members, by combining the location service with network size.
the membership management to avoid the need and Besides the need of managing group membership as well
overhead of using a separate location server. as constructing and maintaining a multicast structure, a geo-
3) Introducing an important concept zone depth, which is graphic multicast protocol also requires a location service [15]
efficient in guiding the tree branch building and tree [16] to obtain the positions of the members. The geographic
structure maintenance, especially in the presence of node multicast protocols presented in [17], [18] and [19] need to
mobility. With nodes self-organizing into zones, zone- put the information of the entire tree or all the destinations
based bi-directional-tree-based distribution paths can be into packet headers, which would create a big header overhead
built quickly for efficient multicast packet forwarding. when the group size is large and constrain these protocols to be
4) Addressing the empty zone problem, which is critical used only for small groups. In DSM [17], each node floods its
in a zone-based protocol, through the adaption of tree location in the network. A source constructs a Steiner tree and
structure. encodes the multicast tree into each packet, and delivers the
5) Evaluating the performance of the protocol through packet by using source routing. LGT [18] requires each group
quantitative analysis and extensive simulations. Our member to know the locations of all other group members, and

3. IEEE TRANSACTIONS MOBILE COMPUTING
IEEE TRANSACTIONS ON ON MOBILE COMPUTING, VOL. 10, NO. 4, April 2011 3
proposes two overlay multicast trees: a bandwidth-minimizing
LGS tree and a delay-minimizing LGK tree. In PBM [19],
a multicast source node finds a set of neighboring, next-hop
nodes and assigns each packet destination to one next-hop
node. The next-hop nodes, in turn, repeat the process. Thus, no
global distribution structure is necessary. GMP in [29] attempts
to build a more efficient multicast tree through a centralized
calculation for tree construction, and is also more applicable
for a smaller group. The focus of EGMP, however, is to
improve the scalability and efficiency of geometric multicast. Fig. 1: Zone structure and multicast session example.
The HRPM [30] and SPBM [20] are more related to our
work, as they also support hierarchical group management. be generated when the network size increases as a result
HRPM consists of two key design ideas: 1) hierarchical of membership flooding. With this proactive and periodic
decomposition of a large group into a hierarchy of recursively membership updating scheme, the membership change of a
organized manageable-sized subgroups and 2) the use of node may need to go through L levels to make it known to the
distributed geographic hashing to construct and maintain such whole network, which leads to a long multicast group joining
a hierarchy. Although it is interesting to apply hashing to time. Instead of using multiple levels of flooding for group
find the rendezvous point (RP) for the network to store and membership management, EGMP uses more efficient zone-
retrieve state information, the hashed location is obtained with based tree structure to allow nodes to quickly join and leave the
the assumption of the network size, which is difficult for a group. EGMP introduces root zone and zone depth to facilitate
dynamic network. Also, as the hashed location is virtual, it is simple and more reliable group membership management.
possible that the nodes could not find the (consistent) RP. This EGMP does not use any periodic network-wide flooding, thus
can happen when a message (e.g., Join) reaches a node whose it can be scalable to both the group size and network size.
transmission range covers the virtual point, but the node is Finally, a lot of work have been done on geocasting [31],
neither the one closest to the RP, nor aware of the node (which [32], [34]. Different from general multicasting, in which
may be out of its transmission range) closest to the RP. The the destinations are a group of receivers, the destination of
mobility of nodes will introduce additional challenge to the geocasting is one or multiple geographic regions (squares are
protocol, which may not only result in frequent RP handoff, normally defined). When packets reach the destined region,
but also increase the chance of RP search inconsistency and they will be sent to the nodes in the region through flooding
failure. Additionally, requiring a node to contact RP first for or other methods. There is no need of forming multicast
a Join will increase joining delay. In contrast, EGMP does infrastructure to deliver packets to group members that may
not make any assumption of the network size in advance, and distribute widely in the whole network domain and change
the change of the membership of a zone does not need to be their positions as nodes move.
sent to a far-away RP but only needs to be updated locally. In [33], we proposed an efficient and robust geographic
Instead of using one RP as a core for group membership multicast protocol for MANET. In this paper, we further
management, which may lead to a point of failure, EGMP introduce zone-supported geographic forwarding to reduce
introduces the root zone which is much more stable than a the routing failure, and provide mechanism to handle zone
single point, and manages group membership more efficiently partitioning. In addition, we introduce a path optimization
within the local range. Instead of using the overlay-based process to handle multiple paths, and provide a detailed cost
multiple unicast transmissions, EGMP takes advantage of the analysis to demonstrate the scalability of the proposed routing
promiscuous mode transmission to forward packets along more scheme.
efficient transmission paths. We did not directly compare our
work with HRPM, as we do not know the hashing algorithm 3 E FFICIENT G EOGRAPHIC M ULTICAST P RO -
used and a different RP distribution scheme would lead to TOCOL
different performance. However, we evaluated the performance
In this section, we will describe the EGMP protocol in details.
of EGMP using a much larger default network size, which
We first give an overview of the protocol and introduce the
is known to have much more challenge to ensure reliable
notations to be used in the rest of the paper in Section
multicast transmissions than a smaller network.
3.1. In Sections 3.2 and 3.3, we present our designs for the
In SPBM [20], the network terrain is divided into a quad-
construction of zone structure and the zone-based geographic
tree with L levels. The top level is the whole network and the
forwarding. Finally, in Sections 3.4, 3.5 and 3.6, we introduce
bottom level is constructed by basic squares. Each higher level
our mechanisms for multicast tree creation, maintenance and
is constructed by larger squares with each square covering
multicast packet delivery.
four smaller squares at the next lower level. All the nodes
in a basic square are within each other’s transmission range.
At each level, every square needs to periodically flood its 3.1 Protocol Overview
membership into its upper level square. Such periodic flooding EGMP supports scalable and reliable membership manage-
is repeated for every two neighboring levels and the top level ment and multicast forwarding through a two-tier virtual-
is the whole network region. Significant control overhead will zone-based structure. At the lower layer, in reference to

4. IEEETRANSACTIONS ON MOBILE COMPUTING
IEEE TRANSACTIONS ON MOBILE COMPUTING, VOL. 10, NO. 4, April 2011 4
a pre-determined virtual origin, the nodes in the network zone center: For a zone with ID (a,b), the position of its
self-organize themselves into a set of zones as shown in center (xc , yc ) can be calculated as: xc = x0 + (a + 0.5) × r,
Fig. 1, and a leader is elected in a zone to manage the yc = y0 + (b + 0.5) × r. A packet destined to a zone will be
local group membership. At the upper layer, the leader serves forwarded towards the center of the zone.
as a representative for its zone to join or leave a multicast zLdr: Zone leader. A zLdr is elected in each zone for
group as required. As a result, a network-wide zone-based managing the local zone group membership and taking part
multicast tree is built. For efficient and reliable management in the upper tier multicast routing.
and transmissions, location information will be integrated tree zone: The zones on the multicast tree. The tree zones are
with the design and used to guide the zone construction, responsible for the multicast packet forwarding. A tree zone
group membership management, multicast tree construction may have group members or just help forward the multicast
and maintenance, and packet forwarding. The zone-based tree packets for zones with members.
is shared for all the multicast sources of a group. To further root zone: The zone where the root of the multicast tree is
reduce the forwarding overhead and delay, EGMP supports located.
bi-directional packet forwarding along the tree structure. That zone depth: The depth of a zone is used to reflect its distance
is, instead of sending the packets to the root of the tree first, a to the root zone. For a zone with ID (a, b), its depth is:
source forwards the multicast packets directly along the tree. depth = max(|a0 − a|, |b0 − b|),
At the upper layer, the multicast packets will flow along the
where (a0 , b0 ) is the root-zone ID. For example, in Fig. 1,
multicast tree both upstream to the root zone and downstream
the root zone has depth zero, the eight zones immediately
to the leaf zones of the tree. At the lower layer, when an on-
surrounding the root zone have depth one, and the outer seven
tree zone leader receives the packets, it will send them to the
zones have depth two.
group members in its local zone.
In EGMP, the zone-structure is virtual and calculated based
Many issues need to be addressed to make the protocol
on a reference point. Therefore, the construction of zone struc-
fully functional and scalable. The issues related to zone
ture does not depend on the shape of the network region, and it
management include: the schemes for more efficient and robust
is very simple to locate and maintain a zone. The zone is used
zone construction and maintenance, the strategies for election
in EGMP to provide location reference and support lower-
and maintenance of a zone leader with minimum overhead,
level group membership management. A multicast group can
zone partitioning as a result of severe wireless channels or
cross multiple zones. With the introduction of virtual zone,
signal blocking, potential packet loss when multicast members
EGMP does not need to track individual node movement but
move across zones. The issues related to packet forwarding
only needs to track the membership change of zones, which
include: the efficient building of multicast paths with the
significantly reduces the management overhead and increases
zone structure, the handling of empty zone problem, the
the robustness of the proposed multicast protocol. We choose
efficient tree structure maintenance during node movements,
to design the zone without considering node density so it
the reliable transmissions of control and multicast data packets,
can provide more reliable location reference and membership
and obtaining location information to facilitate our geometric
management in a network with constant topology changes.
design without resorting to an external location server.
For the convenience of presentation, we first introduce the
terminologies used in the paper. In EGMP, we assume every 3.2 Neighbor Table Generation and Zone Leader
node is aware of its own position through some positioning Election
system (e.g., GPS [10]) or other localization schemes. The For efficient management of states in a zone, a leader is
forwarding of data packets and most control messages is elected with minimum overhead. As a node employs periodic
based on the geographic unicast routing protocol GPSR [13] BEACON broadcast to distribute its position in the underneath
described in Section 1. EGMP, however, does not depend on geographic unicast routing [13], to facilitate leader election
a specific geographic unicast protocol. and reduce overhead, EGMP simply inserts in the BEACON
Some of the notations to be used are: message a flag indicating whether the sender is a zone leader.
√
zone: The network terrain is divided into square zones as With zone size r ≤ rt / 2, a broadcast message will be
shown in Fig. 1. received by all the nodes in the zone. To reduce the beacon-
r: Zone size, the length of a side of the zone square. The
√ ing overhead, instead of using fixed-interval beaconing, the
zone size is set to r ≤ rt / 2, where rt is the transmission beaconing interval for the underneath unicast protocol will be
range of the mobile nodes. To reduce intra-zone management adaptive. A non-leader node will send a beacon every period of
overhead, the intra-zone nodes can communicate directly with Intvalmax or when it moves to a new zone. A zone leader has
each other without the need of any intermediate relays. to send out a beacon every period of Intvalmin to announce
zone ID: The identification of a zone. A node can calculate its leadership role.
its zone ID (a, b) from its position coordinates (x, y) as: a = A node constructs its neighbor table without extra signaling.
[ x−x0 ], b = [ y−y0 ], where (x0 , y0 ) is the position of the virtual
r r When receiving a beacon from a neighbor, a node records the
origin, which can be a known reference location or determined node ID, position and f lag contained in the message in its
at network setup time. A zone is virtual and formulated in neighbor table. Table 1 shows the neighbor table of node 18 in
reference to the virtual origin. For simplicity, we assume all Fig. 1. The zone ID of the sending node can be calculated from
the zone IDs are positive. its position, as discussed earlier. To avoid routing failure due to

5. IEEETRANSACTIONS ON MOBILE COMPUTING
IEEE TRANSACTIONS ON MOBILE COMPUTING, VOL. 10, NO. 4, April 2011 5
4
outdated topology information, an entry will be removed if not 10
Number of lost packets
Number of lost packets
EGMP_non_zonemode
refreshed within a period T imeoutN T or the corresponding EGMP_forward
neighbor is detected unreachable by the MAC layer protocol. 3 10
3
10
TABLE 1: The neighbor table of node 18 in Fig. 1.
SPBM_forward
EGMP_forward
nodeID position flag zone ID 10
2
30 40 50 60 70 80 90
10
2
30 40 50 60 70 80 90
16 (x16 , y16 ) 1 (1, 1) 2
Node density (nodes/km )
2
Node density (nodes/km )
1 (x1 , y1 ) 0 (1, 1)
7 (x7 , y7 ) 1 (0, 1) (a) (b)
13 (x13 , y13 ) 1 (1, 2)
Fig. 2: Impact of forwarding strategies.
A zone leader is elected through the cooperation of nodes
and maintained consistently in a zone. When a node appears in Fig. 1, node 7 is the only node in zone (0, 1), while node
in the network, it sends out a beacon announcing its existence. 18 in zone (1, 1) is closest to the center of zone (0, 1). When
Then it waits for an Intvalmax period for the beacons from node 16 sends a packet to zone (0, 1) with its center as the
other nodes. Every Intvalmin a node will check its neighbor destination, the underlying geographic unicast protocol (for
table and determine its zone leader under different cases: 1) example, GPSR [13] described in Section 1) will forward the
The neighbor table contains no other nodes in the same zone, packet to node 18 greedily as it is closer to the destination. As
it will announce itself as the leader. 2) The flags of all the node 18 cannot find a neighbor closer to the center of zone
nodes in the same zone are unset, which means that no node (0, 1) than itself, the perimeter mode [13] may be used to
in the zone has announced the leadership role. If the node is continue the forwarding. This still cannot guarantee the packet
closer to the zone center than other nodes, it will announce to arrive at node 7, as the destination is a virtual reference
its leadership role through a beacon message with the leader point. Such a problem is neglected by the previous geographic
flag set. 3) More than one node in the same zone have their protocols that use a region as destination (e.g., [20]).
leader flags set, the one with the highest node ID is elected. To avoid this problem, we introduce a zone forwarding
4) Only one of the nodes in the zone has its flag set, then the mode in EGMP when the underlying geographic forwarding
node with the flag set is the leader. fails. Only when the zone mode also fails, the packet will be
dropped. In zone mode, a sender node searches for the next
hop to the destination based on its neighbor table, which can
3.3 Zone-supported Geographic Forwarding more accurately track the local network topology. The node
With a zone structure, the communication process includes selects as its next hop the neighboring node whose zone is the
an intra-zone transmission and an inter-zone transmission. In closest to the destination zone and closer to the destination
our zone-structure, as nodes from the same zone are within zone than its own zone. If multiple candidates are available, the
each other’s transmission range and are aware of each other’s neighbor closest to the destination is selected as the next hop.
location, only one transmission is required for intra-zone To compare the distances of different zones to the destination
communications. Transmissions between nodes in different zone, the node can calculate the distance value dis(a,b) of a
zones may be needed for the network-tier forwarding of zone (a,b) to the destination zone (adst , bdst ) as:
control messages and data packets. As the source and the
destination may be multiple hops away, to ensure reliable dis(a,b) = (a − adst )2 + (b − bdst )2 . (1)
transmissions, geographic unicasting is used with the packet
forwarding guided by the destination position. However, in A zone with a smaller dis value is closer to the destination
normal geographic unicast routing, location service is required zone. In the above example, if the underlying geographic
for the source to obtain the destination position. In EGMP, unicast forwarding fails at node 18, it will try to continue
to avoid the overhead in tracking the exact locations of a the forwarding using zone mode. It checks its neighbor table
potentially large number of group members, location service is (Table 1). Since the dis value of zone (0, 1) has zero value
integrated with zone-based membership management without to the destination zone (0, 1), node 18 selects its neighbor
the need of an external location server. At the network tier, node 7 in zone (0, 1) as the next hop and forwards the packet
only the ID of the destination zone is needed. A packet is to node 7. To avoid possible routing loop, an intermediate node
forwarded towards the center of the destination zone first. only forwards a packet that is received for the first time.
After arriving at the destination zone, the packet will be To validate our zone-supported geographic forwarding strat-
forwarded to a specific receiving node or broadcast depending egy, we compare our scheme (represented as EGMP forward)
on the message type. Generally, the messages related to with two other schemes through simulations: SPBM [20]
multicast group membership management and multicast data (represented as SPBM forward), in which a sender uses the
will be forwarded to the zone leader to process. point in the square which is closest to itself as the desti-
In the above design, for scalability and reliability, the center nation position; a unicast strategy which also uses the zone
of the destination zone is used as the landmark for sending a center to estimate the destination position (represented as
packet to the group members in the zone although there may EGMP non zonemode) but does not use the zone forwarding
be no node located at the center position. This, however, may mode. The settings and protocol parameters are the same as
result in the failure of geographic forwarding. For example, in Section 5. We simulated 30 CBR traffic flows with each

6. IEEE TRANSACTIONS ON MOBILE COMPUTING
IEEE TRANSACTIONS ON MOBILE COMPUTING, VOL. 10, NO. 4, April 2011 6
flow sent at 8 Kbps between a randomly chosen source and Procedure LeaderJoin(me, pkt)
a non-empty zone. A packet is considered to be successfully me: the leader itself
pkt: the JOIN REQ message the leader received
delivered if it is received by any node in the destination zone.
In Fig. 2, when the destination is a zone, the zone center is BEGIN
a better estimation of the destination position than the closest if (pkt.srcZone == me.zoneID) then
/* the join request is from a node in the local zone */
point in the destined zone. As the estimated closest point in the /* add the node into the downstream node list of the multicast table */
destined zone could be very close to the zone border, compared AddNodetoMcastTable(pkt.groupID, pkt.nodeID);
to the zone center, it is more likely for an out-of-zone node to else
/* the join request is from another zone */
be closer to the estimated point and become the forwarder than if (depthme < depthpkt ) then
an intra-zone node. Hence, the forwarder may have a higher /* add this zone to the downstream zone list of the multicast table
chance of dropping the packet when not able to find a next-hop */
AddZonetoMcastTable(pkt.groupID, pkt.zoneID);
node closer to the destination for forwarding the packet. The else
simulation results confirm that using zone forwarding mode ForwardPacket(pkt);
can help reduce the number of undelivered packets. return;
end if
end if
if (!LookupMcastTableforRoot(pkt.groupID)) then
3.4 Multicast Tree Construction /* there is no root-zone information */
SendRootZoneRequest(pkt.groupID);
In this subsection, we present the multicast tree creation and else if (!LookupMcastTableforUpstream(pkt.groupID)) then
maintenance schemes. In EGMP, instead of connecting each /* there is no upstream zone information */
group member directly to the tree, the tree is formed in the SendJoinRequest(pkt.groupID);
else
granularity of zone with the guidance of location information, SendReply;
which significantly reduces the tree management overhead. end if
With a destination location, a control message can be transmit- END
ted immediately without incurring a high overhead and delay
to find the path first, which enables quick group joining and Fig. 3: The pseudocode of the leader joining procedure.
leaving. In the following description, except when explicitly
indicated, we use G, S and M respectively to represent a
3.4.2 Multicast group join
multicast group, a source of G and a member of G.
When a node M wants to join the multicast group G, if it is not
3.4.1 Multicast session initiation and termination a leader node, it sends a JOIN REQ(M, P osM , G, {Mold })
When a multicast session G is initiated, the first source node message to its zLdr, carrying its address, position, and group
S (or a separate group initiator) announces the existence of to join. The address of the old group leader Mold is an option
G by flooding a message N EW SESSION (G, zoneIDS ) used when there is a leader handoff and a new leader sends an
into the whole network. The message carries G and the ID of updated JOIN REQ message to its upstream zone. If M did
the zone where S is located, which is used as the initial root- not receive the NEW SESSION message or it just joined the
zone ID of group G. When a node M receives this message and network, it can search for the available groups by querying
is interested in G, it will join G using the process described its neighbors. If a zLdr receives a JOIN REQ message or
in the next subsection. A multicast group member will keep wants to join G itself, it begins the leader joining procedure
a membership table with an entry (G, root zID, isAcked), as shown in Fig. 3. If the JOIN REQ message is received
where G is a group of which the node is a member, root zID from a member M of the same zone, the zLdr adds M to the
is the root-zone ID and isAcked is a flag indicating whether downstream node list of its multicast table. If the message is
the node is on the corresponding multicast tree. A zone leader from another zone, it will compare the depth of the requesting
(zLdr) maintains a multicast table. When a zLdr receives the zone and that of its own zone. If its zone depth is smaller,
NEW SESSION message, it will record the group ID and the i.e., its zone is closer to the root zone than the requesting
root-zone ID in its multicast table. Table 2 is an example of zone, it will add the requesting zone to its downstream zone
one entry in the multicast table of node 16 in Fig. 1. The table list; otherwise, it simply continues forwarding the JOIN REQ
contains the group ID, root-zone ID, upstream zone ID, down- message towards the root zone.
stream zone list and downstream node list. To end a session If new nodes or zones are added to the downstream list, the
G, S floods a message END SESSION(G). When receiving leader will check the root-zone ID and the upstream zone ID.
this message, the nodes will remove all the information about If it does not know the root zone, it starts an expanded ring
G from their membership tables and multicast tables. search. As the zone leaders in the network cache the root-zone
ID, a result can be quickly obtained. With the knowledge of
TABLE 2: The entry of group G in multicast table of node 16
the root zone, if its upstream zone ID is unset, the leader will
group ID G represent its zone to send a JOIN REQ message towards the
root-zone ID (2, 2) root zone; otherwise, the leader will send back a JOIN REPLY
upstream zone ID (2, 2) message to the source of the JOIN REQ message (which may
downstream zone list (0, 1), (0, 0)
downstream node list 1
be multiple hops away and the geographic unicasting described
in Section 3.3 is used for this transmission). When the source

7. IEEE TRANSACTIONS ON MOBILE COMPUTING 7
of the JOIN REQ message receives the JOIN REPLY, if it 3.5.1 Packet sending from the source
is a node, it sets the isAcked flag in its membership table After the multicast tree is constructed, all the sources of the
and the joining procedure is completed. If the leader of a group could send packets to the tree and the packets will
requesting zone receives the JOIN REPLY message, it will be forwarded along the tree. In most tree-based multicast
set its upstream zone ID as the ID of the zone where the protocols, a data source needs to send the packets initially
JOIN REPLY message is sent, and then send JOIN REPLY to the root of the tree. If this scheme is used and node 5
messages to unacknowledged downstream nodes and zones. in Fig. 1 is a source, node 5 needs to unicast the packets
An example is given in Fig. 1, in which the root zone of G is initially to root zone (2, 2). The sending of packets to the root
(2, 2), and the double circled nodes are zone leaders. Suppose would introduce extra delay especially when a source is far
currently zone (0, 0) and (1, 1) are not on the multicast away from the root. Instead, EGMP assumes a bi-directional-
tree, and their leader nodes 15 and 16 already know the root tree-based forwarding strategy [23], with which the multicast
zone ID from the NEW SESSION message. Now node 15 packets can flow not only from an upstream node/zone down
plans to join G with the leader joining procedure. As it finds to its downstream nodes/zones, but also from a downstream
its upstream zone ID is unset, node 15 sends a JOIN REQ node/zone up to its upstream node/zone.
message towards root zone (2, 2). The message reaches zone
A source node is also a member of the multicast group
(1, 1) and is intercepted by leader node 16, which then starts
and will join the multicast tree. When a source S has data
its leader joining procedure. Node 16 compares the depths
to send and it is not a leader, it checks the isAcked flag in
of zone (0, 0) and its own zone. Since depth(0,0) = 2 and
its membership table to find out if it is on the tree. If it
depth(1,1) = 1, depth(0,0) > depth(1,1) , node 16 adds zone
is, i.e., its zone has joined the multicast tree, it sends the
ID (0, 0) to its downstream zone list. As node 16 finds its
multicast packets to its leader. When the leader of an on-
upstream zone ID is unset, it sends a JOIN REQ message
tree zone receives multicast packets, it forwards the packets
towards the root zone. This message is received by the leader
to its upstream zone and all its downstream nodes and zones
of the root-zone, node 3, and triggers the joining procedure of
except the incoming one. For example, in Fig. 1, source node 1
node 3. Node 3 adds the zone ID (1, 1) to its downstream zone
sends the packets to its leader node 16, which will send the
list after comparing the depth. As the root zone does not have
packets to its upstream zone (2, 2) and its downstream zones
an upstream zone, node 3 sends back a JOIN REPLY message
(0, 1) and (0, 0), but not to the downstream node 1 which is
to the zone (1, 1). On receiving this message, node 16 sets the
the incoming node. When the packets are received by leader
upstream zone ID as (2, 2) and sends a JOIN REPLY message
node 3 of the root zone, it continues forwarding the packets to
to its unacknowledged downstream zone (0, 0). Node 15 sets
its downstream zones (1, 3), (3, 3), (2, 1) except the incoming
its upstream zone as (1, 1) on receiving the JOIN REPLY
zone (1, 1). The arrows in the figure indicate the directions of
message and the joining process is completed, with two
the packet flows.
multicast branches built between zones (2, 2) and (1, 1), and
When a source node S is not on the multicast tree, for
between zones (1, 1) and (0, 0) respectively.
example, when it moves to a new zone, the isAcked flag will
Through the joining process, the group membership man-
remain unset until it finishes the rejoining to G through the
agement is implemented in a distributed manner. An upstream
leader of the new zone. To reduce the impact of the joining
zone only needs to manage its downstream zones, and the
delay, S will send packets directly to the root zone until it
group membership of a local zone is only managed by its
finishes the joining process.
leader. The zone depth is used to guide efficient tree construc-
tion and packet forwarding.
3.5.2 Multicast data forwarding
3.4.3 Multicast group leave In our protocol, only zLdrs maintain the multicast table,
When a member M wants to leave G, it sends a and the member zones normally cannot be reached within
LEAV E(M, G) message to its zone leader. On receiving a one hop from the source. When a node N has a multicast
LEAVE message, the leader removes the source of the LEAVE packet to forward to a list of destinations (D1 , D2 , D3 , . . .),
message from its downstream node list or zone list depending it decides the next hop node towards each destination (for
on whether the message is sent from an intra-zone node or a a zone, its center is used) using the geographic forwarding
downstream zone. Besides removing a branch through explicit strategy described in Section 3.3. After deciding the next hop
LEAVE, a leader will remove a node from its downstream nodes, N inserts the list of next hop nodes and the destinations
list if it does not receive the beacon from the node exceeding associated with each next hop node in the packet header. An
2×Intervalmax . If its downstream zone list and node list of G example list is (N1 : D1 , D3 ; N2 : D2 ; . . .), where N1 is
are both empty and it is not a member of G either, the leader the next hop node for the destinations D1 and D3 , and N2
sends a LEAVE(zoneID, G) message to its upstream zone. is the next hop node for D2 . Then N broadcasts the packet
Through the leave process, the unused branches are removed promiscuously (for reliability and efficiency). Upon receiving
from the multicast tree. the packet, a neighbor node will keep the packet if it is one
of the next hop nodes or destinations, and drop the packet
3.5 Multicast Packet Delivery otherwise. When the node is associated with some downstream
In this subsection, we explain how the multicast packets are destinations, it will continue forwarding packets similarly as
forwarded to the members. done by node N.

8. IEEE TRANSACTIONS ON MOBILE COMPUTING 8
7
For example, in Fig. 1, after node 3 receives the multicast 2
( ,3
2 )
8
(3 )
,3
packet from zone (1, 1), it will forward the packet to down- 2
stream zones (2, 1), (1, 3) and (3, 3). It determines the next hop 10
1 13
10
node for each destination and inserts the list (12: (1,3),(3,3); 4
6
14: (2,1)) in the packet header. After broadcasting the packet 11 5
(2,2) (3,2)
promiscuously, its one-hop neighbors node 12, node 14 and 12
node 8 will receive the packet. Node 8 will drop this packet,
while node 12 and node 14 will continue the forwarding. Fig. 4: Multiple clusters in one zone.
Node 12 replaces the list carried in the packet header with
During the transition, the old leader may still receive multicast
(17: (1,3); 2: (3,3)) and broadcasts this packet. Node 14 finds
packets. It will forward all these packets to the new leader
group information from its multicast table, and broadcast the
when the handover process is completed. If there is no other
packet with a header (9: (1,0); 5:(3,0)).
node in the zone and the zone will become empty, it will
use the method introduced in the next subsection to deliver
3.6 Multicast Route Maintenance and Optimization its multicast table. In the case that the leader dies suddenly
In a dynamic network, it is critical to maintain the connection before handing over its multicast table, the downstream zones
of the multicast tree, and adjust the tree structure upon the and nodes will reconnect to the multicast tree through the
topology changes to optimize the multicast routing. In the zone maintenance process described in Section 3.6.4.
structure, due to the movement of nodes between different
zones, some zones may become empty. It is critical to handle 3.6.2 Dealing with empty zones
the empty zone problem in a zone-based protocol. Compared A zone may become empty when all the nodes move away.
to managing the connections of individual nodes, however, The probability that a zone is empty is approximately P =
2
there is a much lower rate of zone membership change and e−ρr when the node density is ρ and the zone size is r.
hence a much lower overhead in maintaining the zone-based Assume r = 150m, which is the zone size that allows all the
tree. As the tree construction is guided by location information, nodes in the same zone to be within the transmission range,
a disconnected zone can quickly re-establish its connection to the probability of the zone being empty is: P = 0.207 if
the tree. In addition, a zone may be partitioned into multiple d = 70nodes/km2 , and P = 0.509 if d = 30nodes/km2 .
clusters due to fading and signal blocking. In this subsection, We can see that the probability of a zone becoming empty
we discuss our maintenance schemes. is not negligible and it is critical to address the empty zone
problem.
3.6.1 Moving between different zones In EGMP, if a tree zone becomes empty, the multicast tree
When a member node moves to a new zone, it must rejoin the will be adjusted correspondingly to keep the multicast tree
multicast tree through the new leader. When a leader is moving connected. Because of the importance of the root zone, we
away from its current zone, it must handover its multicast table will treat it differently. When a leader is moving away from
to the new leader in the zone, so that all the downstream zones a non-root tree-zone and the zone is becoming empty, it will
and nodes will remain connected to the multicast tree. send its multicast table to its upstream zone. The upstream
Whenever a node M moves into a new zone, it will rejoin a zone leader will then take over all its downstream zones,
multicast group G by sending a JOIN REQ message to its new and delete this requesting zone from its downstream zone
leader. During this joining process, to reduce the packet loss, list. The new upstream zone needs to send JOIN REPLY
whenever the node broadcasts a BEACON message to update messages to all the newly added downstream zones to notify
its information to the nodes in the new zone, it also unicasts a them the change. When receiving the JOIN REPLY messages,
copy of the message to the leader of its previous zone to update these downstream zones will change their upstream zone ID
its position. Since it has not sent the LEAVE message to the accordingly.
old leader, the old leader will forward the multicast packets to If the to-be empty zone is the root zone, since the root zone
M. This forwarding process helps reduce the packet loss and has no upstream zone, the leader will check its neighboring
facilitates seamless packet transmissions during zone crossing. zones and choose the one closest to the root zone as the
When the rejoining process finishes, M will send a LEAVE new root zone. The leader then forwards its multicast table
message to its old leader. to the new root zone, and floods a NEW ROOT message to
To handle leader mobility problem, if a leader finds its announce the change.
distance to the zone border is less than a threshold or it is
already in a new zone, it assumes it is moving away from 3.6.3 Handling Multiple Clusters per Zone
the zone where it was the leader, and it starts the handover When there is severe shadowing/fading or a hill/building that
process. To look for the new leader, it compares the positions prevents the radio communication between nodes in a zone,
of the nodes in the zone it is leaving from and selects the the nodes in the same zone may form multiple clusters as
one closest to the zone center as the new leader. It then sends shown in Fig. 4, where the two clusters are not connected
its multicast table to the new leader, which will announce its in the zone although they are connected through some nodes
leadership role immediately through a BEACON message. It outside the zone. In this case, two nodes in different clusters
will also send a JOIN REQ message to its upstream zone. can communicate with each other by using unicasting because

9. IEEE TRANSACTIONS ON MOBILE COMPUTING 9
they are connected on the network topology graph, but an 2 ∗ Intvalactive , it assumes that it loses the connection to the
intra-zone flooding message initiated in one cluster may not multicast tree and restarts a joining process.
reach other clusters. This problem is also a key problem for
zone-based protocols. 3.6.5 Route Optimization
EGMP handles the zone partitioning problem as follows. If Sometimes a zone leader may receive duplicate multicast pack-
there are multiple clusters in a zone, because these clusters are ets from different upstream zones. For example, as described in
not aware of the existence of each other, each cluster will elect the above subsection, when failing to receive any data packets
a leader. When an upstream zone leader receives JOIN REQ or ACTIVE messages from the upstream zone for a period
messages from multiple leaders of the same zone and the new of time, a tree-zone will start a rejoining process. However,
message is not sent as a result of leader handover (in which it is possible that the packet and message were lost due to
case the old leader’s address needs to be carried), it detects that collisions, so the old upstream zone is still active after the
the downstream zone has partitioned into multiple clusters. It rejoining process, and duplicate packets will be forwarded by
identifies a cluster by its zID and the leader’s address. When two upstream zones to the tree-zone. In this case, the one
sending a packet to the cluster, it uses the leader’s position closer to the root zone will be kept as the upstream zone. If
instead of the zone center (in which case the zone ID is the two upstream zones have the same distances to the root
carried as the destination) as the transmission reference. Even zone, one of them is randomly selected.
though the leader may move, its position carried in JOIN REQ
message can still be used as a reference to forward packets 4 C OST A NALYSIS
to its cluster. When receiving a packet with the position of
In this section, we will quantitatively analyze the per node
the leader as the reference, a cluster leader can learn that
cost of the protocol, which is defined as the average number
multiple clusters exist within its zone. In case that not all the
of control messages transmitted by each node per second. The
clusters of a partitioned zone send JOIN REQ messages, the
notations to be used in this section are listed in Table 3.
upstream zone leader may not be aware of the partitioning
The cost of the overall protocol consists of the following
of the downstream zone. When a cluster leader receives a
three components: zone building and geographic routing, tree
packet destined to its zone but does not match its status, it will
construction, and tree maintenance.
send an update message to its upstream zone. For example,
when a cluster leader receives a JOIN REPLY message or a TABLE 3: Notations used in the cost analysis.
multicast packet but did not send JOIN REQ message, it will
send a LEAVE message to the upstream zone. When receiving N total number of mobile nodes within the network
r zone size, the length of a side of the square zone
messages from multiple leaders of the same zone, the upstream
R network size, assuming a square network terrain with a
leader can detect zone partitioning. It will resend the previous side length R
message to the target cluster with the position of the zone v average moving speed of the mobile nodes
leader as the destination. T the lasting time of the multicast session
Mn total number of group member nodes
When the leader of a cluster changes, if the cluster is Mz total number of multicast tree zones.
on-tree, the new leader sends a JOIN REQ message to its
upstream zone immediately which also carries the old leader’s 4.1 Cost for zone building and geographic routing
address. With multiple clusters in its upstream zone, the The zone is virtual and determined by each node based on its
JOIN REQ message from a zone leader will generally be position and the reference origin, without the need of extra
intercepted by one of the clusters, which will be responsible signaling messages. The leader information is distributed with
a flag inserted in the beacon messages of the underlying geo-
for forwarding the packets to the zone. Some clusters may graphic unicast routing protocol. Therefore, the per node cost
merge later into a larger cluster, and through the leader election of the zone building and geographic routing is impacted by
procedure, only one of the leaders will win as the new cluster’s the beaconing frequency 1/Intvalmin introduced in Section
leader. The new leader will send a JOIN REQ message to 3.2, and the cost is as follows:
the upstream zone to refresh the cluster’s information. The 1
Costunicast ≤ = O(1). (2)
leaders of the other merged-in clusters will also send LEAVE Intvalmin
messages to the upstream zone, which will remove their
information from the multicast table. 4.2 Cost for tree construction
The tree construction process is associated with the multicast
3.6.4 Tree branch maintenance session initiation and termination, and the member joining and
leaving the multicast tree.
To detect the disconnection of tree-branches in time, if there Lemma 1: The per node cost of multicast tree construction
are no multicast packets or messages to deliver for a period of is O(1) with respect to the network size and the group size.
Intvalactive , the leader of a tree-zone will send an ACTIVE Proof: Multicast session initiation and termination in-
message to its downstream nodes and zones to announce clude a flooding of a NEW SESSION message and a flooding
of END SESSION message, so the cost for multicast session
the activity of the multicast branches. The message is sent initiation and termination is:
through multicast to multiple downstream entities. When a 1
Costinit end = (2 × N ) = O(1).
member node or a tree-zone fails to receive any packets or NT
messages from its leader or upstream zone up to a period of

10. IEEE TRANSACTIONS ON MOBILE COMPUTING 10
To analyze the cost for the joining and leaving process, we A and B is z, the length of a moving trail is decided by
consider the worst case that all the zones need to join the its angle θ and the distance z. Therefore, we can obtain the
multicast tree and become tree zone and all the members to average distance of a node moving in a zone as
join the tree are not zone leaders. In this case, group members
need to first send a JOIN REQ message to their leaders in π
4 r sin θ z
r (cos θ−sin θ)
r
local zones, and each leader needs to send a JOIN REQ 0 (2 0 sin θ cos θ
dz + r2sin θ cos θ
dz)dθ
d= π r (cos θ+sin θ)
message towards the root zone to join the multicast tree. The 4 2
dzdθ
0 0
JOIN REQ message from a zone will be intercepted by an πr
upstream zone leader. The distance between an upstream and
√ = . (3)
4
a downstream zone leader is shorter than 2 2r+rt , where rt is
the transmission range. According to [22], the average number
of hops of the greedy forwarding path between the source and Lemma 3: The per node cost of multicast tree maintenance
¯ ¯
the destination is d , where d is the average distance between
z
¯
is O(1) with respect to the network size and the group size.
the source and the destination and z is the average forwarding
¯ Proof: The cost for the tree maintenance is composed
progress made towards the destination in the course of one of the cost for handling zone crossing of member nodes, the
transmission. Parameter z depends on rt and the average
¯
number of nodes within the transmission range, and is constant cost in adapting the tree structure in the presence of empty
with respect to the group size and the network size. Hence, zones, and the cost in maintaining tree branches, as presented
√ in Section 3.6.1, 3.6.2 and 3.6.4. We first analyze these costs
1 2 2r + rt
Costjoin ≤ (Mn + Mz ), separately.
NT z
¯
The first component includes the cost of handling the
and as Mn ≤ N and Mz ≤ N , Costjoin ≤ O(1). Since moving between different zones due to non-leader members
the JOIN REPLY message follows the reverse direction of and due to leaders. For a non-leader member, it must send
JOIN REQ message, and the leaving process is similar to a JOIN REQ message to the new zone leader, which will
send a JOIN REPLY, and a LEAVE message to the old leader.
the joining process, Costreply = Costjoin ≤ O(1) and Its distances to the new and the old zone leaders are shorter
√ √
Costleave = Costjoin ≤ O(1). Therefore, the cost for than 2r and 2 2r respectively. By Lemma 2, the average
4v
multicast tree construction is: frequency of a node moving between different zones is πr . A
leader will send its multicast table to the new selected leader
when moving out of the zone. Hence, the cost due to member
Costtree = Costinit end + Costjoin + Costreply + Costleave nodes moving across zones is:
= O(1).
Costmoving = Costnon zLdr + CostzLdr
√ √
Mn 4v (1 + 1 + 2) × 2r Mz 4v 2r
≤ +
This indicates that the per-node control overhead involved N πr z
¯ N πr z
¯
in multicast tree construction remains relatively constant with = O(1). (4)
respect to network size and group size.
Due to node movement, a zone may become empty. The
empty zone may be a tree zone or the root zone. When the
4.3 Cost for tree maintenance upstream zone of a tree zone is to be empty, the moving away
The cost involved in multicast tree maintenance include the leader will hand the tree zone over to its own upstream zone,
which will send a JOIN REPLY message to this tree zone.
handling of zone crossing of multicast members, the tree The cost for this process should be less than the cost for the
reconstruction when there is an empty zone, and the tree joining process as shown in Lemma 1. If the upstream zone is
branch maintenance. the root zone, besides the above cost, a NEW ROOT message
is flooded in the network. The frequency of a zone becoming
empty should be less than the frequency of a node moving
4v
c between different zones, which is πr . Hence,
Costemptyzone = CosttreeZone + CostrootZone
r l 4vT N 4v
≤ (Costjoin + Costreply ) +
πr N πr
B a z = O(1). (5)
b
A
The cost for tree branch maintenance should be also less
1
Fig. 5: The moving distance of a mobile node in a zone. than the cost of joining process with frequency Intvalactive .
T
Lemma 2: Assume that a node keeps the same moving Costactive ≤ (Costjoin + Costreply ) = O(1). (6)
Intvalactive
direction in a zone. The average moving distance of the mobile
nodes in a zone is πr .
4
Therefore, the total per node cost for tree maintenance is:
Proof: The moving distance d of a node in a zone is the
length of its moving trail in the zone square. For example, Costmaintain = Costmoving + Costemptyzone + Costactive
in Fig. 5, line a is such a moving trail. Suppose the angle ≤ O(1). (7)
formed by the moving trail and the bottom side of the zone
square is θ. Due to the symmetry of the square, we only need
to consider the case when θ ∈ [0, π ]. As illustrated in Fig. 5,
4
all the possible moving trails with angle θ are located between 4.4 Cost for the Protocol
two parallel lines b and c, where b and c are tangent to the zone
with angle θ. Line l is perpendicular to b and c and intersects b We summarize the per node cost of the protocol and validate
at point A. a intersects l at B. Suppose the distance between
our quantitative analysis through simulations.

11. IEEE TRANSACTIONS ON MOBILE COMPUTING 11
cost (transmissions/node/s)
message was received for the reverse path back to the source.
cost (transmissions/node/s)
1 1
0.8 0.8 A receiver creates and broadcasts a Join Reply to its neighbors,
0.6 0.6 with the next hop node ID field filled by extracting information
0.4 0.4 from its routing table. The neighbor node whose ID matches
0.2 0.2
the next-hop node ID of the message realizes that it is on the
0
path to the source and is part of the forwarding group. It then
0
1500 2000 2500 3000
Network range (m)
3500 4000 0 50 100
Group size
150 200
broadcasts its own Join Table built upon matched entries. This
(a) (b) whole process constructs (or updates) the routes from sources
to receivers and builds a mesh of nodes, the forwarding group.
Fig. 6: Cost analysis: (a) Protocol cost vs. network size ; (b) The simulations were run with 400 nodes randomly dis-
Protocol cost vs. group size (b). tributed in an area of 2400m × 2400m. The nodes moved
following the modified random waypoint mobility model [25].
The moving speed of nodes are uniformly set between the
4.4.1 Quantitative analysis on the per node cost
minimum and maximum speed values which are set as as 1
Theorem 1: The EGMP control overhead as the average m/s (with pause time as 100 seconds) and 20 m/s respectively
number of control message transmissions per node every except when studying the effect of mobility. We set the
second has a complexity of O(1) with respect to the network MAC protocol and radio parameters according to the Lucent
size and the group size. WaveLANT M card, which operates at a data rate 11Mbps and
Proof: The overhead of the protocol is generated from the
tree construction and maintenance and the periodic beaconing radio frequency 2.4GHz with a nominal transmission range
in the underlying geographic unicast routing protocol. By 250m. IEEE 802.11b was used as the MAC layer protocol.
Lemma 1, Lemma 3 and Eq. 2, the cost of the protocol, i.e., the Each simulation lasted 500 simulation seconds. Each source
number of transmissions of control messages per node every
second with respect to the network size and the group size is: sends CBR data packets at 8 Kbps with packet length 512
bytes. The CBR flows start at around 30 second so that the
Costprotocol = Costtree + Costmaintain + Costunicast
group membership management has time to initialize and
= O(1). (8)
stop at 480 second. By default, there is one source, and one
4.4.2 Validation of the cost analysis by simulation multicast group with 100 members. A simulation result was
We validate our quantitative analysis on the protocol cost gained by averaging over six runs with different seeds.
through simulations. The simulation settings and protocol
parameters were set as those in Section 5. We studied the pro- 5.1 Parameters and Metrics
tocol cost, i.e., the average number of transmissions of control Table 4 lists the simulation parameters of EGMP with beacon
messages by each node per second, with network size varied interval set as [13]. The simulations for ODMRP are based
from 1500m × 1500m with 156 nodes to 3900m × 3900m on the codes carried with the simulator, with the parameters
with 1056 nodes and the group size varied from 10 members set as in [9]. We fixed several bugs in the GloMoSim codes
to 200 members. which would prevent a forwarding group node from sending
Fig. 6 (a) and (b) validate our quantitative analysis on the JOIN TABLES. The improvement doubles the delivery ratio
protocol cost. The protocol cost keeps almost constant between and reduces the control overhead of ODMRP. Additionally, we
0.3 and 0.4 with different network sizes and group sizes. implemented SPBM in GloMoSim according to [20] and the
The above analysis results indicate that when the network ns2 codes provided by the authors with the same parameter
size and the group size increase, the control overhead placed settings except that the square size was set to 150 m so that the
on each node per second by the protocol will remain relatively nodes in a square are within each other’s transmission range.
constant. Next, we will further demonstrate the scalability and The number of levels of the quad-tree changes accordingly
efficiency of the protocol by simulation studies. with the square size and the network size we used. For packet
forwarding in SPBM, different from the scheme described in
5 P ERFORMANCE E VALUATION [20], we used the square center as the destination position,
We implemented the EGMP protocol using Global Mobile which improves the delivery ratio of SPBM.
Simulation (GloMoSim) [24] library, and compare it with We focus on the studies of the scalability and efficiency of
ODMRP [8] which is widely used and considered to be robust the protocol under the dynamic environment and the following
over a dynamic network, and the geographic multicast protocol metrics were used for the multicast performance evaluation:
SPBM [20] which is designed to improve the scalability 1) Packet delivery ratio: The ratio of the number of packets
of position-based multicast. The SPBM is a quad-tree-based received and the number of packets expected to receive.
protocol as introduced in Section 2. ODMRP is a mesh- Thus for multicast packet delivery, the ratio is equal to
based on-demand non-geographic multicast protocol, and takes the total number of received packets over the number of
a soft-state approach to maintain multicast group members. originated packets times the group size.
A multicast source broadcasts a Join-Query messages to the 2) Normalized control overhead: The total number of con-
entire network periodically. An intermediate node stores the trol message transmissions divided by the total number
source ID and the sequence number, and updates its routing of received data packets. Each forwarding of the control
table with the node ID (i.e. backward learning) from which the message was counted as one transmission. Different