UC Santa Cruz
UC Santa Cruz Previously Published Works
Title
Efficient and Robust Multicast Routing in Mobile Ad Hoc Networks
Permalink
https://escholarship.org/uc/item/3c33493j
Author
Garcia-Luna-Aceves, J.J.
Publication Date
2005
Peer reviewed
eScholarship.org Powered by the California Digital Library
University of California
Efficient and Robust Multicast Routing in Mobile
Ad Hoc Networks
Ravindra Vaishampayan
Department of Computer Science
University of California Santa Cruz
ravindra@cse.ucsc.edu
J.J. Garcia-Luna-Aceves
Department of Computer Engineering
University of California Santa Cruz
jj@cse.ucsc.edu
Abstract— This paper argues that tree based protocols
can have packet delivery ratios comparable to mesh based
protocols if the tree construction algorithm can fix and detect
broken links quickly, and at the same time have a much lower
data packet overhead due to the absence of redundancy.
We present such a protocol and call it robust multicasting
in ad hoc networks using trees (ROMANT). ROMANT does
not require a unicast routing protocol or the preassignment
of cores to groups. We compare ROMANT with ODMRP
and MAODV which are the state of the art in mesh based
and tree based protocols respectively. The results from a
wide range of scenarios of varying mobility, group members,
number of senders, traffic load and number of multicast
groups show that ROMANT attains a comparable or better
packet delivery ratio than ODMRP and MAODV, and a
much lower control overhead which is almost constant
for a fixed number of groups, and varies sublinearly with
increasing groups.
Keywords— Ad hoc networks, routing, multicasting,
multicast mesh, multicast tree.
I. INTRODUCTION
Mobile ad hoc networks have applications in a wide
range of areas including disaster relief and military. Most
of these scenarios need one to many or many to many
communication. In fact, some networks may need multicast
routing only and not need unicast routing at all. This makes
multicasting a very important feature in such networks. As
a result, it is important to have a multicasting protocol
that provides a high packet delivery ratio even in extreme
conditions (e.g., high mobility and high traffic load). It is
equally important for such protocols to have a low over-
head, because bandwidth and battery power are extremely
precious in these kinds of networks.
Over the past few years, several multicast routing proto-
cols have been proposed for ad hoc networks [1], [2], [3],
[4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15],
[16]. For the purposes of our discussion, the approaches
taken to date can be classified into tree-based and mesh-
based approaches.
A tree-based multicast routing protocol establishes and
maintains either a shared multicast routing tree or multiple
source-based multicast routing trees (one for each group
source) to deliver data packets from sources to receivers of
a multicast group. Recent examples of tree-based multicast
routing approaches are the multicast ad hoc on-demand
distance vector protocol (MAODV) [4], and the adaptive
demand-driven multicast routing protocol (ADMR) [8]. 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. Two well-known
examples of mesh-based multicast routing protocols are the
core assisted mesh protocol (CAMP) [1] and the on-demand
multicast routing protocol (ODMRP) [2].
MAODV maintains a shared tree for each multicast
group, consisting of only receivers and relays. Sources
wishing to send to the group acquire routes to the group on
demand in a way similar to the ad hoc on demand distance
vector (AODV) [17] protocol. Each multicast tree has a
group leader, which is the first node to join the group in the
connected component. The group leader in each connected
component periodically transmits a group hello packet to
become aware of reconnections. Receivers join the shared
tree with a special route request. The route replies coming
from different multicast tree members specify the number
of hops to the nearest tree member. The node wishing to
join the tree joins through the node reporting the freshest
route with the minimum hop count to the tree.
ADMR maintains source-based trees, i.e., a multicast
tree for each source of a multicast group. A new receiver
performs a network-wide flood of a multicast solicitation
packet when it needs to join a multicast tree. Each group
source replies to the solicitation, and the receiver sends a re-
ceiver join packet to each source answering its solicitation.
An individual source-based tree is maintained by periodic
keep-alive packets from the source, which allow routers
to detect link breaks in the tree by the absence of data
or keep-alive packets. A new source of a multicast group
also sends a network-wide flood to allow existing group
receivers to send receiver joins to the source. MZR [15]
like ADMR, maintains source based trees. MZR performs
zonal routing; hence, the flooding of control packets is less
expensive. Compared to approaches based on shared trees,
the use of source-based trees creates much more state at
routers participating in many groups, each with multiple
sources.
ODMRP requires control packets originating at each
source of a multicast group to be flooded throughout the
ad hoc network. The control packet floods help repair
the link breaks that occur between floods. The limitations
of ODMRP are the need for network-wide packet floods
and requiring that the sources of multicast packets for a
group be part of the group’s multicast mesh, even if such
sources are not interested in receiving multicast packets
sent to the group. DCMP [14] is an extension to ODMRP
in that it designates certain senders as cores and reduces
the number of senders performing flooding. NSMP [16] is
another extension to ODMRP aiming to restrict the flood of
control packets to a subset of the entire network. However,
both DCMP and NSMP do not entirely eliminate ODMRP’s
drawback of multiple control packet floods per group.
CAMP avoids the need for network-wide floods from
each source to maintain multicast meshes by using one
or more cores per multicast group. A receiver-initiated
approach is used for receivers to join a multicast group by
sending unicast join requests towards a core of the desired
group. The drawbacks of CAMP is that it needs the pre-
assignment of cores to groups and a unicast routing protocol
to maintain routing information about the cores, and this
may incur considerable overhead in a large ad hoc network.
ROMANT is based on a receiver-initiated group joining
scheme that does not require an underlying unicast routing
protocol to operate or the pre-assignment of cores to
groups. The first receiver joining a group becomes the core
of the group and starts transmitting core announcements
periodically. An election takes place if more than one
receivers join at the same time. Each such announcement
specifies a sequence number, the address of the group, the
address of the core, the sending node, and the distance to
the core. Routers use the best core announcements they
receive to send their own core announcements to their
neighbors, and over time each router has one or multiple
paths to the elected core of each known group in the ad hoc
network. To join a multicast group, a receiver sends a join
announcement to its next-hop towards the core of the group,
which it learns from core announcements. Nodes receiving
join announcements intended for them join the group and
also send a join announcement periodically to their next-
hops for the group core. In this way join announcements
propagate from each receiver towards the core, establishing
the various branches of the tree. Similarly, a multicast data
packet for a group is forwarded from its source towards
the core of the group, using next-hop information obtained
in core announcements, and is flooded within the tree of
the group as soon as it reaches the first tree member. As
Section II-E shows, multicast data packets do not have to
be encapsulated in unicast data packets to reach a mesh
member from a given source outside the group.
Section II describes ROMANT in detail. Section III
compares ROMANT to ODMRP [2] and MAODV [4].
Comparison with ODMRP serves to illustrate why the
packet delivery ratio of ROMANT matches or exceeds that
of ODMRP even though ROMANT has far less redundancy.
As expected the data packet overhead of ROMANT is
much lower than that of ODMRP as ROMANT is a tree
based protocol. However even the control packet overhead
for ROMANT is much lower. Comparison with MAODV
explains why ROMANT is able to maintain a high packet
delivery ratio in a wide range of simulation scenarios while
MAODV is not, even though both are tree based protocols.
We did not compare ROMANT with CAMP, because
our approach is intended to work without the need of
any unicast routing protocol or predefined cores. We did
not compare ROMANT with DCMP, MZR, ADMR and
NSMP because the improvement of these approaches over
ODMRP in terms of control packet overhead as described
in [14], [15], [8] and [16] and is significantly lower
than what we achieve in ROMANT. MZR also had a lower
packet delivery ratio at high mobility. Our main objective
of comparing ROMANT with MAODV was to illustrate
some of the reasons as to why tree based protocols have
not been able to match mesh based protocols in terms of
packet delivery ratio, and how ROMANT corrects those
problems.
Section IV presents our conclusions.
II. ROMANT D
ESCRIPTION
A. Overview
ROMANT supports the IP multicast service model of
allowing any source to send multicast packets addressed
to a given multicast group, without having to know the
constituency of the group. Furthermore, sources need not
join a multicast group in order to send data packets to the
group.
Like CAMP and MAODV, ROMANT uses a receiver-
initiated approach in which receivers join a multicast group
using the address of a special node (core in CAMP or group
leader in MAODV), without the need for network-wide
flooding of control or data packets from all the sources
of a group. Like MAODV, ROMANT eliminates the need
for a unicast routing protocol and the pre-assignment of
cores to multicast groups.
ROMANT implements a distributed algorithm to elect
one of the receivers of a group as the core of the group, and
to inform each router in the network of at least one next-hop
to the elected core of each group. The election algorithm
used in ROMANT is essentially the same as the spanning
tree algorithm introduced by Perlman for internetworks of
transparent bridges [18]. Within a finite time proportional
to the time needed to reach the router farthest away from
the eventual core of a group, each router has one or multiple
paths to the elected core.
Every receiver connects to the elected core along any one
shortest path between the receiver and the core. All nodes
on such a shortest path between any receiver and the core
collectively form the tree. A sender sends a data packet
to the group also along any one shortest path between the
sender and the core. When the data packet reaches a tree-
member, it is flooded within the tree, and nodes maintain
a packet ID cache to drop duplicate data packets.
ROMANT uses two kinds of control packets. The core
announcement and the join announcement. Each core an-
nouncement specifies a sequence number, the address of
the group (group ID), the address of the core (core ID), the
distance to the core, and the sending router. Successive core
announcements have a higher sequence number than previ-
ous core announcement announcements sent by the core.
With the information contained in such announcements,
nodes elect cores, and each node in the network learns
of one or more routes to the core. A join announcement
specifies the sender, the intended group (group ID), and
the parent of the node sending the announcement, in the
multicast tree. Join announcements help create and maintain
the multicast tree.
B. Core Election
When a receiver joins the group, it checks to see if it
has ever received a core announcement for that group. If so,
then it does not participate in a core election and the current
core of the group remains unchanged. On the other hand, if
it has never received a core announcement for that particu-
lar group, then it considers itself the core of the group and
starts transmitting core announcement packets periodically
to its neighbors stating itself as the core of the group and a
0 distance to itself. Nodes propagate core announcements
based on the best core announcements they receive from
their neighbors. A core announcement with higher core
ID is considered better than a core announcement with a
lower core ID. Eventually, each connected component has
only one core. If one receiver joins the group before other
receivers, then it becomes the core of the group. If several
receivers join the group concurrently, then the one with the
highest ID becomes the core of the group.
A core election is also held if the network is parti-
tioned. The election is held in the partition which does
not have the old core. A node detects a partition if
it does not receive a fresh core announcement for 3
x core
announcement interval. Once a receiver detects a
partition, it behaves in exactly the same way it would upon
joining the group, and participates in the core election.
C. Connectivity Lists and Core Announcement Propagation
A node that believes itself to be the core of a group
transmits core announcements periodically for that group.
As the multicast announcement travels through the network,
it establishes a connectivity list at every node in the net-
work. Using connectivity lists, nodes are able to establish
a mesh, and route data packets from senders to receivers.
A node stores all the core announcements it receives
from its neighbors in the connectivity list. Fresher core
announcements from a neighbor (i.e., one with a higher
sequence number) overwrite entries with lower sequence
numbers for the same group. Hence, for a given group,
a node has only one entry in its connectivity list from a
particular neighbor.
Each entry in the connectivity list, in addition to storing
the core announcement, also stores the time when it was
received, and the neighbor from which it was received. The
node then generates its own core announcement based on
the best entry in the connectivity list.
For the same core ID, core announcements with higher
sequence number are considered better. For the same core
12
3
4
7
8
9
10
6
5
179
2
1
12260
12180
12152
579
Core Announcement
Core Announcement
224.0.0.1
Sequence Number
Distance To Core
Core Id
Group Id
generated by node 6
11
2
79
Connectivity List at node 6 : Core Id = 11 Group Id = 224.0.0.1
11
11
5
1
79
11Core
Sequence Number Distance To Core Parent
Neighbor
Time
(ms)
7
Fig. 1. Dissemination of core announcements
ID and sequence number, core announcements with smaller
distances to the core are considered better. When all those
fields are the same, the multicast announcement that arrived
earlier is considered better. After selecting the best core
announcement, the node generates the fields of its own core
announcement in the following way:
Core ID: The core ID in the best core announcement
Group ID: The group ID in the best core announce-
ment
Sequence number: The sequence number in the best
core announcement
Distance to core: One plus the distance to core in the
best core announcement
Connectivity lists store information about the one or
more route that exist to the core. When a core change
occurs for a particular group, then the node clears its old
connectivity list and builds a new one, specific to the new
core. Hence the group ID and core ID entries are same
for all neighbors, and are not stored separately. Figure 1
illustrates the propagation of core announcements and the
building of connectivity lists. The solid arrows indicate
the neighbor from which a node receives its best core
announcement. Node 6 has three entries in its connectivity
list for neighbors 5, 1, and 7. However it chooses the entry
it has received from 5 as the best entry, because it has the
shortest distance to core and has been received earlier that
the one from node 1. It uses this entry to generate its own
core announcement. When a node node wants to send data
packets to the group it forwards it to the node from which it
received its best core announcement. If that link is broken
then it tries its next best and so on. Hence each node in
the network has one or more routes to the core. The core
announcement sent by the core has distance to core set to
zero.
Fresh core announcements are generated by the core
every three seconds, after which they are disseminated
throughout the network within a relatively short time.
A node thus receives all core announcements with the
latest sequence number within a short period of time from
all its neighbors. After receiving a core announcement
with a fresh sequence number, nodes wait for 100ms
to collect core announcements from multiple neighbors
before generating their own core announcement. A node
may send its core announcement before receiving the core
announcements of some of its neighbors with the same or
longer distance to core. e.g. in Figure 1 node 6 generates its
core announcement at time = 12252ms, which is 100ms
after it receives its first core announcement of sequence
number 79. It receives a core announcement from node 7
later, at time = 12260ms.
D. Tree Establishment and Maintenance
Initially only receivers consider themselves tree-
members. In order to establish a connection to the core each
receiver periodically transmits join announcements. i.e.
once every three seconds. To generate a join announcement
a node also accesses its connectivity list to obtain its best
core announcement. A node generates the fields of the join
announcement in the following way :
Group ID: The ID of the group it wants to join
Sender: Its own ID
Parent : The node from which it received its best core
announcement.
If a non-member receives a join announcement with its
node ID in the parent field, it considers itself to be a tree
member, and similarly generates periodic join announce-
ments. Hence a join announcement sent by each receiver,
triggers the generation of join announcements by all nodes
lying on a shortest path between the receiver and the core.
As all receivers establish a path to the core it follows that
the resulting multicast tree connects all receivers together.
This is illustrated in Figure 2. The tail of the arrow indicates
the node sending the join announcement. The head of the
arrow indicates the node in the parent field of the join
announcement. If a node which is already a tree member
receives a join announcement from a new node, it does
not need to generate an additional join announcement as it
already has established a path to the core. e.g. if node N3
decides to join the group it directs its join announcement
towards node N4. This does not trigger the generation of
join announcement in N4 as it is already a tree member.
It only generates a join announcement once three seconds
have elapsed since it generated its last one.
Every time a node receives a fresh batch of core an-
nouncements, the best entry in its connectivity list may
change depending on the mobility of the network in the
last three seconds. Thus, every time a node sends a join
announcement, the parent field of the join announcement
may vary depending on the latest “best entry” in the
connectivity list. Thus every three seconds each branch of
the tree is established afresh, and each receiver connects to
the core along the “best path”. As a result, certain nodes
which were at one time on the best path from a receiver
N1
N2
N3
N9
N10
N11
N12
N7
N8
N4
Non−Member
Receiver (the group leader
is also a receiver)
R3
R4
R1
Tree member (not a receiver)
Periodic Transmission of Joins
Core
R1
R4
R3
R2
Core
R2R2
000
000
000
000
000
000
000
111
111
111
111
111
111
111
000
000
000
000
000
000
000
111
111
111
111
111
111
111
000
000
000
000
000
000
000
111
111
111
111
111
111
111
000
000
000
000
000
000
000
111
111
111
111
111
111
111
000
000
000
000
000
000
111
111
111
111
111
111
00
0
0
0
0
0
0
00
11
1
1
1
1
1
1
11
N5
N4
N6
N11
N12
Fig. 2. Tree formation in ROMANT
to the core, may no longer be on it. Such nodes will no
longer receive join announcements with their node ID in
the parent field. If no such join announcement is received
by the node for a period of 3 x join
announcement interval,
then the node no longer considers itself to be a tree member
and stops generating join announcements.
E. Data Packet Forwarding
Similar to how join announcements are send, a node
sends a data packet to the node from which it received its
best core announcement. A node learns the MAC address
of its neighbors simply by examining the MAC headers of
their core announcements.. When a node forwards a data
packet, it sets the destination MAC address to the MAC
address of the node from which it received its best core
announcement. A non-member on receiving a data packet,
drops the packet if the destination MAC address is not the
same as its own MAC address. Otherwise it sets the MAC
address to the address of the node from which it received its
best core announcement. This process continues, until the
data packet reaches a tree-member. From there, the packet
is flooded throughout the tree, with a packet ID cache used
to drop duplicate packets. Tree-members forward all data
packets without looking at their MAC addresses. Unlike
PIM sparse mode [19], where a multicast data packet is
encapsulated inside a unicast packet till it reaches the
rendezvous point, there is no need for encapsulation in
ROMANT as the data packet moves from sender to the
tree member.
F. Implicit Acknowledgments
The routing of data packets from senders to receivers is
also used to detect broken links and update the connectivity
list. Assume node X transmits a data packet to node
Y, from whom it received its best core announcement.
