MAODV-Based Multisource Multicast Routing with

Fast Route Recovery Scheme in MANETs

Chia-Hui Huang, Chun-Ting Wu, Kai-Wei Ke, and Ho-Ting Wu
Department of Computer Science and Information Engineering
National Taipei University of Technology
Taipei, Taiwan, R.O.C.
Email: [email protected], [email protected], [email protected], [email protected]

Abstract—MAODV (Multicast Ad-hoc On-demand Distance with tree-based approach, the mesh-based approach maintains
Vector), a well-known multicast routing protocol in MANETs, more than one path between each pair of source and receiver.
has been proposed over ten years. It is originally designed The mesh topology provides a more robust data delivery
for single-source multicast operation and thus inefficient when
applied to multisource scenario. In addition, MAODV requires a path than that of tree topology; however, it brings on more
route rediscovery procedure to recover multicast routing tree control overhead to maintain multiple paths. Thus, the trade-
from partition of the tree and takes a long time to recover off between tree-based and mesh-based approaches is the
the multicast routing whenever the root of the tree is failed. maintenance overhead and robustness of data delivery.
By modifying the MAODV protocol, this research presented a Most of the existing multicast routing protocols in MANET
multisource multicast routing and partition recovery scheme in
MANETs. Simulation results demonstrated that the proposed consider only one source in a multicast group and become
multisource multicast routing method can improve the bottleneck inefficient when the protocol is extended to multi-source
problem of MAODV in data delivery and the proposed partition multicasting. To achieve multisource multicast routing based
recovery scheme can achieve shorter recovery time than that of on a single source one the simplest way is applying the concept
MAODV with the lower control overhead. of PIM-SM (Protocol Independent Multicast - Sparse Mode)
Index Terms—MANET, Multisource Multicast, MAODV, Route
Recovery. [13]. PIM-SM protocol redirects all data flows from different
sources to the core node of the tree and then distributed by
the core node. Obviously, this solution suffers from the single-
I. I NTRODUCTION
point-of-failure and bottleneck problems.
A Mobile Ad-hoc NETwork (MANET) is a self-organizing This research revises the MAODV (Multicast Ad-hoc On-
wireless network, which has no fixed infrastructure or central demand Distance Vector) protocol by adapting the concept
control station. It consists of dynamic collection of nodes and similar to the Multicast Reverse Path Forwarding (RPF)
relatively low-bandwidth wireless links with rapidly chang- [13][14] to perform multisource multicast data delivery. The
ing multi-hop topology [1][2]. A communication session in proposed multisource routing scheme not only provides multi-
MANET is achieved either through single-hop transmission source routing but also avoids bottleneck problem. In addition,
if a destination node is within the transmission range of the the proposed recovery scheme utilizes a candidate leader to
source node, or by relaying through intermediate nodes to a reduce the average recovery time and total control overhead.
distant destination. The remainder of this paper is organized as follows: Section
Multicasting is the transmission of data flows to a group II introduces related works. Section III and IV present detailed
of nodes that identified by a single destination address. It discussion on the proposed schemes for multisource multicast
can efficiently support a variety of application, such as video routing and partition recovery, respectively. Simulation results
conference, distance learning, and video streaming. The main are shown in Section V. Finally, conclusion is drawn in
benefit of multicasting is the significant reduction of network SectionVI.
load when packets need to be transmitted to a group of nodes.
However, in MANET environment, multicast routing protocols II. R ELATED W ORKS
are faced with the challenge of producing multi-hop routing ODMRP (On-Demand Multicast Routing Protocol) [7] is
under dynamic topology and bandwidth constraints. a mesh-based multicast routing protocol. It uses the concept
Several multicast routing protocols have been proposed of forwarding group to construct a mesh between source and
for MANETs [3][4][5][6][7][8][9][10]. Based on the structure all of its receivers. By adopting mesh structure, ODMRP can
used for data delivery, most of the existing multicast routing achieve more reliable data delivery in case of node move-
protocols can be classified into two categories [11][12]: tree- ments. However, it is not designed to support the multisource
based [3][4][5][6] and mesh-based [7][8] approaches. In tree- multicast efficiently [6].
based approach, all the routes form a tree infrastructure with The AMRIS (Ad-hoc Multicast Routing Protocol utilizing
the source node as the root, thus there is only one single Increasing id-numberS) [4] establishes a shared-tree for mul-
path between every pair of source and receiver. In contrast ticast data forwarding. Each node in the AMRIS is assigned

978-1-4244-7640-4/10/$26.00 ©2010 IEEE рт

 œŰŶŵŦġŕŢţŭŦ ŎŶŭŵŪŤŢŴŵġœŰŶŵŦġŕŢţŭŦ ŎŶŭŵŪŤŢŴŵġœŰŶŵŦġŕŢţŭŦ
ŅŦŴŵįġŊőġłťťųŦŴŴ ŎŶŭŵŪŤŢŴŵġňųŰŶűġŊőġłťťųŦŴŴ ŎŶŭŵŪŤŢŴŵġňųŰŶűġŊőġłťťųŦŴŴ
ŅŦŴŵįġŔŦŲįġŏŶŮį ŎŶŭŵŪŤŢŴŵġňųŰŶűġōŦŢťŦųġŊőġłťťųŦŴŴ ŎŶŭŵŪŤŢŴŵġňųŰŶűġōŦŢťŦųġŊőġłťťųŦŴŴ
ʼnŰűġńŰŶůŵġŵŰġŅŦŴŵ į ŎŶŭŵŪŤŢŴŵġňųŰŶűġŔŦŲ įġŏŶŮį ŎŶŭŵŪŤŢŴŵġňųŰŶűġŔŦŲ įġŏŶŮį
ŏŦŹŵġʼnŰű ŏŦŹŵġʼnŰűŴ őŢųŦůŵ
ōŪŧŦŵŪŮŦ ōŪŧŦŵŪŮŦ ŏŦŹŵġʼnŰűŴ
ĩŢĪ ĩţĪ ōŪŧŦŵŪŮŦ

Fig. 1. Routing tables maintained by MAODV nodes. Fig. 2. Multicast routing table maintained by MMAODV nodes.

a multicast session ID number. The ranking order of ID is B. The Proposed Multisource Multicast Routing Scheme
used to direct the flow of multicast data. In AMRIS, the MAODV is an efficient shared tree multicast routing pro-
Branch Reconstruction (BR) mechanism operates continuously tocol in MANET [3]. However, there is no clear illustration
in the background to ensure a node remains connected to the of how the multisource multicast operates. With the shared
multicast session delivery tree. Therefore, the performance of tree structure, using the concept similar to the PIM-SM would
AMRIS was very sensitive to mobility [15]. be the simplest approach to implement multisource multicast
STMRP (Shared-tree-based Multisource Multicast Routing routing based on the single source approach. The concept of
Protocol) [6] dynamically decides a core node to construct a PIM-SM is that when a source other than the core node of
shared tree to support multicasting in the multisource envi- the shared tree has data to send, it must unicast its data to the
ronment. The core node will be changed by comparing the core node of the tree, the core node then multicasts the data to
average number of hops to all receivers of current core node all receivers of the multicast group. In PIM-SM approach, the
and candidate core node. The STMRP uses multiple shared- multisource multicast routing is operated without any addition
tree to increase the reliability of data delivery. However, there protocol overhead; however, it exhibits the single-point-of-
is no recovery mechanism in case of the shared-tree becomes failure and bottleneck problem at the core node of the shared
several independent partitions. tree.
Each node running MAODV protocol maintains two routing
III. P ROPOSED M ULTISOURCE M ULTICAST ROUTING tables: the first one is the route table, which is used to record
S CHEME the next hop for routes to other nodes in the network; the
second one is the multicast route table, which records the
In this research, we propose a Multisource Multicast Ad- information of all multicast groups. The fields of route table
hoc On-demand Distance Vector (MMAODV) routing scheme. and multicast route table are shown in the Fig. 1 (a) and (b),
The following two subsections describe how to establish respectively. In the route discovery procedure of MAODV, the
the multicast routing tree and deliver multicast data on the route table will be updated by route requests (RREQs) and
established tree, respectively. route replies (RREPs). When a node receives a RREQ/RREP
message and it does not have a route entry for that source,
it places a new entry to route table. Otherwise, it updates the
A. Multicast Tree Establishment
lifetime of this entry. For multicast route table, new entries
In MMAODV, the same RREQ/RREP/MACT messages and are placed in this table after the node becomes a member or
route discovery cycle as in MAODV is used to discover the router for a multicast group. According to the next hops field
routing path and establish the multicast tree. By MAODV of multicast route table, the multicast data can be delivering
protocol, a network node that wants to be a member of a from the root to all receivers.
multicast group will initiate join procedure by broadcasting a In this work, the authors adopt the concept similar to
RREQ message with the IP address of that group as destination the multicast RPF technique to achieve multisource multicast
address. Upon the receipt of a RREQ, only the member of that routing on the tree constructed in the route discovery cycle
group may respond to the RREQ by replying a RREP. After a (RREQ/RREP/MACT). In RPF technique, when a multicast
group member unicasts a RREP back to the requesting group packet enters a router’s interface it will look up the list of
member, the temporary path(s) between requesting group networks that are reachable via that incoming interface. If
member and the multicast routing tree is established. Since a the router finds a matching routing entry for the source IP
requesting group member is broadcasting the RREQ message, of the multicast packet, the RPF check passes and the packet
it may receive more than one RREP reply. Hence, a MACT is forwarded to all interfaces that are participating in multicast
message is used to ensure that the multicast tree does not for this multicast group except the incoming interface.
have multiple paths to any tree node. The MACT is initiated Considering the routing tree of MAODV, the direction of
by the requesting member to the replying members along the the link is relative to the location of the group leader, i.e.
path that has the best performance, and the route between UPSTREAM (parent) is a next hop towards the group leader,
requesting member and the multicast group is enabled. and DOWNSTREAM (children) is a next hop away from the

сй
 őųŰŤŦťŶųŦĻġŇŰųŸŢųťŠŅŢŵŢ ňųŰŶűġōŦŢťŦųġIJ
ŃŦŨŪů
ŊŧĩŪŴŇŪųŴŵŕŪŮŦĩŅŢŵŢĪġłůťġŪŴňųŰŶűŠŎŦŮţŦųĩĪĪ ňųŰŶűġōŦŢťŦųġijġ
ĩŭŰŸŦųġŊőġłťťųŦŴŴ Ī
ŃŦŨŪů

œœ
œœ

ņŒ
őųŰŤŦŴŴŠŅŢŵŢĩŅŢŵŢĪļ

ņő ġ

ġĩĵ
ĩĶ Ī

ijĪ
ŃųŰŢťŤŢŴŵĩŅŢŵŢĭġňųŰŶűŠŊőŠłťťųĪļ

ő ġĩ

IJĪ
ňų Ű

Œġĩ
ņ
ņůť Ŏňōij Ŷű ġ
ʼnŦŭ

œœ

ņ
œœ ŭŰ

œœ
ņŭŴŦ ņ
œœ ŒġĩĴ Ī
ŅŪŴŤŢųťĩŅŢŵŢĪļ ņőġ
ĩķ Ī ŎňōIJ
ņůť

Fig. 3. Actions taken by a group member to forward multicast data. œœņŒİœœņőġŎŦŴŴŢŨŦ ňųŰŶűġōŦŢťŦų
ňųŰŶűġʼnŦŭŭŰġŎŦŴŴŢŨŦ ňųŰŶűġŎŦŮţŦų
ŎŃ

Ŏł Fig. 5. Procedure of MAODV to reconnect partitions.

ňųŰŶűġ
ōŦŢťŦų Group Leader forwards multicast packet to MA and MB .
Ŏń
IV. R ECONNECTING PARTITIONED T REES
ŎŅ ŔŰŶųŤŦġŎŦŮţŦų A. Leader’s 1-hop Virtual Mesh
ŎŶŭŵŪŤŢŴŵġňųŰŶűġŎŦŮţŦų In MANET environment, links between nodes may break
due to node mobility or failure. MAODV protocol has a
Ŏņ ŎŇ ŏŦŵŸŰųŬġŏŰťŦ
complete procedure to recover multicast routing tree from the
ŎŶŭŵŪŤŢŴŵġŕųŦŦġōŪůŬ
broken of links, but it is inefficient to recover the multicast
ŎŶŭŵŪŤŢŴŵġŧŭŰŸġŰŧġňųŰŶűġōŦŢťŦų
Ŏň ŎŶŭŵŪŤŢŴŵġŧŭŰŸġŰŧġŎ Ņ
routing tree from the failure of root.
In MAODV protocol, a node failure can be detected by
Fig. 4. Example of MMAODV routing scheme. exchanging Hello message between neighboring nodes. When
a failed node is detected, the downstream node of the failed
node is responsible for repairing the connection. The down-
group leader. As shown in Fig. 1 (a), the DOWNSTREAM stream node repairs the connection by broadcasting a RREQ to
information is maintained in the multicast route table (the rejoin in the multicast routing tree. Then, the new connection
next hops field). However, by the multicast RPF technique, is built by the RREP message. If no RREP is received at the
the UPSTREAM information of a node i is needed to relay downstream node, the multicast routing tree will be split into
multicast packet that from the DOWNSTREAM of i to the two partitions.
UPSTREAM of node i, when the multicast source is located If two partitions reconnect, a node receives a Group Hello
at the DOWNSTREAM of node i. Thus, as shown in Fig. 2, that contains group leader information that differs from the
we modify the multicast route table by adding a parent field. information it already has. A member of the partition whose
Practically, the parent address can be obtained by group hello group leader has lower IP address should initiate the reconnec-
message during the local connectivity management phase [3]. tion of the multicast tree. Fig. 5 illustrates the procedure of
Hence, the multisource multicast routing approach is, upon MAODV to reconnect two partitions. When MGL2 receives
the receipt of a multicast packet from any source, the node a Group Hello from MGL1 , it initiates the reconnection of
will relay this multicast packet to all the next hops and parent partitions by unicasting a RREQ to its group leader (Group
node of this multicast group except the incoming node. Fig. 3 Leader 2) to ask the permission to repair the partitions. The
illustrated the procedure of forwarding multicast data. Group Leader 2, after receiving such a RREQ, grants the node
Fig. 4 illustrates an example of this multisource multicast permission to rebuild the tree by unicasting a RREP to MGL2 .
routing approach, where Group Leader and MD are the multi- Then, MGL2 unicasts a RREQ to Group Leader 1 by using
cast source member. As shown in the Fig. 4, when the Group the node which it received the Group Hello as the next hop.
Leader is the source member, since this multicast routing tree Group Leader 1 then unicasts a RREP back to MGL2 via the
is stems from the Group Leader, the multicast data flow of same path of RREQ. Thus, the reconnecting of partitions is
Group Leader will follow the path that formed by the next completed.
hops of multicast route table in each group member. When The procedure of MAODV is effective to reconnect two
MD is the source member, MD initiates the multicast session partitions. However, when the root is failed, the multicast rout-
by transmitting multicast packet to its next hop nodes (ME and ing tree becomes many partitions (depends on the number of
MF ) and parent node (MC ). The multicast packets are relayed children of the root). According to the procedure, reconnecting
to Group Leader and MF by MC and MF respectively, then, of two partitions needs many steps to grant the permission.

ск
 ńŶųųŦůŵġōŦŢťŦųġġ őųŰŤŦťŶųŦĻġœŰŶŵŦŠœŦŤŰŷŦųź
ňųŰŶűġʼnŦŭŭŰ ŃŦŨŪů
ńŢůťŪťŢŵŦġōŦŢťŦųĻġŎń œŦŮŰŷŦŠŎœŕŠņůŵųźĩňųŰŶűŠōŦŢťŦųĪļ
ŊŧĩōŰŤŢŭŠŊőŠłťťųġľľġńŢůťŪťŢŵŦŠŊőŠłťťųĪ
ŃŦŨŪů
Ŏł Ŏń ŎŃ ŴŦŵňųŰŶűŠōŦŢťŦųġľġōŰŤŢŭŠŊőŠłťťųļ
ŃųŰŢťŤŢŴŵĩųŦűŢŪųŠňųŰŶűŠʼnŦŭŭŰĭġňųŰŶűŠŊőŠłťťųĪļ
ŔŶţĮŵųŦŦ ŔŶţĮŵųŦŦ ŔŶţĮŵųŦŦ ņůť
ņŭŴŦ
ŃųŰŢťŤŢŴŵĩŋŰŪůŠœœņŒĭġńŢůťŪťŢŵŦŠŊőŠłťťųĪļ
ŎŶŭŵŪŤŢŴŵġŕųŦŦġōŪůŬ ňųŰŶűġōŦŢťŦų ņůť

ŎŦŴũġōŪůŬ ňųŰŶűġŎŦŮţŦų
Fig. 8. Actions taken by candidate group leader to recover multicast tree.
Fig. 6. Virtual mesh maintained by 1-hop nodes of current leader.
ŎŃ
ńŢůťŪťŢŵŦġōŦŢťŦų ńŢůťŪťŢŵŦġŭŦŢťŦų ĻġŎń

Œ
Ŏń ġĩIJĪ Ŏł

œ œņ
œœņ Œ
Ŏł

œœ ņő
ġĩIJĪ ĩijĪ
œ œņŒ œ œņőġ ġĩ ĵ
Ī
Ŏŏ œœ ņ Œ ńŢůťŪťŢŵŦġŭŦŢťŦų ĻġŎń
ő ġĩijĪ ņő ĩIJ Ī ő
œœņ œœ ņ Œ ġ œœņ
ŎŃ œœņőġĩijĪ œœ

ő
œ œņ

œœ ņ
œœņŒġĩIJ ġĩĴ Ī GroupLeader
Ī ņő
œœ Ī
ġĩ ij
ņŒ
œœ
Ŏń

ŎŅ
ńŶųųŦůŵġňųŰŶűġōŦŢťŦų
œœņŒİœœņőġŎŦŴŴŢŨŦ ňųŰŶűġōŦŢťŦų ňųŰŶűġŎŦŮţŦų ŏŦŵŸŰųŬġŏŰťŦ ŎŶŭŵŪŤŢŴŵġňųŰŶűġŎŦŮţŦų
Ŏņ ŎŇ ŏŦŵŸŰųŬġŏŰťŦ
Fig. 7. Procedure of MMAODV to reconnect partitions.
ŎŶŭŵŪŤŢŴŵġŕųŦŦġōŪůŬ
Ŏň œœņŒİœœņő
Hence, when the number of partitions becomes large, it may ŃųŰŬŦůġŕųŦŦġōŪůŬ
take a very long time to recover the whole multicast routing
Fig. 9. Example of MMAODV to reconnect partitions.
tree.
The idea we proposed to address the problem of long
recovery time is to maintain a virtual mesh topology between
the 1-hop neighbors of the leader. By maintaining a virtual RREQ to the candidate leader. Nodes with current route to the
mesh topology, a candidate leader can be predetermined. The candidate leader can unicast a RREP back to the source of the
reconnecting of partitions can be accomplished by the group RREQ.
leader of each partition immediately after the current leader The partitions can be reconnected via three different paths.
fail and thus the time to recover the multicast routing tree from As shown in Fig. 7, the nodes that rooted at the partitioned
multiple partitions can be reduced. sub-trees are responsible for repairing the partitions (except
Fig. 6 depicts the concept of the virtual mesh topology the candidate leader). These nodes reconnect the partitions
where current leader is the leader that is currently active; by initiating a RREQ message to the candidate leader. If the
MA , MB , and MC are the group members that selected as candidate leader (MC ) is in the 1-hop away of these root
the children of current leader. Each child of current leader nodes (MA and MB ), a RREP is replied by the candidate
maintains a candidate leader that piggybacked in the Group leader directly. Otherwise, the RREQ message may reach the
Hello message. The candidate leader is selected by the current candidate group leader or it’s sub-tree through either a node
leader according to the rule of lowest IP address. As shown in in the candidate leader’s sub-tree or any other node in the
Fig. 6, by maintaining the candidate leader, a mesh structure is network. In either way, a RREP message can be replied by
formed between the current leader and all its 1-hop neighbors. candidate leader itself or any node that in the candidate’s sub-
tree and the sub-trees are reconnected. Fig. 8 illustrated the
B. Partition Recovery Scheme procedure of MMAODV to recover multicast tree.
Based on the virtual mesh, Fig. 7 illustrates the procedure Fig. 9 illustrates an example of partition recovery where
of MMAODV to reconnect partitions. Stemming from Fig. GroupLeader is the current group leader, MC is the candidate
6, once the current leader is unreachable, the sub-trees that leader. Once the current group leader becomes unavailable,
rooted at the MA , MB , and MC become three partitioned MA and MB recover the partition by initiating a RREQ
trees. According to the information of candidate leader, MA message to candidate leader MC via the network node M N .
and MB can then simultaneously initiate reconnect by sending After that, a RREP message is replied by MC to MA and MB .

сл
 Control Overhead (Total number of packets)
0.055 4500

0.05 "MAODV_DeliveryDelay" "MAODV_ControlOverhead_NumPkts"

"MMAODV_DeliveryDelay" 4000 "MMAODV_ControlOverhead_NumPkts"
0.045
Delivery Delay (sec)

0.04 3500

0.035
3000
0.03
2500
0.025

0.02 2000

0.015
1500
0.01

0.005 1000
5 10 15 20 25 30 5 10 15 20 25 30
Group Size Group Size

Fig. 10. Average data delivery delay of MMAODV with respect to different Fig. 12. Total number of control packets.
group size.
65000

Control Overhead (Total number of bytes)

9
60000 "MAODV_ControlOverhead_NumBytes"
"MMAODV_ControlOverhead_NumBytes"
8 "MAODV_RecoveryTime" 55000
"MMAODV_RecoveryTime"
7 50000
Recovery Time (sec)

6 45000

5 40000

4 35000

30000
3
25000
2
20000
1
15000
0 5 10 15 20 25 30
5 10 15 20 25 30 Group Size
Group Size
Fig. 13. Total number of bytes of contorl information.
Fig. 11. Average recovery time of MMAODV with respect to different group
size.

1) Average Delivery Delay: Fig. 10 depicts the comparison

Finally, MA and MB become child of MC and the partition of average data delivery delay. As shown in the Fig. 10, the
recovery is completed. average delay of MMAODV is always lower than the delay
of MAODV. In addition, the delay of both protocols increases
V. P ERFORMANCE E VALUATION with the group size, however, the delay of MAODV increases
faster than that of MMAODV. This is because the root of
A. Simulation Setup
MAODV routing tree becomes the bottleneck of data delivery,
We evaluate the performance of MMAODV scheme and especially when the number of group member becomes larger.
compare to the performance of MAODV using OMNETpp 2) Average Recovery Time: Fig. 11 illustrates the average
simulator version 4.0 [16]. The simulation scenario consists of recovery time. The average recovery time of MMAODV
25 multicast nodes randomly distributed in a 600m × 400m is smaller than that of MAODV. In MAODV protocol, the
area. The random waypoint model [17] is used to model the recovery procedure takes a long time to grant the permission
mobility of mobile nodes. The moving speed of the mobile to repair the partition. When the number of partition becomes
nodes is uniformly distributed in 1m to 10 m per second. For large, the overhead of granting time will be increased. In
multisource simulation, 35% of group members are selected MMAODV, the recovery procedure is initiated by the group
as the multicast source. leader of partitioned tree without any permission granting is
The following three performance metrics are used: (1) required. Hence, the recovery time can be reduced.
Average delivery delay: the average time taken for data packets 3) Control Overhead: Figure 12 and Fig. 13 demonstrate
to be transmitted across a network from source to destination, the control overhead in terms of control packets and bytes,
(2) Control overhead: total number of control packets and total respectively. The results indicate that the control overhead of
number of bytes of control information, (3) Average recovery MMAODV is lower than that of MAODV since MMAODV
time: the average time taken to recover tree from root failure. saves the RREQ/RREP (for permission granting) overhead by
maintaining a virtual mesh topology at the 1-hop neighbors of
B. Simulation Results root nodes.

см
 VI. C ONCLUSION
This research presents a MAODV-based multisource multi-
cast routing with fast partition recovery scheme. The proposed
multisource routing scheme not only provides multisource
routing but also avoids bottleneck problem. By maintaining
the candidate leader, the partition can be recovered by the
group leader of each partitioned tree without requiring any
permission granting is required. Hence, the recovery time and
control overhead can be reduced.
R EFERENCES
[1] M. Younis, Dr. and S. Z. Ozer, Dr., “Wireless ad hoc networks:
technologies and challenges: Editorials,” Wirel. Commun. Mob. Comput.,
vol. 6, no. 7, pp. 889–892, 2006.
[2] L. Junhai, Y. Danxia, X. Liu, and F. Mingyu, “A survey of multicast
routing protocols for mobile ad-hoc networks,” IEEE Communications
Surveys & Tutorials, vol. 11, no. 1, pp. 78–91, 2009.
[3] E. M. Royer and C. E. Perkins, “Multicast ad hoc on-demand distance
vector (maodv) routing,” draft-ietf-manet-maodv-00.txt, 2000.
[4] C. W. Wu and Y. C. Tay, “Amris: a multicast protocol for ad hoc wireless
networks,” in Proc. IEEE Military Communications MILCOM’99, vol. 1,
pp. 25–29, 1999.
[5] J. Xie, R. R. Talpade, A. Mcauley, and M. Liu, “Amroute: ad hoc
multicast routing protocol,” Mob. Netw. Appl., vol. 7, no. 6, pp. 429–439,
2002.
[6] F. Sato, “An efficient shared-tree-based multi-source multicast routing
protocol in mobile networks,” in International Conference on Advanced
Information Networking and Applications Workshops, WAINA ’09.,
2009, pp. 377 –382, 2009.
[7] W. S. Yunjung Yi Sung-Ju Le and M. Gerla, “On-demand multicast
routing protocol (odmrp) for ad hoc networks,” draft-ietf-manet-odmrp-
04.txt, 2002.
[8] L. K. Law, S. V. Krishnamurthy, and M. Faloutsos, “Understanding
and exploiting the trade-offs between broadcasting and multicasting in
mobile ad hoc networks,” Mobile Computing, IEEE Transactions on,
vol. 6, no. 3, pp. 264 –279, march 2007.
[9] Y.-Y. Su, S.-F. Hwang, and C.-R. Dow, “An efficient multi-source
multicast routing protocol in mobile ad hoc networks,” in Proc. 11th
Int Parallel and Distributed Systems Conf,, vol. 1, pp. 8–14, 2005.
[10] F. E. B. Y. Q. Stefan Birrer, Dong Lu and P. Dind, “Fatnemo: Building
a resilient multi-source multicast fat-tree,” Web Content Caching and
Distribution, Lecture Notes in Computer Science, vol. 3293, pp 182-
196, 2004.
[11] C. de Morais Cordeiro, H. Gossain, and D. P. Agrawal, “Multicast over
wireless mobile ad hoc networks: present and future directions,” vol. 17,
no. 1, pp. 52–59, 2003.
[12] K. Viswanath, K. Obraczka, and G. Tsudik, “Exploring mesh and tree-
based multicast. routing protocols for manets,” vol. 5, no. 1, pp. 28–42,
2006.
[13] D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S. Deering,
M. Handley, V. Jacobson, C. Liu, P. Sharma, and L. Wei,
“Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol
Specification,” RFC 2362 (Experimental), Internet Engineering Task
Force, Jun. 1998, obsoleted by RFCs 4601, 5059. [Online]. Available:
http://www.ietf.org/rfc/rfc2362.txt
[14] B. Fenner and D. Meyer, “Multicast Source Discovery Protocol
(MSDP),” RFC 3618 (Experimental), Internet Engineering Task Force,
Oct. 2003. [Online]. Available: http://www.ietf.org/rfc/rfc3618.txt
[15] S. K. Soni and T. C. Aseri, “A review of current multicast routing
protocol of mobile ad hoc network,” in Proc. Second Int. Conf. Computer
Modeling and Simulation ICCMS ’10, vol. 3, pp. 207–211, 2010.
[16] J. Chen, J. Zhang, W. Xu, L. Shu, and Y. Sun, “The development of
a realistic simulation framework with omnet++,” in Proc. Second Int.
Conf. Future Generation Communication and Networking FGCN ’08,
vol. 1, pp. 497–500, 2008.
[17] T. Camp, J. Boleng, and V. Davies, “A survey of mobility models for ad
hoc network research,” Wireless Communications & Mobile Computing
(WCMC): Special issue on Mobile Ad Hoc Networking: Research,
Trends and Applications, vol. 2, pp. 483–502, 2002.

сн