Supporting efficient and scalable multicasting


Published on

Dear Students
Ingenious techno Solution offers an expertise guidance on you Final Year IEEE & Non- IEEE Projects on the following domain
For further details contact us:
044-42046028 or 8428302179.

Ingenious Techno Solution
#241/85, 4th floor
Rangarajapuram main road,
Kodambakkam (Power House)

Published in: Education, Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Supporting efficient and scalable multicasting

  1. 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 maintenanceThere are increasing interests and importance in support- of the tree/mesh structure over the dynamic 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 scalablemessages among a group of soldiers in a battlefield, commu- and robust packet transmissions. The existing geographicnications among the firemen in a disaster area, and the support routing protocols generally assume mobile nodes are awareof multimedia games and teleconferences. With a one-to-many of their own positions through certain positioning systemor many-to-many transmission pattern, multicast is an efficient (e.g., GPS), and a source can obtain the destination positionmethod to realize group communications. However, there is a through some type of location service [15] [16]. In [13], anbig challenge in enabling efficient multicasting over a MANET intermediate node makes its forwarding decisions based onwhose 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 learnedbe ascribed into two main categories, tree-based and mesh- from the periodic beaconing of the neighbors. By default, thebased. However, due to the constant movement as well as packets are greedily forwarded to the neighbor that allows forfrequent network joining and leaving from individual nodes, the greatest geographic progress to the destination. When noit is very difficult to maintain the tree structure using these such a neighbor exists, perimeter forwarding is used to recoverconventional 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-handFGMP [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 overheadredundant paths between the source and the destination pairs. and support more reliable multicasting, an option is to makeConventional 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:, geography-based transmission from unicast to multicast is to put the addresses and positions of all the members into the packet header, however, the header overhead will increase
  2. 2. IEEE TRANSACTIONS ON MOBILE COMPUTING IEEE TRANSACTIONS ON MOBILE COMPUTING, VOL. 10, NO. 4, April 2011 2significantly 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. Ourscalable geographic multicast protocol also needs to efficiently simulation studies confirm the scalability and efficiencymanage 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 ofThe existing small-group-based geographic multicast proto- the EGMP protocol in Section 3, and quantitatively analyzecols [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 inprotocol, 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 formore reliable operation. Instead of addressing only a specific 2 R ELATED W ORKpart of the problem, it includes a zone-based scheme to In this section, we first summarize the basic proceduresefficiently 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 theefficiently track the locations of all the group members without literature.resorting to an external location server. The zone structure Conventional topology-based multicast protocols includeis 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 treea reference origin. In topology-based cluster construction, a structure for more efficient forwarding of packets to all thecluster is normally formed around a cluster leader with nodes group members. Mesh-based protocols expand a multicastone hop or k-hop away, and the cluster will constantly change tree with additional paths which can be used to forwardas network topology changes. In contrast, there is no need to packets when some of the links break. Although efforts wereinvolve 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 difficultmore efficient and reliable communications over a dynamic to scale to a large network size, as the construction andMANET. By making use of the location information, EGMP maintenance of the conventional tree or mesh structure involvecould quickly and efficiently build packet distribution paths, high control overhead over a dynamic network. The work inand reliably maintain the forwarding paths in the presence [26], [27] attempts to improve the stateless multicast protocolof network dynamics due to unstable wireless channels or [2], which allows it a better scalability to group size. Infrequent 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. 3. IEEE TRANSACTIONS MOBILE COMPUTING IEEE TRANSACTIONS ON ON MOBILE COMPUTING, VOL. 10, NO. 4, April 2011 3proposes two overlay multicast trees: a bandwidth-minimizingLGS tree and a delay-minimizing LGK tree. In PBM [19],a multicast source node finds a set of neighboring, next-hopnodes and assigns each packet destination to one next-hopnode. The next-hop nodes, in turn, repeat the process. Thus, noglobal distribution structure is necessary. GMP in [29] attemptsto build a more efficient multicast tree through a centralizedcalculation 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. Fig. 1: Zone structure and multicast session example. The HRPM [30] and SPBM [20] are more related to ourwork, as they also support hierarchical group management. be generated when the network size increases as a resultHRPM consists of two key design ideas: 1) hierarchical of membership flooding. With this proactive and periodicdecomposition of a large group into a hierarchy of recursively membership updating scheme, the membership change of aorganized manageable-sized subgroups and 2) the use of node may need to go through L levels to make it known to thedistributed geographic hashing to construct and maintain such whole network, which leads to a long multicast group joininga hierarchy. Although it is interesting to apply hashing to time. Instead of using multiple levels of flooding for groupfind 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 thethe assumption of the network size, which is difficult for a group. EGMP introduces root zone and zone depth to facilitatedynamic 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, thuscan 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 whichmay be out of its transmission range) closest to the RP. The the destinations are a group of receivers, the destination ofmobility of nodes will introduce additional challenge to the geocasting is one or multiple geographic regions (squares areprotocol, 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 floodingfailure. Additionally, requiring a node to contact RP first for or other methods. There is no need of forming multicasta Join will increase joining delay. In contrast, EGMP does infrastructure to deliver packets to group members that maynot make any assumption of the network size in advance, and distribute widely in the whole network domain and changethe 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 geographicInstead of using one RP as a core for group membership multicast protocol for MANET. In this paper, we furthermanagement, which may lead to a point of failure, EGMP introduce zone-supported geographic forwarding to reduceintroduces the root zone which is much more stable than a the routing failure, and provide mechanism to handle zonesingle point, and manages group membership more efficiently partitioning. In addition, we introduce a path optimizationwithin the local range. Instead of using the overlay-based process to handle multiple paths, and provide a detailed costmultiple unicast transmissions, EGMP takes advantage of the analysis to demonstrate the scalability of the proposed routingpromiscuous mode transmission to forward packets along more scheme.efficient transmission paths. We did not directly compare ourwork 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 TOCOLdifferent 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 theis known to have much more challenge to ensure reliable notations to be used in the rest of the paper in Sectionmulticast 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 geographictree with L levels. The top level is the whole network and the forwarding. Finally, in Sections 3.4, 3.5 and 3.6, we introducebottom level is constructed by basic squares. Each higher level our mechanisms for multicast tree creation, maintenance andis constructed by larger squares with each square covering multicast packet delivery.four smaller squares at the next lower level. All the nodesin a basic square are within each other’s transmission range.At each level, every square needs to periodically flood its 3.1 Protocol Overviewmembership 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. 4. IEEETRANSACTIONS ON MOBILE COMPUTINGIEEE TRANSACTIONS ON MOBILE COMPUTING, VOL. 10, NO. 4, April 2011 4a pre-determined virtual origin, the nodes in the network zone center: For a zone with ID (a,b), the position of itsself-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 belocal group membership. At the upper layer, the leader serves forwarded towards the center of the a representative for its zone to join or leave a multicast zLdr: Zone leader. A zLdr is elected in each zone forgroup as required. As a result, a network-wide zone-based managing the local zone group membership and taking partmulticast 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 arewith the design and used to guide the zone construction, responsible for the multicast packet forwarding. A tree zonegroup membership management, multicast tree construction may have group members or just help forward the multicastand maintenance, and packet forwarding. The zone-based tree packets for zones with shared for all the multicast sources of a group. To further root zone: The zone where the root of the multicast tree isreduce the forwarding overhead and delay, EGMP supports packet forwarding along the tree structure. That zone depth: The depth of a zone is used to reflect its distanceis, 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 immediatelyto the leaf zones of the tree. At the lower layer, when an on- surrounding the root zone have depth one, and the outer seventree zone leader receives the packets, it will send them to the zones have depth 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 itmanagement include: the schemes for more efficient and robust is very simple to locate and maintain a zone. The zone is usedzone 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 canzone 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 butmove across zones. The issues related to packet forwarding only needs to track the membership change of zones, whichinclude: the efficient building of multicast paths with the significantly reduces the management overhead and increaseszone structure, the handling of empty zone problem, the the robustness of the proposed multicast protocol. We chooseefficient tree structure maintenance during node movements, to design the zone without considering node density so itthe reliable transmissions of control and multicast data packets, can provide more reliable location reference and membershipand obtaining location information to facilitate our geometric management in a network with constant topology without resorting to an external location server. For the convenience of presentation, we first introduce theterminologies used in the paper. In EGMP, we assume every 3.2 Neighbor Table Generation and Zone Leadernode is aware of its own position through some positioning Electionsystem (e.g., GPS [10]) or other localization schemes. The For efficient management of states in a zone, a leader isforwarding of data packets and most control messages is elected with minimum overhead. As a node employs periodicbased on the geographic unicast routing protocol GPSR [13] BEACON broadcast to distribute its position in the underneathdescribed in Section 1. EGMP, however, does not depend on geographic unicast routing [13], to facilitate leader electiona 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 beshown 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, thezone size is set to r ≤ rt / 2, where rt is the transmission beaconing interval for the underneath unicast protocol will berange of the mobile nodes. To reduce intra-zone management adaptive. A non-leader node will send a beacon every period ofoverhead, the intra-zone nodes can communicate directly with Intvalmax or when it moves to a new zone. A zone leader haseach 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 theorigin, which can be a known reference location or determined node ID, position and f lag contained in the message in itsat network setup time. A zone is virtual and formulated in neighbor table. Table 1 shows the neighbor table of node 18 inreference to the virtual origin. For simplicity, we assume all Fig. 1. The zone ID of the sending node can be calculated fromthe zone IDs are positive. its position, as discussed earlier. To avoid routing failure due to
  5. 5. IEEETRANSACTIONS ON MOBILE COMPUTINGIEEE TRANSACTIONS ON MOBILE COMPUTING, VOL. 10, NO. 4, April 2011 5 4outdated topology information, an entry will be removed if not 10 Number of lost packets Number of lost packets EGMP_non_zonemoderefreshed within a period T imeoutN T or the corresponding EGMP_forwardneighbor 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 nodesand maintained consistently in a zone. When a node appears in Fig. 1, node 7 is the only node in zone (0, 1), while nodein the network, it sends out a beacon announcing its existence. 18 in zone (1, 1) is closest to the center of zone (0, 1). WhenThen it waits for an Intvalmax period for the beacons from node 16 sends a packet to zone (0, 1) with its center as theother nodes. Every Intvalmin a node will check its neighbor destination, the underlying geographic unicast protocol (fortable and determine its zone leader under different cases: 1) example, GPSR [13] described in Section 1) will forward theThe neighbor table contains no other nodes in the same zone, packet to node 18 greedily as it is closer to the destination. Asit will announce itself as the leader. 2) The flags of all the node 18 cannot find a neighbor closer to the center of zonenodes in the same zone are unset, which means that no node (0, 1) than itself, the perimeter mode [13] may be used toin the zone has announced the leadership role. If the node is continue the forwarding. This still cannot guarantee the packetcloser to the zone center than other nodes, it will announce to arrive at node 7, as the destination is a virtual referenceits leadership role through a beacon message with the leader point. Such a problem is neglected by the previous geographicflag 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 forwarding4) Only one of the nodes in the zone has its flag set, then the mode in EGMP when the underlying geographic forwardingnode 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 can3.3 Zone-supported Geographic Forwarding more accurately track the local network topology. The nodeWith a zone structure, the communication process includes selects as its next hop the neighboring node whose zone is thean intra-zone transmission and an inter-zone transmission. In closest to the destination zone and closer to the destinationour zone-structure, as nodes from the same zone are within zone than its own zone. If multiple candidates are available, theeach 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 destinationcommunications. Transmissions between nodes in different zone, the node can calculate the distance value dis(a,b) of azones 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 thedestination 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 packetforwarding guided by the destination position. However, in A zone with a smaller dis value is closer to the destinationnormal geographic unicast routing, location service is required zone. In the above example, if the underlying geographicfor the source to obtain the destination position. In EGMP, unicast forwarding fails at node 18, it will try to continueto avoid the overhead in tracking the exact locations of a the forwarding using zone mode. It checks its neighbor tablepotentially large number of group members, location service is (Table 1). Since the dis value of zone (0, 1) has zero valueintegrated with zone-based membership management without to the destination zone (0, 1), node 18 selects its neighborthe need of an external location server. At the network tier, node 7 in zone (0, 1) as the next hop and forwards the packetonly the ID of the destination zone is needed. A packet is to node 7. To avoid possible routing loop, an intermediate nodeforwarded 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 thewill 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 zoneof the destination zone is used as the landmark for sending a center to estimate the destination position (represented aspacket to the group members in the zone although there may EGMP non zonemode) but does not use the zone forwardingbe no node located at the center position. This, however, may mode. The settings and protocol parameters are the same asresult in the failure of geographic forwarding. For example, in Section 5. We simulated 30 CBR traffic flows with each
  6. 6. IEEE TRANSACTIONS ON MOBILE COMPUTING IEEE TRANSACTIONS ON MOBILE COMPUTING, VOL. 10, NO. 4, April 2011 6flow 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 receiveddelivered if it is received by any node in the destination zone.In Fig. 2, when the destination is a zone, the zone center is BEGINa 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 ) thenan intra-zone node. Hence, the forwarder may have a higher /* add this zone to the downstream zone list of the multicast tablechance 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 elsesimulation 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)) then3.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)) thenmaintenance 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); elsegranularity of zone with the guidance of location information, SendReply;which significantly reduces the tree management overhead. end ifWith a destination location, a control message can be transmit- ENDted immediately without incurring a high overhead and delayto 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 explicitlyindicated, we use G, S and M respectively to represent a 3.4.2 Multicast group joinmulticast group, a source of G and a member of G. When a node M wants to join the multicast group G, if it is not3.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 groupS (or a separate group initiator) announces the existence of to join. The address of the old group leader Mold is an optionG by flooding a message N EW SESSION (G, zoneIDS ) used when there is a leader handoff and a new leader sends aninto the whole network. The message carries G and the ID of updated JOIN REQ message to its upstream zone. If M didthe zone where S is located, which is used as the initial root- not receive the NEW SESSION message or it just joined thezone ID of group G. When a node M receives this message and network, it can search for the available groups by queryingis interested in G, it will join G using the process described its neighbors. If a zLdr receives a JOIN REQ message orin the next subsection. A multicast group member will keep wants to join G itself, it begins the leader joining procedurea membership table with an entry (G, root zID, isAcked), as shown in Fig. 3. If the JOIN REQ message is receivedwhere 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 theis the root-zone ID and isAcked is a flag indicating whether downstream node list of its multicast table. If the message isthe 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 requestingroot-zone ID in its multicast table. Table 2 is an example of zone, it will add the requesting zone to its downstream zoneone entry in the multicast table of node 16 in Fig. 1. The table list; otherwise, it simply continues forwarding the JOIN REQcontains the group ID, root-zone ID, upstream zone ID, down- message towards the root zone list and downstream node list. To end a session If new nodes or zones are added to the downstream list, theG, 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 ringG 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 ofTABLE 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. 7. IEEE TRANSACTIONS ON MOBILE COMPUTING 7of the JOIN REQ message receives the JOIN REPLY, if it 3.5.1 Packet sending from the sourceis a node, it sets the isAcked flag in its membership table After the multicast tree is constructed, all the sources of theand the joining procedure is completed. If the leader of a group could send packets to the tree and the packets willrequesting zone receives the JOIN REPLY message, it will be forwarded along the tree. In most tree-based multicastset its upstream zone ID as the ID of the zone where the protocols, a data source needs to send the packets initiallyJOIN REPLY message is sent, and then send JOIN REPLY to the root of the tree. If this scheme is used and node 5messages 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 farcurrently 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 multicastzone ID from the NEW SESSION message. Now node 15 packets can flow not only from an upstream node/zone downplans to join G with the leader joining procedure. As it finds to its downstream nodes/zones, but also from a downstreamits 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 dataits leader joining procedure. Node 16 compares the depths to send and it is not a leader, it checks the isAcked flag inof 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 itdepth(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 theID (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 packetstowards the root zone. This message is received by the leader to its upstream zone and all its downstream nodes and zonesof the root-zone, node 3, and triggers the joining procedure of except the incoming one. For example, in Fig. 1, source node 1node 3. Node 3 adds the zone ID (1, 1) to its downstream zone sends the packets to its leader node 16, which will send thelist after comparing the depth. As the root zone does not have packets to its upstream zone (2, 2) and its downstream zonesan upstream zone, node 3 sends back a JOIN REPLY message (0, 1) and (0, 0), but not to the downstream node 1 which isto the zone (1, 1). On receiving this message, node 16 sets the the incoming node. When the packets are received by leaderupstream zone ID as (2, 2) and sends a JOIN REPLY message node 3 of the root zone, it continues forwarding the packets toto its unacknowledged downstream zone (0, 0). Node 15 sets its downstream zones (1, 3), (3, 3), (2, 1) except the incomingits upstream zone as (1, 1) on receiving the JOIN REPLY zone (1, 1). The arrows in the figure indicate the directions ofmessage 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, forbetween 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 theagement is implemented in a distributed manner. An upstream leader of the new zone. To reduce the impact of the joiningzone only needs to manage its downstream zones, and the delay, S will send packets directly to the root zone until itgroup 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 forwarding3.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 withinLEAV E(M, G) message to its zone leader. On receiving a one hop from the source. When a node N has a multicastLEAVE 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 (foron whether the message is sent from an intra-zone node or a a zone, its center is used) using the geographic forwardingdownstream zone. Besides removing a branch through explicit strategy described in Section 3.3. After deciding the next hopLEAVE, a leader will remove a node from its downstream nodes, N inserts the list of next hop nodes and the destinationslist if it does not receive the beacon from the node exceeding associated with each next hop node in the packet header. An2×Intervalmax . If its downstream zone list and node list of G example list is (N1 : D1 , D3 ; N2 : D2 ; . . .), where N1 isare both empty and it is not a member of G either, the leader the next hop node for the destinations D1 and D3 , and N2sends a LEAVE(zoneID, G) message to its upstream zone. is the next hop node for D2 . Then N broadcasts the packetThrough the leave process, the unused branches are removed promiscuously (for reliability and efficiency). Upon receivingfrom 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 packet3.5 Multicast Packet Delivery otherwise. When the node is associated with some downstreamIn this subsection, we explain how the multicast packets are destinations, it will continue forwarding packets similarly asforwarded to the members. done by node N.
  8. 8. IEEE TRANSACTIONS ON MOBILE COMPUTING 8 7 For example, in Fig. 1, after node 3 receives the multicast 2 ( ,3 2 ) 8 (3 ) ,3packet from zone (1, 1), it will forward the packet to down- 2stream zones (2, 1), (1, 3) and (3, 3). It determines the next hop 10 1 13 10node for each destination and inserts the list (12: (1,3),(3,3); 4 614: (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 12node 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 leadergroup information from its multicast table, and broadcast the when the handover process is completed. If there is no otherpacket 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 deliver3.6 Multicast Route Maintenance and Optimization its multicast table. In the case that the leader dies suddenlyIn a dynamic network, it is critical to maintain the connection before handing over its multicast table, the downstream zonesof the multicast tree, and adjust the tree structure upon the and nodes will reconnect to the multicast tree through thetopology 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 differentzones, some zones may become empty. It is critical to handle 3.6.2 Dealing with empty zonesthe empty zone problem in a zone-based protocol. Compared A zone may become empty when all the nodes move managing the connections of individual nodes, however, The probability that a zone is empty is approximately P = 2there 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 thetree. 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 ifthe 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 emptywe 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 treeWhen a member node moves to a new zone, it must rejoin the will be adjusted correspondingly to keep the multicast treemulticast tree through the new leader. When a leader is moving connected. Because of the importance of the root zone, weaway from its current zone, it must handover its multicast table will treat it differently. When a leader is moving away fromto the new leader in the zone, so that all the downstream zones a non-root tree-zone and the zone is becoming empty, it willand 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 zoneleader. During this joining process, to reduce the packet loss, list. The new upstream zone needs to send JOIN REPLYwhenever the node broadcasts a BEACON message to update messages to all the newly added downstream zones to notifyits 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 IDits 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 zoneM. This forwarding process helps reduce the packet loss and has no upstream zone, the leader will check its neighboringfacilitates seamless packet transmissions during zone crossing. zones and choose the one closest to the root zone as theWhen the rejoining process finishes, M will send a LEAVE new root zone. The leader then forwards its multicast tablemessage 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 isalready in a new zone, it assumes it is moving away from 3.6.3 Handling Multiple Clusters per Zonethe zone where it was the leader, and it starts the handover When there is severe shadowing/fading or a hill/building thatprocess. 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 asone closest to the zone center as the new leader. It then sends shown in Fig. 4, where the two clusters are not connectedits multicast table to the new leader, which will announce its in the zone although they are connected through some nodesleadership role immediately through a BEACON message. It outside the zone. In this case, two nodes in different clusterswill also send a JOIN REQ message to its upstream zone. can communicate with each other by using unicasting because
  9. 9. IEEE TRANSACTIONS ON MOBILE COMPUTING 9they are connected on the network topology graph, but an 2 ∗ Intvalactive , it assumes that it loses the connection to theintra-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 forzone-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 innot aware of the existence of each other, each cluster will elect the above subsection, when failing to receive any data packetsa leader. When an upstream zone leader receives JOIN REQ or ACTIVE messages from the upstream zone for a periodmessages 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 tocase the old leader’s address needs to be carried), it detects that collisions, so the old upstream zone is still active after thethe downstream zone has partitioned into multiple clusters. It rejoining process, and duplicate packets will be forwarded byidentifies a cluster by its zID and the leader’s address. When two upstream zones to the tree-zone. In this case, the onesending a packet to the cluster, it uses the leader’s position closer to the root zone will be kept as the upstream zone. Ifinstead of the zone center (in which case the zone ID is the two upstream zones have the same distances to the rootcarried 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 REQmessage can still be used as a reference to forward packets 4 C OST A NALYSISto its cluster. When receiving a packet with the position of In this section, we will quantitatively analyze the per nodethe leader as the reference, a cluster leader can learn that cost of the protocol, which is defined as the average numbermultiple clusters exist within its zone. In case that not all the of control messages transmitted by each node per second. Theclusters 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 followingof the downstream zone. When a cluster leader receives a three components: zone building and geographic routing, treepacket 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 willsend 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 zonemessages from multiple leaders of the same zone, the upstream R network size, assuming a square network terrain with aleader can detect zone partitioning. It will resend the previous side length Rmessage to the target cluster with the position of the zone v average moving speed of the mobile nodesleader 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 itsupstream zone immediately which also carries the old leader’s 4.1 Cost for zone building and geographic routingaddress. With multiple clusters in its upstream zone, the The zone is virtual and determined by each node based on itsJOIN REQ message from a zone leader will generally be position and the reference origin, without the need of extraintercepted 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 costmerge later into a larger cluster, and through the leader election of the zone building and geographic routing is impacted byprocedure, only one of the leaders will win as the new cluster’s the beaconing frequency 1/Intvalmin introduced in Sectionleader. 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 Intvalminmessages to the upstream zone, which will remove theirinformation from the multicast table. 4.2 Cost for tree construction The tree construction process is associated with the multicast3.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 constructionare 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 sessionthe 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 NTmessages from its leader or upstream zone up to a period of
  10. 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 byconsider the worst case that all the zones need to join the its angle θ and the distance z. Therefore, we can obtain themulticast tree and become tree zone and all the members to average distance of a node moving in a zone asjoin the tree are not zone leaders. In this case, group membersneed to first send a JOIN REQ message to their leaders in π 4 r sin θ z r (cos θ−sin θ) rlocal 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 0JOIN REQ message from a zone will be intercepted by an πrupstream zone leader. The distance between an upstream and √ = . (3) 4a downstream zone leader is shorter than 2 2r+rt , where rt isthe transmission range. According to [22], the average numberof 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 composedprogress made towards the destination in the course of one of the cost for handling zone crossing of member nodes, thetransmission. 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 emptywith 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 membersthe JOIN REPLY message follows the reverse direction of and due to leaders. For a non-leader member, it must sendJOIN 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 4vmulticast 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 the4.3 Cost for tree maintenance upstream zone of a tree zone is to be empty, the moving awayThe 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 thereconstruction when there is an empty zone, and the tree joining process as shown in Lemma 1. If the upstream zone isbranch 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) Intvalactivedirection in a zone. The average moving distance of the mobilenodes 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 thelength of its moving trail in the zone square. For example, Costmaintain = Costmoving + Costemptyzone + Costactivein 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 zonesquare is θ. Due to the symmetry of the square, we only needto consider the case when θ ∈ [0, π ]. As illustrated in Fig. 5, 4all the possible moving trails with angle θ are located between 4.4 Cost for the Protocoltwo parallel lines b and c, where b and c are tangent to the zonewith angle θ. Line l is perpendicular to b and c and intersects b We summarize the per node cost of the protocol and validateat point A. a intersects l at B. Suppose the distance between our quantitative analysis through simulations.
  11. 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 the4.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 respectivelynumber of control message transmissions per node every except when studying the effect of mobility. We set thesecond has a complexity of O(1) with respect to the network MAC protocol and radio parameters according to the Lucentsize and the group size. WaveLANT M card, which operates at a data rate 11Mbps and Proof: The overhead of the protocol is generated from thetree construction and maintenance and the periodic beaconing radio frequency 2.4GHz with a nominal transmission rangein 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 sourcenumber of transmissions of control messages per node everysecond 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 one4.4.2 Validation of the cost analysis by simulation multicast group with 100 members. A simulation result wasWe validate our quantitative analysis on the protocol cost gained by averaging over six runs with different seeds.through simulations. The simulation settings and protocolparameters were set as those in Section 5. We studied the pro- 5.1 Parameters and Metricstocol cost, i.e., the average number of transmissions of control Table 4 lists the simulation parameters of EGMP with beaconmessages by each node per second, with network size varied interval set as [13]. The simulations for ODMRP are basedfrom 1500m × 1500m with 156 nodes to 3900m × 3900m on the codes carried with the simulator, with the parameterswith 1056 nodes and the group size varied from 10 members set as in [9]. We fixed several bugs in the GloMoSim codesto 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 ratioprotocol cost. The protocol cost keeps almost constant between and reduces the control overhead of ODMRP. Additionally, we0.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 parametersize and the group size increase, the control overhead placed settings except that the square size was set to 150 m so that theon 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 accordinglyefficiency 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 in5 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 ofODMRP [8] which is widely used and considered to be robust the protocol under the dynamic environment and the followingover 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 packetsof 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 tobased on-demand non-geographic multicast protocol, and takes the total number of received packets over the number ofa 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 numbersource ID and the sequence number, and updates its routing of received data packets. Each forwarding of the controltable with the node ID (i.e. backward learning) from which the message was counted as one transmission. Different