Gateway-based multicast protocol – a novel multicast

protocol for mobile ad hoc networks

J. Xie, S. Nandi, A.K. Gupta and A. Das

Abstract: Multicasting in mobile ad hoc networks (MANETs) poses several challenging problems.
Though a number of multicast protocols for MANETs exist in the literature, there are many areas
where improvements are desirable and possible. A new multicast protocol is proposed for
MANET, called the gateway-based multicast protocol (GBMP) that seeks to improve upon the
existing protocols in terms of the speed and the cost of the multicast tree repair mechanism, the
transmission efficiency and the amount of control overhead. GBMP achieves these improvements
by using a number of novel features, such as both global and local maintenance of group-shared
trees, a bidirectional multicast tree repair mechanism and the suppression of unnecessary
acknowledgments. In addition, we have introduced a new metric called weighted occurrence
of consecutive packet loss to measure the discontinuity in data packet delivery. Extensive
simulation study shows that GBMP outperforms the more established ODMRP and ADMR
protocols in a number of important performance metrics under different traffic patterns and source
node counts.

1 Introduction In this paper, we present a new multicast protocol, the

gateway-based multicast protocol (GBMP) [3] for the
A mobile ad hoc network (MANET) [1] comprises mobile MANETs and study its performance through extensive
wireless nodes. All the nodes may move arbitrarily and simulations. GBMP has the following features:
therefore the network topology changes dynamically. In the
MANET, communications between two nodes that are not
in each other’s transmission range must be via other (1) it constructs a group-shared loosely structured multicast
intermediate nodes to form a multihop transfer. tree for data forwarding;
Unicast, multicast and broadcast are three major (2) it applies the passive receive mode (PRM) to improve
communication models for the MANETs. Among the transmission efficiency
three, multicast is the most efficient one to support the (3) it employs bidirectional local repair to cope with broken
transmission of packets to a subset of the hosts in links.
the network [2]. However, multicasting in MANETs is
challenging for several reasons. First, the limited and In order to measure the discontinuity in data packet
possibly asymmetrical radio bandwidth limits the amount delivery, we propose a new metric called weighted
of the control and data packets to travel through mobile occurrence of consecutive packet loss (WOCPL).
nodes, which may cause inaccurate operations if they are
not delivered timely. Secondly, the nodes’ mobility leads to 2 Related work
an ever-changing topology, making the construction and
maintenance of the multicast architecture more difficult. Many protocols have been proposed in the literature for
Thirdly, the unreliable radio links and arbitrarily changing multicasting in MANETs. MAODV [4], AMRoute [5],
topology also affects group membership management. AMRIS [6], PLBM [7] and ADMR [8, 9] create bidirec-
Nodes may fail to send or receive membership management tional shared multicast trees connecting multicast sources
control packets. This may result in wrong understanding of and receivers. In addition to the tree-based protocols, there
a member’s status of entering or leaving the group at other are some mesh-based multicast protocols, which include
nodes. Consequently, multicast architecture may evolve ODMRP [10], CAMP [11] and FGMP [12]. Both ODMRP
incorrectly and may further prevent the multicast opera- and FGMP use the forwarding group (FG) concept, and
tions from being executed appropriately and efficiently. the FG nodes make up the mesh for packet delivery.
CAMP uses ‘core nodes’ to limit the control traffic when
the receivers join the multicast groups. The mesh-based
r IEE, 2005
protocols outperform the tree-based protocols [13, 14] in
IEE Proceedings online no. 20045207
mobile scenarios due to the moderate topology redundancy
doi:10.1049/ip-com:20045207
in providing alternate routes. However, they suffer from
Paper first received 14th September 2004 and in final revised form 3rd June 2005
high control overheads whenever the number of senders
J. Xie, A.K. Gupta and A. Das are with School of Computer Engineering,
increases (e.g. in the ODMRP) or the nodes’ mobility is
Nanyang Technological University, Singapore 639798, Singapore high (e.g. in the CAMP).
S. Nandi is with Department of Computer Science & Engineering, Indian In order to achieve the mesh’s robustness against mobility
Institute of Technology, Guwahati 781039, India while preserving the merits of the tree-based topology,
E-mail: [email protected] protocols with hierarchical topology, such as ADB [15],
IEE Proc.-Commun., Vol. 152, No. 6, December 2005 811
MHMR [16] and MCEDAR [17], and protocols enhancing own ID into the ‘gateway node ID’ field, thereby claiming
the mesh-based protocols, such as DCMP [18] and that it has become a GN. It then forwards the GJQ. After
PatchODMRP [19], have been proposed. ADB extracts a that, the GN sends a global join reply (GJR) back to the
subset of nodes (core nodes) to form a virtual backbone source. (A local group with too many hops is hard to
infrastructure. Cores are connected using mesh topology, maintain; while with too few hops, there will be too many
and inside each local area, a tree is built to achieve the local groups in the network, which defeats the purpose of
efficiency. With the help of GPS, MHMR builds a similar the hierarchical architecture.) Every intermediate node
hierarchical structure. MCEDAR is the multicast extension receiving the GJR checks whether or not its own ID is
of CEDAR [20]. A set of nodes is elected in a distributed equal to the ‘next hop ID’ field in the GJR message. If this
and dynamic manner to become the cores using only local is the case, the node becomes an FG node, and chooses its
information. These core nodes construct a multicast mesh own next hop address to forward the message until it
for delivering data packets from one core to the multicast reaches the multicast source.
receivers in the other cores. DCMP tries to reduce the If in the GJQ initiated by the group leader, a receiver
control overheads that rise with the increase in the number finds that the ‘local TTL’ is less than or equal to
of sources. By making a source (core active source) to act MAX_LOCAL_GROUP_RANGE, it knows that it is
as an agency for some of other sources (passive sources) within the range of a local group. Then, the receiver stores
in creating the mesh among the sources and receivers, the ID of the GN and the path towards it in the route table
DCMP’s control overheads are proportional only to the decreases the ‘local TTL’ by one and broadcasts it. If the
number of core active sources. PatchODMRP improves value of the ‘local TTL’ is equal to zero, which means this
ODMRP by introducing a patching procedure, with which GJQ has reached the border of a local group, then before
the sources do not have to refresh the mesh frequently, and broadcasting the GJQ, it is reset to INVALID_TTL.
consequently, control overheads are reduced. Receivers in a local group should send a local join reply
(LJR) to its GN in order to set up the local group-shared
tree. Nodes along the path, which is travelled by the LJR
3 Gateway-based multicast protocol back to the GN, become FG nodes of the group. The
process of constructing a local group is illustrated in Fig. 1.
The following data structures are used to describe the In between two successive GJQs from the group leader,
protocol: the GNs should maintain their local groups by sending a

Route table: stores the destination node’s ID and the ID of local join query (LJQ). The nodes, which belong to a local
group, should respond by sending a local join reply (LJR)
the next hop node towards the destination node.
to their GN.

FG node status table: stores the status of whether a node is
an FG node or not for a certain multicast group.

Responsibility table (RSP table): stores the IDs of all the
F
downstream nodes for whose data packet receipt a node C
is responsible.

Monitor table (MNT table): stores IDs of all the down-
stream nodes whose data packet receipt status a node is A
monitoring.
B
GJQ
3.1 Multicast architecture GJR D
GBMP builds a group-shared multicast tree rooted at the LJR
E
group leader, which is the source that has the lowest ID
among all the sources in a multicast group. The inter-
mediate nodes on the tree forward only those data packets gateway node FG node multicast receiver
of the multicast groups in which they are involved. In the
following text, we name these nodes also as the forwarding Fig. 1 Local group construction
group (FG) [12] nodes.
Each multicast source must broadcast a global join query
(GJQ) when it wants to start sending data. If this multicast Hence, the global group-shared tree is further divided
source is the group leader, the GJQ triggers the construction into local trees (local groups), which are the subtrees rooted
or refreshing of the multicast architecture. The format of at the GNs. The introduction of the local tree concept has
GJQ is: the following advantages:
global join query ðmessage type; multicast group ID; global
TTL; global hop count; local TTL; sequence number; (i) The GNs maintain the local trees, making the interval of
maintaining the global topology longer, and therefore
gateway node IDÞ: save control overheads;
In the GJQ, the ‘local TTL’ field is initialised with a (ii) When a receiver is eligible to become a GN, it sends
predefined value INVALID_TTL, and is used to limit the back the GJR to the source at once (rather than waiting
range of a local group being set up. When a receiver receives for its downstream nodes’ GJRs or LJRs and then
a GJQ from the group leader, and if the value of this field is sending its own GJR).
equal to INVALID_TTL, the receiver is eligible to become
a gateway node (GN) for a local group. It starts This accelerates the construction of the multicast tree and
constructing a local group by setting the ‘local TTL’ to shortens the delay between the multicast architecture
MAX_LOCAL_GROUP_RANGE, which is the range of construction and the sending of the succeeding data packets
the local group (the default value is 3); and by putting its from a source.
812 IEE Proc.-Commun., Vol. 152, No. 6, December 2005
3.2 Selection of the group leader variable InPRM. The ‘last node ID’ contains the ID of the
All the sources should compete to become the group leader. node that sends the current data packet. The ‘previous node
When a source wants to send data packets to the network, it ID’ contains the ID of the node from which the last node
must first try to broadcast a GJQ. If it receives a GJQ from (specified by the ‘last node ID’ field) receives this data
another multicast source that has a lower ID, it cancels packet. If ‘InPRM’ is set to FALSE, it means that the node
broadcasting its own GJQ and forwards the other’s. Like which sends this packet is not in PRM; otherwise, it is in
the receivers, the sources (other than the group leader) must PRM and the current packet is used as a heartbeat (which is
send either a global join reply (GJR) or a local join reply explained later).
(LJR) to take part in constructing the tree. The PRM utilises the passive acknowledgment (PsvAck)
If a source successfully receives GJRs in response to its technique. As shown in Fig. 3, when an FG node, say B,
GJQ, it becomes the group leader. It will then broadcast the receives a nonduplicate data packet, it moves the content of
GJQ regularly to refresh the group-shared tree. the data header field ‘last node ID’ to the field ‘previous
As the other sources also take part in the multicast node ID’, puts its own ID into the ‘last node ID’ and then
architecture construction, they do not have to send their forwards this data packet. When its upstream node, A,
own GJQs periodically. However, if the next GJQ is missing receives the PsvAck (a duplicate data packet) from B and if
or a ‘source leave’ message from the group leader (which in the ‘previous node ID’ it finds its own ID, this implies
indicates that the group leader will stop sending data) is that B has just forwarded a packet received from A and
received, the sources will again compete for becoming the node A is responsible for the data receipt at B. Then A
group leader. stores the ‘last node ID’ (which contains B’s ID) in its RSP
If, in-between two GJQs from the group leader, a new table, and discards the packet. Otherwise, it stores the ‘last
source wants to send data packets to the group, it node ID’ in its MNT table (the use of MNT table will be
broadcasts a GJQ. If its ID is smaller than the existing illustrated in Section 3.5).
group leader, this source becomes the group leader and the
multicast architecture is rebuilt. Otherwise, when this GJQ
reaches either a group member or an FG node, say node A,
last node = B
then node A unicasts a join acknoledgment message to D
previous node = A
the new source. When the new source receives the join
acknoledgment message, it unicasts back a join notification
message to set up the FG nodes along the path.
A B C

3.3 Data delivery data packets

We choose the same strategy as described in the ADMR for
data delivery within the multicast tree, i.e. we do not restrict
the packet delivery to specific branches. A node may receive When node B forwards a data packet received
from node A, it sets the field last node to its node
data packets from any branch (Fig. 2). When a node ID, and sets the field previous node to A’s ID.
receives a data packet, if it is an FG node of the group, it
forwards the received packet. Hence, the packet flows along Fig. 3 Passive acknowledgment
the tree branches from the sources to all the receivers.

A receiver, which does not have any downstream node,

broadcasts a data receive acknowledgment (DRA) message
A containing its upstream node’s ID within one hop to
provide an explicit acknowledgment for the data packets
received. Receiving the DRA, the upstream node would be
S
responsible for the data packet delivery at the receiver.
C Whenever node A has forwarded a data packet, it waits
for the PsvAck from B. If node A finds that B is no longer
receiving data packets from it but receiving from another
B node, say D, it moves the entry for B from its RSP table to
its MNT table. After every movement of the entry, A
D checks if its RSP table is empty. If this is the case, A enters
passive receive mode, and broadcasts an ‘enter PRM’
message within one hop to inform its upstream nodes.
tree links data paths When A’s upstream node, which is responsible for A,
receives the ‘enter PRM’, it lengthens the time out duration
Fig. 2 Multicast data delivery for receiving PsvAcks from node A for subsequent data
packets. The node A, which is in the PRM, will forward
data packets from its upstream node with longer interval,
3.4 Passive receive mode (PRM) say, one data packet every two seconds, which is commonly
In order to improve the transmission efficiency, we propose known as heartbeat. (The average distance between two
the passive receive mode (PRM). Rather than applying a communicating neighbouring nodes is half the transmission
prune mechanism, in the PRM, an FG node forwards one range, i.e. 250/2 ¼ 125 m. When nodes move at medium
data packet every few seconds while remaining on the speed, i.e. less than 20 m/s, the relative speed between them
multicast tree. Whenever required, the FG node can resume is less than 40 m/s. Then, the average duration for the link
forwarding every data packet. between them to break is about three seconds. Thus, the
To implement this, in each data packet header, we add heartbeat interval of two seconds is reasonable.) In the
three fields; last node ID, previous node ID and a Boolean header of each heartbeat (data packet), the InPRM is set to
IEE Proc.-Commun., Vol. 152, No. 6, December 2005 813
TRUE. An FG node in PRM sends heartbeats to inform its receipt at node B. Through previous PsvAcks, both nodes A
upstream nodes of its existence. It also looks for PsvAcks or and D know that B is ‘FG node as well as receiver’ and is
DRAs in response to its heartbeats, which indicate that not in PRM. Assume that B moves in the direction shown
there are some nodes in the neighbourhood that need to by the dashed arrow and thus it cannot receive data packets
receive data packets from it. If a PsvAck or DRA is from A any more. Having not received MAX_TIMES_
received, the FG node leaves the PRM, and then forwards NO_PSV_ACK PsvAcks from B, node A initiates the
every subsequent data packet, setting the InPRM field in UNILR procedure. Node A first disables (not deletes) the
the data header to FALSE. When its upstream node RSP table entry for B. Secondly, it broadcasts within one
receives the PsvAck with InPRM set to FALSE, the hop a repair query (RQ), asking for help from other FG
upstream node automatically resets the timeout value for nodes.
receiving a PsvAck. From that point onwards, it waits Upon receiving the RQ, the FG nodes of the same
for the PsvAck for every subsequent data packet. multicast group are eligible to respond by sending a repair
acknowledgment (RA) if they know that B is in their
3.5 Bi-directional link repair neighbourhood. However, in order to suppress excessive
To tackle link breakages, repair mechanisms are necessary. control packets, different priorities are assigned to these
In GBMP, we use a bidirectional local link repair nodes to respond, according to their knowledge of the
mechanism to handle this issue. The bidirectional repair is queried node (node B, in our example). A higher priority
achieved by first triggering the upstream-node-initiated local means smaller back-off time before sending an RA. The
repair (UNILR) at the broken link’s upstream node. If priorities are assigned as follows from the highest to the
UNILR succeeds, no repair from the downstream direction lowest:
is needed. Otherwise, downstream nodes may initiate the
(1) The queried node has the highest priority and does not
receiver-initiated attach procedure (RIAP).
wait before sending an RA.
In the rest of this Section, we first describe the UNILR
and RIAP mechanisms. Then, we discuss the details of how (2) A node that is responsible for the data receipt at the
these two mechanisms co-operate to achieve bidirectional queried node has the next lower priority, and is
link repair. allocated the back-off window of [1, 31].
(3) The next lower priority is assigned to a node that is
3.5.1 Upstream-node-initiated local repair monitoring the data receipt at the queried node and
(UNILR): MNT table: Let us illustrate the use of the is not in PRM. The back-off window for this priority
table through an example. In Fig. 3, node D receives a is [32, 63].
PsvAck from node B and finds node A’s ID in the ‘previous (4) A node that is monitoring the data receipt at the queried
node ID’ field, then it stores B’s ID into its MNT table. This node and is in PRM has the lowest priority. The
means that D is monitoring the data receipt at B. allocated back-off window is [64, 127].
Node status: In order to facilitate the co-operation between
the UNILR and RIAP, four status of nodes (including the
sources which can be receivers or FG nodes for other If node A receives the RA sent by B, it realises that B is still
sources) are defined: in its neighbourhood. It enables the entry for B in its RSP
table, and will not act upon other RAs that arrive later. Any

FG node only: a node that only acts as an FG node, and is node that knows B randomly selects a back-off value from
not a receiver. the back-off window (of its current priority), and then waits

Receiver only: a node that only acts as a receiver, and is accordingly (e.g. if the value selected is 31, then the node
not an FG node. waits for 31 ms). During this delay, if it overhears an RA
towards A, the node cancels the operation; otherwise, it

FG node as well as receiver: a node that acts as both an sends out an RA. Let us suppose that node D successfully
FG node and a receiver. sends out an RA towards A because it is now monitoring

Normal node: a node that is neither an FG node, nor a the data receipt at B. Node A receives the RA from D first,
receiver, nor a source. and responds to it by sending a repair notification (RN).
Then, A deletes the entry for B in its RSP table. When node
A field enNodeStatus specifying the ‘node status’ is added D receives the RN, it leaves PRM and from then on
in each of the following messages: the data header, the forwards every data packet for B.
control message ‘enter PRM’ and ‘data receive acknoledg- It is possible that node A does not receive any RA in
ment’. response to its RQ. In this case, it will perform UNILR
Figure 4 demonstrates how UNILR works. Suppose, at multiple times (a typical value is three). After that, if still no
first, node A is responsible for the data receipt at node B, RA is received, node A gives up hope of repairing using
and the node D, being in PRM, is monitoring the data UNILR. In this scenario, the RIAP may be triggered by a
node downstream of the broken link as described in the
next two Sections.
We note that whenever the downstream node is in the
B PRM, a single loss of PsvAck at the upstream node is
considered to be quite severe, and thus the UNILR is
node B is
D moving immediately triggered.
UNILR attempts to make good use of the limited
redundancy provided by the loosely structured tree. If
another FG node is responsible for the data receipt at the
A B C queried node, UNILR does not need to do anything.
However, if the queried node is monitored by another FG
node, which is in PRM, UNILR requires the monitoring
Fig. 4 Upstream-node-initiated local repair node to leave the PRM.
814 IEE Proc.-Commun., Vol. 152, No. 6, December 2005
3.5.2 Receiver-initiated attach procedure (c) When an upstream FG node fails to receive one PsvAck
(RIAP): RIAP is triggered by a receiver when it detects from one of its downstream nodes (the downstream
the loss of several consecutive data packets. RIAP requires node is in PRM) that it is responsible for, the upstream
that, while receiving data packets, every receiver stores the node initiates the UNILR for this downstream node.
data packets’ arrival time and their sequence numbers. (d) When a ‘receiver only’ node fails to receive three
Using the information, a receiver is able to calculate the consecutive data packets, it initiates the RIAP proce-
packets’ average interarrival time, and estimate the arrival dure. As the receiver’s upstream node should be able to
time of the next data packet. When PKT_LOSS_THRES- know the receiver’s status through DRAs, its upstream
HOLD estimated data packets are lost, the receiver initiates node will not start the UNILR procedure.
the RIAP by broadcasting an attach request (AReq) with
TTL set to two hops. (The loss of PKT_LOSS_THRES- Therefore, GBMP first initiates the UNILR if the down-
HOLD consecutive packets indicates that the link is stream node is not a ‘receiver only’ one. If the UNILR fails,
probably broken, and thus the repair is initiated. Receivers it is up to the downstream node to decide whether or not to
with different node status have different values for this execute RIAP according to its status. If the downstream
threshold, which will be discussed in the following Section. node is ‘receiver only’, it initiates the RIAP without waiting
In order to reduce the control overhead, the TTL is set to for the upstream node to execute UNILR.
two, and the repair is performed in the local area only.)
All the nodes on the tree are allowed to respond to the 3.6 Membership management
AReq provided that they have received data packets Nodes are free to enter or leave the multicast group at any
recently. (Otherwise, a node just decrements the value of time. A node may enter the multicast group by broadcasting
TTL by one and broadcasts it until TTL is equal to zero, at an attach request message or by responding to a GJQ by
which the packet is discarded.) However, these nodes have sending a GJR or LJR. A multicast receiver node may leave
different priorities (higher priority means smaller back-off the multicast group silently. A multicast source node is also
time before sending an Attach acknowledgment in response allowed to leave the multicast group at any time. If it wants
to the AReq). The priorities are as follows: to do so, it must flood a message ‘source leave’ to the whole
network. Every node should have source table storing IDs
(i) the FG nodes have a higher priority than the non-FG
of all the multicast source nodes in a multicast group. When
nodes. the group leader leaves, the multicast source, whose ID is
(ii) an FG node that is not in PRM has a higher priority the least large as the former leader, becomes the group
than the ones in PRM. leader (see Section 3.2).

4 Performance evaluation
Before sending the attach acknowledgment (AAck), a node
waits for a random delay according to its priority. During In this Section, we compare the performances of ODMRP,
the wait, if it does not receive any AAck meant for the ADMR and GBMP through extensive simulations.
initiator of the AReq, the node sends out the AAck;
otherwise, it does not send any. The node sending the AAck 4.1 Simulation environment
is called the attach point node (APN). The receiver that We evaluate the performance of our proposed protocol
initiated the AReq responds to the first AAck it receives by GBMP, and compare it with ODMRP and ADMR using
sending an attach notification (ANtf) towards the APN. GloMoSim [21]. Both ODMRP and ADMR are mature
The intermediate node on the path towards the APN, if it is protocols and have their respective IETF drafts. The
not already an FG node, becomes one for this multicast ODMRP has to flood the join query frequently so as to
group; otherwise, it leaves PRM if it is in this mode. Then refresh the multicast architecture timely to cope with node’s
the intermediate node forwards the ANtf to the APN. mobility. Also, the lifetime for an FG node should not be
When the APN receives the ANtf, if it is in PRM, it leaves too long, otherwise, the bandwidth efficiency decreases.
this mode. Thus, the receiver resumes receiving data packets Thus, we choose 3 s for the join query interval and 4 s for
from a new path. the lifetime of an FG node. For ADMR, a source sends a
data packet every 30 s using network flooding. For GBMP,
3.5.3 Co-operation between UNILR and GJQ is sent every 60 s, and LJQ is sent every 9 s. The large
RIAP: The bidirectional link repair is achieved by the durations for multicast architecture refreshing are chosen
co-operation between UNILR and RIAP. The following for ADMR and GBMP since these two protocols employ
rules are applied for this purpose: link repair mechanisms.
The radio transmission range is 250 m. The propagation
(a) When an upstream FG node fails to receive MAX_ path-loss model is free space. IEEE 802.11 is used as the
TIMES_NO_PSV_ACK (set to three) consecutive MAC layer protocol. Channel capacity is assumed to be
PsvAcks (the loss of three consecutive packets is 2 Mbit/s. Each simulation runs for 1000 s. In all the
considered to be the result of a link breakage. So the simulation runs, there is one multicast group. All multicast
UNILR is initiated after three consecutive passive members retain their membership throughout the simula-
acknowledgments are lost) from one of its downstream tion. The sources start transmitting CBR traffic at the fifth
nodes (which is not in PRM) that it is responsible for, second of the simulation time and stops transmitting at
and the downstream node’s status is ‘FG node as well as 1000th second. There are 50 mobile nodes in an area of
receiver’ or ‘FG only’, the upstream node initiates the 1000 m  1000 m. From these nodes, 20 nodes are randomly
UNILR for this downstream node; otherwise, UNILR chosen to be multicast group members. For simplicity,
is not initiated. multicast sources are randomly selected from the 20 group
(b) When an ‘FG node as well as receiver’ fails to receive six members and these sources are also receivers. The mobility
data packets, it initiates the RIAP. (The loss of three model is random-way-point. All the nodes are moving at
more data packets for an ‘FG node as well as receiver’ is the same speed, which varies from one simulation to
used to separate the initiation of UNILR and RIAP.) another. The pause time is assumed to be 5 s.
IEE Proc.-Commun., Vol. 152, No. 6, December 2005 815
 Two different traffic patterns are defined. For the traffic (WOCPL) to be
pattern 1 (represented as TP-1), constant bit rate data N

P 
packets, which are 256 bytes long, are sent at an interval i2  OCPLi
of 250 ms; for traffic pattern 2 (TP-2), each source sends WOCPL ¼ i¼4N
constant bit rate data packets, which are 256 bytes long, P
with an interval of 100 ms. The two traffic patterns do not ði  OCPLi Þ
i¼1
represent any particular application, but are defined to test
the protocols’ capability in delivering data packets under where OCPLi stands for the number of occurrences of
different traffic intensity. consecutive i data packets loss. We let N ¼ 30 in our
simulation; we do not record loss of more than 30
4.2 Metrics consecutive packets as that implies that partitioning has
The following metrics are used to compare the performance occurred, which has nothing to do with the performance
of the three protocols: of the protocols. The denominator represents the total

Packet delivery ratio (PDR): the percentage of data number of data packets lost due to link breakages, while
the numerator is the weighted number of data packets
packets that is delivered to (or received by) all the receivers,
lost (normally, a loss of a small number of data packets is
which is defined as
not a serious problem for real-time traffic; hence this
P
NR
number is calculated from four to N;). WOCPL measures
ðthe number of data packets actually delivered to receiver iÞ
i the discontinuity in the data packet delivery. The smaller
100%
P
NR the value of WOCPL for a protocol is, the less the
ðthe number of data packets should be delivered to receiver iÞ
i protocol is suffering from consecutive packet loss, and
the more suitable it is for real-time traffic.
where NR is the number of receivers. PDR demonstrates a
protocol’s ability to deliver data packets and is directly 4.3 Simulation results
related to the performance of upper layers.

Number of data packets delivered per data packet 4.3.1 Impact of mobility and traffic load
transmitted (transmission efficiency, TE): indicates the
multicast efficiency of the protocol, which is defined as 4.3.1.1 Single source case: Figures 5 and 6 show
the performance of the three protocols under two different
P
NR
traffic patterns when there is one source in the network. In
ðthe number of data packets actually delivered to receiver iÞ
i most of the cases, GBMP has the highest packet delivery
NP
NW ratio with the lowest control overheads and the lowest
ðthe number of data packets transmitted by node jÞ normalised packet overhead among the three while
i
exhibiting slightly lower transmission efficiency than that
where NNW is the number of nodes in the network. of ADMR.

Control overhead (CO): the number of control packets GBMP and ADMR have higher packet delivery ratio
transmitted per data packet delivered to the receivers, which (PDR) than ODMRP in most of the mobility scenarios.
is defined as The reasons are as follows. First, for single source case,
NP
the network topology is actually a source-based tree. For
NW
ðthe number of control packets transmitted by node jÞ GBMP and ADMR, because they employ loosely
j structured multicast forwarding trees, the number of
P
NR sources in the network has very little effect on the
ðthe number of data packets actually delivered to receiver iÞ topology. However, in ODMRP, in the case of a single
i
source, enough redundancy is not there in the topology.

Control byte overhead (CBO): the number of control bytes Secondly, ODMRP requires the source to flood the join
transmitted per data packet delivered to the receivers, which query frequently in order to cope with the link breakages
is defined as and the suboptimal routes, and it has no mechanism to
repair broken links. GBMP and ADMR, nevertheless,
NP
NW
ðthe length in bytes of control packets transmitted by node jÞ have their own mechanisms for link breakage repair, so
j that broken links can be repaired promptly and therefore
P
NR the packet loss decreases. Thirdly, ODMRP’s frequent
ðthe number of data packets actually delivered to receiver iÞ sending of broadcast packets (join query) increases
i
collisions, which decreases the number of data packets

Normalised packet overhead (NPO): the total number of received. However, with the help of the link repair
all the data and control packets transmitted per data packet mechanisms, both GBMP and ADMR need not refresh
delivered to the receivers, which is defined as the multicast architecture so often as ODMRP does,
leading to higher packet delivery ratio.
NP
NW Note that the PDR of ADMR is lower than that of
ðthe number of data packets transmitted by node jÞ
j GBMP. This is due to ADMR’s pruning mechanism, in
! which a node N prunes itself from the multicast tree if it has
NP
NW
þ ðthe number of control packets transmitted by node jÞ no downstream nodes. With the pruning mechanism,
j ADMR is able to achieve high transmission efficiency (see
P
NR Figs. 5b and 6b) as less data packets are forwarded.
ðthe number of data packets actually delivered to receiver iÞ Nevertheless, in a mobile network, it is possible that after
i
some time, node N is required to forward data packets

Consecutive packet loss: the distribution of the number of again for its ‘new’ downstream nodes. In ADMR, the only
data packets lost consecutively at the receivers. We define way for node N to re-embark on the multicast forwarding
the weighted occurrence of consecutive packet loss tree is to rely on its downstream nodes’ local or global
816 IEE Proc.-Commun., Vol. 152, No. 6, December 2005
 ODMRP GBMP ADMR

1.00 1.9 0.60

1.8 0.55
0.95 0.50
1.7
0.90 1.6 0.45
0.40
PDR

1.5

CO
TE
0.85 0.35
1.4 0.30
0.80 1.3 0.25
1.2 0.20
0.75
1.1 0.15
0.70 1.0 0.10
0 5 10 15 20 25 30 35 40 0 5 10 15 20 25 30 35 40 0 5 10 15 20 25 30 35 40
speed, m/s speed, m/s speed, m/s
a b c

15 1.5 9
1.4 8
13
1.3 7
11 6

WOCPL
1.2
CBO

9 NPO 1.1
5
4
1.0
7 3
0.9 2
5
0.8 1
3 0.7 0
0 5 10 15 20 25 30 35 40 0 5 10 15 20 25 30 35 40 0 5 10 15 20 25 30 35 40
speed, m/s speed, m/s speed, m/s
d e f

Fig. 5 Performance of one source under TP-1

a PDR, 1 src, TP-1
b TE, 1 src, TP-1
c CO, 1 src, TP-1
d CBO, 1 src, TP-1
e NPO, 1 src, TP-1
f WOCPL, 1 src, TP-1

ODMRP GBMP ADMR

1.0 1.9 0.26

1.8 0.24
1.7 0.22
0.9 1.6
0.20
1.5
PDR

CO
TE

0.18
1.4
0.8 1.3 0.16
1.2 0.14
1.1 0.12
0.7 1.0 0.10
0 5 10 15 20 25 30 35 40 0 5 10 15 20 25 30 35 40 0 5 10 15 20 25 30 35 40
speed, m/s speed, m/s speed, m/s
a b c

8 1.1 18
16
7 1.0 14
6 12
WOCPL

0.9
CBO

NPO

10
5
8
0.8
4 6
0.7 4
3
2
2 0.6 0
0 5 10 15 20 25 30 35 40 0 5 10 15 20 25 30 35 40 0 5 10 15 20 25 30 35 40
speed, m/s speed, m/s speed, m/s
d e f

Fig. 6 Performance of one source under TP-2

a PDR, 1 src, TP-2
b TE, 1 src, TP-2
c CO, 1 src, TP-2
d CBO, 1 src, TP-2
e NPO, 1 src, TP-2
f WOCPL, 1 src, TP-2

repair mechanism. In contrast, GBMP uses the PRM at so that newly arriving downstream nodes can be quickly
the FG nodes to reduce data packet forwarding while discovered and node N returns to normal forwarding status
remaining on the tree; also, GBMP sends heartbeat packets, earlier. In this manner, although the transmission efficiency
IEE Proc.-Commun., Vol. 152, No. 6, December 2005 817
of GBMP is slightly lower than ADMR, packet delivery N start a timer to monitor the result of the local repair.
ratio is improved and control overhead is reduced. PRM When the timer expires and if there is still no data packet
thus makes a good trade-off between the transmission coming from their upstream nodes, the receivers on this
efficiency and packet delivery ratio. subtree will initiate their own global repair. When the global
In the traffic pattern TP-1, the control overheads and repairs are triggered, the control overheads incurred are
normalised packet overheads of GBMP and ADMR are proportional to the number of receivers on the subtree and
less than those of ODMRP (Figs. 5c and 5e). The reason the number of nodes in the network. In GBMP, however,
is that the flooding intervals of GBMP and ADMR whenever a link breakage that cannot be repaired by
(to optimise the multicast architecture) are longer than that UNILR occurs, the affected receivers initiate the RIAP
of ODMRP. Although the local repairing mechanisms of independently. Both the UNILR and the RIAP are
GBMP and ADMR generate extra overheads, the benefits restricted in local areas. Therefore, the overheads are only
outweigh the overheads. Nevertheless, in the heavier traffic proportional to the number of nodes in the nearby areas
pattern TP-2 (Figs. 6c and 6e), the control overheads of (within two hops) and the number of receivers affected by
ADMR are higher than that of ODMRP, and the the link breakage. Consequently, the control overheads of
normalised packet overheads of ADMR and GBMP GBMP are less than that of ADMR.
approach that of ODMRP as node speed increases. The The control byte overhead (CBO) performance varies in
reasons for the above performance in TP-2 are as follows. different traffic patterns. For TP-1, GBMP has the least
Under the heavier traffic load, all three protocols suffer CBO (Fig. 5d). This is due to its reduced control overheads.
from frequent data packet loss, and therefore the link However, under TP-2, GBMP’s CBO is a bit higher than
repairing procedures are initiated more frequently in GBMP ODMRP’s (Fig. 6d). This is because in heavy traffic, the
and ADMR. GBMP employs only local repair mechanism, possibility of losing data packets increases due to increased
and its control overheads increase moderately, and there- collisions. Hence, GBMP uses more control packets.
fore, the control overheads of GBMP are less than However, considering that, in practice, not all the nodes
ODMRP and ADMR. ADMR, however, utilises a global move with the same high speed (in contrast, the nodes in
repair mechanism once the local repair fails, and as a result our simulations do), therefore normally there will be less
the control overheads increase, especially at high speeds. control packets, and consequently reducing CBO.
However, due to the high transmission efficiency of GBMP
and ADMR, their NPO are still less than that of ODMRP. 4.3.1.2 Multiple source case – three sources:
In TP-2, we note that ADMR has higher control Figures 7 and 8 demonstrate the performance of the three
overheads than GBMP. This is mainly due to ADMR’s protocols under the two traffic patterns when there are three
global repair mechanism. Let us recall that whenever a link sources in the network.
breakage occurs, ADMR lets the node, say node N, which Under TP-1, the packet delivery ratio is the highest in
is immediately downstream of the broken link, initiate a ODMRP, while under TP-2 it is highest in GBMP. In a
local repair. The nodes that are on the subtree ‘below’ node relatively light traffic load (i.e. TP-1), the advantage of the

ODMRP GBMP ADMR

1.00 1.6 0.5

1.5
0.96 1.4
1.3 0.4
0.92 1.2
PDR

CO
TE

1.1 0.3
0.88 1.0
0.9
0.8 0.2
0.84
0.7
0.80 0.6 0.1
0 5 10 15 20 25 30 35 40 0 5 10 15 20 25 30 35 40 0 5 10 15 20 25 30 35 40
speed, m/s speed, m/s speed, m/s
a b c
12 2.0 10
11 9
1.8 8
10
9 1.6 7
WOCPL

6
CBO

NPO

8
1.4 5
7
4
6 1.2 3
5 2
1.0
4 1
3 0.8 0
0 5 10 15 20 25 30 35 40 0 5 10 15 20 25 30 35 40 0 5 10 15 20 25 30 35 40
speed, m/s speed, m/s speed, m/s
d e f

Fig. 7 Performance of three sources under TP-1

a PDR, 3 src, TP-1
b TE, 3 src, TP-1
c CO, 3 src, TP-1
d CBO, 3 src, TP-1
e NPO, 3 src, TP-1
f WOCPL, 3 src, TP-1

818 IEE Proc.-Commun., Vol. 152, No. 6, December 2005

 ODMRP GBMP ADMR

0.96 1.6 0.30

1.5
0.92 1.4
1.3 0.25
0.88 1.2
PDR

CO
TE
1.1 0.20
0.84 1.0
0.9
0.15
0.80 0.8
0.7
0.76 0.6 0.10
0 5 10 15 20 25 30 35 40 0 5 10 15 20 25 30 35 40 0 5 10 15 20 25 30 35 40
speed, m/s speed, m/s speed, m/s
a b c

9 1.8 12
8 1.6 10
7
1.4 8

WOCPL
6
NPO
CBO

5 1.2 6
4 1.0 4
3
0.8 2
2
1 0.6 0
0 5 10 15 20 25 30 35 40 0 5 10 15 20 25 30 35 40 0 5 10 15 20 25 30 35 40
speed, m/s speed, m/s speed, m/s
d e f

Fig. 8 Performance of three sources under TP-2

a PDR, 3 src, TP-2
b TE, 3 src, TP-2
c CO, 3 src, TP-2
d CBO, 3 src, TP-2
e NPO, 3 src, TP-2
f WOCPL, 3 src, TP-2

mesh used in ODMRP is evident. With the provision of source case under traffic patterns TP-1 and TP-2,
moderate redundancy, ODMRP is able to cope with respectively; Figs. 7f and 8f demonstrate the WOCPL for
mobility well. For GBMP and ADMR, the topology the three-source case. In all four scenarios, GBMP delivers
redundancy is less than that of ODMRP, which leads to a the best WOCPL performance at all the speeds. GBMP’s
bit lower packet delivery ratio than ODMRP. However, UNILR and RIAP promptly repair the broken links and
ODMRP’s high PDR is achieved at the cost of lower therefore the consecutive data packet loss instances are
transmission efficiency and more overheads. Moreover, reduced.
under higher traffic load (i.e. TP-2), GBMP gives the best The performance of ADMR is not as good as GBMP.
PDR performance due to its effective local repair mechan- ADMR’s repair mechanism relies on the operation of a
isms. The degradation in PDR for ODMRP under heavy single node (say node N) for the local repair; and after the
traffic load is because of the increased collisions, which local repair fails, affected receivers initiate their own global
occur due to more packets being forwarded in the mesh. repairs. A delay exists between the initiation of local repair
With the increase of node mobility, especially above and global repair, during which receivers may continue to
30 m/s, GBMP’s transmission efficiency is slightly better suffer from packet loss. Furthermore, even though the local
than that of ADMR (Figs. 7b and 8b), which proves that repair succeeds, because of the mobility in the network, the
the PRM performs well under heavy traffic load at high subtree ‘below’ node N may have other link breakages.
speeds. Consequently, the timers, which are used by the receivers on
Under TP-1, both GBMP’s and ADMR’s control this subtree to monitor the result of the local repair, may
overheads and normalised packet overheads are much less expire before all the broken links are repaired. Therefore,
than ODMRP’s. However, under TP-2, the control over- some of the receivers may still initiate the global repairs
head and control byte overhead of GBMP are slightly independently. So, this process delays the resumption of the
higher than those of ODMRP at speeds above 30 m/s, data packet delivery, without reducing control overheads
which should be acceptable, considering that significantly.
ODMRP has the most severe discontinuity in receiving
(1) in our simulation runs, node speeds are much higher data packets because, instead of utilising a repair mechan-
than those likely to be in practical scenarios. ism, all the sources flood the network every three seconds,
(2) GBMP yields higher packet delivery ratio, higher resulting in more collisions, which worsens the continuity
transmission efficiency and lower normalised packet in data packet delivery.
overheads.
5 Conclusions

Performing multicast in MANETs is challenging due to the

4.3.2 Consecutive packet loss wireless networks’ physical constraints as well as node
In order to study the discontinuity in delivering data mobility. In this paper, we have proposed a new multicast
packets, Figs. 5f and 6f demonstrate the weighted occur- protocol for MANETs, called the gateway-based multicast
rence of consecutive packet loss (WOCPL) for the single protocol. By constructing local trees (local groups), the
IEE Proc.-Commun., Vol. 152, No. 6, December 2005 819
delay between the building of the multicast architecture and 6 Wu, C.W., Tay, Y.C., and Toh, C.-K.: ‘Ad hoc multicast routing
the sending of the succeeding data packets is reduced. protocol utilizing increasing id-numberS (AMRIS) functional specifi-
cation’, Internet draft, Nov. 1998
Receivers are grouped into local groups and the links 7 Sisodia, R.S., Kanthigeyan, I., Manoj, B.S., and Siva Ram Murthy, C.:
among them are maintained locally to reduce the control ‘A preferred link based multicast protocol for wireless mobile ad hoc
overheads. The passive receive mode is utilised to suppress networks’. IEEE Int. Conf. on Communications, 2003
8 Jetcheva, J.G., and Johnson, D.B.: ‘Adaptive demand-driven multicast
unnecessary data packet forwarding. Upstream-node- routing in multi-hop wireless ad hoc networks’. In Proc. 2001 ACM
initiated local repair and receiver-initiated attach procedure Int. Symp. on Mobile ad hoc networking & computing, Long Beach,
CA, USA, 2001
are initiated from upstream and downstream directions, 9 Jetcheva, J.G., Johnson, D.B.: ‘The adaptive demand-driven multicast
respectively, to repair the broken links locally. We define routing protocol for mobile ad hoc networks (ADMR)’, Internet-
a new performance metric, called WOCPL, to measure the Draft, ‘draft-jetcheva-manet-admr-00.txt’, July 2001
10 Yi, Y., Lee, S.-J., Su, W., Gerla, M.: ‘On-demand multicast routing
discontinuity in the data packet delivery, which indicates protocol (ODMRP) for ad hoc networks’, Internet-Draft, ‘draft-ietf-
whether or not a protocol is suitable for real-time traffic. manet-odmrp-04.txt’, Nov. 2002
Through extensive simulations using different number of 11 Garcia-Luna-Aceves, J., and Madruga, E.: ‘The core-assisted mesh
protocol’, IEEE J. Sel. Areas Commun., 1999, 17
sources as well as different traffic intensity, the results prove 12 Chiang, C.-C., Gerla, M., and Zhang, L.: ‘Forwarding group
that GBMP is able to achieve high packet delivery ratio multicast protocol (FGMP) for multihop, mobile wireless networks’,
ACM Baltzer J. Cluster Computing: Special Issue on Mobile
with low overheads and high transmission efficiency in high Computing, 1998, 1, (2), pp. 187–196
mobility and high traffic load scenarios. The WOCPL 13 Varshney, U.: ‘Multicast over wireless networks’, Commun. ACM,
performance shows that GBMP is suitable for real-time 2002, 45, (12), pp. 31–37
14 Kunz, T., and Cheng, E.: ‘Multicasting in ad-hoc networks:
traffic. It achieves improvements over the existing protocols comparing MAODV and ODMRP’. 7th European Conf. on
in the transmission efficiency and in the speed and cost of Computer Supported Cooperative Work (ECSCW 2001)
the multicast architecture construction and maintenance. 15 Jaikaeo, C., and Shen, C-C.: ‘Adaptive backbone-based multicast for
ad hoc networks’. IEEE Int. Conf. on Communications, 2002
16 An, B., and Papavassiliou, S.: ‘A mobility-based hybrid multicast
routing in mobile ad-hoc wireless networks’. Proc. IEEE
6 References Military Communications Conf. (MILCOM 2001), Oct. 2001, pp.
316–320
1 IETF, Mobile Ad Hoc Network Working Group, http://www.ietf. 17 Sinha, P., Sivakumar, R., and Bharghavan, V.: ‘MCEDAR: multicast
org/html.charters/manet-charter.html core-extraction distributed ad hoc routing’. Proc. Wireless Commu-
2 Deering, S.E., and Cheriton, D.R.: ‘Multicast routing in datagram nications and Networking Conf., 1999
internetworks and extended LANs’, ACM Trans. Comput. Syst., 1990, 18 Das, S.K., Manoj, B.S., and Siva Ram Murthy, C.: ‘A dynamic core
8, (2), pp. 85–110 based multicast routing protocol for ad hoc wireless networks’.
3 Xie, J., Nandi, S., Gupta, A.K.: ‘Gateway-based multicast protocol MobiHoc, 2002
for mobile ad hoc networks’. The Fifth IEEE Int. Conf. on Mobile 19 Lee, M., and Kim, Y.K.: ‘PatchODMRP: an ad-hoc multicast routing
and wireless communications networks (MWCN 2003) protocol’. Proc. 15th Int. Conf. on Information Networking, 2001,
4 Royer, E.M., and Perkins, C.E.: ‘Multicast ad hoc on-demand pp. 537–543
distance vector (MAODV) routing’, Internet-Draft, ‘draft-ietf-manet- 20 Sivakumar, R., Sinha, P., and Bharghavan, V.: ‘CEDAR: a core-
maodv-00.txt’, July 2000 extraction distriuted ad hoc routing algorithm’, IEEE J. Sel. Areas
5 Liu, M., Talpade, R.R., and McAuley, A.: ‘AMRoute: adhoc Commun., 1999, 17, (8)
multicast routing protocol’. Tech. Rep. 99, The Institute for Systems 21 Global Mobile Information Systems Simulation Library, UCLA,
Research, University of Maryland, USA,1999 http://pcl.cs.ucla.edu/projects/glomosim

820 IEE Proc.-Commun., Vol. 152, No. 6, December 2005