8

CHAPTER 1
INTRODUCTION TO MOBILE AD HOC NETWORKS
In this chapter we provide a gentle introduction to ad hoc networks, we look at their
applications, the different mechanisms of establishing multicast trees in terms of their
pros and cons. We then show by means of an example why multicast protocols for
wireline networks need to evolve for the new environment.
1.1 Mobile Ad Hoc networks
A mobile Ad hoc Network (MANET) is a collection of autonomous mobile nodes
capable of communicating with each other via wireless links. Nodes in a MANET have
limited transmission range; communication is achieved by making use of nodes to
forward packets to other nodes, which thereby have to operate as routers. Finding a path
between two communication end points in an ad hoc network is non trivial; node mobility
results in highly dynamic network topologies. These networks are rapidly deployable as
they do not require any infrastructure in place. MANETs are highly desirable in a variety
of scenarios: disaster recovery - where the entire communication infrastructure might
have been destroyed, business meetings - where a group of people have to share
resources and communicate with each other, communication over rugged terrain – where
establishing infrastructure is not cost effective. Ad hoc networks can also be used to
deploy multimedia services; however efficient routing protocols have to be developed
before this can be realized.
The high node mobility, low bandwidth wireless interfaces, limited battery power and
contention for the shared wireless medium makes designing routing protocols for ad hoc
networks difficult; any new routing protocol must take note of these factors critically.
Several unicast routing protocols for ad-hoc networks have already been proposed [1].
1.2 The Multicast capability
Multicasting is the ability to send packets to and receive packets directed at a subset of
nodes in the network. Multicast group communication has many applications, including
video and audio conferencing and distributed interactive simulation (DIS). Another
interesting application is video-on-demand, wherein a set of multicast receivers are able
to receive (when required) video data multicast by a single video server. Establishing
multicast trees are definitely more efficient than the brute force approach of Unicasting
multicast packets to all the members of a group. In general, multicast routing is achieved
using either source based or core based trees. In a source based mechanism, each sender
in the multicast group constructs a shortest-path tree spanning all multicast members. The
advantage of a source based mechanism is that multicast packets are delivered with
relatively low latency, because of the use of shortest paths for communication between
the sender and the multicast receivers. The disadvantage, however, is that this scheme
does not scale very well as the number of multicast senders in a group increases, because
of the need to maintain tree information with respect to every sender in the multicast
group. Clearly, such a scheme is well suited to group communication involving few
senders, such as the video-on-demand application mentioned above. However ensuring a
shortest path tree at all times is impossible and if attempted would incur excessive control
overhead. Our proposed multicast protocol for MANETs - LTMP, is a source based
multicast protocol. The core based multicast mechanism [2] uses a multicast tree shared
by all members of the multicast group. The CBT (Core Based Tree) mechanism was
designed primarily to address the topic of scalability; shared tree architecture offers an
improvement in scalability over source tree architectures by a factor of the number of
active multicast sources. The CBT is optimized with respect to a common ‘core’ i.e. the
CBT is a shortest path spanning tree from the core spanning all multicast members.
However, source-based tree algorithms are clearly robust; a sender simply sends its
data, and intervening routers "conspire" to get the data where it needs to, creating state
along the way. This is the so-called "data driven" approach -- there is no set-up protocol
involved. It is not as easy to achieve the same degree of robustness in shared tree
algorithms; a shared tree's core router maintains connectivity between all group members,
and is thus a single point of failure. Protocol mechanisms must be present that ensure a
core failure is detected quickly, and the tree reconnected quickly using a replacement
core router. Any CBT mechanism for a MANET environment is complicated by the fact
that selecting a core is non trivial and a poor selection can result in large latencies.
1.3 Multicast routing issues for MANETs – Problems with the DVMRP
approach
In DVMRP (Distance Vector Multicast Routing Protocol) [3], the protocol used in the
internet (Mbone), each multicast sender uses flooding to direct the multicast packets to all
nodes within a specified range (defined by TTL). Multicast packets are selectively
forwarded according to the reverse shortest path forwarding protocol [8]. Non-member
leaf nodes and nodes without any downstream members send prune messages upstream to
prune off branches to non-member nodes. After timeout, pruned branches become
alive again and get flooded with messages. A new receiver member can also
send a graft message to upstream nodes in order to speed up the connect process. To
understand some of the multicast routing issues in a MANET environment, it would be
useful to analyze the problems that occur when DVMRP is extended to a MANET
environment. One problem is the data flooding overhead. Because upstream nodes may
change or be disconnected due to node mobility, it is necessary to reflood by exploring
pruned branches after timeout in order to reestablish the upstream information, reconnect
lost members, or allow new members to join. In addition, reflooding is needed to
confirm the existence of the sender source. A sender is declared non-existent
after timeout. This periodical reflooding of data causes very large transmission overhead
for the low bandwidth wireless channel that exists in a MANET. Another problem is the
Reverse shortest Path Forwarding (RPF). Since DVMRP uses the RPF mechanism,
packets are accepted only from the shortest path. If the shortest path changes and there
are no packets to be forwarded in the new path, the node will be disconnected from the
tree (since it will not accept packets from the old path). Furthermore, in a wireless
environment, there is no notion of explicit link interface like in a wired point to point
channel. Multicast forwarding is based on nodes (routers) which are going to accept
multicast packets rather than on links on which multicast packets are forwarded.
Traditional multicast protocols based on upstream and downstream links (like DVMRP)
are not suitable here because creating and maintaining upstream and downstream link
status in a wireless network is not efficient. The FGMP and other protocols (described in
the next chapter) are explicitly designed to work in a MANET environment and
overcome some of the problems that occur when DVMRP is extended to a wireless
environment. Our proposed protocol, LTMP, is modeled on FGMP and is an
improvement over several existing MANET protocols.
LOCALIZED TREE CHANGE MULTICAST PROTOCOL
The previous chapter provided a brief description of some of the existing source based
multicast routing protocols for ad hoc networks.Although these protocols were designed
with the aim of coping with some of the challenges posed by a MANET environment and
are hence an improvement over the DVMRP approach, there remain some issues that
need to be addressed. Consider for instance, the FGMP protocol. Although FGMP
improves upon DVMRP by reducing unnecessary storage overhead, it still requires
group senders or receivers to periodically flood membership information globally. Such
periodic global flooding can increase contention for the shared wireless medium. Clearly,
such a mechanism is not well suited to a scenario in which the sender or receiver
membership status changes infrequently. A better method would be to require senders or
receivers to globally update their membership information, only when there are changes
to their current status. Also, in most multicast protocols, including FGMP and DDM,
nodes use the MAC layer broadcast facility to forward multicast packets. Since MAC
layer protocols such as 802.11 provide acknowledge messages only for unicast
transmissions, multicast data packet collisions at the MAC layer remain undetected, i.e.
collisions result in multicast data packet loss. The increased contention for the shared
wireless medium (due to the periodic global flooding in FGMP) only increases the
probability of multicast data packet loss due to collisions at the MAC layer. The DDM
protocol, also described in detail in the previous chapter, suffers from excessive
complexity and requires forwarder nodes to possess good processing power in order to
ensure fast delivery of multicast packets. Also, both these protocols are heavily
dependent on an underlying unicast protocol with good convergence characteristics.
The LTMP protocol has been designed to address the issues mentioned above and is
modeled on FGMP, in that a forwarding group is maintained by enabling a forwarding
flag at each of the forwarder nodes. Such an approach, as explained in chapter 1, makes
better sense in a MANET environment. Unlike FGMP, however, LTMP does not require
group members to periodically flood their membership status. This reduces the control
overhead considerably in our protocol when compared with that of FGMP. Group
receivers that wish to receive data from a multicast sender use a Request Response
procedure to join the group. Such a scheme allows for end-to-end signaling between the
source and the receiver. End to end signaling between the multicast source and the
receiver has several useful benefits, as illustrated in [5]. In particular, it is possible for the
source to authenticate potential multicast receivers. When a receiver wants to leave a
group, it simply stops transmitting group hello packets (used in group maintenance), thus
negating the need for any explicit GROUP LEAVE packet, resulting in a further
reduction in control overhead. We believe that this reduced control overhead in our
protocol is one of the main reasons behind its excellent overall performance. Also,
conceptual multicast tree changes are localized and no upstream information is
maintained. We make use of the broadcast nature of the wireless medium to encapsulate
upstream information in group hello packets meant for downstream nodes. This ability
for localized tree change allows our protocol to ensure stable multicast delivery with as
few additions to the forwarding group as possible, thus improving multicast efficiency
and reducing the channel overhead. Also, unlike DDM and FGMP, the LTMP protocol
does not depend on any unicast protocol for its operation. And unlike DDM, LTMP is a
simple protocol, with very little processing cost at the forwarder nodes.
3.1 The LTMP protocol design
The group hello packet used in forwarding group maintenance is a four tuple containing
the following entries {Sequence number, Group address, Multicast Source Address, My
address, My upstream’s address}. The sequence number is used to ensure freshness of the
group hello packet. As mentioned earlier, the upstream address information is
encapsulated in the group hello packet meant for downstream nodes. As in FGMP, a
forwarding flag is set at each node to indicate that it is a forwarder for a particular
multicast source. Associated with each such flag are two timers described below. If either
of these time out, the forwarding flag is reset and the node ceases to be a forwarder.
The Timer_group_hello timer is set to indicate the maximum amount of time that can
elapse before a FRESH group hello packet, with a sequence number higher than that of
the Group hello last received from a particular multicast source, MUST be received,
failing which the node ceases to be a multicast forwarder for that multicast source. The
Timer_group_hello_upstream timer is set to indicate the maximum amount of time that
can elapse before a multicast forwarder MUST receive a FRESH group hello packet from
one of its downstream nodes, failing which the node ceases to be a multicast forwarder
for that multicast source. The functions of these timers become clear when the group
maintenance process is understood. The forwarding group with respect to a particular
multicast source is first initialized using a request response procedure. A group JOIN
request is sent by a receiver when it wants to receive multicast packets from a multicast
source. This JOIN request packet is flooded and is handled by intermediate nodes in a
manner similar to the RREQ (Route Request) packet in the AODV (Ad Hoc on Demand
Distance Vector) protocol [4]. An important difference, however, is that only the source
can respond with an RREP packet, because of the need for end to end signaling (unlike in
AODV, where an intermediate node with a fresh enough route to the source can respond
with an RREP packet). End to end signaling between the source and the receiver has
several useful benefits, as illustrated in [5]. In particular, it is possible for the source to
authenticate potential multicast receivers. Another difference in the way JOIN request
packets are handled in LTMP (as opposed to the RREQ packet in AODV) is that once a
JOIN request packet reaches a group forwarder, a flag in the packet is enabled and the
packet is then forwarded only by group forwarders. This is an improvement over rigorous
flooding, which requires every node in the network to forward the packet. The source
responds to the first JOIN request it receives with an ACCEPT packet similar to the
RREP in AODV. All nodes on the intermediate path are made forwarders with respect to
that multicast source to which the JOIN request was sent. As mentioned earlier, group
maintenance is achieved by multicasting group hello packets. The manner in which a
forwarder handles group hello packets is explained in the pseudo code. First, the node
checks to see if the packet received is not a duplicate, using the sequence number field. If
the packet is fresh enough, it inserts upstream information into the packet and forwards it
after refreshing Timer_group_hello. If the packet is a duplicate, then the node checks to
see if it has been made an upstream by the node forwarding the packet. If so, it resets
Timer_group_hello_upstream. From this procedure, it is clear that a node ceases to be a
forwarder under two conditions.
(I) A forwarder hasn’t received a fresh enough group hello packet from the source for a
length of time defined in Timer_group_hello. This could be due to node failures on the
intermediate path between the source and the forwarder, due to node mobility or simply
due to packet loss. Or it could be that the source just stopped sending group hello packets,
because it has no more data to send.
(II) A forwarder hasn’t received a group hello packet in which it has been specified as an
upstream. This could be due to packet loss or it could mean that there are no forwarders
downstream of the forwarder with respect to the multicast source. It must however, be
noted that only condition I applies to a multicast receiver. All multicast receivers are, by
default, forwarders, even if they do not have a downstream. This is to ensure that nodes
upstream of the receiver refresh Timer_group_hello_upstream.
Join Request and Group creation in LTMP Join requests for a particular group are made
by means of RREQs during which reverse paths to the destination are set up. The source
acknowledges the first arriving RREQ, the RREP traverses the pre established reverse
path setting up forwarding flags for the group on its way. Source S receives RREQs for
S1 from F via 2 paths. It chooses the path S-A-F.
Node F before the link failure would have rebroadcast the group hello with parent address
set to A. However once it fails to get a group hello from A, it switches to C as its
upstream. This is the localized tree change; we resort to flooding only when absolutely
necessary. C learns by means of F’s rebroadcast that there exists at least one child node
and therefore should remain a forwarder. If C was not a forwarder for S1, F would not
have received any group hello and its timer would have expired. It would have ceased to
be a forwarder and a local tree change would have been attempted at levels lower to F,
i.e. its downstream nodes.

A node needs to remain as a forwarder only as long as there remains at least one node
downstream to it. Consider the case of A, node F switched predecessors and node H quit
the group. A fails to receive at least one group hello with parent address set to itself.
Eventually its timer expires and A ceases to be a forwarder for A. The source of a
multicast group periodically sends group hellos.
52
Multicast group members do not use an explicit LEAVE packet to
indicate that they no longer wish to be part of a group. A multicast receiver,
when it wishes to leave the group, simply stops forwarding group hello
packets. A multicast sender also stops sending group hello packets when it
wants to leave a group. The use of timers to maintain forwarder status results
in correct synchronization of the forwarding group to reflect topology
changes and member ship changes.
3.2 Loop Freedom of the LTMP protocol
The LTMP protocol ensures loop free paths for a multicast packet from a multicast
source S to its receivers i.e. the conceptual multicast tree rooted at source S is indeed a
tree and is devoid of any loops. To prove this, we follow the style of proof used in [6].
Consider the directed graph G defined by nodes i and arcs ( S i U , i), where S i U denotes
the upstream for node i with respect to the multicast source S, where each node i is either
a multicast group member or a forwarder. The LTMP protocol ensures that G is loop free
i.e. the conceptual multicast tree rooted at S is indeed a tree and is loop free. Potentially,
a loop may form when a node i changes its upstream. This can happen in two cases. The
first case is when node i detects that the link to S i U is broken and sets S
i U to null. Clearly, this cannot result in a loop. The second case is when node i receives a
group hello packet from one of its neighbours k, with sequence number S
k X that is greater than S i X Here, S i X denotes the sequence number corresponding to
multicast source S stored at node i. By choosing node k as its next hop, node i cannot
close a loop. This can be deduced from the following observation. A node I propagates
sequence number S i X only after receiving it from its current upstream. Therefore, at all
times, the sequence number stored at the upstream is always greater than or equal to the
sequence number stored at node i. Starting from node i, if we follow the chain of
upstreams, the sequence number values corresponding to S stored at the visited nodes
would form a nondeccreasing sequence. Now assume node i closes a loop by choosing
node k as its upstream. This would imply that S k X <= S i X . But this contradicts our
initial assumption that S i X < S k X . Thus, loops cannot be formed if newer sequence
numbers are used to pick upstream nodes.
PERFORMANCE ANALYSIS
For evaluation purposes, we have formulated and implemented our
protocol in the MANET simulator, Glomosim. We have also implemented
four other existing protocols for comparison purposes, namely FGMP,
Reverse FGMP, DDM and Constrained Multicast flooding. From the
simulation results, it is clear that LTMP outperforms most of the protocols
under analysis with regard to a number of performance parameters. We
believe that this quantum improvement in performance is due to the reduced
control traffic in our protocol and its ability for localized tree change.
To evaluate the performance of the LTMP protocol and to enable
comparison with the existing protocols, we have used four performance
parameters, namely multicast delivery (throughput), control overhead,
multicast efficiency and average forwarding group size. The plots shown
below illustrate how each of these parameters varies with the number of
groups in the network and with node mobility. A large number of simulation
trials were carried out, and the graphs shown represent the mean values.
4.1 Multicast Delivery:
To measure multicast performance, we define a parameter called the
multicast delivery ratio, as follows:
Multicast delivery ratio = Total number of multicast packets received at all multicast receivers
_
i
iiPR
Where i R is the number of receivers in group i
i P is the total number of multicast packets sent by all senders in the
group i over the simulation period
The multicast delivery ratio is an indication of the effectiveness of the
multicast protocol in delivering packets in a reliable manner. Multicast
delivery is affected primarily by the loss of a multicast route due to mobility
and by packet loss due to collisions at the MAC layer.
The graph Figure 13 shows how the multicast delivery (expressed in
percentage) varies with the number of multicast groups. The simulation
environment was set up in Glomosim such that each multicast group had
five receivers and one sender. Each sender used a CBR traffic generation
model to generate multicast traffic for the experiment. This configuration
corresponds roughly to a broadcast service such as video on demand. For a
particular N value, simulation trials were carried out at various member
configurations and node speeds. The mean multicast delivery is plotted.
As expected, flooding has the best delivery characteristics due to the
high level of redundancy in multicast routes (Every node is a forwarder).
There is, however, a dip in delivery rates as the number of groups increase.
This is because occasional packets remain undelivered as a result of packet
loss due to collisions at the MAC layer. (The higher amount of traffic in the
network, for larger N values, increases the likelihood of there being packet
loss due to collisions at the MAC layer.)

56
The LTMP protocol clearly outperforms the other protocols for
network configurations where the number of groups is greater than two. It
can be seen from the graph that the multicast delivery of the FGMP and
Reverse FGMP protocols degrades much more than LTMP’s as the number
of groups, N increases. This is due to the excessive amount of control traffic
involved in these protocols, as for example is generated by receivers who
57
frequently advertise their membership by globally flooding membership
packets. This control traffic increases as N increases and, in combination
with the already high multicast traffic for large N values, results in an
increased probability of packet loss due to collisions at the MAC layer.
Unlike flooding, FGMP and Reverse FGMP do not have much redundancy
in multicast routes. As a result, the effect of packet loss on multicast
delivery
is magnified.
The LTMP protocol does not employ as much unnecessary control
traffic as the other protocols, with the result that its multicast delivery ratio
is relatively higher for larger N values. It is also interesting to note that
LTMP’s delivery ratio is stable across varying N. This can be explained as
follows; even though an increase in control traffic is expected as the number
of groups increases, the LTMP protocol has been designed in such a way
(with minimal inherent control traffic) that even this increase does not result
in appreciable data packet loss due to collisions at the MAC layer. DDM’s
delivery ratio, although stable, is much lower than LTMP’s.
Figure 14 shows how the multicast delivery varies with node mobility.
The multicast delivery ratio (in percentage) is plotted against various values
of node speeds. We used the random waypoint model in our simulation
experiments. For each value of node speed, simulation trials were carried out
at various member configurations and for network configurations with
varying number of groups. The mean multicast delivery is plotted.
59
LTMP outperforms other protocols at all node speeds. We believe that
one reason for this could be that tree changes are localized i.e. a node can
change its upstream dynamically and start obtaining multicast data from the
sender. LTMP will thus resort to flooding only if a receiver cannot find an
upstream for the group. Global Flooding results in more packets being
broadcast and only increases contention for the channel (which is shared by
adjacent nodes). The reduced flooding requirements of our protocol thus
results in reduced packet loss due to collisions and improves multicast
delivery. Also, the LTMP protocol does not generate unnecessary control
traffic unlike the other protocols, and this again reduces the likelihood of
packet loss due to collisions.
The other protocols, however, do frequently resort to flooding to reestablish
multicast routes. Protocols such as FGMP and DDM use the
underlying unicast protocol (AODV in our simulation experiments) to find
routes to multicast receivers. Increased mobility would mean frequent link
failures. This, in turn would require nodes to recompute routes to the
receivers by flooding route request packets. Delivery is thus affected by the
frequent absence (at least until the route discovery process is finished) of a
valid route to the receiver. Also, the flooding requirement, coupled with
other unnecessary control traffic results in increased packet loss due to
collisions. This, we believe, is an important reason for the relatively low
multicast delivery performance of these protocols.
As expected, the multicast delivery ratio of LTMP (and most of the
other protocols) decreases as node mobility increases. This is because with
higher node speeds, there is a strong possibility that the paths set up between
60
the multicast source and the receivers become useless more often, with the
result that the delivery ratio suffers.
4.2 Multicast Efficiency:
In a wireless medium, a multicast protocol can take advantage of the
MAC layer broadcast facility to reduce channel overhead. For instance, in
FGMP and LTMP a multicast packet broadcast by an upstream is received
and processed by each of its immediate downstream nodes. An efficient
MANET multicast protocol thus makes good use of the MAC layer
broadcast facility. We use a parameter called multicast efficiency to measure
how effectively the broadcast facility is used to reduce channel overhead:
Multicast efficiency ME = Total number of multicast receptions (along the path as well as at the receiver)
Total number of multicast transmissions (at each node)
To measure the total number of multicast receptions, we accumulate the
hopcount of every multicast packet at each multicast receiver. Lower values
of ME imply a lot of redundant multicast transmissions. This leads to
unnecessary channel overhead. The other source of channel overhead is the
use of control messages. This has been studied using parameter 4.4, the
number of control bytes sent per data byte received.
Figure 15 shows how the multicast efficiency varies with the number
of multicast groups in the network. The network configuration is the same
one used for measuring multicast delivery. As before, several trials were
conducted and the average value of efficiency was plotted.
LTMP clearly has the best multicast efficiency among the protocols
under analysis. This is a reflection on the average forwarding group size of
LTMP, which is the lowest among the protocols under analysis. Both DDM
and FGMP operate in a similar manner in that they use AODV to determine
and maintain the forwarding group for a multicast sender. As a result, these
two protocols have similar values for multicast efficiency. The number of
groups in the network has little effect on the multicast efficiency, as can be
seen from the graph.
Also, as expected, flooding is the least efficient multicast protocol
(with ME<1, meaning there are a lot of redundant multicast transmissions).
This is because every node in the network is a multicast forwarder for all
groups. As a result, nodes receive a lot of redundant multicast packets and
the broadcast nature of the medium is not utilized efficiently.
Figure 16 shows how multicast efficiency varies with node mobility.
It greatly resembles the previous graph. Again, LTMP has the best multicast
efficiency among the protocols under analysis. As in the previous graph,
flooding has the lowest multicast efficiency. Node mobility has a moderate
degrading effect on the multicast efficiency of LTMP. This is again a
reflection on the average FG size of the LTMP protocol, which increases
slightly with increasing mobility.
63
4.3 Forwarding Group size:
The size of the forwarding group FG should be kept as small as
possible to avoid unnecessary channel overhead. Also, larger forwarding
groups affect multicast delivery because of the increased likelihood of
packet loss due to collisions. Figure 17 shows the average size of the
forwarding group for the various protocols under analysis.
64
The graph shown above (Figure 17) shows how the average FG size
(FG is assumed to include every multicast forwarder in the network and FG
size is averaged over the experiment) varies with the number of groups, N.
As expected, the FG size grows as more multicast groups are added to the
network. It must be noted that the FG size for flooding has not been plotted
in this graph. This is because the multicast flooding protocol we have
65
implemented uses a constant FG size of 50 (which is the number of nodes in
the network- every node is a forwarder).
LTMP has the lowest average FG size among the protocols under
analysis. One reason for this could be that LTMP, unlike other protocols,
adds new forwarders to the FG only when absolutely necessary. Localized
tree changes allow for stable multicast delivery with minimal additions to
the forwarding group. New forwarders are added to the FG only when the
receiver is unable to obtain a valid upstream to the multicast source.
Protocols such as FGMP and DDM, on the other hand, frequently employ
the route discovery mechanism of the AODV protocol if a valid route to the
receiver does not exist. In highly mobile scenarios, involving frequent link
failures, this might mean frequent additions to the FG as new routes to the
receiver are discovered as part of the AODV route discovery process.
The graph (Figure 18) illustrates how the average forwarding group
size (averaged over the experiment) varies with the speed of nodes in the
network. As in the previous graph, LTMP has the lowest average forwarding
group size. There is a slight increase in FG size as node mobility increases.
This is expected, because at higher node speeds, the number of link failures
due to nodes moving out of range is also higher. As a result, the number of
such failures that actually get propagated to the receiver is also likely to be
higher. This leads to an increase in the frequency of receiver floods, thus
resulting in relatively frequent additions to the FG (when compared with low
mobility scenarios).
66
4.4 Control Overhead:
To measure the control overhead, we use a parameter that represents
the number of control bytes transmitted per data byte received. Unnecessary
control messages increase channel overhead and result in increased
contention for the channel. Control overhead has an adverse impact on
multicast delivery, because a protocol that uses a large number of control
messages is also likely to suffer data packet loss due to collisions with
control packets.
67
Figure 19 shows how the control overhead varies with the number of
groups for the various protocols. The Reverse FGMP protocol has the lowest
control overhead among the protocols under analysis. And as expected, its
control overhead is fairly constant (both in Figure 19 and in Figure 20,
which shows how the control overhead varies with node mobility). The
Reverse FGMP protocol uses membership request messages that are
periodically flooded by the receivers in order to refresh membership status
with the multicast source and establish paths between the multicast source
and its receivers. The protocol implementation does not involve any other
control messages to handle link failures or other abnormal network
conditions. This low control overhead of the Reverse FGMP protocol should
be weighed against the fact that its delivery characteristics are poor, as seen
in Figures 13 and 14.
LTMP clearly has very low control overhead, when compared to
protocols like DDM and FGMP. As explained before, these two protocols
use excessive control messages. These protocols, in many cases, use global
flooding to transmit the control messages, which only adds to the control
overhead. The control overhead for the flooding protocol is set to zero. This
is because the flooding protocol does not use any control packets. All
multicast data packets are globally flooded using a constrained flooding
protocol.

69
Figure 20 shows how the control overhead varies with node mobility.
In many ways, it resembles the previous graph. One noticeable feature is a
gradual increase in the control overhead of the LTMP protocol as node
mobility increases. As nodes become more mobile, there is a greater chance
that multicast routes set up between the source and the multicast receiver(s)
might become invalid. In some cases, this might lead to the receiver flooding
(using a special flooding protocol aimed at reducing channel overhead) a
Join request to the source. This could be one reason for the moderate
increase in control overhead with node mobility.
71
CONCLUSION
In this project, we have designed and evaluated a novel source based
multicast protocol for MANETs – the LTMP protocol. The key
distinguishing features of our protocol are its low control overhead and its
ability for localized tree change. For evaluation purposes, we have
formulated and implemented our protocol in the MANET simulator,
Glomosim. We have also implemented four other existing protocols for
comparison purposes, namely FGMP, Reverse FGMP, DDM and
Constrained Multicast flooding. From the simulation results, it is clear that
LTMP outperforms most of the protocols under analysis with regard to a
number of performance parameters, including multicast delivery, multicast
efficiency, average forwarding group size and control overhead.
An interesting outcome of our project is an understanding of the
relationship between the control traffic employed by a protocol and the
delivery characteristics of that protocol in a MANET environment. From the
performance evaluation, it is clear that LTMP, with its relatively lower
levels of control traffic, has the best delivery characteristics (after flooding,
which is hardly a feasible option in a MANET environment). Lesser control
traffic translates to lesser amounts of packet loss due to collisions at the
MAC layer (multicast transmissions at the MAC layer are unacknowledged).
Also, a protocol with higher control traffic is likely to spend more time and
bandwidth on control operations, rather than on actual data delivery.
Additionally, the provision for localized tree changes in our protocol negates
the need for frequent RREQ flooding by intermediate forwarder nodes
(unlike in protocols like DDM and FGMP); In LTMP, only receivers flood
join requests (using a procedure designed to minimize control overhead)
aimed at multicast sources.
The LTMP protocol was thus designed with reducing control overhead as
top priority and as indicated by the evaluation results, does an excellent job.
Though the performance of LTMP may not be comparable to mesh based
protocols as network traffic increases (just like any other tree based
protocol), LTMP is one of the finer tree based protocols around.
REFERENCES
1. A.Ballardie, P.Francis, and J.Cowcroft (1993), “Core Based Trees”
,Proceedings of SIGCOMM 1993
2. Ching-Chuan Chiang, Mario Gerla and Lixia Zhang (1998),
“Forwarding Group Multicast Protocol (FGMP) for Multihop, Mobile
Wireless Networks”, CLUSTER COMPUTING 1998
3. S. E. Deering and D. R. Cheriton (1990), “Multicast Routing in
Datagram Internetworks and Extended LANs”, ACM Transactions on
Computer Systems 1990.
4. Lusheng Ji and M. Scott Corson (2001), “Differential Destination
Multicast-A MANET Multicast Routing Protocol for Small Groups”,
INFOCOMM 2001.
5. David B. Johnson and David A. Maltz (1996), “Dynamic Source
Routing in Ad Hoc Wireless Networks”, Mobile Computing 1996.
6. Charles E. Perkins and Pravin Bhagwat (1994), “Highly Dynamic
Destination-Sequenced Distance-Vector Routing (DSDV) for Mobile
Computers”, Proceedings of SIGCOMM 1994.
7. Charles E. Perkins and Elizabeth M. Belding-Royer(1999) ,“Ad hoc
On-Demand Distance Vector (AODV) Routing”, Proceedings of the
2nd IEEE Workshop on Mobile Computing systems and applications
1999.
8. Elizabeth M. Royer and Chai-keong Toh (1999), “A review of current
routing protocols for ad-hoc networks”, IEEE Personal
Communications 1999.