a new wireless ad hoc multicast routing protocol

A new wireless ad hoc multicast routing protocol

Seungjoon Lee *, Chongkwon Kim

School of Computer Science and Engineering, Seoul National University, Seoul 151-742, South Korea

Received 16 May 2000; received in revised form 5 June 2001; accepted 25 June 2001

Responsible Editor: A. Campbell

Abstract

An ad hoc network is a multi-hop wireless network of mobile nodes without the intervention of fixed infrastructure.

Limited bandwidth and mobility require that ad hoc routing protocols be robust, simple, and energy conserving. This

paper proposes a new ad hoc multicast routing protocol called neighbor-supporting multicast protocol (NSMP). NSMP

adopts a mesh structure to enhance resilience against mobility. And NSMP utilizes node locality to reduce the overhead

of route maintenance. NSMP also attempts to improve route efficiency and reduce data transmissions. Our simulation

results show that NSMP delivers packets efficiently while substantially reducing control overhead in various envi-

ronments. � 2002 Elsevier Science B.V. All rights reserved.

Keywords: Ad hoc network; Multicast routing; Node locality

1. Introduction

An ad hoc network is a multi-hop wirelessnetwork formed by a collection of mobile nodeswithout the intervention of fixed infrastructure.Because an ad hoc network is infrastructure-lessand self-organized, it is used to provide im-promptu communication facilities in inhospitableenvironments. Typical application areas includebattlefields, emergency search and rescue sites, anddata acquisition in remote areas. An ad hoc net-work is also useful in classrooms and conventionswhere participants share information dynamicallythrough their mobile computing devices.

Each mobile node in an ad hoc network func-tions as a router to establish end-to-end connec-tions between any two nodes. Although a packetreaches all neighbors within transmission range, amobile node has limited transmission ranges andits signals may not reach all hosts. To providecommunications throughout the network, a se-quence of neighbor nodes from a source to adestination form a path and intermediate mobilehosts relay packets in a store-and-forward mode.

Unique characteristics of an ad hoc networkraise several requirements for the routing protocoldesign: ad hoc network routing must be simple,robust and minimize control message exchanges.Ad hoc routing must be simple because routing isperformed by generic mobile hosts which havelimited CPU and memory capacities and arepowered by batteries. Bandwidth is a scarce re-source in wireless networks. Routing algorithmswhich consume excessive bandwidth for routing

Computer Networks 38 (2002) 121–135

www.elsevier.com/locate/comnet

*Corresponding author.

E-mail addresses: [email protected] (S. Lee), ckim@

popeye.snu.ac.kr (C. Kim).

1389-1286/02/$ - see front matter � 2002 Elsevier Science B.V. All rights reserved.

PII: S 1 3 8 9 - 1 2 8 6 ( 0 1 ) 0 0 2 4 5 - 6

control message exchanges may not be appropriatefor wireless networks. The topology of an ad hocnetwork is inherently volatile and routing algo-rithms must be robust against frequent topologychanges caused by host movements.

Many routing schemes have been presented toprovide adequate performance of ad hoc net-works. Ad hoc routing is classified into proactiverouting and reactive routing based on when routesare determined. Proactive routing continuouslymakes routing decisions so that routes are imme-diately available when packets need to be trans-mitted. DBF [1], DSDV [2], WRP [3] are proactiverouting protocols. Reactive routing determinesroutes on an as-needed basis: when a node has apacket to transmit, it queries the network for aroute. TORA [4], DSR [5], AODV [6], ABR [7],RDMAR [8] belong to reactive routing. Proactiverouting consumes a great deal of radio resources toexchange routing information. Also, pre-deter-mined routes may rapidly lose their validity in anad hoc network because its topology changesrapidly. Previous study showed that reactive pro-tocols performed better than proactive protocols[9–11].

In addition to unicast routing protocols, severalmulticast routing protocols for ad hoc networkshave been proposed in more recent years [12–16].Unicast is a special form of multicast, and someproposed multicast routing protocols support bothunicast and multicast routing [12,13]. Proposedmulticast routing can be classified into tree-basedprotocols and mesh-based protocols. Tree-basedprotocols [12,15,16] build a tree that connects allmulticast members. Tree-based protocols are gen-erally more efficient than mesh-based protocols,but they are not robust against topology changesbecause there is no alternative path between asource and a destination. As a result, every linkfailure in a multicast tree may involve a set ofcontrol message exchanges for tree re-build. Con-trary to tree-based protocols where there is onlyone path between any two nodes, mesh-basedprotocols allow redundant paths between twonodes because mesh-based multicast protocolsprovide alternative paths and a link failure neednot trigger the recomputation of a mesh. Previousstudies showed that mesh-based protocols are ro-

bust against topology change and are more suit-able than tree-based protocols [14,17].

Although reactive routing protocol finds pathson demand and uses ‘‘soft state’’ to avoid staleroute information, route failure still occurs due tofrequent topology changes in ad hoc networks.Most ad hoc routing protocols have path mainte-nance mechanisms that provide adequate connec-tivity under topology changes. We can reduce thepath maintenance cost using old path informationand node locality information. One method toreduce the path maintenance cost is to use an oldpath segment and search a new path segmentstarting from the link failure point. ‘‘Expandedring search (ERS)’’ is typically used for the newpath segment search to further reduce the pathmaintenance cost. More recently, more system-atized efforts for localized repair have been pro-posed in the context of unicast routing [8,18].

ODMRP is an ad hoc multicast routing proto-col based on a multicast mesh [13]. In ODMRP, ifa source node has data to send, it periodicallybroadcasts ‘‘Join Request’’ to find and maintainmulticast routes. All the other nodes re-broadcastthe packet when they receive non-duplicate one.When a multicast group member receives ‘‘JoinRequest’’, the node replies with ‘‘Join Table.’’ Andsubsequent replies by the nodes along a reversepath establish a route. ODMRP uses soft states, soleaving a group is automatically handled bytimeout. As shown, ODMRP relies on frequentnetwork-wide flooding, which may lead to a sca-lability problem when the number of source nodesis large. The control packet overhead becomesmore prominent when the multicast group is smallin comparison with the entire network.

In this paper, we present a new on-demandmulticast routing protocol called neighbor-sup-porting multicast protocol (NSMP). NSMP is arobust, low overhead and efficient protocol. Wechoose to use the mesh infrastructure because re-silience against link failures is an importantproperty of ad hoc multicast routing. NSMP is thefirst multicast routing protocol that exploits nodelocality for route maintenance except for basicERS. Broadcasts are expensive operations in adhoc networks [19]. NSMP minimizes the frequencyof control message broadcasts. Broadcasts are

122 S. Lee, C. Kim / Computer Networks 38 (2002) 121–135

occasionally used for initial route establishment ora network partition repair. For normal and peri-odic mesh maintenances, control messages reachonly forwarding nodes and their neighbor nodes.In selecting a new route, NSMP prefers a path thatcontains existing forwarding nodes. Thus, NSMPenhances the route efficiency by reducing thenumber of forwarding nodes.

We have evaluated the performance of NSMPvia computer simulation. The simulation resultshows that NSMP is robust against frequent to-pology changes and delivers more than 96% ofdata packets under reasonable simulation envi-ronments. Moreover, data packet transmissionsand control message exchanges are reduced by5–30% compared to existing mesh-based ad hocmulticast routing protocols.

The rest of this paper is organized as follows.Section 2 contains an overview of NSMP, and amore detailed description of NSMP is presented inSection 3. Section 4 provides results of simulationexperiments, and Section 5 concludes the paper.

2. A new multicast routing protocol

2.1. An overview of NSMP

NSMP is a robust, yet efficient ad hoc multicastrouting protocol. Mesh infrastructure used inNSMP has resilience against link failures. A softstate approach is used, and routes are built andmaintained with basic route discovery and replymessages. NSMP also operates independent ofunicast routing protocol.

Localizing route discovery and maintenanceoperations, NSMP reduces the routing overhead.As discovered in RDMAR [8], most link failurerecoveries can be localized to a small region alonga previous route. NSMP performs two types ofroute discovery: flooding route discovery and localroute discovery. For routine path maintenances,NSMP uses local route discovery which is re-stricted only to a small set of mobile nodes directlyrelated to a multicast group. For an initial routeestablishment or a network partition repair,NSMP occasionally performs flooding route dis-covery in which control messages are broadcast by

all nodes. For long-lived connections, routine pathmaintenances occur many times more frequentlythan the initial path establishment, and the savingby localized path maintenance could be sizable.

NSMP attempts to achieve the route efficiencyof the multicast tree while enjoying the robustnessof the multicast mesh infrastructure. It is knownthat the mesh structure is more robust againsttopology changes than the tree structure [14,17].However, previous study [17] found that tree-based protocol transmits less data packets thanmesh-based protocol. In selecting a route, NSMPprefers a path that contains existing forwardingnodes to reduce the number of forwarding nodes.This enhances route efficiency, leading to lesscontention in the network.

2.2. Multicast mesh creation

A new source initially sends a FLOOD_REQpacket. The FLOOD_REQ packet has an up-stream node field. When an intermediate node re-ceives the FLOOD_REQ packet, it caches theupstream node and updates the field with its ownaddress before forwarding it to next nodes. Whena receiver receives the FLOOD_REQ packet, itsends a REP packet to the node from which itreceived the packet. The upstream node receivesthe REP packet and adds an entry for the group toits routing table. Then it forwards the REP packetto its own upstream node, and the REP packeteventually reaches the source node. The interme-diate nodes that relay the REP packet becomeforwarding nodes. A multicast mesh of a groupconsists of sources, receivers, forwarding nodes,and links connecting them. The nodes in a multi-cast mesh are called mesh nodes.

Fig. 1 illustrates how a multicast mesh is built.Assume that nodes 6 and 13 are receivers of amulticast group. When node 4 joins the group as asource, it broadcasts a FLOOD_REQ packet.Node 5 receives the packet and broadcasts it.When node 6 receives the FLOOD_REQ packet, itsends a REP packet to its upstream, node 5. Whennode 5 receives the REP packet, it knows that it ison the multicast mesh and relays the packet to itsupstream, node 4. Similarly, node 13 also sends aREP packet when it receives a FLOOD_REQ.

S. Lee, C. Kim / Computer Networks 38 (2002) 121–135 123

Although there are other reverse paths for thisREP to take (e.g. 13–12–8–4), we assume here thatREP takes the path (13–9–5–4) and that node 9becomes a forwarding node. Fig. 1(b) shows theresulting multicast mesh. When a source transmitsa DATA packet, only forwarding nodes relay thepacket, so that the packet is delivered to receiversalong an established mesh.

Now let us consider neighbor nodes of the mul-ticast mesh. Neighbor nodes are nodes that are di-rectly connected to at least one mesh node. In Fig.1(b), nodes 1, 2, 3, 7, 8, 10, 12, and 17 are theneighbor nodes. Forwarding nodes and groupneighbor nodes lose their function unless they arerefreshed within pre-defined timeout period. Sec-tion 3 shows detailed procedures of how amulticastmesh is built and a node becomes a group neighbor.

2.3. Multicast mesh maintenance

2.3.1. Local route discoveryEach source periodically transmits a LO-

CAL_REQ packet, and only mesh nodes andgroup neighbor nodes relay the packet. Therefore,all nodes two hops away from the mesh nodes

receive the LOCAL_REQ packet. This mechanismcan reduce control overhead, and due to node lo-cality, it repairs most link failures caused by nodemovements. REP packets to LOCAL_REQpackets are relayed to a source in the same way asREP packets to FLOOD_REQ packets in Section2.2. Forwarding nodes and group neighbor nodesalong a multicast mesh are updated as REPpackets are relayed to a source.

For example, assume that a failure occurs to alink (9, 13) in Fig. 2. Node 4 will eventually send aLOCAL_REQ packet since each source periodi-cally performs local route discovery. When node 8receives the packet, it broadcasts the packet sincegroup neighbor nodes relay LOCAL_REQ pack-ets. When node 12 subsequently broadcasts thepacket, node 13 receives it and sends a REP packetto build a new route to the source. The repairedmesh is shown in Fig. 2(b). Note that more than30% of the nodes (i.e. 6 nodes) in Fig. 2(a) do notre-broadcast the LOCAL_REQ packet.

Local route discovery ensures lower controloverhead, but it does not repair all link failures.Suppose that a link (8, 12) in Fig. 2(b) failed. Localroute discovery cannot repair this link failure.

Fig. 1. Multicast mesh creation (a) initial network and (b) after mesh creation.


With reasonable network connectivity, however,locally unrecoverable link failures occur less fre-quently than link failures that can be repaired bylocal route discovery. Simulation results in Section4 show that local route discovery is effective undervarious environments.

2.3.2. Flooding route discoveryNSMP uses flooding route discovery in several

cases. When a node becomes a new source, it sendsa FLOOD_REQ packet in order to create an ini-tial mesh. In NSMP, a node within two hops awayfrom mesh nodes can join the group as a receiverby replying to a LOCAL_REQ packet. However, anode more than two hops away from the meshnodes must flood a MEM_REQ packet. In addi-tion, network partitions only can be recovered byFLOOD_REQ packets.

2.4. Route efficiency improvement

In selecting a route, NSMP gives a preference toa path that contains more existing forwardingnodes. The level of preference is an importantparameter that trade-offs the routing efficiency and

path robustness. Assume that node 17 becomes anew receiver in Fig. 1(b). And further assume thatnode 17 receives two route discovery packets: onefrom the path (4, 5, 9, 13, 17) and the other fromthe path (4, 8, 12, 16, 17). Both paths have thesame length. However, the path (4, 5, 9, 13, 17)uses the existing path and the path (4, 8, 12, 16, 17)requires three new forwarding nodes. In terms ofroute efficiency, the former is better than the latter,and vice versa in terms of robustness.

3. Detailed description of NSMP

3.1. Data structures and packet header

Fig. 3 shows the packet header of NSMP. Wealso assume the availability of ttl field in otherprotocol (e.g. IP) used together. Forward Count(FC) denotes the number of forwarding nodesalong a path. A forwarding node increases the FCby one before relaying a route discovery packet.Non-forward Count (NC) is the number of non-forwarding nodes. Type field is one of the follow-ing values:

Fig. 2. Multicast mesh maintenance (a) link failure and (b) after local recovery.


• DATA: data packet,• FLOOD_REQ: flooding route discovery packet

sent by a group leader,• LOCAL_REQ: local route discovery packet

sent by a source,• MEM_REQ: route discovery packet sent by a

new receiver,• REP: reply packet to a route discovery packet.

Every node maintains a routing table. Fig. 4shows the fields of an entry in a routing table.When a node becomes a forwarding node of agroup, it sets corresponding ForwardingFlag. Itsets GroupNeighborFlag when it becomes a groupneighbor node. Forwarding timeout and Group-Neighbor timeout fields denote the times when anode loses its function.

In addition, every node maintains a DataCacheand a ReqCache to detect duplicate data packetsand route discovery packets, respectively. Thestructures of the two caches are shown in Fig. 5.Every source node needs to maintain a SourceListthat consists of source addresses of the samegroup.

3.2. Initiating and relaying FLOOD_REQ andLOCAL_REQ

When a node becomes a multicast source,it transmits an initial FLOOD_REQ packet.After that, all sources periodically transmitLOCAL_REQ packets at every REQ_PERIODinterval. REQ_PERIOD is important to the per-

formance of NSMP and should be carefully ad-justed according to network environments. Asbriefly discussed in Section 2.3, NSMP usesflooding to recover network partitions. For thispurpose, a group leader is selected among sources.The group leader sends FLOOD_REQ packets atevery FLOOD_PERIOD interval. Upstream andSource Address fields are set to its own address,and FC and NC are set to zero.

When a node receives a route discovery packet,it consults ReqCache to find whether the packet hasa more recent sequence number. (Group Address,Source Address, Sequence Number) fields inReqCache are used to determine if the packet isduplicate. If the packet is a new one, the receivingnode updates the corresponding entry of ReqCache

Fig. 3. Packet header of NSMP.

Fig. 4. Routing table used in NSMP.

Fig. 5. Caches used in NSMP (a) DataCache and (b) Req-

Cache.


to have correct information about Sequence Num-ber and Upstream.

A node relays all FLOOD_REQ packets.However, it relays LOCAL_REQ packets only if itis either a mesh node or a neighbor node of thegroup. Before relaying a route discovery packet, anode must change Upstream field with its ownaddress for later reverse path establishment. Arelaying node increments FC by one if it is a for-warding node; otherwise, NC is incremented byone. Handling duplicate route discovery packets isdescribed in Section 3.3.

3.3. Initiating and relaying REP

A path from a source to a receiver is establishedwhen a REP packet is forwarded along the reversepath from the receiver to the source. The reversepath is already recorded in the Upstream field ofthe ReqCache. When an intermediate node receivesthe REP packet, it sets the ForwardingFlag bit andrefreshes the Forwarding timeout of its routingtable. Then the intermediate node relays the REPpacket to its upstream node. Note that a packet isbroadcast to all neighbor nodes in wireless net-work. All nodes that detect the REP packet (ex-cept mesh nodes) become neighbor nodes of thegroup. The neighbor nodes set the GroupNeigh-borFlag and refresh the GroupNeighbor timeout ofits routing table.

As explained before, NSMP tries to balance therouting efficiency and path robustness, givingpreference to paths that contain more forwardingnodes. A receiver receives many route discoverypackets. When a receiver receives a first non-duplicate route discovery packet, it stores the in-formation of the packet header into ReqCache anddelays sending REP for a short time. It computesthe weighted path length, using different weightsfor FC and NC. The choice of these weights is alsoimportant in achieving route efficiency and resil-ience against mobility. If the receiver receives an-other route discovery packet within the waitingperiod, it computes the weighted path length. Ifthe new path is better than the currently best path,then the receiver replaces the ReqCache with theinformation of the new path. It sends a REPpacket using the information of the best path

stored in ReqCache after pre-determined timeelapses since the non-duplicate route discoverypacket reception. When an intermediate node re-ceives a duplicate route discovery packet, it alsochecks if the new weighted path length is betterthan the one in ReqCache. If so, it stores the betterupstream node in ReqCache. This information isnot further relayed but used later if it receives aREP packet and needs to relay it to its upstreamnode.

NSMP ensures partition recovery by perform-ing flooding route discovery. When previouslydisconnected partitions have regained connecti-vity, a FLOOD_REQ packet from one partitionwill eventually reach a receiver in another parti-tion. Partition is recovered when a REP packet issent and relayed across previous partitions. LargerFLOOD_PERIOD may introduce longer delay inpartition recovery, so flooding route discoveryneeds to be performed more often in case of lowernetwork connectivity.

3.4. Becoming a group neighbor

In previous subsection, we already explainedthe procedure of when a node becomes a neighbornode of a multicast group. Another case to becomea group neighbor is when a non-mesh node findsthat one of its neighbors is a source. If Upstreamfield of a route discovery packet is the same asSource Address field of the packet, the node be-comes a group neighbor. Table 1 summarizes nodebehaviors when it receives route discovery packets.

3.5. Receiving and forwarding DATA packets

When a node receives a DATA packet, it con-sults DataCache to see if the packet is duplicate. Ifso, it discards the packet. Otherwise, it updatesDataCache to reflect the packet header informa-tion, especially the sequence number. And thepacket is re-broadcast if the receiving node is aforwarding node.

3.6. Joining and leaving a group

When a node wants to join a group as a re-ceiver, it waits for a LOCAL_REQ packet for


REQ_PERIOD. It will receive one and be ableto build a route if it is a mesh node, a neighbornode of the group, or two hops away from themesh. For example, nodes 11, 14, and 18 in Fig.2(b) will receive a LOCAL_REQ packet withinREQ_PERIOD.

If the new receiver does not receive aLOCAL_REQ packet, it broadcasts a MEM_REQ packet. On receiving a MEM_REQ packet,a node operates analogous when it receives aFLOOD_REQ packet; it needs to update an entryin ReqCache. MEM_REQ uses a ttl field. Allnodes that receive a MEM_REQ packet relay thepacket only if ttl value is greater than zero. ttlvalue is decremented by one whenever it is relayed.

Source nodes and forwarding nodes send a REPpacket when they receive a MEM_REQ packet.REP packets to MEM_REQ packets are relayedtoward the new receiver in the same way as REPpackets to FLOOD_REQ or LOCAL_REQ. Thereception of a REP packet to a MEM_REQpacket also requires routing table update. Andsome nodes become forwarding nodes or neighbornodes according to Upstream field of the REPpacket.

NSMP uses ERS to reduce the bandwidth usagefor MEM_REQ packets. The value of ttl field inthe initial MEM_REQ is set to three because thenew receiver sending MEM_REQ (e.g., node 15 or19 in Fig. 2(b)) is more than two hops away fromthe mesh. If the new receiver fails to receive anyREP packet within timeout, then it floods aMEM_REQ packet.

Multiple REP packets to a MEM_REQ packetmay increase the number of forwarding nodesmore than necessary. This problem, however, willbe resolved by timeout since only one path will be

refreshed when the receiver receives route discov-ery packets and replies to them.

Leaving a group in NSMP does not need anyadditional control messages. When a node leaves agroup, it does not send REP packets to subsequentroute discovery packets, and soft states stored inintermediate nodes will expire.

3.7. Electing a group leader

A group leader is the source node whose ad-dress is the smallest among source nodes in thesame multicast group. Since every source periodi-cally sends a LOCAL_REQ packet, a source canhave up-to-date information about other sources.When a source receives a LOCAL_REQ packetfrom another source of the same group, it updatesSourceList to include the source address. With thisinformation, a source can determine if its addressis the smallest or not. An entry in a SourceList isdeleted if no LOCAL_REQ packets from thecorresponding source are received within pre-determined time, for example, two times REQ_PERIOD.

4. Performance simulation

4.1. Simulation environment

ns-2 simulator was used for performance simu-lation. ns-2 is originally developed by the Univer-sity of California at Berkeley and the VINTproject [20] and recently extended to provide sim-ulation support for ad hoc networks by theMONARCH project [21] at Carnegie MellonUniversity. Ref. [9] gives a detailed description

Table 1

Summary of node behaviors when a route discovery packet arrives

Route discovery Source Receiver Forwarding node Group neighbor Other node

Flooding Update SourceTable Send REP � ��Relay Relay Relay Relay Relay

Local Update SourceTable Send REP � ��Relay Relay Relay Relay

� GroupNeighbor timeout is refreshed if Source Address ¼ Upstream.

�� The node becomes a group neighbour if Source Address ¼ Upstream.


about physical layer, data link layer, and IEEE802.11 MAC protocol used in the simulation.

The protocol simulation consists of 50 wirelessmobile nodes forming an ad hoc network, movingaround over a square (1000� 1000 m) flat spacefor 300 s of simulated time. Nodes move accordingto the ‘‘random waypoint’’ model [9] withoutpause time. A multicast source generates 128-bytedata packets with constant bit rate (CBR) of eightpackets per second.

A number of movement scenario files and groupscenario files were generated and used as inputs tothe simulations. Each movement scenario file re-cords movements of 50 mobile nodes, and thespeeds of mobile nodes are uniformly distributedup to a maximum speed. Group scenario files de-scribe receiver and source nodes and also describethe time when they join and leave a group. Eachgroup scenario file has one multicast group.However, in one experiment, we use three groupscenarios on average to simulate the multiplegroup environments.

In comparing the protocols, the followingmetrics were used:

• Data Packet Delivery Ratio: The percentage ofdata packets correctly delivered to multicast re-ceivers.

• Number of Data Transmissions per Data PacketDelivered: This metric reveals how efficiently aprotocol establishes a path.

• Number of Control Packets per Data Packet De-livered: This metric represents control overheadof each protocol.

We compare the performance of NSMP withthose of ODMRP and MAODV (multicastAODV) [12]. It was assumed that no nodes wereequipped with GPS, so a source in ODMRP pe-riodically flooded ‘‘Join Request’’ packets. Wefound that ‘‘Join Request’’ period and REQ_PERIOD of two seconds showed reasonable per-formance in terms of data delivery ratio andcontrol overhead. So in the following simulationexperiments, we set both ‘‘Join Request’’ period inODMRP and REQ_PERIOD in NSMP to twoseconds. And recommended parameter constantswere used for MAODV [12]. MAODV used link-

layer unicast for all data transmissions while link-layer broadcast was used for NSMP and ODMRPdata transmissions. And MAODV exploited link-layer ACK to maintain local connectivity. Al-though IEEE 802.11 uses additional controlpackets for unicast, we did not count MAClayer control packets for control overhead forMAODV. We used the same movement scenariosand the same group scenarios.

4.2. Simulation results

4.2.1. Experiments on NSMP parametersWe first experimented on the impact of

FLOOD_PERIOD on data delivery ratio andcontrol overhead of NSMP. If FLOOD_PERIODis long, less flooding route discovery operationswill decrease control overhead, but data deliveryratio may drop due to more locally unrecoverablelink failures. Since more sources with NSMP tendto increase mesh resilience, we used multicastgroups of one source to isolate the effect of dif-ferent FLOOD_PERIOD. We assumed five re-ceivers per group and set maximum node speed to20 m/s. Different values of FLOOD_PERIOD (2,20, and 100 s) were used with different transmis-sion ranges. We also investigated the highest pos-sible data delivery ratio as different transmissionranges led to different network topology.

In Fig. 6, we can observe that packet deliveryratio improves up to 6% when FLOOD_PERIODreduces from 100 to 20 s. However, further reduc-tion of FLOOD_PERIOD from 20 to 2 s have mar-ginal impact on packet delivery ratio. Fig. 6 alsoillustrates that shorter transmission range causeslower data delivery ratio due to frequent networkpartition. Note that when FLOOD_PERIOD isset to 2 s, NSMP performs flooding route discov-ery only. When FLOOD_PERIOD is 20 s, locallyunrecoverable link failures occur infrequently, sodata delivery ratio is similar to that with 2 s.However, when FLOOD_PERIOD increases to100 s, data delivery ratio drops significantly. Andthere was no significant difference in controloverhead when FLOOD_PERIOD changes from20 to 100 s. Considering data delivery ratio andcontrol overhead, we set FLOOD_PERIOD to 20s in the following experiments.


We also simulated to study the impact of pre-ferring forwarding nodes in establishing a reversepath. We used the following metric function:

Metric ¼ ð1� aÞ � FCþ a�NC; 06 a6 1:

And a path of smaller metric was selected as areverse path. Here, ameans relative weight for FC.A large a reduces the number of forwarding nodesand achieves route efficiency at the cost of a lessresilient multicast mesh. In the other way, asmaller a tends to include more forwarding nodesbut makes the mesh more robust. In the followingsimulation, we varied a from 0.4, 0.5 to 0.6.Transmission range was set to 250 m, and themaximum node speed was set to 10 m/s. A grouphad two sources, and we changed group sizes from5 to 20.

Fig. 7 shows the packet delivery ratio as afunction of the group size varying a ¼ 0:4, 0.5 and0.6. In this figure, we can observe that the groupsize does not have great impact on the packet de-livery ratio. We can also observe that the weight, a,has marginal effects on the packet delivery ratio.However, Fig. 8, which shows the ‘‘Data packet/

Total delivered packet’’ ratio as a function of thegroup size, reveals that larger a reduces the over-head of redundant packet transmissions signifi-cantly. When a increases from 0.4 to 0.6, thedelivery ratio degradation is less than 1%. How-ever, data transmissions are reduced by around20%. We used 0.6 as the relative weight value inthe following experiments.

In Fig. 7, as group size increases, data deliveryratio of NSMP slightly drops. Also, data deliveryratio difference between different a’s becomessmaller since more group members tend to lead tomore resilient multicast meshes. In Fig. 8, we canobserve that data transmission per delivered datapacket decreases as group members increase. It isbecause the number of forwarding nodes does notincrease in proportion to the number of receiverssince data path to each receiver can be shared.

4.2.2. Performance comparisonWe simulated and compared the performance

of NSMP with those of ODMRP and MAODV.First, we investigated the impact of node mobilityon each protocol. We varied the maximum node

Fig. 6. Data delivery ratio with different FLOOD_PERIOD.


Fig. 7. Data delivery ratio with different weight.

Fig. 8. Data packet transmissions with different weight.


speed to study the resilience of protocols againstthe node mobility. A group has two source nodesand five receivers. Transmission range is set to 250meters.

Fig. 9 shows the packet delivery ratio as afunction of the maximum node speed. All threeprotocols deliver data packets well when there isno node mobility. However, performance of tree-based MAODV degrades rapidly as the nodespeed increases. This performance degradation isdue to frequent tree link failures. Since meshstructure of NSMP and ODMRP provides alter-native paths, their data delivery ratios are higher incase of node mobility. We can observe thatNSMP’s data delivery ratio is comparable to thatof ODMRP (within 1% difference). The perfor-mance gap between ODMRP and NSMP is due tothe fact that NSMP performs local failure recoverywhile ODMRP performs global failure recovery.

Fig. 10 illustrates data transmission overhead asa function of the maximum node speed. In general,MAODV has lower data transmission overheadthan the other two protocols. However, the over-head of NSMP is as low as that of MAODV. This

result endorses that the route created by NSMPis as efficient as that of tree-based protocols. Theoverhead of ODMRP is 20–30% larger than thatof NSMP and MAODV. In Figs. 10 and 11, wecan conclude that NSMP achieves the robustnessof mesh-based protocols while enjoying the effi-ciency of tree-based protocols. Control overhead isreported in Fig. 11. MAODV incurs the lowestcontrol overhead. 1 NSMP decreases controloverhead by 5–15% compared to ODMRP usinglocalized route discovery.

Fig. 12 shows the packet delivery ratio as afunction of the number of sources to investigatethe scalability of NSMP. In the simulation, trans-mission range is fixed to 250 m, maximum speed isset to 10 m/s, and a group has five receivers.ODMRP and NSMP perform better than MAODVin all cases. The performance of both NSMP andODMRP increases as the number of source in-creases from one to two. We guess that the

Fig. 9. Comparison of data delivery ratio with mobility change.

1 Note that we did not include control overhead for link-

layer unicast.


Fig. 10. Comparison of data transmissions with mobility change.

Fig. 11. Comparison of control overhead with mobility change.


performance improvement is due to the increasedredundancy of multicast meshes. However, as thenumber of source nodes increases further, theperformance decreases due to increased traffic.However, because NSMP reduces both control anddata packet transmissions, it exhibits less severeperformance degradation in data delivery ratiothan other two protocols. As overall networktraffic grows higher, NSMP begins to show the bestdata delivery ratio.

5. Conclusions

This paper has proposed a new on-demandmulticast routing protocol for ad hoc networks.The new routing scheme, NSMP, is based onmulticast meshes and designed to minimize datatransmissions and control overhead in maintainingthe meshes. A key concept is to localize controlmessages to a small set of mesh nodes and groupneighbor nodes and minimize the frequency ofnetwork-wide flooding. NSMP also attempts toimprove route efficiency by giving preference toforwarding nodes in establishing a route. This

leads to reduction in data packet transmissionsand less contention in a network.

We simulated NSMP using ns-2 simulator, andsimulation results reveal that NSMP effectivelyroutes data packets. And NSMP substantially re-duces control overhead and decreases data packettransmissions compared to ODMRP. Also, a meshcreated by NSMP is efficient, and the number ofdata transmissions of NSMP is as low as tree-based MAODV. NSMP scales well with increasinggroup size and sources, and node mobility. Futureresearch could be on how to adjust the period ofroute discovery packets under various mobilityand traffic environments.

References

[1] D. Bertsekas, R. Gallager, Data Network, second edition,

Prentice-Hall, Englewood Cliffs, NJ, 1992, pp. 404–410.

[2] C. Perkins, P. Bhagwat, Highly dynamic destination-

sequenced distance-vector routing (DSDV) for mobile

computers, ACM SIGCOMM, October 1994.

[3] S. Murthy, J.J. Garcia-Luna-Aceves, An efficient routing

protocol for wireless networks, ACM Mobile Networks

Fig. 12. Comparison of data delivery ratio with increasing number of sources.


and Applications Journal, Special issue on Routing in

Mobile Communication Networks, 1996.

[4] V. Park, S. Corson, Temporally-Ordered Routing Algo-

rithm (TORA), ver. 1, Internet draft, IETF, August 1998.

[5] J. Broch, D.B. Johnson, D.A. Maltz, The dynamic source

routing in ad hoc wireless networks, in: T. Imielinski, H.

Korth (Eds.), Mobile Computing, Kluwer Academic Pub-

lishers, Dordrecht, 1996, pp. 153–181 (Chapter 5).

[6] C. Perkins, E.M. Royer, S.R. Das, Ad Hoc on Demand

Distance Vector (AODV) routing, Internet draft, IETF,

June 1999.

[7] C.K. Toh, Long-lived Ad Hoc Routing based on the Con-

cept of Associativity, Internet draft, IETF, March 1999.

[8] G. Aggelou, R. Tafazolli, RDMAR: a bandwidth-efficient

routing protocol for mobile ad hoc networks, Proceedings

of The Second ACM International Workshop on Wireless

Mobile Multimedia (WoWMoM), Seattle, WA, August

1999.

[9] J. Broch, D.A. Maltz, D.B. Johnson, Y. Hu, J. Jetcheva, A

performance comparison of multi-hop wireless ad hoc

network routing protocols, Proceedings of the Fourth

Annual ACM/IEEE International Conference on Mobile

Computing and Networking, Dallas, TX, October 1998.

[10] P. Johansson, T. Larsson, N. Hedman, B. Mielczarek,

M. Degermark, Scenario-based performance analysis of

routing protocols for mobile ad-hoc networks, Mobi-

Com’99, August 1999.

[11] S. Corson, J. Macker, Mobile Ad hoc Networking

(MANET): Routing Protocol Performance Issues and Eval-

uation Considerations, RFC 2501, IETF, January 1999.

[12] E. Royer, C.E. Perkins, Multicast operation of the ad-hoc

on-demand distance vector routing protocol, Mobi-


[13] S. Lee, W. Su, M. Gerla, Ad hoc wireless multicast with

mobility prediction, IEEE ICCCN’99, Boston, MA, Octo-

ber 1999.

[14] J.J. Garcia-Luna-Aceves, E.L. Madruga, The core-assisted

mesh protocol, IEEE J. Selected Area Commun. (Special

Issue on Ad-Hoc Networks) 17 (8) (1999).

[15] C.W. Wu, Y.C. Tay, C.-K. Toh, Ad hoc Multicast Routing

Protocol Utilizing Increasing id-numbers (AMRIS) Func-

tional Specification, Internet draft, IETF, November 1998.

[16] E. Bommaiah, M. Lui, A. McAuley, R. Talpade, AMRo-

ute: Adhoc Multicast Routing Protocol, Internet draft,

IETF, August 1998.

[17] S. Lee, W. Su, J. Hsu, M. Gerla, R. Bagrodia, A

performance comparison study of ad hoc wireless multicast

protocols, INFOCOM 2000, March 2000.

[18] R. Castaneda, S. Das, Query localization techniques for

on-demand routing protocols in ad hoc networks, Mobi-


[19] S.-Y. Ni, Y.-C. Tseng, Y.-S. Chen, J.-P. Sheu, The

broadcast storm problem in a mobile ad hoc network,

MobiCom’99, August 1999.

[20] K. Fall, K. Varadhan (Eds.), ns notes and documentation,

The VINT Project, UC Berkeley, LBL, USC/ISI and Xerox

PARC, November 1997. Available at http://www-

mash.cs.berkeley.edu/ns/.

[21] The CMU Monarch Project’s Wireless and Mobility

Extensions to ns, The CMU Monarch Project, August

1999. Available at http://www.monarch.cs.cmu.edu/.

Seungjoon Lee was born in Korea in1973. He received B.S. degree andM.S. degree in Computer Science fromSeoul National University, Seoul,Korea, in 1996 and 2000, respectively.He is a Ph.D. student of Departmentof Computer Science, University ofMaryland, College Park. His researchinterests are wireless networks, dis-tributed systems, and performanceevaluation.

Chong-kwon Kim was born in Korea in1958. He received the B.S. degree inindustrial engineering from Seoul Na-tional University, the M.S. degree inoperations research from Georgia In-stitute of Technology, and the Ph.D.degree in Computer Science fromUniversity of Illinois at Urbana-Champaign in 1981, 1982, and 1987,respectively. In 1987, he joined Bell-core as an MTS in Applied Research.He worked on Broadband ISDNswitching, ATM QoS support, andtraffic management problems in Bell-

core. Since February 1991, he has been with Seoul NationalUniversity as a Professor in the School of Computer Scienceand Engineering. His current research interests are wirelessnetworks, high speed network control, distributed processing,and performance evaluation.


a new wireless ad hoc multicast routing protocol

Documents