Transmission range effects on AODV multicast communication.
As laptop computers begin to dominate the marketplace, wireless adapters with varying bandwidth and range capabilities are being developed by hardware vendors. To provide multihop communication between these computers, ad hoc mobile networking is receiving increasing research interest. While increasing a node's transmission range allows fewer hops between a source and destination and enhances overall network connectivity, it also increases the probability of collisions and reduces the effective bandwidth seen at individual nodes. To enable formation of multihop ad hoc networks, a routing protocol is needed to provide the communication and route finding capability in these networks. The Ad hoc On-Demand Distance Vector Routing protocol (AODV) has been designed to provide both unicast and multicast communication in ad hoc mobile networks. Because AODV uses broadcast to transmit multicast data packets between nodes, the transmission range plays a key role in determining the performance of AODV. This paper studies the effects of transmission range on AODV's multicast performance by examining the results achieved at varying transmission ranges and network configurations.
Introduction
Within the last few years, mobile computing has
gained popularity as laptop computers have become
smaller, lighter, and more powerful. It has become
commonplace for professionals to carry their computers
with them as they travel. With this increase in popularity
has also come a greater demand for connectivity.
The idea of anywhere/anytime network access naturally
appeals to mobile users. These users want to access the
Internet and communicate with their associates, whatever
their location. This provides the motivation for ad
hoc networking, or the on-the-
y formation of networks.
Protocols for managing such ad hoc networks must be
able to formulate routes between any given source and
destination, and then be able to maintain these routes
as the location of the users changes.
As the number of mobile users has risen, a wide variety
of applications have become available. Some of
these new applications rely on multicast communication
for their operation. While identical semantically
to the corresponding concept in wired networks, multi-cast
in ad hoc mobile networks has a distinguishing set
of characteristics and constraints. These include limited
power, limited bandwidth, and high error rates.
An ad hoc multicast protocol must be able to connect
all group members and then maintain this connectivity
after topological changes in the network.
The Ad hoc On-Demand Distance Vector (AODV)
routing protocol provides both unicast and multicast
communication connectivity in an ad hoc mobile environment
[11,16]. AODV is a reactive protocol in that it
creates routes on-demand, or as needed. Both unicast
and multicast routes are built using a route discovery
cycle, which is initiated when a source node wishes to
either nd a route to some destination or join a multi-cast
group. Nodes which are able to provide a route to
the desired destination respond to the source node by
sending it a reply packet. Once a route is established, it
is maintained as long as it is needed; i.e., until either the
source node stops sending packets, or until there are no
longer any members of the multicast group. AODV is
able to quickly repair link breaks in active routes whenever
they occur.
Other ad hoc multicast protocols have recently been
developed as this topic has attracted the attention of the
research community. The On-Demand Multicast Routing
nProtocol (ODMRP) [9] is a mesh-based algorithm
which calculates a forwarding group for each multicast
group. The forwarding group is a set of nodes which forward
multicast packets that they receive. The group is
periodically refreshed by a network-wide Join Request
message broadcast by each multicast source node. An
alternative protocol is the Core-Assisted Mesh Protocol
(CAMP) [6]. Like ODMRP, CAMP also creates
a shared mesh per multicast group. CAMP uses core
nodes to limit the amount of control tra-c when nodes
join a group, and it ensures that the shortest path from
receivers to sources is a part of the mesh. Finally, the
Lightweight Adaptive Multicast protocol (LAM) [7] is
similar to AODV in that it is tightly coupled with a
unicast protocol (TORA [10]), and also creates a shared
tree for each multicast group. However, LAM bases this
shared tree at a pre-selected core node.
Current wireless modems oer a wide range of transmission
power and connectivity. For instance, the
Wavelan IEEE Turbo card, which oers 2 Mb/s at a
400m transmission radius in open o-ce conditions and
a 90m radius in semi-open conditions. The 1 Mb/s data
rate for this card oers a 550m and 115m range in the
same conditions. Proxim's 1.6 Mb/s RangeLAN2 oers
a 300m outdoor range and 150m indoor range. Breeze-
com's SA-PC Pro card provides data rates between 1
and 3 Mb/s, while transmitting at a range of 600m outdoors

These products oer a variety of power levels, and
thus transmission ranges, for fairly similar bandwidth.
It might seem desirable to have the largest possible
transmission radius, since this would provide the greatest
amount of connectivity. However, high density networks
suer from channel access delays and an increased
number of collisions. Moreover, applications sometimes
have to run in constrained environments. For instance,
in a conference scenario, attendees are likely to be conned
within some xed area, possibly in just a single
large room. With that area, it is not necessarily the
case that the largest transmission radius is the best
solution for connectivity. A large transmission radius
necessarily implies that more users are aected by each
transmission, thereby limiting the eective bandwidth
of neighboring users. The larger the transmission ra-
dius, the more users aected by transmissions.
In the case of unicast data, the eects of a large
transmission radius in a conned area may be somewhat
mitigated by channel access schemes such as the IEEE
802.11 Distributed Coordination Function (DCF) [4].
For unicast communication, DCF utilizes short control
packets for acquiring the channel, and provides an acknowledgment
to ensure data reception. Thus, while
the number of collisions of the control packets may increase
with larger transmission radii, thereby increasing
channel access time, data throughput may not be notably
aected. Since the number of hops to reach a
destination is smaller for a larger transmission radius,
the total delay for a data packet between source and
destination might even decrease.
However, for multicast data, the situation is quite
dierent. Multicast data packets are in some ways similar
to broadcast tra-c. In the case of AODV, when a
node receives a data packet with a multicast destination
address, it must send the packet up the protocol
stack at least as far as the IP layer to determine whether
to accept or forward the packet. For short transmission
radii, the number of nodes aected by a single transmission
is small, so a network node that does not belong
to any multicast groups is less likely to waste signi-
cant processing power discarding useless packets. How-
ever, as the transmission range increases, the number
of nodes which receive multicast data transmissions also
increases, and, assuming that the membership of a multicast
group is a relatively small percentage of the total
network population, the number of nodes adversely affected
by these multicast transmissions similarly rises.
Hence there is a tradeo between being able to reach
multicast group members in a smaller number of hops,
and keeping the set of nodes aected by multicast data
transmissions to a minimum.
This paper investigates the nature of that trade-
o, examining the eects of varying transmission range
within dierent conned network areas. A variety of
results are examined, including the packet delivery ratio
for multicast data packet delivery, and the number
of multicast data packets non-group members must dis-
card. The remainder of this paper is organized as fol-
lows. Section 2 takes an in-depth look at how AODV
provides multicast connectivity for the lifetime of a multicast
group, including the creation and maintenance of
the multicast tree. Section 3 describes the forwarding
mechanism used for the multicast data packets. Then,
section 4 describes the simulations performed and examines
the results of these simulations to determine
how the change in transmission range eects varying
aspects of the protocol and the network connectivity.
Section 5 describes directions for future work, and -
nally section 6 presents the conclusions from this study.
2. The Protocol
AODV's multicast operation is based on a route discovery
cycle. When a node wishes to either join a multicast
group or nd a route to a group, it initiates route
discovery by sending a Route Request (RREQ) packet.
As nodes join the multicast group, a bidirectional tree
is formed from the group members and the nodes connecting
those group members (tree routers). There is
only one tree per multicast group, and each multicast
group has associated with it a multicast group leader.
The multicast group leader's sole responsibility is to
maintain and disseminate the multicast group sequence
number. AODV utilizes sequence numbers to ensure
relative freshness of routes, and thereby to prevent routing
loops.
2.1. Routing Tables
Each node running AODV must potentially maintain
two tables related to multicast. If a node is either
a member of a multicast group or is a router for such a
group, it must maintain a Multicast Route Table (MRT).
The MRT is used by nodes to maintain next hop information
for the multicast trees. The elds of the MRT
are as follows:
Multicast Group IP Address
Multicast Group Leader IP Address
Multicast Group Sequence Number
HopCount to Multicast Group Leader
Next hops, with the following data per hop:
Next Hop IP Address
Link Direction
Activated Flag
There is one entry in the MRT for each multicast
group of which the node is either a member or a tree
router. Each entry has associated with it a list of one
or more next hops, or neighbors on the multicast tree.
The next hops eld is a linked list of structures, each of
which contains the indicated information.
The link direction of a next hop is dened to be up-stream
if the link is towards the group leader, and down-
Group Leader
Next Hops
A

Figure

1. Sample Multicast Tree.
stream if it is away from the group leader. Because of
the tree structure, a node should have at most one up-stream
link at any time. The Activated
ag associated
with each next hop is an indication of whether the link
has been o-cially added to the multicast tree (see section
2.3.3). When a link is added to the tree, the
ag
is set, and only after that time can the link be used
for receiving multicast data packets. In gure 1, node
A's next hops on the multicast tree are enclosed by the
dashed line.
AODV also maintains a Group Leader Table (GLT)
with two elds per entry:
Multicast Group IP Address
Multicast Group Leader IP Address
When a node receives a Group Hello (section 2.2),
it updates its GLT to re
ect the multicast group/group
leader association indicated in the Group Hello message.
If the node later wants to join a multicast group, it rst
checks its GLT for an entry for that group. If there is
such an entry, and if the node has a route to the multi-cast
group leader, it may unicast its Route Request to
the group leader instead of broadcasting it across the
network. This table is used only as an optimization; its
elimination does not aect the correct operation of the
protocol.
2.2. The Group Leader
Each multicast group has associated with it a group
leader. When a node wishes to join a multicast group,
it broadcasts a RREQ and then waits for a reply. If after
some maximum number of attempts (rreq retries
does not receive a reply, it may assume that
there are no other members of the group in the connected
partition of the network. It then becomes the
group leader for that multicast group and initializes the
sequence number to one. Once it becomes the group
leader, it broadcasts a Group Hello (GRPH) message.
This message contains the following elds:
mgroup seqno >
Currently, there are two
ags dened. The rst of
these is the Update
ag. This is set when there is
a change in group leader information, as described in
section 2.5.1. The second
ag is Omtree. When the
group leader initiates the GRPH, it leaves this
ag un-
set. Whenever a node not on the multicast tree receives
the message, it sets this
ag. This indicates that the
GRPH message has traveled o the tree along this path.
When a node on the multicast tree receives a GRPH
with the Omtree
ag unset, it knows that the GRPH
has traveled solely on tree links, and so the hop cnt eld
can be used to update the node's current distance from
the group leader. Otherwise, if a multicast tree node receives
the packet with that
ag set, it knows it cannot
use the hop cnt value as an indicator of its distance from
the group leader, because the packet has not traveled
only along the tree. The signicance of this message
being broadcast instead of multicast across the tree is
shown in section 2.5.3.
The hop cnt eld is incremented each time the GRPH
packet is forwarded. The source addr eld is set to
the group leader's IP address, and the mgroup addr
and mgroup seqno elds are set to the multicast group
IP address and current sequence number, respectively.
The group leader increments the group sequence number
each time it initiates a new GRPH message.
When a node receives the GRPH packet, it records
the multicast group IP address and sequence number
before rebroadcasting the packet. If it later receives
a GRPH with this same multicast group IP ad-
dress/sequence number combination, it knows it has already
seen this GRPH message and it can discard the
packet. If, on the other hand, a node receives a GRPH
packet it has not seen before, it updates its GLT to reect
the current group/group leader combination. If it
is a member of the multicast tree, it also updates the
multicast group sequence number.
A group leader change occurs when the current group
leader either decides to unsubscribe from the group, or
when the multicast tree becomes partitioned. These
scenarios are described in sections 2.4 and 2.5.2, respectively

2.3. Subscribing to the Multicast Group
A route discovery cycle is initiated each time a node
would like to nd a route to a multicast group. It may
initiate route discovery in order to subscribe to a new
group, or because it would like to begin sending to a
group of which it is not already a member. The node
initiates route discovery by broadcasting a RREQ. It
then waits for the reception of a Route Reply (RREP)
packet. After the discovery period, the node selects
its next hop towards the multicast tree. It activates
this link by unicasting this node a Multicast Activation
(MACT) message.
2.3.1. Route Requests
When a node wishes to subscribe to a multicast
group or to nd a route to a group of which it is not
already a member, it initiates route discovery by broadcasting
a RREQ. The RREQ has the following structure

broadcast ID; dest addr;
dest seqno; source addr; source seqno >
The currently dened
ags are Join and Repair. Join
is set when the node wishes to join the group, as opposed
to just nd a route to the group. The Repair
ag
is set when the RREQ is sent to repair the multicast tree
(section 2.5.3). The dest addr eld is the IP address of
the desired multicast group, and the dest seqno is the
source's record of the last known sequence number of
the multicast group. Processing for the other RREQ
elds follows the unicast algorithms as specied in [12]
and reported in [11].
When a node receives the RREQ, it notes the node
from which the RREQ arrived, and creates a next hop
entry in its MRT for that previous hop. The Activated
ag for that next hop is false. The node then determines
whether it can send a RREP by the method described in
section 2.3.2. If it cannot send a RREP, it rebroadcasts
the request to its neighbors.
To reduce the impact of route discovery, the RREQ
may be sent in an expanding ring search [12] for the
destination. Figure 2(a) illustrates the propagation of
a join RREQ throughout the network. In this gure, as
well as in the multicast gures in the following sections,
multicast group members are represented by shaded cir-
cles, and tree routers are represented by circles with the
letter 'R'.
Group Leader
R
R
(a) RREQ Propagation
Group Leader
R
R
(b) RREPs Returned to Source
Group Leader
R
R
R
(c) Multicast Tree Branch
Addition

Figure

2. Multicast Group Join.
2.3.2. Route Replies
If the RREQ is not a join request, any node with
a current route to the multicast group can respond by
sending a RREP. A current route is a route to the multicast
group whose associated sequence number is no
less than the dest seqno of the RREQ. On the other
hand, if the RREQ is a join RREQ, only a node that
is a member of the multicast tree may respond to the
RREQ. Since a RREP in response to a join request sets
up a potential branch addition to the multicast tree,
only members of the multicast tree are allowed to initiate
this RREP. In either case, if the node determines
it can respond to the RREQ, it creates a RREP and
unicasts the RREP to the source node. RREP contains
the following parameters:
prefix size; hop cnt; dest addr;
dest seqno; source addr; lifetime >
The only
ag currently dened for the RREP is Re-
pair. This
ag is set when the RREP is in response to
a repair request (section 2.5.1). The prex size eld is
utilized for subnet routing, as discussed in [12]. If the
node generating the RREP is a member of the multicast
tree, the hop cnt eld is initialized to zero. Otherwise, it
is set to the responding node's distance from the multi-cast
tree. This eld is incremented each time the RREP
is forwarded, so that when the source node receives the
RREP it indicates the source's distance from the multi-cast
tree. The dest addr is set to the multicast group's
IP address, and the dest seqno is set to the responding
node's record of the group's sequence number. The
source addr is the address of the node that originated
the request. The lifetime eld is used when the request
is not a join request. It is set to the responding node's
current lifetime for the multicast group route entry. For
nodes on the multicast tree, the multicast group entry
itself does not time out, and hence does not have a life-time
associated with it. Only the individual next hop
links may time out.
If the RREQ was a join request, the RREP also contains
an extension called the Multicast Group Information
Extension. This extension contains the multi-cast
group leader IP address and another hopcount eld
called mgroup hcnt. This hopcount is set equal to the
responding node's distance from the group leader. It is
incremented each time the packet is forwarded, so that
when the subscribing node (i.e., the node that sent the
RREQ) receives the RREP, it indicates that node's distance
from the group leader.
When a node receives a RREP, it stores the IP address
of the node from which it received this packet.
It also adds a next hop entry for the previous node
to its multicast route table entry, and leaves the Activate

ag associated with this next hop unset. The
node then forwards the RREP towards the source. If an
intermediate node later receives another RREP for the
same subscribing node and multicast destination pair,
it only forwards the new RREP if that RREP oers
a better route than was previously known. A better
route is one with either a greater destination sequence
number or the same destination sequence number but
a smaller hopcount to the multicast tree. Figure 2(b)
shows the path of the RREPs sent back to the subscribing
node.
After transmitting the RREQ, the subscribing node
waits the discovery period (route discovery timeout)
before selecting a route. During this period, it keeps
track of the best route (greatest sequence number and
smallest hopcount) to the multicast tree. At the end
of the discovery period, the subscribing node selects its
next hop and activates that next hop, as described in
the next section.
2.3.3. Multicast Activation
Once the discovery period has ended and the subscribing
node has chosen its next hop, it activates this
entry in its MRT by setting the Activated
ag associated
with that next hop. It then creates a Multicast
Activation (MACT) message, and unicasts this message
to its selected next hop. The MACT message contains
the following elds:
source seqno >
The currently dened
ags for the MACT message
are Join, Prune, Grpldr, and Update. The Join
ag is
set when the node is joining the multicast tree, while
the Prune
ag is used by a node when it wishes to prune
itself from the tree (section 2.4). The Grpldr
ag is used
after a network partition when a new group leader must
be selected (section 2.5.2), and the Update eld is used
after a tree branch repair (section 2.5.1).
The hop cnt eld is primarily used after a tree repair
(section 2.5.1). For link activation, this eld is
set to one. The mgroup addr eld is set to the IP address
of the multicast group, and the source addr and
source seqno elds are set to the IP address and current
sequence number of the node initiating the MACT, respectively

When the next hop receives the MACT message, it
activates the next hop entry for the sending node in its
MRT. If this next hop was already a member of the
multicast tree, the addition of the new branch to the
tree is completed. Otherwise, if this next hop was not
already a member of the multicast tree, then, like the
subscribing node, it will also have been keeping track
of the best next hop to the multicast tree. It activates
this next hop in its MRT, and then unicasts a MACT
message to this next hop. Processing continues in this
manner until an existing member of the multicast tree
is reached. Figure 2(c) shows the multicast tree after
the join is completed.
2.4. Unsubscribing From the Multicast Group
Multicast group membership is dynamic; nodes can
subscribe to or unsubscribe from a multicast group at
any time. A node prunes itself from the multicast tree
using a variation of the MACT message.
A multicast group member may unsubscribe from a
multicast group of which it is a member at any time.
However, it may only exit the multicast tree if it is a
leaf node. If a non-leaf node attempted to exit the tree,
the tree would then become partitioned. Hence, a non-leaf
node that wishes to unsubscribe from the multicast
group may change its member status internally, but it
takes no overt action to notify any of the other tree
members.
A leaf node unsubscribes from the multicast group
by pruning itself from the multicast tree. It does this
by rst deleting the entry for that multicast group from
its MRT, and then creating a MACT message with a
set Prune
ag. It then unicasts this message to its next
hop.
When the next hop receives the prune message, it
deletes the sending node's information from its MRT
entry for that multicast group. If, due to the pruning
of the sending node, the receiving node is now a leaf
node, and if this node is not a multicast group member
(only a tree router), it can in turn prune itself from the
tree in the previously described manner. Otherwise, if
it is not a leaf node, or if it is a member of the multicast
group, then pruning ends at this node.

Figure

3 illustrates a pruning operation. In g-
ure 3(a), node A is a multicast group member that
wishes to unsubscribe from the group. Since it is a leaf
node, it should also prune itself from the tree. It creates
the MACT prune message and unicasts this message to
its next hop, node B. When node B receives the mes-
sage, it deletes node A from its next hop entries, and
then notes that it is now a leaf node. Since it is a tree
router and not a group member, it then prunes itself
from the tree as well. Figure 3(b) illustrates the multi-cast
tree after pruning.
When the group leader decides to unsubscribe the
group, it operates in a similar manner. If it is a leaf
node, it may prune itself from the tree. Otherwise, it
must remain a router for the tree.
If it is a leaf node, it sends the prune message to its
next hop and deletes the multicast group information
from its MRT. When the next hop receives the prune
message, it is handled as described in section 2.5.2. Oth-
erwise, if the group leader is not a leaf node, it selects
one of its next hops and sends this node a MACT mes-
(a) Pruning of Multicast Group
Member
R
R
(b) Multicast Tree After
Prune

Figure

3. Unsubscribing from the Multicast Group.
sage with set Grpldr
ag, as is also described in section
2.5.2.
2.5. Multicast Tree Maintenance
Because the network nodes are mobile, links between
nodes are likely to break. A multicast tree is maintained
for the lifetime of the multicast group. Hence, there
must be a way of maintaining the tree after topological
changes in the network.
Multicast tree maintenance generally falls into one
of three broad categories: (i) link break and repair; (ii)
link break and subsequent network partition; and (iii)
tree merge after a network partition.
2.5.1. Repairing Link Breaks
Nodes determine that a link has broken in the same
way as described in [11], whether or not the link is part
of the multicast tree.
If the multicast tree has recently been used to send
data packets, then a node on the tree must hear each
of its next hops (except the node from which the
packet was received) retransmit a data packet within
retransmit time, generally three times the propagation
delay through a node. Because IP is a \best ef-
fort" network-layer protocol, a multicasting node does
not need to hear each of its next hops retransmit
each packet; it just must hear each next hop transmit
something within that time frame. This special
retransmit time is used because waiting the full
hello life time period to detect a broken multicast
tree link would often result in a large number of lost
packets.
When a link break on the multicast tree occurs, the
node downstream of the break is responsible for repairing
the link. A node knows it is downstream of the break
because it knows the direction of each of its next hops in
relation to the multicast group leader. Only the down-stream
node should initiate the repair; if nodes on both
sides of the break tried to repair the link, they might repair
the link through dierent intermediate nodes, thus
forming a loop. The downstream node initiates the repair
by broadcasting a RREQ with the Join
ag set
and with a special extension included. This extension,
called the Multicast Group Leader Extension, contains
a mgroup hcnt eld, which is set equal to the node's
current distance from the multicast group leader. In
gure 4(a), the downstream node sets this eld equal
to two, since it is two hops away from the group leader.
When this extension is included, only nodes that are
no farther from the group leader can respond. This
prevents nodes on the same side of the break as the
downstream node from responding to the RREQ, which
would form a loop. Because the two nodes are likely to
still be close by, the downstream node can set the initial
value of the RREQ to be small, thereby allowing
for a local repair and preventing the RREQ from being
broadcast across the entire network.
Because the RREQ has the Join
ag set, only a node
on the multicast tree can respond. When such a node
receives the RREQ with this extension eld, it checks
whether it is at least as close to the group leader as indicated
by the mgroup hcnt eld. If so, and if its record
of the group sequence number is at least as great as that
contained in the RREQ, it can reply to the RREQ by
unicasting a RREP back to the initiating node. RREP
forwarding and subsequent route activation with the
MACT message are handled as previously described.

Figure

4(b) illustrates the multicast tree after the repair
is completed.
E. Royer, C. Perkins / Transmission Range Eects on AODV Multicast Communication
R
R
R
Group Leader
Downstream Node
(a) Link Break
R
R
Group Leader
(b) Repaired Multicast Tree

Figure

4. Repair of Multicast Tree Branch.
Once the repair is nished, it is possible that the node
which initiated the repair is now a new distance from the
group leader. If this is the case, it must inform it down-stream
next hops of their new distance from the group
leader. The node creates a MACT message, sets the Up-
date
ag, and sets the hop cnt eld equal to its distance
from the group leader. It then multicasts this message
to the multicast group. When the downstream nodes
receive this message, they increment the hop cnt value
and then update their current distance from the group
leader. If they are not leaf nodes, they in turn send this
update message to their downstream next hops, and so
on. Because the MACT is multicast, the node that is
upstream of the multicasting node also receives the mes-
sage. In this case, it notes that the packet came from
its downstream link, and discards the message.
When a link break occurs, the node upstream of the
break also notices the disconnection. It is possible that
the tree branch will not be reconnected through that
node. If this upstream node is not a group member,
and if the loss of that link has made that node a leaf
node, it sets a prune timer to wait for the repair. This
prune timer should be longer than the route discovery
period in order to allow time for the repair to be com-
pleted. The new leaf node may prune itself after the
timer expires, if the next hop does not reactivate it (by
sending it a MACT message).
2.5.2. Network Partitions
If a node attempting to repair a broken tree link does
not receive a RREP within the discovery period, it re-broadcasts
its RREQ up to rreq retries more times,
using the same expanding ring search as indicated in
section 2.3.1. If no response is received after this many
attempts, the node must assume that the network has
become partitioned and that the multicast tree cannot
yet be repaired. If this is the case, the multicast tree
partition that was downstream of the break is now left
without a group leader.
If the node that was trying to repair the break is a
multicast group member, then it becomes the new group
leader. It broadcasts a GRPH message to announce the
group leader change, and sets the Update
ag in this
message to indicate that the change has occurred.
If the node that was trying to repair the break is not
a multicast group member, there are two possibilities.
The rst is that this node has only one downstream link.
If this is the case, then the link loss has made this node
a leaf on the tree, and so it can prune itself from the
tree. It unicasts its next hop a prune message, and then
deletes all the group information from its MRT. When
the next hop receives the prune message, it deletes the
sending node's next hop information from its MRT, and
notes that the message came from its upstream link. It
is then in the same position as the previous node. If it is
a group member, it becomes the new group leader. Oth-
erwise, if it has only one downstream next hop link, it
prunes itself from the tree along this link. This process
continues until a multicast group member is reached.
This node becomes the new group leader.
The second possibility is that the node that was trying
to repair the link has multiple downstream branches.
In this case, it cannot prune itself from the tree, because
doing so would disconnect the tree. It instead selects
any one of its downstream links, and unicasts that next
hop a MACT message with set Grpldr
ag. This
ag
indicates that the next group member to receive this
message should become the new group leader. After
unicasting this message, it changes the direction associated
with this next hop in its MRT so that the direction
R
R
Group Leader 1
Group Leader 2
Network Partition
(a) Partitioned Network before the Repair
R
R
R
Group Leader
(b) Reconnected Network

Figure

5. Merge of Two Components of Multicast Tree.
is now upstream. If the next hop to receive the MACT is
a group member, it becomes the new group leader. Oth-
erwise, it in turn chooses one of its downstream links,
and sends that next hop the MACT message with set
Grpldr
ag. It also updates the direction associated
with that next hop to be upstream. This process ends
once a multicast group member is reached.
Once the new group leader is determined, it broadcasts
a GRPH message with set Update
ag and incremented
group sequence number to announce its new
status as group leader.
2.5.3. Merging Two Disjoint Trees
Once a network partition has occurred, there are
two group leaders for the same multicast group, each
of which periodically broadcasts a GRPH message. If
the two network partitions come back into contact with
each other, group members learn of this occurrence
through the reception of a GRPH message that has
information about a new group leader. The two partitions
of the multicast tree must then be reconnected.
The only node which can initiate the repair of the tree
is the multicast group leader with the lower IP address.
This distinction is made because if more than one node
tried to repair the tree, it is likely that it would be repaired
through dierent intermediate nodes, and thus
form a loop.
When the group leader with the lower IP address
receives the GRPH, it creates a RREQ with set
Join and Repair
ags and unicasts this message to the
other group leader (GL 2 ), using the node from which
it received the GRPH as the next hop. As the RREQ
travels to GL 2 , nodes process the packet as they would
a regular RREQ with the following exception. If a node
that is a member of GL 2
's tree receives the RREQ, it
forwards the RREQ to GL 2 along its upstream multi-cast
tree link. This prevents the formation of routing
loops once the RREP is sent.
When GL 2 receives the RREQ, it notes the set Re-
ag, and creates a RREP to send back to GL 1 . It
sets the Repair
ag of this RREP, and then unicasts
the RREP back to GL 1 . It also updates the multicast
group sequence number by taking the larger of its record
of the group sequence number and that contained in the
RREQ, and incrementing this value by one. The next
time GL 2 broadcasts a GRPH message, it includes this
new sequence number value, and sets the Update
ag to
indicate a group leader change has occurred.
As the RREP travels back to GL 1 , nodes that receive
the RREP create the next hop entries and activate these
entries immediately. Because the RREQ was unicast,
there is only one potential tree branch being added to
the tree, and so a MACT message does not need to be
sent. Hence the next hop entry can be activated without
delay. If a node that is on the multicast tree of GL 1
receives the RREP message, it updates its group leader
information for that multicast group to re
ect GL 2 as
the new group leader. This node forwards the RREP
along its upstream tree link towards GL 1 to prevent
routing loops. It then changes the direction of that
link to downstream, and marks the link from which the
packet arrived as upstream. This link direction change
occurs because the new group leader is in a dierent
direction than the previous one. Once GL 1 receives the
RREP, it notes that it is no longer the group leader,
makes the link addition or direction change, and the
tree merge is complete. Figure 5 shows an example of
a tree repaired in this manner.
3. Data Packet Forwarding
Data packets destined for the multicast group are
transmitted as broadcast tra-c, unless there is support
for multicast at layer 2. When a node receives a multicast
data packet, it checks whether it is a part of the
multicast tree for that multicast group. If not, it discards
the packet. If it is a member of the multicast tree,
it then determines whether it has already received that
packet. Nodes on the multicast tree keep a record of the
source IP address, fragment id, and fragment oset of
the multicast data packets they receive. If this source
IP address/fragment id/oset combination is already
represented in their records, they discard the packet.
Otherwise, they create a new entry to represent the
packet. In this way, if the node later receives the same
data packet transmitted by another next hop, it knows
not to reprocess the packet. If the node has not already
received the data packet, the node processes the packet
if it is a member of the multicast group to which the
packet is addressed. Then, if the node is on the multicast
tree for that group, it forwards (by broadcast or
multicast) the packet to its next hops.
4. Simulations
The transmission range R xmit is a key parameter in
the interconnection pattern of a network. Its value affects
a wide range of results, including:
the neighbor degree of network nodes,
the throughput,
the probability of collision,
the contention for channel access,
battery lifetime of the transmitting node,
average number of hops, and thus the delay, for message
transmission,
and the impact of transmissions on neighboring
nodes.
In the following simulations, the eect of the transmission
range is studied on dierent network topologies.
To investigate the eect of the transmission range on
the AODV multicast protocol, a variety of results are
examined. First, the packet delivery ratio is calculated
by taking the number of data packets received, divided
by the number of data packets transmitted. Control
packets are not counted for the purposes of this calcu-
lation. The packet delivery ratio is a key indicator of
how well the protocol performs under the given condi-
tions. Since each data packet must be received by every
member of the multicast group, the packet delivery ratio
is then divided by the number of group members to
yield the normalized overall packet delivery ratio.
To understand the packet delivery ratio results, various
other results are examined. The average distance
from a multicast group member to the group leader
is directly aected by the transmission range. When
transmissions have relatively small range, the path
length to the multicast group leader is much longer.
Longer path lengths lead to a higher probability of a
packet collision before the packet reaches its destina-
tion, and also a higher probability of tree link breaks.
Both of these events result in a lower packet delivery
ratio. Since the amount of control message overhead is
directly related to the number of breaks in the multicast
tree, a shorter transmission radius is likely to result in
a greater amount of control tra-c.
A large transmission radius increases the average
number of neighbors per node. This leads to shorter
path lengths to reach multicast group members, but a
greater number of nodes receive each data packet broad-
cast. Consequently, there is an increase in battery utilization
at individual nodes, as well as an increase in
the likelihood of data packet collisions.
4.1. Simulation Environment
The simulations were performed using the GloMoSim
Network Simulator developed at UCLA [1]. This simulator
models the OSI network architecture and includes
models for IP and UDP. The simulator also allows for
network node mobility, thereby enabling simulation of
mobile ad hoc networks.
The MAC layer protocol used in the simulations is
the IEEE standard 802.11 Distributed Coordination
Function (DCF) [4]. This standard uses Request-To-
Send (RTS) and Clear-To-Send (CTS) control packets
for unicast data transmissions between neighboring
nodes. A node wishing to unicast a data packet
to its neighbor broadcasts a short RTS control packet.
When its neighbor receives the packet, it responds with
a CTS packet. Once the node receives the CTS, it
transmits the data packet. After receiving this data
packet, the neighbor then sends an acknowledgment
(ACK) to the sender of the data packet, signifying
reception of the packet. The use of the RTS-CTS
Parameter Name Meaning Value
allowed hello loss # of Allowed Hello Losses 2
group hello interval Frequency of Group Hello Broadcasts 5 sec
hello interval Frequency of Hello or Other Broadcasts 1 sec
hello life Maximum Time Allowed Between Hello Pkt Receptions 3 sec
pkt id save Time to Buer Data Packet
prune timeout Time to Wait to Receive a MACT before Prune 3 sec
retransmit time Time to Wait for Data Packet Retransmissions 750 msec
route life Time to Keep Reverse Route Entries 3 sec
rreq retries Max # of RREQ Retransmissions 2
route discovery timeout Max Time to Wait for a RREP 1 sec

Table
Simulated Parameter Values.
control packets reduces the potential for the hidden-
terminal problem [17]. Broadcast data packets and
RTS control packets are sent using the unslotted Carrier
Sense Multiple Access protocol with Collision Avoidance
(CSMA/CA) [4]. When a node wishes to broadcast
a packet, it rst senses the channel. If it does not
detect an on-going transmission, it sets a short timer
and then re-senses the channel once the timer expires.
If the channel is still idle, it broadcasts its packet. On
the other hand, if it does detect a transmission, it calculates
a backo time and then waits this amount of
time before reattempting the transmission.
The bandwidth for the simulations is 2 Mb/sec. The
propagation model used is the free space model [14] with
threshold cuto included in the GloMoSim simulation
package. The free space model has a power signal attenuation
of 1=d 2 , where d is the distance between nodes.
The radio model used also has capture capability, where
it can lock on to a strong signal during interference, and
still receive the packet. Other interfering packets with
weaker signal strength are dropped.
Node movement is modeled by the random direction
mobility model [15]. In this model, nodes are initially
placed randomly within the network simulation area.
Each node chooses a random direction between 0 and
360 degrees, and then selects a destination on the border
of the network area in that direction of travel. The
node then moves to that destination at its pre-assigned
speed (between 0 and 5 m/s). When the node reaches
its destination, it rests for seconds. It then chooses
a new direction, this time between 0 and 180 degrees.
The degree selected is adjusted relative to the boundary
on which the node is located. The node then resumes
movement. Except for the 0 m/s mobility scenario, this
movement model causes continual changes in the net-work
topology.
Each simulation simulates 300 seconds and models a
network of 50 nodes. During each simulation, there
is one multicast group which contains ten members.
Nodes join the multicast group at the beginning of the
simulation. Once all the nodes have joined the group
and the tree is formed, data transmission begins. Data
packets are sent by one of the group members at a
constant rate of eight packets per second throughout
the duration of the simulation. Each data packet is 64
bytes.
When a node receives a multicast data packet and is
a member of that multicast group, it sends the packet
to the application layer for processing and increments
its count of the number of data packets it has received.
It then rebroadcasts the packet. If the node is not a
member of the multicast group but is on the multicast
tree, it simply rebroadcasts the packet to allow reception
of the packet by its next hops. In order to achieve
100% packet delivery, every member of the multicast
group must receive the data packet. No layer 2 support
for multicast is assumed.
AODV does not guarantee packet delivery; however,
it does nd good routes for IP's best-eort delivery.
Because data packets are not buered for retransmis-
sion, losses can occur. If a collision involving a data
packet occurs at a node and the packet cannot be cap-
tured, the packet is lost. Typically, if a link break occurs
on the multicast tree, data packets are lost before that
break is noticed and while the link is being repaired.
Hence, it is essential to take steps to monitor multi-cast
tree links and provide for immediate repair so that
link breaks result in minimum packet loss. Unfortu-
)Packet
Delivery
200m
300m
400m
500m
(a) 1000m1000m Network
Packet
Delivery
200m
300m
400m
500m
(b) 1500m300m Network

Figure

6. Packet Delivery Ratio.
Speed (m/s)
Hops
200m
300m
400m
500m
(a) 1000m1000m Network
Speed (m/s)
Hops
200m
300m
400m
500m
(b) 1500m300m Network

Figure

7. Average Number of Hops to Multicast Group Leader.
nately, because multicast data packets are broadcast,
MAC layer feedback provides no notication of broken
links. For this reason, AODV provides a method
of monitoring these active links, as described in section
2.5.1.

Table

1 shows the essential parameter values for these
simulations. Note that the expanding ring search was
not used in the simulations.
There are two dierent network roaming areas simu-
lated. The rst is a 1000m1000m area, and the second
is a 1500m300m area. These two size areas have been
used in several other ad hoc network simulations [2,3,8].
They are modeled here to determine the eect of transmission
range in them.
In order to explore the eects of transmission range,
seven dierent ranges, from 200m to 500m, are studied.
Shorter than 200m, network connectivity is too sparse
for an accurate comparison, as network partitions oc-
cur. The results of the 450m and 500m simulations are
similar enough to be able to extrapolate the eects of
further increasing the transmission range. Each transmission
radius/speed combination was run for ten different
initial network congurations.
4.2. Results
First, consider the achieved packet delivery ratio.

Figure

6(a) shows the results in the 1000m1000m
area for the seven dierent transmission ranges mod-
eled, and illustrates how the packet delivery ratio is affected
by the changing speed of the network nodes. Figure
6(b) shows the same results for the 1500m300m
simulations. For both network congurations, an increase
in range yields an increase in the packet delivery
ratio, or the number of data packets received by
multicast group members. For the 1000m1000m net-
work, the increase in speed results in a decrease in the
packet delivery ratio for the more sparsely connected
networks. In the 1500m300m network, the increase in
speed has a smaller eect on the overall packet delivery

Repairs
200m
300m
400m
500m
(a) 1000m1000m Network
Repairs
200m
300m
400m
500m
(b) 1500m300m Network

Figure

8. Multicast Tree Repairs.
Speed (m/s)
Packets
200m
300m
400m
500m
(a) 1000m1000m Network
Speed (m/s)
Packets
200m
300m
400m
500m
(b) 1500m300m Network

Figure

9. Control Packet Overhead.
To understand why the packet delivery ratio is affected
by the transmission range, it is necessary to investigate
how the transmission range aects other aspects
of the network. Figures 7(a) and 7(b) illustrate
the eect of the transmission range on the average distance
of a multicast group member to its group leader.
The distance to the group leader gives an indication of
the size of the tree and how many hops data packets
must traverse between destinations. The gures indicate
that for smaller transmission ranges, the average
number of hops to the group leader is greater. A larger
distance to the group leader results in greater potential
for packet collisions, as well as a higher chance of link
breaks. Thus, a greater transmission range results in
fewer hops on the multicast tree, which produces a better
packet delivery ratio. It is interesting to note that
there is not a notable dierence in results between the
two network sizes.
Because the average path length to the group leader
is inversely proportional to the transmission radius, the
number of repairs to the multicast tree is also likely to
be inversely proportional. This is veried in gures 8(a)
and 8(b). These gures show the average number of
repairs needed to x broken multicast tree links during
the simulation. As expected, the number of repairs
increases for increasing speed. Also as expected, the
greatest transmission range requires the fewest number
of repairs, again resulting in a better packet delivery
ratio for these networks.
The amount of control overhead generated during the
simulation directly corresponds to the number of repairs
to the multicast tree. Figures 9(a) and 9(b) show
the number of control packets produced during each of
the simulations. The number of control packets represented
here is found by summing the number of RREQ,
RREP, MACT, and GRPH packets initiated. The g-
ures show a reduction in the number of control messages
as the transmission range is increased. For zero
mobility, there are no repairs needed to the multicast
tree.

Figures

9(a) and 9(b) indicate that the number
of control messages needed to initialize the multicast
tree is approximately constant at the dierent trans-
)Neighbors
200m
300m
400m
500m
(a) 1000m1000m Network
Neighbors
200m
300m
400m
500m
(b) 1500m300m Network

Figure

10. Average Number of Neighbors.
Speed (m/s)
Collisions
200m
300m
400m
500m
(a) 1000m1000m Network
Speed (m/s)
Collisions
200m
300m
400m
500m
(b) 1500m300m Network

Figure

11. Collisions.
mission ranges. The variation in control overhead becomes
more signicant once the nodes begin moving.
As nodes travel more quickly, there are more breaks and
repairs to the multicast tree, and hence there are more
control packets generated. Because there are fewer link
breaks for the longer transmission ranges, there are subsequently
fewer control packets generated in these simulations
as well. The 200m transmission range in the
1000m1000m network particularly suers from the increase
in mobility. The network topology and low connectivity
in this network conguration often result in
multiple attempts per repair to re-establish tree link
connections.
Having examined only these results, it appears that
increasing the transmission radius has a uniformly positive
eect on the network. A larger transmission radius
results in better packet delivery ratio, fewer link breaks
in the multicast tree, and less control overhead. How-
ever, it is also necessary to examine the impact that increasing
the neighborhood size has on the network. Increasing
the transmission range also increases the number
of neighboring nodes aected by each transmission.

Figures

10(a) and 10(b) indicate the number of neighbors
per node at the varying transmission ranges. For
the purpose of the gure, two nodes are considered to
be neighbors if the distance between them is less than
or equal to the given transmission radius. As would be
expected, the number of neighbors per node increases
with increasing transmission range.
One of the primary eects of increasing the size of the
neighborhood is the increase in the number of packet
collisions. Figures 11(a) and 11(b) illustrate the total
number of packet collisions in the networks. The
gures show that the number of collisions rapidly increases
as the transmission range grows. The number
of collisions with 450m and 500m transmission ranges
is nearly ve times that of the 200m transmission range
network.
To further explore the eect of the dierent neighborhood
sizes, the number of multicast data packets received
at nodes which are not group members is examined
in gures 12(a) and 12(b). At a packet transmission
frequency of eight packets per second and simulation
length of 300 seconds, just under 2200 data packets

Figure

12. Multicast Data Packets Received By Non-Group Members.
Speed (m/s)
Packet
Delivery
200m
300m
400m
500m
(a) 1000m1000m Network
Speed (m/s)
Packet
Delivery
200m
300m
400m
500m
(b) 1500m300m Network

Figure

13. Packet Delivery Ratio for Increased Data Rate.
are initiated during the simulation. The gures indicate
that for a transmission radius of only 200m, non-group
member nodes receive, on average, each multicast data
packet approximately twice. However, for the highest
mobility and transmission radius combination, nodes
receive each data packet approximately six times. Such
a redundancy in packet reception is likely to have quite
a negative eect on a node's battery lifetime, as the
node will spend a large percentage of its battery power
processing unnecessary packets. The higher nodal density
engenders additional contention for slotted MAC
schemes. This causes more collisions during the contention
period, resulting in increased queuing delays as
nodes are forced to wait longer periods of time between
packet transmissions.
The results presented so far are based on one source
with a moderate sending rate (eight packets per sec-
ond). To determine the interaction between transmission
range and network tra-c, a second set of experiments
was performed with the number of sources increased
to two and with each source sending 20 packets
per second. The data packet size in these simulations
is 512 bytes, as opposed to the 64 byte packets in the
previous experiments.
The packet delivery ratio for this set of experiments
is shown in gure 13. The results here dier from the
packet delivery ratio for the lower sending rate, shown
in gure 6. Here, it is no longer the case that the longest
transmission range produces the greatest packet delivery
ratio. The nodes in these networks are not able
to deliver as many data packets due to the increased
contention for channel access and the increased likelihood
of collisions. The transmission range of 400m
in the 1000m1000m networks and 400-450m in the
1500m300m network results in more delivered data
packets than does the 500m transmission range. The
ranges of 200m and 250m still produce the lowest packet
delivery ratio due to the lower connectivity in these networks

The control packet overhead for the increased data
rate is given in gure 14. These graphs do not vary
signicantly from the results shown in gure 9. The

Figure

14. Control Packet Overhead for Increased Data Rate.
Speed (m/s)
Collisions
200m
300m
400m
500m
(a) 1000m1000m Network
Collisions
Speed (m/s)
200m
300m
400m
500m
(b) 1500m300m Network

Figure

15. Number of Collisions for Increased Data Rate.
control tra-c in the 200 and 250m networks still dominates
in both network sizes.
Finally, the number of collisions is shown in gure 15.
Here, the results vary slightly from those in gure 11 for
the large transmission range. Except for the static net-
works, the number of collisions is greatest in the 450m
transmission range scenarios.
5. Future Work
Our work on multicast can be extended in many di-
rections. We would like to investigate larger node pop-
ulations, higher rates of mobility, and the eects of different
parameter settings. We would also like to investigate
algorithms for tunable power control. It is
possible that certain broadcast multicast transmissions
should be replaced by unicast (tunneled multicast) to
the appropriate neighbors in the multicast tree. We
would like to make the relevant comparisons and use
the results for possible revisions to the way that multicast
datagrams are handled. This information could
be incorporated into the AODV protocol operation for
multicast routing.
Other multicast algorithms for ad hoc networks have
been proposed [6,7,9]. We would like to compare the
power consumption vs. packet delivery ratio observed
for AODV against the performance of the other algo-
rithms. Feeney [5] has already made similar measurements
for unicast algorithms, and her techniques should
be easily adaptable to provide the necessary comparison
data for multicast algorithms.
Power control represents an interesting area of re-search
because the power level used at a mobile node has
the eect of dynamically creating or destroying links.
This dynamic link control can happen even without any
node movement. Thus, there are two interacting mechanisms
for changing the topology of the network. It
seems likely that, at certain times, a mobile node should
be able to benecially reduce its power consumption if it
has numerous links to nodes in its neighborhood. In this
way, it would be able to conserve power. Alternatively,
when the node has few other nodes in its neighborhood
and has a large percentage of its battery power remain-
ing, it might be useful for it to increase its transmission
range so that better network connectivity may be es-
tablished. Ramanathan and Rosales-Hain have made
steps towards this goal by developing a mechanism for
dynamically adjusting the transmitter power at individual
nodes in order to optimize the overall network
topology [13]. Their scheme is able to adapt depending
on the connectivity or bi-connectivity constraints.
The cases where battery power is diminished but
more network connectivity is needed are not handled
so easily. It is possible that AODV would benet
from acquiring information about neighborhoods once
removed. Such information may be useful for power
control algorithms. A more ambitious approach would
be an attempt to nd global information about links
that may become useful to unreachable nodes. Perhaps
exploratory, high-power probes should be transmitted
occasionally, to get rst-hand information about how
the local neighborhood connectivity could be improved
by the use of higher power for data transmissions.
6. Summary and Conclusions
In this paper, we have presented the AODV multicast
routing algorithm, and have shown the eects of various
transmission ranges and mobility rates on packet
delivery and the number of repairs needed for maintenance
of the multicast delivery tree. AODV handles the
transmission of multicast and broadcast data in a natural
way, maintaining compatibility with traditional IP
route table mechanisms and the needs of unicast packet
routing. The AODV routing protocol is able to provide
multicast communication between group members in a
variety of network congurations and mobility scenar-
ios. By building bi-directional multicast trees between
group members, AODV quickly connects group mem-
bers, and is able to maintain these connections through-out
the lifetime of the multicast group.
AODV's multicast routing algorithm is a straightforward
extension to the algorithm used to discover unicast
routes. The basic broadcast RREQ discovery mecha-
nism, with unicast RREP messages, is adapted for use
with multicast routing. Since the multicast IP address
is not allocated to any specic network node, the responsibility
for maintaining the sequence number for
multicast routes has to be assigned to a distinguished
node called the group leader. Aside from this, the main
dierence introduced by multicast routing is the need
for maintaining multiple next hops per multicast route
entry instead of just one next hop, as is the case for
unicast routing. Having multiple next hops also creates
new opportunities for route loops; however, this possibility
is eliminated through the use of a new message
type called the Multicast Activation (MACT) message.
This message enables just one of several possible multicast
tree paths; since only one path is enabled, route
loops remain impossible even for multicast routing.
The transmission range and network size are key determinants
of AODV's multicast performance. Increasing
the transmission range has many benets. The number
of links on the multicast tree is reduced, resulting in
fewer tree links which need to be maintained. Each multicast
tree link repair requires control message overhead.
Reducing the number of repairs has the advantage of
also decreasing the amount of control overhead. For
unloaded networks, the packet delivery ratio increases
for longer transmission ranges due to the reduction in
the number of hops between group members and the
longer-lived tree links.
Despite these advantages, a large transmission range
also causes more network nodes to be aected by multicast
data transmissions, even when the nodes do not
need to receive these packets. A large transmission radius
therefore drains the battery not only of the transmitting
node, but also of neighboring nodes within the
source's transmission range. Worse, a large transmission
radius reduces the eective bandwidth available
to the individual nodes and increases the number of
collisions seen throughout the network, as more nodes
are competing for and utilizing the same network band-
width. This increase in the number of collisions causes a
reduction in the packet delivery ratio for tra-c patterns
that signicantly load the wireless medium. Perhaps
most signicantly, increasing the transmission range
places disproportionately greater demands on the power
requirements of the (typically battery-powered) mobile
nodes. Thus, it is crucial for the consumer market to
nd ways to minimize power consumption.
We hope that this exploratory work on the relationship
between transmission ranges and multicast routing
performance will lead the way towards improving the
reliability of best-eort multicast packet delivery. We
conclude that the transmission range should be adjusted
to meet the targeted throughput while minimizing battery
power consumption. Our work shows that there
are opportunities for power savings when nodes can get
the same (or even better) performance by reducing the
power drain caused by unnecessarily high transmission
ranges.



--R

GlomoSim: A Scalable Network Simulation Envi- ronment
A Performance Comparison of Multi-Hop Wireless Ad Hoc Network Routing Protocols
Performance Comparison of Two On-demand Routing Protocols for Ad Hoc Networks
Access Control (MAC) and Physical Layer (PHY) Speci
An Energy Consumption Model of Performance Analysis of Routing Protocols for Mobile Ad Hoc Networks.

A Lightweight Adaptive Multicast Algorithm.


A Highly Adaptive Distributed Routing Algorithm for Mobile Wireless Networks.

Ad hoc On-Demand Distance Vector (AODV) Routing
Topology Control of Multihop Wireless Networks using Transmit Power Adjust- ment
Communications
An Analysis of the Optimum Node Density for Ad hoc Mobile Networks.
Multicast Operation of the Ad-hoc On-Demand Distance Vector Routing Protocol
Packet Switching in Radio Channels: Part-II - The Hidden Terminal Problem in Carrier Sense MultipleAccess Models and the BusyTone Solution
--TR
A performance comparison of multi-hop wireless ad hoc network routing protocols
Scenario-based performance analysis of routing protocols for mobile ad-hoc networks
Multicast operation of the ad-hoc on-demand distance vector routing protocol
An energy consumption model for performance analysis of routing protocols for mobile ad hoc networks
Communications
Ad-hoc On-Demand Distance Vector Routing
A Highly Adaptive Distributed Routing Algorithm for Mobile Wireless Networks

--CTR
L. Lloyd , Rui Liu , Madhav V. Marathe , Ram Ramanathan , S. S. Ravi, Algorithmic aspects of topology control problems for ad hoc networks, Proceedings of the 3rd ACM international symposium on Mobile ad hoc networking & computing, June 09-11, 2002, Lausanne, Switzerland
L. Lloyd , Rui Liu , Madhav V. Marathe , Ram Ramanathan , S. S. Ravi, Algorithmic aspects of topology control problems for ad hoc networks, Mobile Networks and Applications, v.10 n.1-2, p.19-34, February 2005
ad hoc networks;mobile networking;multicast;wireless networks