1
A Performance Comparison Study of Ad Hoc
Wireless Multicast Protocols
Sung-Ju Lee, William Su, Julian Hsu, Mario Gerla, and Rajive Bagrodia
Wireless Adaptive Mobility Laboratory
Computer Science Department
University of California
Los Angeles, CA 90095-1596
http://www.cs.ucla.edu/NRL/wireless
Abstract—In this paper we investigate the performance of multicast rout-
ing protocols in wireless mobile ad hoc networks. An ad hoc network is
composed of mobile nodes without the presence of a wired support infras-
tructure. In this environment, routing/multicasting protocols are faced with
the challenge of producing multihop routes under host mobility and band-
width constraints. In recent years, a number of new multicast protocols of
different styles have been proposed for ad hoc networks. However, system-
atic performance evaluations and comparative analysis of these protocols in
a common realistic environment has not yet been performed. In this study,
we simulate a set of representative wireless ad hoc multicast protocols and
evaluate them in various network scenarios. The relative strengths, weak-
nesses, and applicability of each multicast protocol to diverse situations are
studied and discussed.
I. INTRODUCTION
N ad hoc network[13], [15]is a dynamicallyreconfigurable
wireless network with no fixed infrastructure or central ad-
ministration. Due to the limited radio propagation range of wire-
less devices, routes are often “multihop.” Applications such as
disaster recovery, crowd control, search and rescue, and auto-
mated battlefields are typical examples of where ad hoc net-
works are deployed. Nodes in these networks move arbitrarily,
thus network topology changes frequently and unpredictably.
Moreover, bandwidth and battery power are limited. These
constraints, in combination with the dynamic network topology
make routing and multicasting in ad hoc networks extremely
challenging.
In a typical ad hoc environment, network hosts work in
groups to carry out a given task. Hence, multicast plays an im-
portant role in ad hoc networks. Multicast protocols used in
static networks (e.g., Distance Vector Multicast Routing Pro-
tocol (DVMRP) [7], Multicast Open Shorted Path First (MO-
SPF) [23], Core Based Trees (CBT) [2], and Protocol Indepen-
dent Multicast (PIM) [8]) do not perform well in ad hoc net-
works because multicast tree structures are fragile and must be
readjusted as connectivitychanges. Furthermore, multicast trees
usually require a global routing substructure such as link state
or distance vector. The frequent exchange of routing vectors
or link state tables, triggered by continuous topology changes,
yields excessive channel and processing overhead.
Various multicast protocols have been newly proposed to per-
form multicasting in ad hoc networks. However, no perfor-
mance study between them has yet been performed. The com-
This work was funded in part by the Defense Advanced Research Projects
Agency (DARPA) under contract DAAB07-97-C-D321, as a part of the Global
Mobile Information Systems (GloMo) program.
parative analysis of ad hoc unicast routing protocols has been re-
ported in [4], [6], [14], [20], but this paper is the first to conduct
a performance comparison study of ad hoc wireless multicast
protocols in a realistic common simulation environment. By us-
ing a detailed simulator, we provide quantitative performance
analysis of five protocols with different characteristics: AM-
Route [3], ODMRP [17], [18], [19], AMRIS [29], CAMP [10],
[11], [21], [22], and flooding. In addition to multicast routing
protocols, we also implemented a detailed and realistic model of
physical and medium access control layer protocols.
The five multicast routingprotocols were simulated in diverse
network scenarios. We studied the impact of mobility on perfor-
mance by varying the speed of network hosts. We varied the
number of data packet senders to emulate a variety of different
multicast applications. One source to many receivers can corre-
spond to battlefield data dissemination. Many sources to many
receivers can correspond to search and rescue team communi-
cation. Different multicast group member sizes were simulated
to investigate the impact on performance. Various traffic loads
were also applied to study how traffic patterns influence mul-
ticast protocol performance. We apply metrics that show the
“efficiency” in addition to the “effectiveness” of the protocols.
Understanding the protocol’s efficiency gives us the ability to
study and discuss relative strengths, weaknesses, and applica-
bility to various situations for each multicast routing protocol.
The rest of the paper is organized as follows. Section II
presents an overview of the multicast protocols we simulate.
The simulation environment and methodology are described in
Section III, followed by simulation results in Section IV. Merits
and shortcomings of each multicasting algorithm are discussed
in Section V and concluding remarks are made in Section VI.
II. MULTICAST PROTOCOLS REVIEW
In this section, we introduce the ad hoc wireless multicast
protocols we have selected. Basic operation procedures and im-
plementation choices are described.
A. Adhoc Multicast Routing (AMRoute)
AMRoute [3] is a tree based protocol. It creates a bidirec-
tional shared multicast tree using unicast tunnels to provide con-
nections between multicast group members. Each group has at
least one logical core that is responsible for member and tree
maintenance. Initially, each group member declares itself as
2
TABLE I
PARAMETER VALUES FOR AMROUTE
Periodic JOIN-REQ interval 60 sec
Periodic JOIN-REQ interval when no 5 sec
group members are connected to the core
Periodic TREE-CREATE interval 20 sec
TREE-CREATE timeout 40 sec
Core resolution algorithm Highest ID
a core for its own group of size one. Each core periodically
floods JOIN-REQS (using an expanding ring search) to discover
other disjoint mesh segments for the group. When a member
node receives a JOIN-REQ from a core of the same group but a
different mesh segment, it replies with a JOIN-ACK and marks
that node as a mesh neighbor. The node that receives a JOIN-
ACK also marks the sender of the packet as its mesh neighbor.
After the mesh creation, each core periodically transmits TREE-
CREATE packets to mesh neighbors in order to build a shared
tree. When a member node receives a non-duplicate TREE-
CREATE from one of its mesh links, it forwards the packet to
all other mesh links. If a duplicate TREE-CREATE is received, a
TREE-CREATE-NAK is sent back along the incoming link. The
node receiving a TREE-CREATE-NAK marks the link as mesh
link instead of tree link. The nodes wishing to leave the group
send the JOIN-NAK to the neighbors and do not forward any
data packets for the group.
The key characteristic of AMRoute is its usage of virtual
mesh links to establish the multicast tree. Therefore, as long
as routes between tree members exist via mesh links, the tree
need not be readjusted when network topology changes. Non-
members do not forward data packets and need not support any
multicast protocol. Thus, only the member nodes that form the
tree incurs processing and storage overhead. AMRoute relies on
an underlying unicast protocol to maintain connectivity among
member nodes and any unicast protocol can be used. The ma-
jor disadvantage of the protocol is that it suffers from temporary
loops and creates non-optimal trees when mobility is present.
Table I shows the AMRoute parameter values used in our ex-
periments. The implementation followed the specification in
[3].
B. On-Demand Multicast Routing Protocol (ODMRP)
ODMRP [17], [18], [19] creates a mesh of nodes (the “for-
warding group”) which forward multicast packets via flooding
(within the mesh), thus providing path redundancy. ODMRP
is an on-demand protocol, thus it does not maintain route in-
formation permanently. It uses a soft state approach in group
maintenance. Member nodes are refreshed as needed and do not
send explicit leave messages.
In ODMRP, group membership and multicast routes are es-
tablished and updated by the source on demand. Similar to
on-demand unicast routing protocols, a request phase and a re-
ply phase comprise the protocol. When multicast sources have
data to send, but do not have routing or membership informa-
tion, they flood a JOIN DATA packet. When a node receives a
non-duplicate JOIN DATA, it stores the upstream node ID (i.e.,
TABLE II
PARAMETER VALUES FOR ODMRP
JOIN DATA refresh interval 3 sec
Acknowledgment timeout for JOIN TABLE 25 msec
Maximum JOIN TABLE retransmission 3
backward learning) and rebroadcasts the packet. When the JOIN
DATA packet reaches a multicast receiver, the receiver creates a
JOIN TABLES and broadcasted to the neighbors. When a node
receives a JOIN TABLE, it checks if the next node ID of one of
the entries matches its own ID. If it does, the node realizes that
it is on the path to the source and thus is part of the forward-
ing group. It then broadcasts its own JOIN TABLE built upon
matched entries. The JOIN TABLE is thus propagated by each
forwarding group member until it reaches the multicast source
via the shortest path. This process constructs (or updates) the
routes from sources to receivers and builds a mesh of nodes,
the forwarding group. Multicast senders refresh the member-
ship information and update the routes by sending JOIN DATA
periodically.
In networks where GPS (Global Positioning System) [16] is
available, ODMRP can be made adaptive to node movements
by utilizing mobility prediction [19]. By using location and mo-
bility information supported by GPS, route expiration time can
be estimated and receivers can select the path that will remain
valid for the longest time. With the mobility prediction method,
sources can reconstruct routes in anticipation of route breaks.
This way, the protocol becomes more resilient to mobility. The
price is, of course, the cost and additional weight of GPS. The
details of mobility prediction and the procedure are described in
[19].
The data transfer phase is identical for both versions. Nodes
forward the data if they are forwarding nodes and the packet
they receive is not a duplicate. Since all forwarding nodes re-
lay data, redundant paths (when they exist) can help deliver data
when the primary path becomes disconnected because of mo-
bility. Another unique property of ODMRP is its unicast capa-
bility. Not only can ODMRP coexist with any unicast routing
protocol, it can also operate very efficiently as unicast routing
protocol. Thus, a network equipped with ODMRP does not re-
quire a separate unicast protocol.
The specification in [19] was used in our implementation. For
consistency with comparison, we used the version without mo-
bility prediction. ODMRP parameter values used are shown in
Table II.
C. Ad hoc Multicast Routing protocol utilizing Increasing id-
numberS (AMRIS)
AMRIS [29] establishes a shared tree for multicast data for-
warding. Each node in the network is assigned a multicast ses-
sion ID number. The ranking order of ID numbers is used to
direct the flow of multicast data. Like ODMRP, AMRIS does
not require a separate unicast routing protocol.
Initially, a special node called Sid broadcasts a NEW-
SESSION packet. The NEW-SESSION includes the Sid’s msm-id
(multicast session member id). Neighbor nodes, upon receiving
3
TABLE III
PARAMETER VALUES FOR AMRIS
Periodic beacon interval 1 sec
Max allowed beacon losses 3
NEW SESSION lifetime 3 sec
Acknowledgment timeout for JOIN-REQ 2 sec
Random broadcast jitter time 50 msec
the packet, calculate their own msm-ids which are largerthan the
one specified in the packet. The msm-ids thus increase as they
radiate from the Sid. The nodes rebroadcast the NEW-SESSION
message with the msm-id replaced by their own msm-ids. Each
node is required to broadcast beacons to its neighbors. The bea-
con message contains the node id, msm-id, membership status,
registered parent and child’s ids and their msm-ids, and partition
id. A node can join a multicast session by sending a JOIN-REQ.
This JOIN-REQ is unicasted to a potential parent node with a
smaller msm-id than the node’s msm-id. The node receiving the
JOIN-REQ sends back a JOIN-ACK if it already is a member of
the multicast session. Otherwise, it sends a JOIN-REQ.PASSIVE
to its potential parent. If a node fails to receive a JOIN-ACK
or receives a JOIN-NAK after sending a JOIN-REQ, it performs
“Branch Reconstruction (BR).” The BR process is executed in
an expanding ring search until the node succeeds in joining the
multicast session.
AMRIS detects link disconnection by a beaconing mecha-
nism. If no beacons are heard for a predefined interval of time,
the node considers the neighbor to have moved out of radio
range. If the former neighbor is a parent, the node must rejoin
the tree by sending a JOIN-REQ to a new potential parent. If the
node fails to join the session or no qualified neighbors exist, it
performs the BR process.
Data forwarding in done by the nodes in the tree. Only the
packets from the registered parent or registered child are for-
warded. Hence, if the tree link breaks, the packets are lost until
the tree is reconfigured.
Our AMRIS implementation followed the specification in
[29]. The AMRIS parameter values are shown in Table III.
D. Core-Assisted Mesh Protocol (CAMP)
CAMP [10], [11], [21], [22] supports multicasting by creat-
ing a shared mesh structure. All nodes in the network maintain
a set of tables with membership and routing information. More-
over, all member nodes maintain a set of caches that contain
previously seen data packet information and unacknowledged
membership requests. CAMP classifies nodes in the network as
duplex or simplex members, or non-members. Duplex members
are full members of the multicast mesh, while simplex mem-
bers are used to create one-way connections between sender-
only nodes and the rest of the multicast mesh. “Cores” are used
to limit the flow of JOIN REQUEST packets.
CAMP consists of mesh creation and maintenance proce-
dures. A node wishing to join a multicast mesh first consults
a table to determine whether it has neighbors which are already
members of the mesh. If so, the node announces its membership
via a CAMP UPDATE. Otherwise, the node either propagates a
TABLE IV
PARAMETER VALUES FOR CAMP
Number of cores in the network 1
Periodic beacon interval 3 sec
Periodic update interval 3 sec
Age out anchor timeout 45 sec
Heartbeat interval 15 sec
Request retransmission interval 9 sec
Max number of JOIN REQUEST retransmission 3
JOIN REQUEST towards one of the multicast group “cores,” or
attempts to reach a member router by an expanding ring search
of broadcast requests. Any duplex member of the node can re-
spond with a JOIN ACK, which is propagated back to the source
of the request.
Periodically, a receiver node reviews its packet cache in or-
der to determine whether it is receiving data packets from those
neighbors which are on the reverse shortest path to the source. If
not, the node sends either a HEARTBEAT or a PUSH JOIN mes-
sage towards the source along the reverse shortest path. This
process ensures that the mesh contains all such reverse shortest
paths from all receivers to all senders. The nodes also period-
ically choose and refresh their selected “anchors” to the multi-
cast mesh by broadcasting updates. These anchors are neighbor
nodes which are required to re-broadcast any non-duplicate data
packets they receive. A node is allowed to discontinue anchor-
ing neighbor nodes which are not refreshing their connections.
It can then leave the multicast mesh if it is not interested in the
multicast session and is not required as anchor for any neighbor-
ing node.
CAMP relies on an underlying unicast routing protocol which
guarantees correct distances to all destinations within finite
time. Routing protocols that are based on the Bellman-Ford al-
gorithm cannot be used with CAMP, and CAMP needs to be
extended in order to work with on-demand routing protocols.
Our implementation of CAMP followed the specification in
[10]. Table IV shows the CAMP parameter values used in our
simulation. Periodic beacon interval is 3 seconds, but the bea-
con is sent only when no packet has been transmitted during the
beacon interval.
E. Protocol Summary
Table V summarizes key characteristics and properties of the
protocols we simulated. Note that ODMRP requires periodic
TABLE V
SUMMARY OF PROTOCOLS
Protocols AMRoute ODMRP AMRIS CAMP Flood
Configuration Tree Mesh Tree Mesh Mesh
Loop-Free No Yes Yes Yes Yes
Dependency on Yes No No Yes No
Unicast Protocol
Periodic Messaging Yes Yes Yes Yes No
Control Packet Flood Yes Yes Yes No No
4
messaging (JOIN DATA) only when sources have data packets
to send.
III. SIMULATION MODEL AND METHODOLOGY
The simulator for evaluating multicasting protocols was im-
plemented within the GloMoSim library [28]. The GloMoSim
library is a scalable simulation environment for wireless net-
work systems using the parallel discrete-event simulation ca-
pability provided by PARSEC [1]. Our simulation modeled a
network of 50 mobile hosts placed randomly within a 1000
1000
area. Radio propagation range for each node was
250 meters and channel capacity was 2 Mbits/sec. There were
no network partitions throughout the simulation and the average
number of neighbors for each node was 6.82. Each simulation
executed for 600 seconds of simulation time. Multiple runs with
different seed numbers were conducted for each scenario and
collected data was averaged over those runs.
A. Channel and Radio Model
A free space propagation model [26] with a threshold cutoff
was used in our experiments. In the free space model, the
power of a signal attenuates as
where
is the distance
between radios. In addition to the free space channel model, we
also implemented SIRCIM (Simulation of Indoor Radio Chan-
nel Impulse-response Models) [27] which considers multipath
fading, shadowing, barriers, foliages, etc. SIRCIM is more ac-
curate than the free space model, but we decided against using
SIRCIM in our study because: (a) the complexity of SIRCIM
increases simulation time by three orders of magnitude; (b) the
accuracy of the channel model does not affect the relative rank-
ing of the multicasting protocols evaluated in this study; and (c)
SIRCIM must be “tuned” to the characteristics of the physical
environment (e.g., furniture, partitions, etc.), thus requiring a
much more specific scenario than we are assuming in our exper-
iments.
In the radio model, we assumed the ability of a radio to lock
onto a sufficiently strong signal in the presence of interfering
signals, i.e., radio capture. If the capture ratio (the ratio of
an arriving packet’s signal strength over the sum of all collid-
ing packets) [26] was greater than a predefined threshold value,
the packet was received while all other interfering packets were
dropped.
B. Medium Access Control Protocol
The IEEE 802.11 MAC with Distributed Coordination Func-
tion (DCF) [12] was used as the MAC protocol. DCF is the
mode which allows mobiles to share the wireless channel in an
ad hoc configuration. The specific access scheme is Carrier
Sense Multiple Access/Collision Avoidance (CSMA/CA) with
acknowledgments. Optionally, the nodes can make use of Re-
quest To Send/Clear To Send (RTS/CTS) channel reservation
control frames for unicast, virtual carrier sense, and fragmenta-
tion of packets larger than a given threshold. By setting timers
based upon the reservations in RTS/CTS packets, the virtual car-
rier sense augments the physical carrier sense in determining
when mobile nodes perceive that the medium is busy. Fragmen-
tation is useful in the presence of high bit error and loss rates, as
it reduces the size of the data units that need to be retransmitted.
In our experiments, we employed RTS/CTS exclusively for
unicast control packets directed to specific neighbors (e.g.,
replies). All other transmissions use CSMA/CA. We chose this
configuration to minimize the frequency and deleterious effects
of collisions over the wireless medium. We did not employ frag-
mentation because our data packets were small enough that the
additional overhead would reduce overall network throughput.
C. Multicast Protocols
When implementing the multicast protocols, we followed the
specifications of each protocol as defined in the published liter-
ature. We directly queried the protocol designers about details
which were not specified in the publications (e.g., various timer
values, core selection algorithm, etc.). ODMRP and AMRIS do
not require underlying unicast protocol to operate, but AMRoute
and CAMP do. While AMRoute can work with any protocol,
the designers of CAMP specifically state that it can operate only
with certain unicast protocols [10]. We have implemented one
of those protocols, WRP [24], a distance-vector based unicast
routing protocol developed by the same group which developed
CAMP. For a fair comparison, WRP was used as the underlying
unicast protocol also for AMRoute. The source code of each
protocol was independently validated by two of the authors.
D. Traffic Pattern
A traffic generator was developed to simulate constant bit rate
sources. The size of data payload was 512 bytes. The senders
were chosen randomly among multicast members who in turn
were chosen with uniform probability among 50 network hosts.
The member nodes join the multicast session at the beginning
of the simulation and remain as members throughout the sim-
ulation. Hence, the simulation experiments do not test/account
for the overhead produced in the session leave process.
E. Metrics
We have used the following metrics in comparing protocol
performance. Some of these metrics were suggested by the IETF
MANET working group for routing/multicasting protocol eval-
uation [5].
Packet delivery ratio: The ratio of the number of data pack-
ets actually delivered to the destinations versus the number of
data packets supposed to be received. This number presents the
effectiveness of a protocol.
Number of data packets transmitted per data packet de-
livered: ‘Data packets transmitted’ is the count of everyindivid-
ual transmission of data by each node over the entire network.
This count includes transmissions of packets that are eventually
dropped and retransmitted by intermediate nodes. Note that in
unicast protocols, this measure is always equal or greater than
one. In multicast, since a single transmission can deliver data to
multiple destinations, the measure may be less than one.
Number of control bytes transmitted per data bytes de-
livered: Instead of using a measure of pure control overhead,
we chose to use the ratio of control bytes transmitted to data
bytes deliveredto investigate how efficiently control packets are
utilized in delivering data. Note that not only bytes of control
packets (e.g., beacons, route updates, join requests, acknowledg-
ments, etc.), but also bytes of data packet headers are included
5
in the number of control bytes transmitted. Accordingly, only
the data payload bytes contribute to the data bytes delivered.
Number of control and data packets transmitted per data
packet delivered: This measure shows the efficiency in terms
of channel access and is very important in ad hoc networks since
link layer protocols are typically contention-based.
IV. SIMULATION RESULTS
A. Mobility Speed
A.1 Scenarios
Each node movedconstantly with the predefined speed. Mov-
ing directions of each node were selected randomly, and when
nodes reached the simulation terrain boundary, they bounced
back and continued to move. The node movement speed was
varied from 0 km/hr to 72 km/hr. In the mobility experiment, 20
nodes are multicast members and 5 sources transmit packets at
the rate of 2 pkt/sec each.
A.2 Results and Analysis
Fig. 1 illustrates the packet delivery ratio of the protocols un-
der different speeds. ODMRP shows good performance even in
highly dynamic situations. ODMRP provides redundant routes
with a mesh topology and the chances of packet delivery to des-
tinations remain high even when the primary routes are unavail-
able. The path redundancy enables ODMRP to suffer only min-
imal data loss and be robust to mobility. In fact, ODMRP was
as effective as flooding in this experiment.
CAMP, which also uses a mesh topology, shows a better per-
formance than protocols which use trees. However, CAMP ex-
hibited poorer performance than we had expected, especially
under mobility. A major reason CAMP was not as effective as
ODMRP was that many packets headed to distant routers in the
mesh were not delivered. In CAMP, since the paths to distant
destinations have fewer redundant paths than those closer to the
center of the mesh, they are more prone to occasional link breaks
preventing a vital “anchoring” node from successfully receiving
packets. Most of the successful packet transmissions occur in
this mesh center, and require fewer data transmissions per de-
livery than transmissions to the mesh edges. In addition, in the
presence of mobility and link breaks, WRP (which is the unicast
protocol CAMP prefers to coexist with) can require a period of
network re-convergence in regards to a subset of destinations.
During this interval, this subset of destinations will be marked
as unreachable by the loop-detection facilities. If the group core
is a part of this subset of temporarily unreachable nodes, the
multicast routing updates regarding mesh maintenance will be
postponed, which also contributes to delays in mesh response to
mobility.
AMRIS shows a poor delivery ratio compared to protocols
that use mesh configuration. Since AMRIS builds a shared tree
for data dissemination, there is only one path between mem-
ber nodes. If a single tree link breaks because of node move-
ments, packet collision, or congestion, destinations can not re-
ceive packets. AMRIS detects node movements and tree breaks
by a beaconing mechanism. Nodes send beacons every second,
and neighbors are considered to have moved away if 3 consec-
utive beacons are not received. Thus, in the best case, it takes
0
0.2
0.4
0.6
0.8
1
0 10 20 30 40 50 60 70
Packet Delivery Ratio
Mobility Speed (km/h)
FLOODING
ODMRP
CAMP
AMRIS
AMROUTE
Fig. 1. Packet Delivery Ratio as a Function of Mobility Speed.
3 seconds after the link break for AMRIS to start tree readjust-
ment. A number of packets can be lost during that period. There
are possible solutions to this problem, but they all have respec-
tive drawbacks. If beacons are sent more often, that could in-
crease packet collisions. If the number of allowed beacon losses
is decremented, a nodemay attempt to find a new route when the
link is not broken but beacons are lost due to collisions. Find-
ing the optimal beacon interval and allowed number of beacon
losses for AMRIS is beyond the scope of the paper and we used
the values recommended by the AMRIS designers. The result
that surprised us was for zero mobility. While other protocols
showed data delivery ratio approaching unity, AMRIS delivered
only 60% of data packets. Since each node sends beacons ev-
ery second, there are a number of packets contending for the
channel. The beacon size of AMRIS is relatively large com-
pared to other protocols that send beacons (see [29]). Thus,
the beacon traffic combined with the data traffic causes a large
number of collisions leading to 40% drop. Under very light data
traffic, AMRIS shows improved performance as will be shown
in Fig. 8.
AMRoute was the least effective of the protocols with mo-
bility. Although its delivery ratio is near perfect in no mobil-
ity, it fails to deliver a significant number of packets even at
low mobility speeds. The delivery ratio steadily worsens as the
mobility speed is increased. One of the reasons AMRoute per-
forms so poorly is due to the formation of loops and the creation
of sub-optimal trees when mobility is present (at 72 km/hr, the
average hop count was nearly 8 while other protocols were be-
low 4). Loops occur during the tree reconstruction phase when
some nodes are forwarding data according to the stale tree and
others according to the newly built tree. The existence of loops
is critical in protocol performance because they cause serious
congestion. At some instants, nodes had up to 13.75 packets
dropped per second. The loss of packets due to buffer overflow
has two consequences. First, if a data packet is dropped in the
early stage of its multicast tree traversal, a large portion of tree
members will not receive it. Second, if control packets (TREE-
