1

Multicasting in Wireless Mesh Networks

Vikas Luthra,
Division of Computing Studies, Arizona State University
Polytechnic Campus
Vikas.Luthra@asu.edu

Abstract Wireless mesh networks are a new networking

paradigm that allow the formation of a temporary
network of wireless nodes without relying on the existing
infrastructure. They are basically traditional wireless
access networks with multi-hop connections through fixed
wireless mesh routers. Due to their cost effectiveness, ease
of expansion and ability to provide reliable Internet
connectivity, WMNs have received attention of the
research community in academia and industry. WMNs
provide broadband wireless connectivity without the costly
wired network infrastructure.
A WMN Task Group is working on creating a standard for
WMNs, the routing protocol that they are considering is
based on AODV (Ad-Hoc On Demand Distance Vector),
which has been researched extensively with MANETs.
Multicast is a key technology for future wireless networks.
Multicasting is the transmission of datagrams to a group
of hosts identified by a single destination address [1]. It
provides efficient communications among a group of
nodes, while reduce bandwidth consumption of many
applications such as videoconferencing, replicated
databases, information distribution, resource discovery,
sharing of text and images, distributed gaming etc.
Bandwidth consumption is an important issue in wireless
networks as many users are sharing the same wireless
channel.
This project compares and contrasts Source Based
Multicasting Protocols (ADMR, MAODV) with Mesh
Based Multicasting Protocols (ODMRP, CAMP) by
utilizing the NS2 (Network Simulator 2). The metrics used
in this experiment involve, packet delivery ratio, number
of data packets transmitted per data packet delivered &
transmitted, number of control packets transmitted per
data packet delivered and number of control packets and
data packets transmitted per data packet delivered. While
the performance is determined on the basis of number of
senders, node mobility and multicast group size
Index Terms Mesh Networks, NS2, ADMR, ODMRP,
Source Based and Mesh based multicasting.

I. INTRODUCTION
WMN stands next in the list of technologies which have the
capacity to influence the way we communicate today. It has
the capacity to change our work style and enhance our
productivity. Although derived from military research into
mobile networks, WMNs have their greatest potential in the
commercial marketplace. Though WMNs can be based upon a
number of technologies, their practical commercial evolution
is primarily occurring through the use of wireless LAN
communications. There are two basic types of wireless LAN
networking structures, referred to as peer to peer and
infrastructure. In a peer to peer networking structure, each
node can directly communicate with the other. While in an
infrastructure LAN networking environment, all traffic flows
through an access point. A wireless mesh network represents
a series of peer to peer transmissions where each node
functions as a router and a repeater. This wireless peer to peer
network structure is also referred to as an ad hoc network.
Compared with their single-hop counterpart, wireless LANs,
the WMNs are self-organized with the nodes automatically
establishing ad hoc networks and maintaining their
connectivity. This provides more reliability, larger coverage
and reduces equipment cost. [2]
As illustrated in the Figure 1, the network architecture
consists of two parts, the mesh backbone and local footprints.
All the mesh nodes are equipped with two wireless interfaces.
One is an IEEE 802.11a/g compliant radio, which is the
backbone traffic carrier. Another is an IEEE 802.11b radio,
which provides access to wireless clients in the local
footprint. It supports standard configured wireless clients,
which usually have off-the-shelf IEEE 802.11 hardware.
Wireless clients can have access to the Internet or intranet
through the wireless mesh backbone. Arriving users can
immediately join the network when they come into range and

2
turn

on

their

devices.

Vector (MAODV) and Multicast Optimized Link State

Routing (MOLSR). In contrast, a mesh-based multicast
routing protocol maintains a mesh consisting of a connected
component of the network containing all the receivers of a
group. They have multiple paths from the source to the
receivers. Examples of mesh based multicasting schemes are
On-Demand Multicast Routing Protocol (ODMRP), Core
Assisted Mesh Protocol (CAMP) and Forwarding Group
Multicast Protocol (FGMP).
The following paragraph discusses the multicast protocols.

Fig .1 Infrastructure Mesh Networks [20]

Mesh networks implement the notion of multiple channels
and multiple interfaces to improve the system performance.
Lately, there has been a lot of research on how these channels
are allotted to different wireless interfaces in unicast routing.
However multicast routing has not been researched
adequately in the field of WMNs. Multicasting has emerged
as one of the most focused areas in the field of networking.
With the growth of the Internet, applications that need
multicasting (e.g., streaming multimedia, replicated database,
information distribution, resource discovery, shared white
boards, video conferencing, online games, webcast and
distance learning among a group of users) are also growing at
a rapid pace. Now with the emergence of wireless ad hoc
networks, multicast plays an important role in the routing of
such networks. They present the idea of groups among these
dynamically reconfigurable wireless networks to be able to
share data among the nodes as a group.
IP router to router multicast protocols like PIM (Protocol
Independent Multicast), DVMRP (Distance Vector Multicast
Routing Protocol) and MOSPF (Multicast Open Shortest Path
First) used in the Internet are not suitable for ad hoc networks
due to the high overhead they require for continuous
topological changes. They are not able to deal with mobility
of end hosts. Also creating and maintaining upstream and
downstream link status for such protocols in a wireless
network is not efficient.
To achieve efficient multicasting in ad hoc networks, special
routing mechanisms have been implemented; one approach
has been implementing an extension of unicast ad hoc routing
protocols while the other one is to specifically design
protocols for multicasting. Most of the multicasting protocols
are classified into two broad categories, source-based and
mesh-based. A source based multicast routing protocol
establishes and maintains one or many multicast routing trees
to deliver data packets from sources to the multicast group. It
builds and maintains a multicast tree based on hard state (The
protocol has to track and react to any changes in the tree)
information [3]. Examples of source based protocols are
Adaptive Demand-Driven Multicast Routing protocol
(ADMR), Ad Hoc Multicast Routing protocol utilizing idnumberS (AMRIS), Multicast Ad hoc On Demand Distance

In ADMR, source based forwarding trees are created

whenever there is at least one source and one destination in
the network. Each multicast data packet is forwarded along
the shortest-delay path with multicast forwarding state, from
the sender to the receivers. It monitors the traffic pattern of
the multicast source application, and based on that can detect
link breaks in the tree. [4]
The MAODV routing protocol [5] discovers multicast routes
on demand using a broadcast route-discovery mechanism. It
builds and maintains a multicast tree based on hard state
information.
AMRIS is an on-demand protocol which constructs a shared
delivery tree to support multiple senders and receivers within
a multicast session. Each participant has a session-specific
multicast session member id (msm-id). This provides each
node with an indication of its "logical height" in the multicast
delivery tree. Each node except the root must have one parent
that has a logical height (msm-id) that is smaller than it [6]
MOLSR is developed as an extension to OLSR. A multicast
tree is built and maintained for any tuple (source, multicast
group) in a distributed manner without any central entity and
provides shortest routes from the source to the multicast
group members. The trees are updated whenever a topology
change is detected. It works even when not all nodes are
multicast capable provided that multicast nodes offer the
minimal connectivity between the sources and the members of
the multicast group. [7]
ODMRP is a mesh-based, rather than a conventional treebased multicast scheme. It uses a forwarding group concept
i.e., only a subset of nodes forwards the multicast packets via
scoped flooding. It applies on-demand procedures to
dynamically build routes and maintain multicast group
membership. It maintains a mesh based on soft state (when a
node wishes to leave the group, it simply stops sending
REQUEST/REPLY packets to the group). No explicit control
message is required to leave. [8]
CAMP generalizes the notion of core based trees introduced
for internet multicasting into multicast meshes that have
richer connectivity than trees. It has multicast meshes with
loop free packet over the meshes. Packets are forwarded along
the reverse shortest path to the source of the group. It uses
core only to reduce traffic required for router to join a
multicast group. [9]
FGMP keeps track of groups of nodes participating in
multicast packet forwarding. To each multicast group G is

3
associated a forwarding group, FG. Any node in FG is in
charge of forwarding (broadcast) multicast packets of G. That
is, when a forwarding node (a node in FG) receives a
multicast packet, it will broadcast this packet if it is not a
duplicate. All neighbors can hear it, but only neighbors that
are in FG will determine if it is a duplicate and then
broadcast it in turn. [10]
This project compares the two different methodologies of
multicasting (source based and mesh based) proposed in
WMNs. Two routing protocols ADMR and ODMRP have
been selected, one from each of these categories. Comparison
of these protocols against metrics including packet delivery
ratio, number of data packets transmitted per data packet
delivered, number of control packets transmitted per data
packet delivered, number of control packets and data packets
transmitted per data packet delivered. While the performance
was determined on the basis of varying the number of
senders, node mobility and multicast group size for each of
these protocols. NS2 (Network Simulator 2) has been used as
the simulator to compare the protocols.
The rest of the paper has been organized as follows, in
section II a few of the papers having related work is
discussed, section III deals with the description of the
multicast routing protocols, section IV discusses the NS2
environment, section V discusses the results and observations
leading to the comparison of the protocols, section VI draws
conclusions based on the results, section VII indicates the
future work that needs to be done to enhance the mesh
network model in NS2.
II.RELATED WORK
A lot of research has been going on in the field of
multicasting in Wireless Mesh Networks. [11] talks about
efficient multicast routing on wireless mesh networks and its
interconnection to wired IP multicast services. They propose a
tree construction scheme which reduces data overhead by
making maximum use of the broadcast nature of the wireless
medium. They define a distributed approximation of MST
heuristic algorithm. [12] compares different approaches to
reliable multicast protocols namely Scalable Reliable
Multicast (SRM), Multicast File Transfer Protocol (MFTP).
[13] has developed a new multicasting protocol (PUMA
protocol for unified multicasting through announcements)
which establishes and maintains a shared mesh for each
multicast group without requiring a unicast routing protocol.
They compared the performance of MAODV, ODMRP and
PUMA on the basis of mobility, group members, number of
senders, traffic load and number of multicast groups. PUMA
uses a receiver initiated approach in which receivers join a
multicast group using the address of a special node (usually
called the group leader), without the need for network-wide
flooding of control or data packets from all the sources of a
group. PUMA eliminates the need for a unicast routing
protocol and the pre-assignment of cores to multicast groups.
PUMA was found to achieve a higher packet delivery ratio
than ODMRP or MAODV, while incurring far less control
overhead.
[3] compares MAODV and ODMRP. They identified some

similarities and differences in the approach applied by these

multicast routing protocols. Both discover multicast routes
only in the presence of data packets to be delivered to a
multicast destination. Route discovery in either protocol is
based on request and reply cycles where multicast route
information is stored in all intermediate nodes on the
multicast path. They identified certain differences, such as
MAODV uses a shared bi-directional multicast tree while
ODMRP maintains a mesh topology rooted from each source.
The MAODV tree is based on hard state information (any
link breakages force actions to repair the tree by the group
leader). ODMRP provides alternative paths and a link failure
need not trigger the recomputation of the mesh, broken links
will time out (soft state). The work however only compares
the two protocols specifically; it does not give a comparison
on the performance of the two different approaches of
multicasting routing protocols on the whole. This paper is an
attempt to give a brief on the performance analysis of source
and mesh based multicasting routing protocols in wireless
mesh networks. We have implemented and compared ADMR
and ODMRP.
III.
OVERVIEW OF THE MULTICAST ROUTING
PROTOCOLS
(1)

ADMR

The Adaptive Demand-Driven Multicast Routing protocol

(ADMR) is a new on-demand ad-hoc network multicast
routing protocol which discovers multi-hop routes between
multicast receivers and senders. Like other tree based
multicast routing protocols, it builds a source based tree to
form a multicast group but unlike others, it does not utilize
any periodic control packet transmissions such as periodic
flooding or neighbor sensing. It performs both its route
discovery and route maintenance functions on demand, and
automatically prunes unneeded multicast forwarding state,
and expires its multicast mesh when it detects that the
multicast application has become inactive. It conforms to the
standard IP multicast API where any node can send data to
any multicast group without explicitly announcing its
intention to send or stop data. Any node can leave the
multicast group at any time. The protocol does not require an
existing infrastructure or preconfiguration to work. In the
event of a broken connection, ADMR maintains connectivity
between the end parties of this broken link.
ADMR consists of 3 phases:
1.

Multicast State Setup

2.

Multicast Packet Forwarding

3.

Multicast State Maintenance

Multicast State Setup

For a given multicast group G. If at least one receiver and one
source exist, ADMR creates a source mesh between each of
the multicast sender and multicast receiver with the tree
rooted at the sender. A multicast packet sent from the source
(S) to the group (G) is dynamically forwarded along the
shortest delay path through the tree to the receiver members

4
of the multicast group. It does not follow any predetermined
sequence of hops. These multicast packets are forwarded only
by the tree members of this multicast forwarding tree.
If no routing state information exists for this sender and
group, the routing layer on S adds an ADMR header to the
data packet and sends the data packet as a network flood.
Also the node records in its Node Table the MAC address of
the node from which it received the packet, and the sequence
number stored in the packet's ADMR header. This
information will be used for duplicate detection and also, for
forwarding packets back to S. This type of forwarding
increases robustness against packet loss due to collisions or
broken links.
Each source floods its first data packet for a group, and each
receiver responds to that flood with a RECEIVER JOIN
packet. All nodes that receive and forward this packet towards
S create a forwarding entry in its Membership Table for the
Source S and Group G. A flood-response cycle is initiated by
each receiver when it first joins the group.
The collection of paths with forwarding state between S and
the receivers for G produces the Forwarding Tree [4]

Multicast Packet Forwarding

As discussed earlier, each multicast packet is dynamically
forwarded from S along the shortest-delay path through the
tree to the receiver members of the multicast group, only by
members of the multicast tree. However these forwarded
packets are not constrained to follow a particular path in the
tree. Hence, packets sent from one source may take different
routes to the same destination. Each node monitors the traffic
pattern and records the information of the packets which it
forwards. Any packet generated by a node in the mesh has the
ADMR header attached to it. The flag bit in this header is
used to differentiate between two floods Tree and Network
flood. The packets are forwarded among nodes belonging to
the multicast forwarding tree or the whole network based on
this flag value.

On receiving a multicast packet from a sender, a node R first

checks the entry for the sender and group in its Membership

5
Table to determine to what nodes it should forward the
packet. If the flag bit is set to tree flooding, then it passes the
multicast packet to the next layer in the protocol stack and the
packet flows along the tree from the sender to the group
receiver. While if the flag bit was set to network flood, the
packet would be flooded among all the nodes in the network.

If this local repair procedure succeeds, the multicast

forwarding tree is reconnected and the receiver members start
receiving data again. While if the disconnection timer expires
at one of the intermediate forwarding nodes, the local repair
failed.
(2)

Multicast State Maintenance

Maintenance of links in multicast routes includes two main
responsibilities for the ADMR protocol Link Break
Detection and Link Break Repair.
Link Break Detection - The ADMR header mentioned above
has inter-packet time field; this field is used for multicast
state maintenance. The value of this field indicates the time
interval for arrival of new packets from the sender S. This
inter-packet time interval can be obtained by dynamically
tracking the average interval at which it originates multicast
packets for the group G, or could be set based on the IP port
number information or could be supplied by the application
itself. Hence this field in the ADMR header helps the nodes
detect broken links in the tree. Also, one can determine the
inactive periods during which S is not sending data
temporarily.
Link Break Repair All nodes in the group maintain a
disconnection timer. Every time they receive a packet from
the group, it resets this connection timer. The inter-packet
time value (described above) of the last received packet and
the number of hop counts from the source determine the value
of this connection timer. Once a broken link is detected, first
the disconnected node sends a REPAIR NOTIFICATION
packet to all the multicast receivers informing them of its
repair action. Nodes accept and forward this REPAIR
NOTIFICATION packet after matching the MAC-layer
transmitting source address of the packet to the previous hop
address stored in that node's Membership Table entry for the
multicast sender S. The sequence number and bitmap in each
node's Node Table entry are used to avoid duplicates in the
forwarding of the Repair Notification packet.
Now after time interval REPAIR_DELAY, the sender node
starts the local repair. If it receives a REPAIR
NOTIFICATION from one of the upstream nodes during this
time interval, it simply cancels its local repair action as the
other node is closer to the break and will repair the link itself.
On receiving this REPAIR NOTIFICATION, the receiver
nodes postpone their disconnection timer for a definite time
interval. This time interval is based on the expected time for
the link repair. If no data arrives in a specified time, it
assumes the local repair failed and cancels the connection
altogether. Now the sender S sends a hop limited
RECONNECT packet flood to perform this localized repair.
The receiver on receiving this RECONNECT packet responds
with a unicast RECONNECT REPLY packet to the sender S.
All intermediate nodes between the sender of RECONNECT
REPLY (usually leaf nodes) and receiver (S) create an entry in
their Membership Tables to record this as they forward the
message.

ODMRP

ODMRP is an on-demand protocol i.e. group membership and

multicast routes are established and updated by the source on
demand. ODMRP is a mesh based approach to multicasting
in Wireless Mesh Networks. The source based approach to
multicasting has issues like intermittent connectivity, traffic
congestion, non-shortest path in a shared tree, etc. When the
node connectivity changes, the tree structure also changes
with it. Multicast trees require a global routing substructure
involving excessive channel and processing overhead. By
maintaining and using a mesh instead of a tree, the
drawbacks of multicast trees are avoided. Such kind of an
approach is useful in case of change in topology or if a link
fails. Here only a subset of nodes forwards packets via scoped
flooding. A soft-state approach is taken to maintain multicast
group members. No explicit control message is required to
leave the group. This makes ODMRP an attractive option
with networks with high mobility.
MulticastRouteandMeshCreation
Similar to on-demand unicast routing protocol, ODMRP has a
request and reply phase. A node has packets to send but is not
aware of any group memberships or route to this group. It
floods a member advertising packet with the data payload
piggybacked. This is the JOIN QUERY packet to refresh the
membership information and update the routes. Now each
node receiving this packet stores the source address and the
unique identifier of the packet into its routing table and
rebroadcasts the packet. Finally when the receiver gets this
JOIN QUERY packet, it creates a JOIN REPLY packet in
response to the request and broadcasts it to its neighbors.
When this JOIN REPLY packet reaches an intermediate node,
it checks if the next node id JOIN REPLY matches with its id.
If this matches, it is a part of the forwarding group; it sets the
Forwarding Group Flag (FG_FLAG) and broadcasts the JOIN
REPLY with the matched entries. Before forwarding this
packet, each node waits for JOIN AGGREGATION
TIMEOUT and combines all JOIN REPLYs for the group
received during this time into one JOIN REPLY. The
forwarding continues until it reaches the destination (original
sender). The source sends JOIN QUERY every FRESH
INTERVAL.
The figure below shows an example of the JOIN REPLY
forwardingprocessdescribedabove

6
R1
S1

I1
R2

S2

I2
R3

JoinReplyofNodeR1
Sender

NextNode

S1

I1

S2

I2

JoinReplyofNodeI1
Sender

NextNode

S1

S1

Nodes S1 and S2 are multicast sources, and nodes R1 and R2

are multicast receivers. Node R2 sends its Join Reply to both
S1 and S2 via I2, and R1 sends its packet to S1 via I1 and to
S2 via I2. When receivers send their Join Replies to next hop
nodes,
an intermediate node I1 sets the FG_FLAG and
builds its own JOIN REPLY since there is a next node ID
entry in the Join Reply received from R1 that matches its ID.
Note that the Join Reply built by I1 has an entry for sender S1
but not for S2 because the next node address for S2 in the
received Join Reply is not I1. In the meanwhile, node I2 sets
the FG_FLAG, constructs its own Join Reply and sends it to
its neighbors. Note that I2 broadcasts the JOIN REPLY only
once even though it receives two Join Replies from the
receivers because the second table arrival carries no new
source information. Channel overhead is thus reduced
dramatically in cases where numerous multicast receivers
share the same links to the source.
Soft State
The protocol maintains a soft state. When a node wishes to
leave the group, it simply stops sending JOIN QUERY/JOIN
REPLY packets to the multicast group, depending on whether
it is a sender or receiver. Nodes in the forwarding group are
demoted to non-forwarding nodes if not refreshed (no Join
Replies received) before they timeout. [13]
Unicast Capability
One of the major strengths of ODMRP is its unicast routing
capability. ODMRP not only can work with any multicast
routing protocol, it can function as both multicast and
unicast. One of the major strengths of ODMRP is its unicast
routing capability.

IV. NS2- NETWORK SIMULATOR

NS2 is a discrete event simulator and object oriented network
simulator targeted at networking research. It provides
substantial support for simulating multi-hop wireless
networks complete with physical and IEEE 802.11 MAC
layer models. NS is primarily useful for simulating local and
wide area networks. It supports TCP, routing, and multicast
protocols over wired and wireless (local and satellite)
networks. NS2 began as a variant of the REAL network
simulator in 1989 and has evolved substantially over the past
few years. In 1995 NS2 development was supported by
DARPA through the VINT project at LBL, Xerox PARC,
UCB, and USC/ISI. Currently NS development is supported
through DARPA with SAMAN and through NSF with
CONSER, both in collaboration with other researchers
including ACIRI [14]. In NS2, the user defines arbitrary
network topologies, composed of routers, links and shared
media. Protocol instances can then be attached to nodes. NS2
does not by itself support any wireless multicasting protocols
but there have been a few multicast implementations in NS2.
A good computing platform provides both system
programming languages (C++, JAVA) and scripting
languages. The programming language is required for the
detailed simulation of protocols for the calculation of byte
transfers, packet headers and other algorithms on large data
sets. The speed of executing is more important than the time
required to run these simulations, finding the bugs in these
simulations, fixing them, recompiling and re-running the
simulations. C++ is fast to run but slower to change making it
a good programming language for this purpose. [15]
On the other hand, in network research one needs to keep
changing network parameters or configurations. Here
iteration time (described above) is more important than the
run time (configuration runs once at the beginning of the
simulation). Otcl (Object Oriented Tcl) can be changed very
quickly even though it runs pretty slow. This makes Otcl ideal
for simulation configuration. NS2 (via Tclcl- A C++/Tcl
interface) provides glue to make objects and variables appear
on both languages. Otcl is the Object Oriented scripting
language Tcl (Tool Command Language). Tclcl provides
linkage for class hierarchy, object instantiation, variable
binding and command dispatching. The simulator supports a
class hierarchy in C++ (also called the compiled hierarchy in
this document), and a similar class hierarchy within the OTcl
interpreter (also called the interpreted hierarchy in this
document). The two hierarchies are closely related to each
other; from the users perspective, there is a one-to-one
correspondence between a class in the interpreted hierarchy
and one in the compiled hierarchy. The root of this hierarchy
is the class TclObject. Users create new simulator objects
through the interpreter; these objects are instantiated within
the interpreter, and are closely mirrored by a corresponding
object in the compiled hierarchy.
The interpreted class hierarchy is automatically established
through methods defined in the class TclClass. User
instantiated objects are mirrored through methods defined in
the class TclObject. There are other hierarchies in the C++
code and OTcl scripts; these other hierarchies are not
mirrored in the manner of TclObject. [16]

7
network components are further divided into two subclasses,
Connector and Classifier, based on the number of the possible
output data paths.

Pure OTcl
objects

OTcl/C++ split
objects

OTcl

Tclcl
linkage
NS-2

Pure C++
objects

C++

Event Scheduler
The figure below shows each network object using an event
scheduler. The network object that issues an event has to
handle it at a later time. Also the data path between the
network objects is different from the event path. The packets
are handed from one network object to another using
send(Packet* p) {target_->recv(p)}; method of the sender and
recv(Packet*, Handler* h = 0) method of the receiver. [21]

Packet
The following shows the format of a NS packet. It is
composed of a stack of headers and an optional data space.

When a packet is created, all these headers are assigned to it,

irrespective of what specific header it uses. [21]
NS has two event schedulers - Real-time and Non-real-time
schedulers. For a non-real-time scheduler, three
implementations (List, Heap and Calendar) are available. The
Calendar non-real-time scheduler is set as the default. The
real-time scheduler is for emulation, which allows the
simulator to interact with a real network. Currently,
emulation is under development. The event scheduler also
schedules simulation events like starting/ending a simulation
event, starting a particular application
Network Components
In the class hierarchy of NS components (Otcl class), the
TclObject class is the root of the hierarchy. As an ancestor
class of TclObject, NsObject class is the superclass of all basic
network component objects that handle packets. The basic

NS2 comes in two packages, building from the source or

allinone. Building it from the source requires each of the
language components (tcl, tclcl, tk, otcl) compiled and run
separately while the allinone version allows us to do it with a
single command (./install). The allinone structure consists of
all these language components inside the parent Ns-allinone
directory. The network simulator directory (Ns-2) consists of
all the C++, Otcl code and validation tests. While the other
directories are required in compiling NS2 (./install).

NS-2: Directory Structure

ns-allinone
Tcl8

TK8

OTcl

Tclcl

...

tcl
ex
exampl
e

test

Ns-2

lib

Nam-1

C++ code

mcast

The simulated environment consists of 100 wireless mobile

nodes roaming in a 1200 meters x 800 meters area for 200
seconds of simulated time. The scenario containing all
movement behavior of the ad-hoc network nodes is generated
in advance so that it can be replaced identically for both the
protocols. Similar mobility and traffic scenarios are used for
both the protocols. Hence the workload is identical for both
the protocols.
A multicast member node joins the multicast group at the
beginning of the simulation (first 30 seconds) and remains as
a member throughout the entire simulation.

...

validation tests
OTcl code

Network Animator (NAM)

NAM is the default visualization tool available in the nsallinone package. It is a Tcl/TK based network animator that
provides packet level animation and protocol specific graphs
to aid the design and debugging of network protocols
animation tool for viewing network simulation traces and real
world packet trace data. NAM takes packet trace data from
NS2 and presents it as a graphical animation of packets
flowing in a network. [17]

Nam requires a trace file to produce an animation of the

network. In an NS2 simulation, one uses tracing events to
produce topology configurations, layout information and
packet traces to make up the trace file. This trace file contains
topology information, e.g., nodes, links, as well as packet
traces. Upon startup, NAM will read the trace file, create
topology, pop up a window, do layout if necessary, and then
pause at time 0. A NAM input file contains both the static
network layout and dynamic events such as packet arrivals,
departures, drops and link failures.

Performance Metrics
ADMR and ODMRPs performance was compared on the
basis of the following metrics. [19]

Packet Delivery Ratio: The ratio of the multicast data

packets received by the destinations to the total number
of packets originally sent by the senders. This ratio
presents the effectiveness of the protocol in delivering
data packets to intended receivers.

Number of data packets transmitted per data packet

delivered: Data packets transmitted is the count of
every individual 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.

Number of control packets transmitted per data packet

delivered: This measure shows the efficiency overhead in
control packets expended in delivering a data packet to
an intended receiver.

Number of control packets and data packets transmitted

per data packet delivered: This measure tries to capture
a protocols channel access efficiency, as the cost of
channel access is high in contention-based link layers.

Results
The trace files generated from executing the tcl (script) files
in NS2 are parsed by the mcast_totals.pl Perl Script [18] to
generate the MATLAB ready output files. These graphs are
generated on MATLAB. MATLAB is a high-level language
and interactive environment that enables performing
computationally intensive tasks [22].
Varying the number of multicast receivers

V. SIMULATION ENVIRONMENT
One protocol from each type of multicasting protocols was
chosen for comparison. The implementation of ADMR (tree
based multicasting protocol) and ODMRP (mesh based
multicasting protocol) from the Monarch Project [18] is used
for analyses.
Experimental Setup

0.7

Control packets transmitted per data packet delivered

1
0.98

0.94
0.92
0.9
0.88
0.86
0.84
ADMR
ODMRP

0.82
0.8

5
6
7
Number of Receivers

As the number of multicast receivers increase in the network,

there are more data packet transmissions, the nodes have
more opportunities to receive a transmission. Hence the
Packet Delivery Ratio (PDR) increases. ODMRP has a higher
PDR than ADMR and remains constant at about 0.988. While
ADMRs PDR increases from 0.82 (1 receiver) to 0.94for 10
receivers.
Data Packets Transmitted per data packet delivered

ADMR
ODMRP

18
16
14
12
10
8
6
4
2
0

5
6
7
Number of Receivers

0.5
0.4
0.3
0.2
0.1
0

10

Graph 1 Packet Delivery Ratio

20

0.6

10

Graph 2 Number of data packets transmitted per data

packet delivered.
The number of re-transmissions (packets transmitted per data
packet delivered) observed for AMDR is much lower than
that for ODMRP. So even though the PDR of ODDMRP is
better than ADMR (varying multicast receivers), ODMRP has
a much higher re-transmission ratio than ADMR.

5
6
7
Number of Receivers

10

Graph 3 Number of Control Packets transmitted per data

packet delivered.
ADMR generates about 4 times less control packet overhead
than ODMRP. The periodic source floods and response cycles
(as mentioned above) in ODMRP is responsible for its
comparatively high control packet overhead.
Control and Data Packets Transmitted per data packet delivered

Packet Delivery Ratio

0.96

ADMR
ODMRP

20

ADMR
ODMRP

18
16
14
12
10
8
6
4
2
0

5
6
7
Number of Receivers

10

Graph 4 - Number of control packets and data packets

transmitted per data packet delivered.
Control and data packets transmitted per data packet
delivered also show that ADMR has a much lower and hence
a greater channel access efficiency than ODMRP.
Varying the number of multicast sources

0.99

ADMR
ODMRP

0.98

0.96
0.95
0.94
0.93
0.92
0.91
0.9

5
6
Number of Sources

10

Graph 1 Packet Delivery Ratio

ADMR
ODMRP

14

ADMR
ODMRP

14
12
10
8
6
4
2
0

5
6
Number of Sources

10

Varying the size of the network

12
1

ADMR
ODMRP

10
0.9

8
6

Packet Delivery Ratio

Data Packets Transmitted per data packet delivered

16

4
2
0

5
6
Number of Sources

0.8

0.7

0.6

10
0.5

Graph 2 Number of data packets transmitted per data

packet delivered.
0.7

Control packets transmitted per data packet delivered

16

Graph 4 - Number of control packets and data packets

transmitted per data packet delivered

0.4

ADMR
ODMRP

4
5
6
7
Number of Groups (Size)

10

Graph 1 Packet Delivery Ratio

0.6
11

0.5
0.4
0.3
0.2
0.1
0

5
6
Number of Sources

10

Graph 3 Number of Control Packets transmitted per data

packet delivered

Data Packets Transmitted per data packet delivered

Packet Delivery Ratio

0.97

Control and Data Packets Transmitted per data packet delivered

10

10
9
8
7
6
5
4
3
2
1

ADMR
ODMRP
1

4
5
6
7
Number of Groups (Size)

Graph 2 Number of data packets transmitted per data

packet delivered

10

11

0.98

ADMR
ODMRP

1.5

0.94
0.92
0.9
0.88

0.5

ADMR
ODMRP

0.96

2.5

Packet Delivery Ratio

Control Packets Transmitted per data packet delivered

0.86

4
5
6
7
Number of Groups (Size)

10

Graph 3 Number of Control Packets transmitted per data

packet delivered

0.84

1.5

2.5
3
3.5
4
Single Source vs Multiple Source

Data Packets Transmitted per data packet delivered

Control and Data Packets Transmitted per data packet delivered

12
10
8
6
4
2
0

ADMR
ODMRP
1

4
5
6
7
Number of Groups (Size)

Graph 4 - Number of control packets and data packets

transmitted per data packet delivered

Graph 1 Packet Delivery Ratio

2.6

14

4.5

ADMR
ODMRP

2.4
2.2
2
1.8
1.6
1.4
1.2
1
0.8

1.5

10

2.5
3
3.5
4
Single Source vs Multiple Source

4.5

Graph 2 Number of data packets transmitted per data

packet delivered

Control Packets Transmitted per data packet delivered

1.4

ADMR
ODMRP

1.2
1
0.8
0.6
0.4
0.2
0

1.5

2.5
3
3.5
4
Single Source vs Multiple Source

4.5

Graph 3 Number of Control Packets transmitted per data

packet delivered
Single Source Vs Multi Source Groups

Control and Data Packets Transmitted per data packet delivered

12
VII. REFERENCES

[1] S. Deering, Host extensions for IP multicasting, RFC 1112,

August 1989, available at http://www.ietf.org/rfc/rfc1112.txt

ADMR
ODMRP

3.5

[2] Guokai Zeng, Bo Wang, Yong Ding, Li Xiao, Matt Mutka,

Multicast Algorithms for Multi-Channel Wireless Mesh
Networks

3
2.5

[3] Thomas Kunz and Ed Cheng, Multicasting in As Hoc

Networks: Comparing MAODV and ODMRP, Proceedings of
International Conference on Distributed Computing Systems
(ICDCS), 2002

2
1.5

[4] Jorjeta G. Jetcheva and David B. Johnson, Adaptive Demand

Driven Multicast Routing in MultiHop Wireless Ad Hoc
Networks

1
0.5

1.5

2.5
3
3.5
4
Single Source vs Multiple Source

4.5

Graph 4 - Number of Control Packets and data packets

transmitted per data packet delivered
V. CONCLUSION
In this paper, we have investigated the performance, control
overheads generated, access channel efficiency and the
retransmissions required to deliver packets for ODMRP
(mesh based multicasting approach) and ADMR (tree based
multicasting approach). The mesh based approach has a
better packet delivery ratio (PDR) than source based routing
protocols for all the metrics employed above. But in the mesh
based multicasting approach more data packet transmissions
fail to reach the destination and hence need re-transmissions.
Also, due to their periodic source floods and response cycles,
they are found to generate a higher control packet overhead.
On the other hand, tree based multicasting protocols utilize
the channel better, minimize control overheads and need less
data packet retransmissions to deliver the same data packets
as the mesh based approach.
VI. FUTURE WORK
Multicasting is the key technology for future wireless
networks. As discussed above the mesh based multicasting
protocols (ODMRP) and source based multicasting protocols
(ADMR) each have their advantages and disadvantages over
the other. We observed that source based routing protocols do
not scale well for packet delivery ratio but are lot more
efficient than mesh based multicast routing protocols in data
delivery ratio and access channel efficiency. Future work can
be done on developing a multicasting protocol which would
be a hybrid of these methodologies. One which would be
efficient for different network sizes and node speeds, yet have
minimum overhead. Also protecting these multicast sessions
is an important issue in wireless mesh networks. There is
further scope of research on a resilient forwarding mesh to
protect the multicast sessions.

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

on-demand distance vector routing protocol, Proc. of the 5th
ACM/IEEE Annual Conf. on Mobile Computing and
Networking, Aug. 1999, pages 207-218.
[6] C.W. Wu, Y.C. Tay, AMRIS: A Multicast Protocol for Ad hoc
Wireless Networks
[7] Anis Laouiti, Philippe Jacquet y, Pascale Minetz, Laurent
Viennot, Thomas Clausen , Cdric Adjih k, Multicast
Optimized Link State Routing, INRIA - INSTITUT NATIONAL
DE RECHERCHE EN INFORMATIQUE ET EN
AUTOMATIQUE, February 2003
[8]

Sung-Ju Lee, Mario Gerla, and Ching-Chuan Chiang, OnDemand Multicast Routing Protocol

[9]

Ewerton L. Madruga and J.J.Garcia-Luna-Aceves,

Multicasting Along Meshes in Ad-Hoc Networks, In
Proceedings of IEEE ICC99, Vancouver, Canada, June 1999
pp. 314-418, butenko-new.

[10] Ching-Chuan Chiang, Mario Gerla and Lixia Zhang,

Forwarding Group Multicast Protocol for Multihop, Mobile
Wireless Networks
[11] Christophe Jelger, Pedro M. Ruiz and Francisco J. Galera and
Thomas Noel, Efficient Multicast Routing in Wireless Mesh
Networks Connected to Internet
[12] Ravindra Vaishampayan and J.J. Garcia-Luna-Aceves,
Efficient and Robust Multicast Routing in Mobile Ad Hoc
Networks, In Proceedings of 2004 IEEE International
Conference on Mobile Ad-hoc and Sensor Systems
[13] On-Demand Multicast Routing Protocol in Multihop Wireless
Mobile Networks,
http://www.csee.umbc.edu/courses/graduate/CMSC628/spring
2002/ppt/meenakshi.ppt
[14] Wikipedia online resource for NS2,
http://nsnam.isi.edu/nsnam/index.php/Main_Page

[15] John Ousterhout. Scripting: Higher-level programming for the

21st century. IEEE Computer, 31(3):2330,March 1998.
[16] NS manual, VINT project,
http://www.isi.edu/nsnam/ns/doc/ns_doc.pdf
[17] Deborah Estrin, Mark Handley, John Heidemann, Steven
McCanne, Ya Xu and Haobo Yu, Network Visualization with
the VINT Network Animator Nam, USC Computer Science
Department Technical Report 99-703b
[18] Multicast Implementations for NS2-1.b8, Monarch Project,
http://www.monarch.cs.rice.edu/multicast_extensions.html

13
[19]

S. Corson and J. Macker. Mobile ad hoc networking

(MANET): Routing protocol performance issues and
evaluation considerations, RFC 2501, January 1999, available
at http://www.ietf.org/rfc/rfc2501.txt

[20] Wireless Mesh Networks at Carleton University, http://kunzpc.sce.carleton.ca/MESH/index.htm

[21] NS by example, Worcester Polytechnic Institute,
http://nile.wpi.edu/NS/
[22] MATLAB, The language of technical computing,
http://www.mathworks.com/

ACKNOWLEDEMENT
The author would like to thank Dr Bruce Millard, Professor of Practice, Division of Computing Studies, ASU
Polytechnic, for his support and guidance throughout this project work.
Bio: Vikas graduated from the Ragiv Gandhi Technical University, Bhopal, India with a bachelors degree in Computer
Science & Engineering in 2006. He joined Arizona State University at the Polytechnic Campus in Fall 2006, majoring in
Computing Studies and completed his Masters degree in 2007. His research interests include network security and web
development.