2010 39th International Conference on Parallel Processing

Distributed Minimum Transmission Multicast Routing

Protocol for Wireless Sensor Networks

Long Cheng , Sajal K. Das , Jiannong Cao , Canfeng Chen and Jian Ma

State Key Lab of Networking & Switching Tech., Beijing Univ. of Posts and Telecomm., China

Center for Research in Wireless Mobility and Networking (CReWMaN), University of Texas at Arlington, USA

Department of Computing, Hong Kong Polytechnic University, Hong Kong

Nokia Research Center, Beijing, China
{longc, das}@uta.edu, csjcao@comp.polyu.edu.hk, {canfeng-david.chen, jian.j.ma}@nokia.com

Abstract such as throughput and fairness, become relatively less

Energy efficient multicast routing is one of the fun-
damental problems in wireless sensor networks (WSNs).
Previous work has shown that when the goal is to find mul-
ticast trees with minimum transmission cost, the problem
becomes NP-complete. In this work, we present a heuristic
distributed minimum transmission multicast routing proto-
col (MTMRP) for WSNs. By introducing the biased backoff
scheme and taking advantage of the broadcast nature of
wireless communication, MTMRP chooses the forward-
ing routes which can connect more multicast receivers.
Moreover, MTMRP introduces a path handover scheme,
which can prune redundant routes for multicast routing.
As a result, the multicast transmission cost is reduced in
a distributed manner. We conduct extensive evaluations to
study the performance of the proposed MTMRP compared
with existing protocols. Simulation results demonstrate
that our scheme effectively improves the multicast routing
energy efficiency.
Index TermsMulticast routing; minimum transmission;
wireless sensor networks
I. Introduction
Wireless sensor networks (WSNs) have attracted in-
tensive attention in recent years due to their wide va-
riety of potential applications, including environment or
habitat monitoring, smart battlefield, home automation,
health care and traffic control, etc. [1]. These sensors
usually operate on limited non-rechargeable battery power,
and are expected to last over several months or years.
Therefore, energy efficiency becomes one of the most
critical design issues for WSNs, while other constraints,
important [2].
The one-to-many communication (multicast routing)
has a lot of potential applications in WSNs, e.g., a source
node sends messages to multiple sinks; or distribution of
control message from a sink to a set of sensor nodes.
One straightforward way to provide the one-to-many com-
munication is through the flooding. With this approach,
the data packet is sent throughout the network, and every
node that receives this packet only broadcasts it to its
immediate neighbors once. However, this naive approach
is too costly for the resource constrained WSNs since a
number of duplicate packets are sent. This observation
brings to the fore the multicast routing, where a message is
to be delivered from a source node to multiple destinations
(also referred as multicast receivers in the literature), to
manage and reduce network traffic. Usually, the research
on multicast routing is to find a multicast tree [3], which
is rooted from the source and spans all destination nodes.
Considering the limitation of sensors on energy supply,
in this work, we address the problem how to improve
the energy efficiency of multicast routing in WSNs. The
objective of this work is to reduce the number of packets
transmitted when multicasting data to a set of destination
nodes. We refer to this problem as the minimum transmis-
sion multicast routing (MTMR) problem, which existing
work [3] [4] has demonstrated that this problem is NP-
complete.
The broadcast nature of wireless communications sug-
gests that the transmission of a multicast data packet from
a given node to any number of its neighbors can be
done with a single transmission. For a multicast tree in
wireless networks, only the non-leaf nodes need to forward
packets further down to multicast receivers and all the leaf
nodes are destinations that only receive multicast packets.

0190-3918/10 $26.00 2010 IEEE 188

DOI 10.1109/ICPP.2010.28
Notice that multicast receivers are not necessarily the leaf
nodes in a multicast tree; they can also act as forwarders.
Therefore, the energy efficiency of multicast routing can
be achieved by reducing the number of forwarding nodes
and increasing the number of leaf nodes.
In this work, we present a heuristic minimum trans-
mission multicast routing protocol (MTMRP) for WSNs
to construct the multicast tree, so that the number of
transmissions required to deliver a packet from the source
node to multicast receivers is minimized. MTMRP is
a lightweight and distributed protocol, it introduces the
destination-driven feature [5] [6] and basically uses only
the one-hop neighborhood information to construct a mul-
ticast tree from the source node. The destination-driven
feature is that, given multiple destinations, paths are biased
towards those that run through destination nodes, i.e.,
the difference of packet routing latency at each hop is
amplified intentionally.
Two main contributions of this work, which make
MTMRP distinct from existing work, are as follows: 1) We
propose a new metric in the biased backoff scheme for se-
lecting routes which can connect more multicast receivers;
2) We introduce a path handover scheme (PHS), which not
only reduces the transmission overhead in the multicast
tree construction phase, but also prunes redundant routes
for the minimum transmission multicast routing. We would
like to point out that the idea in MTMRP can be applied
to most existing on-demand multicast routing protocols.
MTMRP is practical in implementation, thus, it can serve
as a general architectural extension to those on-demand
routing protocols where the route discovery process is
performed.
The rest of this work is organized as follows: Section
II surveys related work. Section III introduces the network
model. In Section IV, the detailed design of MTMRP
is presented. Simulation results are shown in Section V.
Finally, Section VI concludes this work.
II. Related Work
In this section, we briefly review previous work on
multicast routing for wireless ad hoc and sensor networks.
Many multicast routing protocols have been proposed in
the literature. In [7], the authors classified those proposed
multicast routing protocols into four categories based on
how routes are created to the members of the group: 1)
Tree-based approaches [8] [9]; 2) Mesh-based approaches
[10] [11] [12]; 3) Stateless multicast [13] [14]; 4) Hybrid
approaches [15]. A more detailed taxonomy on multicast
routing was presented in [16]. Existing study [17] showed
that the tree-based approach provides high data forwarding
efficiency at the expense of low robustness, whereas mesh-
based approach provides better robustness at the expense
189
of higher forwarding overhead and increased network load.
For WSNs, sensor nodes are usually powered by batter-
ies of limited capacity. Once they are deployed, it is very
difficult or even impossible to recharge or replace their
batteries in many application scenarios, e.g., battlefield
or volcano. Therefore, the energy efficiency becomes the
major design objective for multicast routing in WSNs.
However, the authors in [3] and [4] demonstrated that
computing minimum transmission multicast trees is a NP-
complete problem, which can be proven through reducing
the minimum set (vertex) cover problem or the minimum
common dominating set problem.
Due to the NP-completeness of the minimum transmis-
sion multicast routing problem, several heuristic protocols
have been proposed [18] [19]. However, most existing
proposed protocols are centralized, in which the whole
network topology is assumed to be known by a single node
to compute the multicast tree. For example, the authors
in [3] proposed three heuristic but centralized protocols,
namely Steiner tree based, Node-Join-Tree and Tree-Join-
Tree greedy protocols. Penttinen [20] presented a heuristic
algorithm for multicast tree construction in static ad hoc
networks based on the assumption that the all-pairs shortest
path information is available. Obviously, the centralized
approach that assumes a single node being aware of the
whole network topology is neither practical nor energy
efficient for many applications. Although a distributed
approach was also described in [4], it requires all receivers
to initiate the multicast tree construction phase at the same
time. In DODMRP [6], the authors proposed to reduce
the number of non-multicast group member nodes (called
extra nodes), in order to improve the energy efficiency
of multicast routing. However, we will show that only
reducing the number of extra nodes does not necessarily
reduce the transmission cost.
There are also some proposals [14] [21] taking advan-
tage of location information to perform multicast routing
in WSNs. The geographic multicast routing can remove the
need for state maintenance (e.g., tree/mesh/neighbor table
maintenance) under the assumption that each node knows
its own geographical location and the source node knows
the locations of all the multicast receivers. In geographic
multicast routing, the most challenging problem is to
decide when the message should be replicated/splited into
different packets.
III. Network Model
We consider a multi-hop wireless network with sensor
nodes deployed in a two-dimensional planar region. We
assume the locations of nodes are static or change slowly.
Highly node mobility is not considered in this work. Each
sensor node has a fixed level of transmission power and
has the same transmission range . A packet is received
successfully if the received signal power is greater than
the receiving power threshold. As most other work in this
area, the network is modeled by an undirected graph =
(, ), where is a set of sensor nodes and represents
the set of communication links. For any two nodes 1 and
2 (1 , 2 ), if node 2 is in the transmission power
range of node 1 , then there is an undirected arc (1 , 2 )
. that it only needs 4 transmissions. The low transmission
Suppose (, ) is a given multicast request,
where is the source and specifies a set of
multicast receivers , i.e., all multicast receivers have the
same . Given a graph = (, ), a source
node and a set of receivers , the multicast routing
problem, can be defined as follows: finding a multicast
tree in which connect the source to every multicast
receiver . Such a tree includes a set of forwarding
nodes so that {} are connected. In a
multicast tree , all the leaf nodes are destinations that
only receive multicast packets; only the non-leaf nodes
take the forwarding task.
The cost of a transmission consists of the sending
cost of the sender, and the receiving cost of its one
hop neighbors. Given an evenly distributed WSN without
work/sleep operation, the transmission cost is proportional
to the sending cost. Therefore, to improve the energy
efficiency of multicast routing in WSNs is to reduce the
number of forwarding nodes. The minimum transmission
multicast routing (MTMR) problem can be formulated
as how to minimize the size of the forwarding node set
on the premise that {} are connected.
Since this problem is NP-complete [3] [4] and requires
heuristic solutions, in the next section, we will present our
heuristic minimum transmission multicast routing protocol
(MTMRP) for WSNs to tackle this problem.
IV. Protocol Description
A. Motivation
Before providing the detailed design of MTMRP, we
first illustrate the differences in transmission cost for
three multicast trees over the same network, according
to different path selection metrics as shown in Fig. 1. A
source node sends data to 5 multicast receivers. Each node
has 4 adjacent neighbors at most, there are no diagonal
links. In Fig. 1(a), the multicast tree is constructed in
terms of finding the shortest path to all multicast receivers,
in which the packet can be routed from the source to
any destination with minimum number of hops. In this
example, the multicast tree involves 10 nodes, 9 edges,
and requires 7 transmissions to complete the multicasting
task. Fig. 1(b) is an example illustrating the multicast tree
with minimum edge cost. In fact, such minimum cost
multicast tree is well-known as the Steiner tree problem.
However, it is not the best solution for WSNs, the multicast
routing energy efficiency can be further improved. In this
example, the multicast tree involves 9 nodes, 8 edges, and
requires 7 transmissions. Fig. 1(c) illustrates the minimum
transmission multicast tree, which takes advantage of the
broadcast nature of wireless communication. We can see
overhead makes this kind of multicast tree suitable for the
energy constrained WSNs.
R R R R R R
S R S R
R R R R
(a) (b)
R R R
S Source
Forwarder
S R
R Receiver
R R
R Forwarder and Receiver
(c)
Fig. 1. Examples of three different multicast
trees over the same network: (a) the shortest
path (SPT) multicast tree; (b) the multicast
tree with minimum edge cost, i.e., the mini-
mum Steiner tree; (c) the minimum transmis-
sion multicast tree
B. Initialization
An initialization phase is performed to enable some of
the functions needed for MTMRP. A node periodically
broadcasts a HELLO message to exchange the multicast
group membership information, e.g., multicast GroupID,
with all its one hop neighbors. Such HELLO message will
also be sent if a node wants to update its multicast group
membership information. After this phase, a node knows
all its immediate neighbors multicast group membership.
In MTMRP, each node maintains an one hop neighbor
table, in which the time stamp of each entry (the last time
receiving this HELLO message) is also recorded. Once
receiving a HELLO message, it looks up the neighbor table
according to the NodeID of the received HELLO message.
If it is a new neighbor, a new entry will be inserted into
the table. If an already known neighbor, the time stamp
of that entry will be updated. A node sets up a timer to
avoid misleading information, i.e., the overdue entries in
the neighbor table will be recycled after a time.
190
C. Multicast tree construction
MTMRP is similar to ODMRP [10] in that it also
applies the on-demand procedures to dynamically build
routes and maintain multicast group membership to avoid
channel overhead and improve scalability. When a multi-
cast source has data to send, it floods a multicast request
(, ). To keep consistency with previous work,
we also refer to this multicast request as the JoinQuery
message.
1) JoinQuery propagation: When a multicast source
has data to send, it will flood a JoinQuery. A Join-
Query message is at least composed of the following
elements: MessageType, NodeID, SourceID, GroupID, Se-
quenceNumber, HopCount and PathProfit (defined in Sec-
tion 4.3.3). specifies that it is a JoinQuery covered by other forwarding nodes.
message. is maintained by the source
node and increased each time the source floods a new
JoinQuery. together with the and the overheard JoinReply nearby. If a node overhears that
identifies a JoinQuery to prevent loops a multicast receiver sends out a JoinReply, it will mark
and to discard stale routes. HopCount is the hop distance
from the source thus far. NodeID, HopCount and PathProfit
will be updated at each hop.
When a node receives a non-duplicate JoinQuery, it
stores the upstream (for reverse path learning),
, and into the the source to current forwarding node is the total num-
routing table and will forward this JoinQuery. Instead of
rebroadcasting the JoinQuery immediately, like DODMRP
[6], we introduce a backoff time at the JoinQuery forward-
ing node intentionally, based on a new metric which we
will give the definition below. The aim of this operation
is to amplify the differences of a JoinQuerys traversing
delay along different paths. This enables the JoinQuery
to travel faster along the selected path according to our
defined metric than other paths.
When the backoff timer expires, the JoinQuery is re-
broadcasted. When it reaches a multicast receiver, this
receiver marks itself as a covered multicast receiver, then
generates and broadcasts a JoinReply message. This Join-
Reply will return to the multicast source along the reverse
path of the JoinQuery. Note that in case of receiving the
same JoinQuery several times, the receiver shall only reply
the first received JoinQuery and neglect others.
2) JoinReply propagation: A JoinReply message is
at least composed of the following information: Mes-
sageType, NodeID (refers to the lasthop NodeID), Nex-
thopID, ReceiverID, SourceID, GroupID and Sequen-
ceNumber. NexthopID specifies the selected next hop node.
ReceiverID specifies the node who originates the JoinRe-
ply.
When a node receives a JoinReply, no matter whether
it is a multicast receiver or not, it checks if it is the
selected next hop of the JoinReply. If that is the case, it
realizes that it is on the path to the source, and it marks
itself as a forwarder (by setting a flag ) for
the current multicast session. Then, the forwarding node
updates the JoinReply message, filling its cached upstream
NodeID of this multicast session as the NexthopID. In this
way, the JoinReply is propagated by each forwarder until it
reaches the source via the reverse path of the corresponding
JoinQuery. Finally, this process constructs the routes from
the source to all multicast receivers.
3) Biased backoff scheme: Specifically, we need two
definitions which are used in MTMRP.
Definition 1. (RelayProfit) We define RelayProfit of a
forwarding node as the number of multicast receivers that
this forwarding node covers1 among its neighbors, but not
including the multicast receivers that have already been
The RelayProfit is dynamically calculated according to
this neighbor as a covered receiver. Given the one hop
neighbor table and a JoinQuery message, the forwarding
node knows the number of uncovered multicast receivers
in the same multicast group among its neighbors.
Definition 2. (PathProfit) The PathProfit of a route from
ber of multicast receivers that this path covers, but not
including the RelayProfit of current forwarding node.
= ( ) (1)
=1
where {, 1 , 2 , . . . , , } is a path connecting the
source and current forwarding node . ( )
denotes the RelayProfit of node . We know that Path-
Profit is non-decreasing as the JoinQuery spreads over the
network.
The heuristic of MTMRP lies in the biased backoff
scheme. As we learned from the motivation, giving the
node with larger RelayProfit and PathProfit higher priority
to take the forwarding task may possibly reduce the
number of forwarding nodes and increase the number of
leaf nodes. That is to say, both RelayProfit and PathProfit
influence the backoff time calculation. Thus, we introduce
two kinds of backoff delays: 1) relay backoff delay ;
and 2) path backoff delay , which are defined as Eq.
2 and Eq. 3, respectively.
= 2( ) (2)
1 In this work, covered refers to connected, denoting that there is
a multihop route connecting the source to a multicast receiver via some
forwarding nodes.
191
 RP = 1 RP = 1
PP = 0 PP = 0
A C RP = 1
A C
PP = 1
S S
RP = 1 D RP = 1
PP = 1 B PP = 1 B PP = 0
(a) MTMRP (b)
Fig. 2. MTMRP is designed to involve less
extra nodes. (a) The case that extra node B
forwards the earlier; (b) Multicast
receiver is biased to forward the
earlier. The RelayProfit and PathProfit are de-
noted by and , respectively
= (3)
( + 1)
where and are system parameters, is set to limit
the backoff delay within a certain range, is the time slot
unit.
Besides, MTMRP tends to involve less non-multicast
group members, which we call the extra nodes. Consider
an example scenario as shown in Fig. 2, where source S
multicasts a packet to receivers C and D. In the multicast
tree construction phase, both nodes B and C receive the
message broadcasted by node A and they have
the same RelayProfit and PathProfit values. In this case,
node C is biased to forward the earlier. In
Fig. 2(a), the multicast routing needs 3 transmissions, and
involves 2 extra nodes. However, Fig. 2(b) involves 1 less
extra node.
Let denote the backoff delay at the forwarding
node . is calculated as defined in Eq. 4.
{ the multicast tree is constructed, in which only nodes ,
+ + (0, ), if and are involved as forwarders.
=
+ + (, 2 ), 4) Optimization: To further reduce the transmission
(4)
The random function aims to mitigate the radio inter-
ference. (, ) returns a random value between
and . After computing the , the forwarding node
starts a backoff timer. From Eq. 4, we can see that at each
hop, the larger RelayProfit and PathProfit are, the earlier
time slot it will assign. Consequently, the higher priority is
possibly given to the route with less number of forwarding
nodes and larger number of leaf nodes.
Let us retrospect the example in Fig. 1(c). We show
how MTMRP constructs the multicast tree in Fig. 3. The
figures in square brackets represent the backoff delay at a
forwarding node. When node receives a JoinQuery from
the source, it will first get its RelayProfit and calculates the
. For node , the value is between 4 and 5 .
[4,5]
N=3 A D G
RP = 1 RP = 1
PP = 1 PP = 2
HC = 2
[4,5] [3,4] [3.6,4.6]
D S B RP = 2
E RP = 2
H RP = 2
J
PP = 2 PP = 4
HC = 1 HC = 2 HC = 3
C [4,5] F I
RP = 1
PP = 2
HC = 2
Fig. 3. An example illustrating how MTMRP
constructs the multicast tree. The RelayProfit,
PathProfit and HopCount are denoted by ,
and , respectively
Then, it will update JoinQuerys NodeID, HopCount and
PathProfit fields. Meanwhile, it starts a backoff timer and
rebroadcasts the JoinQuery when the backoff timer expires.
Nodes , and receive the JoinQuery forwarded by
node . Since nodes and are multicast receivers, they
will return JoinReplys to the source. Once node receives
a JoinReply from , it will mark itself as a forwarder
and relay the JoinReply to the source. Meantime, node
overhears the JoinReply from , then, it marks node
as a covered neighbor, who wont be counted when
calculating the RelayProfit. Similarly, node marks
as a covered neighbor. For node , = 2,
= 2 and = 2, thus, it will defer
[3 23 , 4 23 ], according to Eq. 4. While for nodes and
, they will defer [4 23 , 5 23 ]. In this case, node will
rebroadcast the JoinQuery earlier. When nodes and
receive the JoinQuery from and , respectively, since
they have received JoinQuerys with the same multicast
session, they will discard the duplicate JoinQuerys. Finally,
cost for multicast routing, MTMRP could use overhearing
to reduce unnecessary transmissions, which is called path
handover scheme (PHS). The principle of overhearing is
that because the wireless medium is shared, each node can
overhear data packets sent by its neighbor.
When a node receives a JoinReply message, if it is
not the selected next hop of the JoinReply, it compares
the JoinReplys NodeID and ReceiverID. If the NodeID
is not equal to ReceiverID, that means this JoinReply is
relayed from a forwarder. In this case, it will update its
neighbor table and mark this neighbor as a forwarder.
If it is the selected next hop of the JoinReply, it first
checks whether there is any forwarder in its neighbor table.
If finding a forwarder, there is no need to forward this
JoinReply. Because there must be a route from the source
192
to the multicast receiver who originates this JoinReply. It
only marks itself as a forwarder for the current multicast
session.
Similarly, when a multicast receiver receives a Join-
Query message, before replying the JoinReply, it first
checks whether there is any forwarder in its neighbor table.
If there is, it will remain silent. If not, it then sends out a
JoinReply. Besides, considering the uncertainty of wireless
G I
path handover
H
C
F
A Backoff( , );
S /* It will schedule a backoff timer
E whose value is
B D JoinQuery
JoinReply
Fig. 4. An example illustrating the path han-
dover scheme (PHS) in MTMRP
channel, e.g., contention or collision, it is still possible that
a node receives a JoinReply, but it has marked itself as
a forwarder. In this case, it will discard this JoinReply.
When a multicast receiver receives a JoinReply, if it is
the selected next hop of the JoinReply and it has been
covered, it will mark itself as a forwarder and then discard
this JoinReply.
PHS can not only reduce the transmission cost in
multicast tree construction phase, but also prune redundant
routes for multicast routing. An example is shown in Fig.
4. When node receives a JoinReply originated from ,
since node has overheard a JoinReply from before,
it knows that there is a forwarder among its neighbors.
Therefore, it marks itself as a forwarder and then discard
the JoinReply received from . We can see that the origi-
nal path is handovered from [ ]
to [ ] by introducing PHS. This oper-
ation saves 2 transmissions and involves 1 less extra node.
Regarding how a node handles a received JoinQuery
and JoinReply in MTMRP, we illustrate the pseudo codes
of RecvJoinQuery() and RecvJoinReply() in Algorithm 1
and Algorithm 2, respectively.
D. Data forwarding
Once the multicast routing tree is constructed, data for-
warding is very simple. Like ODMRP [10] and DODMRP
[6], when the multicast source sends out data packets,
only those nodes whose is active (marked as
forwarders) will take the forwarding task. To avoid the
1 Procedure: void RecvJoinQuery (Packet *p)
2 if Non-duplicate JoinQuery then
3 if I am a multicast receiver then
4 if There is a forwarder among my
neighbors then
5 remain silent;
6 else
7 send out JoinReply;
8 end
9 mark myself as a covered multicast
receiver;
10 end
11 calculate and call
, then call
forwardJoinQuery(p) when the timer
expires */
12 else
13 Drop();
14 end
Algorithm 1: Algorithm in MTMRP when a node
receives a JoinQuery message
packet duplications, a forwarder shall only forward data
the first time it receives.
It is possible that the discovered routes between source
and multicast receivers break, e.g., a forwarder runs out of
energy. In this situation, the route recovery mechanism can
be adopted. For example, if a multicast receiver detects a
missing forwarder through periodical HELLO messages,
it can broadcast a route error message to repair the failed
link locally [22] or even trigger the source to initiate a new
multicast routing construction process [23].
V. Simulation
In this section, we present simulation results to evaluate
the performance of MTMRP using ns-2 [24] simulator
by comparing it with DODMRP [6], ODMRP [10] and
MTMRP w/o PHS (MTMRP without adopting the path
handover scheme). All the results have been averaged over
100 Monte Carlo runs.
A. Simulation settings
To fully evaluate the MTMRP, we carry out both grid
topology and random topology tests in a 200 200
square area. In the grid topology, 10 10 sensor nodes are
uniformly placed in the field, forming a two dimensional
grid. The random topology with 200 sensor nodes is
193
 loss exponent. We set = = 1, = = 1.5,
1 Procedure: void RecvJoinReply (Packet *p)
= 1, and = 4 in our simulation.
2 if Non-duplicate JoinReply then We select three evaluation metrics:
3 if My NodeID == JoinReply.NexthopID then
Normalized transmission overhead: This metric
4 if There is a forwarder among my
measures the communication overhead and energy
neighbors then
efficiency. We define the normalized transmission
5 mark myself as a forwarder;
overhead as the number of transmissions required to
6 Drop();
deliver a data packet from the source to all multicast
7 else
receivers.
8 if I am a forwarder then Number of extra nodes: This metric is defined as
9 Drop(); the number of extra nodes involved in a multicast
10 else if I am a multicast receiver and tree. Under the premise of reducing the transmission
has been covered then overhead, MTMRP tends to involve less extra nodes.
11 mark myself as a forwarder; Average relay profit: This metric is defined as the
12 Drop(); average of each relays RelayProfit in a multicast tree.
13 else In some sense, it also reflects the energy efficiency of
14 get JoinReplys nexthop; a multicast routing protocol.
15 call forwardJoinReply(p);
16 end B. Simulation results
17 end
18 else 1) Grid topology test: We start our evaluation with a
19 if JoinReply.ReceiverID!=JoinReply.NodeID grid topology, to first measure the performance gains of
then MTMRP before moving onto more general topologies. 20
20 mark this neighbor as a forwarder; multicast receivers are randomly selected at each round.
21 else Fig. 5 shows the results when we vary the multicast group
22 mark this neighbor as a covered size, i.e., the number of the multicast receivers.
receiver; Fig. 5(a) reports the changes of the normalized trans-
23 end mission overhead at increasing the multicast group size.
24 Drop(); The figure clearly shows that MTMRP outperforms
25 end DODMRP and ODMRP in terms of energy efficiency.
26 else
When the multicast group size is small, the gap between
27 Drop(); MTMRP and DODMRP is not obvious. The reason is
28 end
that the multicast receivers are very sparsely distributed in
Algorithm 2: Algorithm in MTMRP when a node the network when multicast group size is small. However,
receives a JoinReply message as the multicast group size increases, we observe that
MTMRP shows obvious superiority to other two protocols.
It can save about 3 transmissions on average2 . We also see
generated by the setdest tool in ns-2. The multicast source that DODMRP approaches to ODMRP as the multicast
node is positioned at bottom left (0, 0), and all the group size increases.
multicast receivers are randomly generated at each round. Fig. 5(b) illustrates the number of extra nodes involved
The sensor node transmission range is taken 40. in a multicast routing as the multicast group size changes.
and are set 0.001 and 4, respectively. The MAC layer It is seen that both DODMRP and MTMRP show ob-
protocol is IEEE 802.11 MAC. TwoRayGround channel vious improvements compared with ODMRP. Although
model is adopted as the signal propagation model, where DODMRP involves least number of extra nodes in this
the shadowing fading factor is not considered. Therefore, test, MTMRP is comparable with DODMRP.
for a unique distance, given the transmission power , the Fig. 5(c) plots the average relay profit under differ-
receiving power is a deterministic value as expressed ent multicast group sizes. As the multicast group size
in Eq. 5,
2 The multicast routing performance depends much on the distribution
2 2
() = (5) of multicast receivers in a network. In our simulation, all the multicast
receivers are randomly generated in each round. For some randomly
generated distributions, e.g., when multicast receivers are very scattered
where is the distance between the sender and receiver; or crowded, MTMRP wont show obvious advantage over other protocols.
and are the antenna gains; and are the Therefore, we believe 3 transmissions saving on average under the
antenna heights; is the loss factor, and is the path- randomly generated distributions is not a minute reduction.

194
Normalized transmission overhead

MTMRP 5.5 MTMRP

40 28
MTMRP w/o PHS 5 MTMRP w/o PHS
DODMRP

Number of extra nodes

26 DODMRP 4.5

Average relay profit

35 ODMRP ODMRP
24 4

30 22 3.5
3
20
25 2.5
18 2
20 MTMRP 16 1.5
MTMRP w/o PHS 1
14
15 DODMRP
0.5
ODMRP 12
0
5 10 15 20 25 30 35 40 45 50 55 60 5 10 15 20 25 30 35 40 45 50 55 60 5 10 15 20 25 30 35 40 45 50 55 60
Multicast group size Multicast group size Multicast group size
(a) Normalized transmission overhead (b) Number of extra nodes (c) Average relay profit

Fig. 5. Performance difference in grid topology

7.5
Normalized transmission overhead

30 7 MTMRP
35
28 6.5 MTMRP w/o PHS
Number of extra nodes

6 DODMRP

Average relay profit

30 26 5.5 ODMRP
24 5
4.5
25 22 4
20 3.5
3
20 18 2.5
MTMRP 16 MTMRP 2
15 MTMRP w/o PHS MTMRP w/o PHS 1.5
DODMRP 14 DODMRP 1
ODMRP 12 ODMRP 0.5
10 0
5 10 15 20 25 30 35 40 45 50 55 60 5 10 15 20 25 30 35 40 45 50 55 60 5 10 15 20 25 30 35 40 45 50 55 60
Multicast group size Multicast group size Multicast group size
(a) Normalized transmission overhead (b) Number of extra nodes (c) Average relay profit

Fig. 6. Performance difference in random topology

increases, the average relay profit for different protocols average relay profit.
increases as well. MTMRP always provides highest aver-
From Fig. 5 and Fig. 6, we also see that MTMRP
age relay profit. Although the differences seem very small,
behaves a little better than MTMRP w/o PHS in all metrics,
it still reflects the energy efficiency of a multicast routing
which benefits from the cases where a longer path is
protocol. This is because that all the results have been
handovered to a shorter path in PHS.
averaged over all forwarders.
2) Random topology test: In this test, 15 multicast 3) Tuning system parameters: In this experiment we
receivers are randomly selected at each round. The simu- adjust the system parameters and used in MTMRP.
lation results are shown in Fig. 6. Fig. 7 shows the effect under different and in grid
Fig. 6(a) depicts the performance comparison on the topology, where 20 multicast receivers are randomly se-
normalized transmission overhead. When the value of lected at each round. We see that MTMRP is more affected
multicast group size is within 10 to 40, the reduction of by the system parameters. This is due to the biased backoff
transmission overhead for MTMRP is obvious. Although scheme, the larger and , the more amplified difference
the performance is more influenced by the uncertainty in of routing latency at each hop. For example, when = 3
random topology, MTMRP shows more or less advantages and = 0.001, there is no significant difference between
over other two protocols averagely. DODMRP and MTMRP. As and increase, MTMRP
Fig. 6(b) shows the changes of the number of involved achieves a distinct advantage over other protocols. Note
extra nodes under different multicast group sizes. When the that the price paying for the reduced transmission cost
multicast group size is small, MTMRP is comparable with for DODMRP and MTMRP is the introduced backoff
DODMRP. However, as the multicast group size increases, delay at each hop during the multicast tree construction
less extra nodes are involved in DODMRP. phase. However, during the data forwarding phase, the
Fig. 6(c) illustrates the results of the average relay transmission overhead can be reduced significantly. When
profit. Similar as the grid topology test, the average relay tuning and in random topology, where 15 multicast
profit for different protocols increases at increasing the receivers are randomly selected at each round, Fig. 8 shows
multicast group size and MTMRP always provides highest the same results as in Fig. 7.

195
 MTMRP MTMRP
MTMRP w/o PHS MTMRP w/o PHS
DODMRP DODMRP

Normalized transmission overhead

Normalized transmission overhead

ODMRP ODMRP
32 26

30 24

28 22

26 20

24 0.03 18 0.03
0.025 0.025
22 3 0.02 16 3 0.02
0.015 0.015
4
5
0.01 4
5
0.01
0.005 0.005
N 6 N 6

Fig. 7. Tuning system parameters and Fig. 8. Tuning system parameters and
in grid topology in random topology

4) A closer observation: To have an intuitive under-
standing of the above tests, we give a closer observation.
We show snapshots of multicast routing paths taken by
three different protocols in Fig. 9 and Fig. 10. The hollow
blue circles represent sensor nodes deployed in the field;
the red crosses represent the multicast receivers; and the
filled black circles represent the forwarders in multicast
routing.
As shown in Fig. 9, MTMRP needs 26 transmissions
and involves 21 extra nodes. 32 transmissions and 20 extra
nodes are required in DODMRP. While for ODMRP, it
needs 33 transmissions and involves 29 extra nodes to com-
plete the multicast routing task. The snapshots of routing
paths for different protocols in random topology are shown
in Fig. 10. In this example, the required transmissions
are 16, 21, 24 for MTMRP, DODMRP and ODMRP,
respectively.
From the above simulation results, we know that only
reducing the number of extra nodes [6] does not neces-
sarily reduce the transmission overhead. To improve the
energy efficiency of multicast routing, it can be achieved
by reducing the number of forwarding nodes and at the
same time increasing the number of leaf nodes. Con-
clusively, compared with existing distributed protocols,
MTMRP reduces the energy cost for multicast routing.
VI. Conclusion
In this work, we proposed MTMRP, a heuristic dis-
tributed multicast routing protocol for WSNs. The design
objective of MTMRP is to reduce the transmission cost
for multicast routing in WSNs. MTMRP introduces the
biased backoff scheme and basically uses only one-hop
neighborhood information to construct a multicast tree. It
also takes advantage of the broadcast nature of wireless
communication and introduces the path handover scheme
(PHS), which can prune redundant routes in multicast rout-
ing. We compared MTMRP with existing protocols using
ns-2 simulator. Simulation results demonstrated that our
proposed MTMRP could effectively improve the energy
efficiency for multicast routing.
Acknowledgment
The authors would like to thank the anonymous re-
viewers for the helpful comments and suggestions. The
work of Long Cheng was done while he was a vis-
iting scholar at CReWMaN Lab at the University of
Texas at Arlington. This work is partially supported by
National Natural Science Foundation of China (NSFC)
under grant No.60873241; National 863 High Technol-
ogy Program of China under grant No.2008AA01Z217
and No.2009AA01Z210. NSF Grant IIS-0326505, CNS-
0721951 and CNS-0916221 and AFOSR Grant A9550-08-
1-0260. The work of S. K. Das is also supported by (while
serving at) the National Science Foundation. Any opinion,
findings, and conclusions or recommendations expressed in
this material are those of the authors and do not necessarily
reflect the views of the National Science Foundation.
References
[1] K. Romer and F. Mattern, The design space of wireless sensor
networks, IEEE Wireless Communications, vol. 11, no. 6, pp. 54
61, 2004.
[2] L. Wang and Y. Xiao, A survey of energy-efficient scheduling
mechanisms in sensor networks, Mobile Networks and Applica-
tions, vol. 11, no. 5, pp. 723740, 2006.
[3] X. Jia, D. Li, and F. Hung, Multicast routing with minimum energy
cost in ad hoc wireless networks, in IEEE GLOBECOM 04, Nov
2004, pp. 28972901.
[4] P. Ruiz and A. Gomez-Skarmeta, Approximating optimal multicast
trees in wireless multihop networks, in IEEE Symposium on
Computers and Communications, June 2005, pp. 686691.

196
 200 200 200
180 180 180
160 160 160
140 140 140
Y-axis (m)

Y-axis (m)

Y-axis (m)
120 120 120
100 100 100
80 80 80
60 60 60
40 40 40
20 20 20
0 0 0
0 20 40 60 80 100 120 140 160 180 200 0 20 40 60 80 100 120 140 160 180 200 0 20 40 60 80 100 120 140 160 180 200
X-axis (m) X-axis (m) X-axis (m)
(a) MTMRP, 26 transmissions, 21 extra nodes (b) DODMRP, 32 transmissions, 20 extra nodes (c) ODMRP, 33 transmissions, 29 extra nodes

Fig. 9. Snapshots of routing paths for different protocols in grid topology, 20 multicast receivers are
randomly selected

200 200 200

180 180 180
160 160 160
140 140 140
Y-axis (m)

Y-axis (m)
Y-axis (m)

120 120 120

100 100 100
80 80 80
60 60 60
40 40 40
20 20 20
0 0 0
0 20 40 60 80 100 120 140 160 180 200 0 20 40 60 80 100 120 140 160 180 200 0 20 40 60 80 100 120 140 160 180 200
X-axis (m) X-axis (m) X-axis (m)
(a) MTMRP, 16 transmissions, 13 extra nodes (b) DODMRP, 21 transmissions, 15 extra nodes (c) ODMRP, 24 transmissions, 23 extra nodes

Fig. 10. Snapshots of routing paths for different protocols in random topology, 15 multicast receivers
are randomly selected

[5] A. Shaikh and K. Shin, Destination-driven routing for low-cost
multicast, IEEE Journal on Selected Areas in Communications,
vol. 15, no. 3, pp. 373381, 1997. [16]
[6] K. Tian, B. Zhang, H. Mouftah, Z. Zhao, and J. Ma, Destination-
driven on-demand multicast routing protocol for wireless ad hoc
networks, in IEEE ICC 09, June 2009, pp. 15. [17]
[7] G. H. A. D. de Morais Cordeiro, C., Multicast over wireless mobile
ad hoc networks: present and future directions, IEEE Network,
vol. 17, no. 1, pp. 5259, 2003. [18]
[8] C. E. Perkins and E. M. Royer, Multicast ad hoc on-demand
distance vector (maodv) routing, IETF Intemet Draft: draft-ietf-
manet-maodv-00.txt, 2000. [19]
[9] S. Anmol, S. Brian, and H. Richard, VLM: a very lightweight
mobile multicast system for wireless sensor networks, in IEEE
WCNC 03, Mar 2003, pp. 19361941. [20]
[10] S. J. Lee, W. Su, and M. Gerla, On-demand multicast routing
protocol in multihop wireless mobile networks, Mobile Networks [21]
and Applications, vol. 7, no. 6, pp. 441453, 2002.
[11] J. Garcia-Luna-Aceves and E. Madruga, The core-assisted mesh
protocol, IEEE Journal on Selected Areas in Communications,
vol. 17, no. 8, pp. 13801394, Aug 1999. [22]
[12] C.-C. Chiang, M. Gerla, and L. Zhang, Forwarding group multicast
protocol (fgmp) for multihop mobile wireless networks, Cluster
Computing, vol. 1, no. 2, pp. 187196, 1998. [23]
[13] M. Lusheng Ji, Corson, Differential destination multicast-a manet
multicast routing protocol for small groups, in IEEE INFOCOM
01, 2001, pp. 11921201.
[14] S. I. Sanchez J.A., Ruiz P.M., GMR: Geographic multicast routing [24]
for wireless sensor networks, in SECON 06, 2006, pp. 2029.
[15] J. Xie, R. R. Talpade, A. Mcauley, and M. Liu, AMRoute: Ad
hoc multicast routing protocol, Mobile Networks and Applications,
vol. 7, no. 6, pp. 429439, 2002.
L. Junhai, X. Liu, and Y. Danxia, Research on multicast routing
protocols for mobile ad-hoc networks, Computer Networks, vol. 52,
no. 5, pp. 988997, 2008.
T. Kunz, Multicasting in ad-hoc networks: Comparing maodv and
odmrp, in Proceedings of the Workshop on Ad hoc Communica-
tions, 2001, pp. 186190.
S. Guo and O. W. W. Yang, Energy-aware multicasting in wireless
ad hoc networks: A survey and discussion, Computer Communi-
cations, vol. 30, no. 9, pp. 21292148, 2007.
C. Papageorgiou, P. Kokkinos, and E. Varvarigos, Energy-efficient
multicasting in wireless networks with fixed node transmission
power, in ACM IWCMC 09, 2009, pp. 958962.
A. Penttinen, Minimum cost multicast trees in ad hoc networks,
in IEEE ICC 06, June 2006, pp. 36763681.
H. Frey, F. Ingelrest, and D. Simplot-Ryl, Localized minimum
spanning tree based multicast routing with energy-efficient guar-
anteed delivery in ad hoc and sensor networks, in WOWMOM 08,
2008, pp. 18.
M. Naderan-Tahan, A. Darehshoorzadeh, and M. Dehghan,
ODMRP-LR: ODMRP with link failure detection and local re-
covery mechanism, in ICIS 09, 2009, pp. 818823.
R. S. Gray, D. Kotz, C. Newport, N. Dubrovsky, A. Fiske, J. Liu,
C. Masone, S. McGrath, and Y. Yuan, Outdoor experimental
comparison of four ad hoc routing algorithms, in ACM MSWiM
04, 2004, pp. 220229.
Network simulator. [Online]. Available:
http://www.isi.edu/nsnam/ns/

197