Exploiting Congestion Information in Network and Higher Layer
Protocols in Multihop Wireless Ad Hoc Networks
Yih-Chun Hu David B. Johnson
University of California, Berkeley Rice University
yihchun@cs.cmu.edu dbj@cs.rice.edu
Abstract
With most routing protocols for ad hoc networks, shorter
paths are generally considered more desirable, making
some areas of network more prone to congestion and de-
creasing overall network throughput. In this paper, we
examine the use of congestion information to a void these
network hotspots. By locally monitoring the network inter-
face transmission queue length and MAC layer behavior at
each node, a node can establish an approximation of the
degree to which the wireless medium around it is busy; this
measurement reflects not only the behavior of the node it-
self, but also the behavior of other nearby nodes sharing the
wireless medium. We suggest a number of uses of such con-
gestion information in an ad hoc network, in the network,
transport, and higher layers, and we evaluate a set of such
uses through simulation. Our results based on modifica-
tions to the Dynamic Source Routing protocol (DSR) and
TCP demonstrate substantial performance improvement in
terms of scalability, packet delivery, overhead, and fairness
resulting from this use of congestion information.
1. Introduction
In a multihop wireless ad hoc network, mobile nodes coop-
erate to form a network without the use of any infrastructure
such as access points or base stations. The mobile nodes,
instead, forward packets for each other, allowing nodes be-
yond direct wireless transmission range of each other to
communicate. The mobility of the nodes and the funda-
mentally limited capacity of the wireless medium, tog ether
with wireless transmission effects such as attenuation, mul-
tipath propagation, and interference, combine to create sig-
nificant challenges for network protocols operating in an
ad hoc network.
In most ad hoc networks, some areas of the network have
higher packet forwarding loads than other areas. For exam-
ple, in a network where the nodes are uniformly distributed
This work was supported in part by NSF under grant CCR-0209204,
by NASA under grant N AG3-2534, and by a gift from Schlumberger to
Rice University. The views and conclusions contained here are those
of the authors and should not be interpreted as necessarily representing
the official policies or endorsements, either express or implied, of NSF,
NASA, Schlumberger, Rice University, Carnegie Mellon Uni versity, the
University of California, or the U.S. Gov ernment or any of its agencies.
in space, the nodes near the center of the network will tend
to carry a higher load when the network routing protocol
prefers shortest-path routes; this preference can make cer-
tain areas prone to congestion and can decrease the over-
all network throughput. Although some Quality-of-Service
routing protocols have been proposed that can often route
around areas of congestion, these protocols are more com-
plex than traditional routing protocols. In addition, many of
these protocols only find routes for flows requiring specific
QoS parameters. In this paper, we design some lightweight
mechanisms for detecting network congestion and for ex-
ploiting this information to improve protocol performance
and behavior for all types of traffic at the network, trans-
port, and higher protocol layers.
The parameters for measuring local network conges-
tion around a node depend largely on the MAC layer, and
many different wireless MAC layers, based on methods
such as random access, TDMA, and polling, have been
proposed and implemented. In this paper, we focus on
the IEEE 802.11 Distributed Coordination Function (DCF)
MAC protocol [12], since it has been adopted as a wire-
less LAN standard and is widely used in both traditional
wireless systems and in multihop ad hoc networking re-
search. Our techniques using MAC layer utilization infor-
mation could also be applied easily with similar random ac-
cess collision avoidance wireless MAC protocols such as
MACA [20] and MACAW [2], and could be adopted with
other types of MAC protocols as well.
The specific network and transport layer protocols we
use in this paper are the Dynamic Source Routing proto-
col (DSR) [16–18] and the TCP transport protocol [24].
We make use of wireless medium congestion information
to improve routing decisions in two areas: first, we modify
DSR’s Route Discovery to prevent the discovery of routes
over which it is undesirable to carry additional traffic since
the wireless medium over those hops is already quite busy,
and second, we use this congestion information to control
the use of certain routing protocol optimizations in DSR
such as packet salvaging. Finally, we also use our conges-
tion information at each node to influence the setting of the
Explicit Congestion Notification (ECN) bits [25] in the IP
header of packets carried through portions of the network
where the wireless medium is particularly busy; this use
Proceedings of the 24th International Conference on Distributed Computing Systems (ICDCS’04)
1063-6927/04 $20.00 © 2004 IEEE
of ECN allows higher layer protocols such as TCP to also
make use of this congestion information.
In Section 2 of this paper, we define our measurement of
congestion at a node, and we suggest a number of uses of
this information in the ne twork , transport, and highe r layer
protocols within the ad hoc network. Section 3 provides
an overview of the operation of the DSR protocol, which
we use in our evaluation of exploiting congestion informa-
tion in routing and higher layers. In Section 4, we define
the example modifications to DSR and TCP that we sim-
ulated in order to quantify the effectiveness of these tech-
niques. Section 5 describes the methodology of our sim-
ulation evaluation, and Section 6 presents our simulation
results. Finally, in Section 7, we present conclusions.
2. Congestion Information
In this section, we describe in detail one method for ob-
taining wireless congestion information each node. We
also discuss a range of general possible uses of conges-
tion estimates in routing and higher layer protocols within
a node; Section 4 later describes three specific uses of such
measurements within the context of the Dynamic Source
Routing protocol (DSR) and TCP, and Section 5, evaluates
these three techniques in detail through simulation.
2.1. Measuring Congestion
We use two metrics to measure the level of congestion at
a node. The first metric is the average MAC layer utiliza-
tion level at a node, which indicates the degree to which
the wireless medium around that node is busy or idle. We
define the average MAC layer utilization as measured by a
node to be the fraction of time during which that node either
(1) has one or more packets to transmit in its transmission
queue for that network interface, or (2) if that node had at-
tempted to transmit, it would not have b een able to do so
then, according to the rules of the MAC layer at that node.
Since the instantaneous MAC layer utilization at a node is
either 0 or 1, we average this value over a period (10 sec-
onds, in our simulations) to obtain an indication of the use
of the wireless medium around that node.
The intuition behind this definition of MAC layer uti-
lization is that the instantaneous value of this metric should
be 0 only when the wireless medium around the node is
available for the node to begin transmission of a new packet
not already in that node’s network interface transmission
queue. Measuring this value requires the node to moni-
tor the state of its own MAC layer. Although many cur-
rent wireless network interface products such as commonly
available IEEE 802.11 wireless LAN cards do not provide
a MAC layer interface to support this monitoring by the op-
erating system software in the node, it is supported by some
interfaces such as the DARPA GloMo Radio API [1], and
additional future wireless products may provide such an in-
terface if it is proven usefu l.
As an example of measu ring MAC layer utilization, we
simulate it in this paper based on a detailed model of the
IEEE 802.11 DCF MAC protocol [12]. We consider instan-
taneous MAC layer utilization level at a node to be 1 at any
time that the MAC layer at that node either detects physi-
cal carrier to be present or is deferring due to virtual car-
rier sensing, interframe spacing, or backoff. Instantaneous
MAC layer utilization at the node is also 1 at any time that
the node has at least one packet in the transmission queue
for its wireless network interface.
The other metric we use is the instantaneous transmis-
sion queue length. In certain cases, a node may not be ex-
periencing much MAC layer congestion, but instead may
have many packets backlogged. If that node is then chosen
to forward other packets, it will increase packet latency, and
may even drop packets due to a limit on the queue length.
In our simulation, we use a combination of the MAC layer
utilization and instantaneou s queue length metrics to deter-
mine the congestion level at each node.
2.2. Uses within the Network Layer
Within the network layer, one use of congestion measure-
ments is to allow the routing protocol to attempt to affect
the routes chosen, such as to avoid choosing routes through
congested portions of the network. Routing protocols for
ad hoc networks can be grouped into two types: proac-
tive (or periodic) protocols, and reac tive (or on-demand)
protocols. In a proactive routing protocol, nodes exchange
routing information with each other (e.g., periodically) such
that each node attempts to always know a current route to
all possible destinations (e.g., [19, 22]). In contract, nodes
using a reactive routing protocol do not exchange routing
information until necessary, and instead attempt to discover
all routes on-demand by an active search within the network
(e.g., [17, 23]). Hybrid routing protocols that combine these
two approaches are also possible (e.g., [10]).
In a proactive routing protocol, nodes can affect the
routes chosen by the p rotocol by using the congestion in-
formation to alter the metric for certain routing table entries
that it exchanges with other nodes. For example, in a dis-
tance vector routing protocol, the node could include an ex-
pression of its congestion level in each of its own routing
advertisements; neighbor nodes receiving such advertise-
ments could u se this value to treat the link from this node
as having a metric that is a function of the advertised con-
gestion level, rather than as is common, treating each such
link as having a metric of 1. For a link state routing proto-
col, a node could use its local measurement of congestion
level similarly to increase the metric that it includes for its
neighboring links in its own routing updates to other nodes.
In a reactive routing protocol, nodes can affect the routes
chosen by the protocol through changes in the operation
of the dynamic route discovery process. We describe this
approach in the context of DSR in Section 4.1. In a hybrid
Proceedings of the 24th International Conference on Distributed Computing Systems (ICDCS’04)
1063-6927/04 $20.00 © 2004 IEEE
routing protocol, a node may naturally use a combination
of mechanisms using congestion level measurements, based
on either the proactive or reactive portions of the hybrid pro-
tocol, to affect the routes chosen.
Another use of congestion level measurements within the
routing protocol at a node is to modify in general the behav-
ior of the routing protocol itself, based on the level to which
the wireless medium around the node is busy. For example,
depending on the congestion measured by a node, optional
features or optimizations within the routing protocol can be
enabled or disabled, if their effectiveness might depend on
whether or not the wireless medium around the node is par-
ticularly busy. We describe a specific example of this type
of optimization in Section 4.2 in th e context of DSR.
Another example of such protocol modification would
be an adaptive distance vector routing proto col, in which
a node modifies the periodic transmission of its own rout-
ing advertisement packets. If the wireless medium around
the node is particularly busy, the node could reduce the fre-
quency of its own advertisements, and could reduce the
number of routing table entries included in each adver-
tisement to include only the most important or most re-
cently changed entries. The ADV ad hoc network routing
protocol [3] performs similar adaptive optimizations, but
the adaptation in ADV is based on “trigger meter” values
that use network layer information, not information adapted
from both the MAC and routing layers as we propose here.
As a final example in this section, the AODV routing
protocol [23] could be modified such that a node does not
attempt local route repair when the wireless medium around
the node is particularly congested. If a node attempts and is
successful at local repair, then the route to that destination
will continue to pass through that node. If instead, in such
cases, the node simply treated the link as broken as normal,
the new route discovered for that destination could be made
to route around that area of the network, when combined
with modifications to Route Discovery similar to those we
define in Section 4.1.
2.3. Uses within the Transport Layer
Within the transport layer, a number of different uses
of congestion level measurements at a node are possible.
Section 4.3 describes one approach in detail for TCP, based
on setting the Explicit Congestion Notification (ECN) bits
in a packet’s IP header [25]; this same approach would also
be applicable for any other transport layer that supported
use of the ECN bits [7]. Below we suggest some other pos-
sible uses within the transport layer for congestion measure-
ments.
Beyond setting ECN bits to improve TCP performance,
it may be possible to use information about the congestion
levels at nodes along a multihop ad hoc network route to al-
low TCP to gain additional information about network con-
ditions. Such information about the degree to which the
wireless medium around nodes is busy might enable TCP
to react better by helping to differentiate conditions of wire-
less packet loss, congestion packet loss, or simple wireless
medium contention-based packet delay.
As a final example of use at the transport layer, the IETF
Reliable Multicast Transport (RMT) Working Group, in at-
tempting to standardize reliable multicast for the Internet, is
considering solutions based on negative acknowledgements
and on positive acknowledgements [14]. Each of these ap-
proaches represents a tradeoff of factors such as overhead
and latency; with additional information such as congestion
level measurements, it might be possible to adaptively bal-
ance between these two approaches.
2.4. Uses within Other Higher Layer Protocols
Above the transport layer, information on the congestion at
a node or along a path, as suggested in Section 2.3, can
be used to adapt some traditional functions of of the pre-
sentation layer, such as data compression. If the congestion
level indicates that the wireless medium is particularly busy,
a sending node could decide to compress the data before
transmission. Such use of compression represents a trade-
off between the bandwidth used for transmission versus the
CPU time consumed for compression and decompression
and the latency in time taken for these functions. Based on
the measured congestion level, a sending node could more
productively make such tradeoff decisions.
If an application programming interface (API) is avail-
able to pass the congestion information to u ser-level pro-
grams, these measurements could also, for example, be used
to aid middleware application adaptation systems such as
Odyssey [21] and Puppeteer [6].
3. Overview of the DSR Protocol
This section provides an overview of the Dynamic Source
Routing protocol (DSR) [16–18], which we use in our eval-
uation of exploiting congestion information. DSR is one of
a number of routing protocols proposed within the Mobile
Ad Hoc Networks (MANET) Working Group of the Internet
Engineering Task Force (IETF) [13]. We use DSR in our
study, since the protocol has been shown to perform well
in earlier simulation studies [5, 15]; DSR is an on-demand
(or reactive) ad hoc network routing protocol. As suggested
in Section 2.2, similar techniques using congestion infor-
mation could be applied to other ad hoc network routing
protocols.
The operation of DSR is based on source routing,in
that the sender of a data packet determines the complete se-
quence of hops to be used as the route for that packet to its
destination. In the basic version of DSR, the source route
for a packet is represented in the header of the packet, al-
though a enhancement to DSR uses implicit source routing
to avoid this overhead in the header of each packet [11].
Instead, after the first packet containing a full source route
Proceedings of the 24th International Conference on Distributed Computing Systems (ICDCS’04)
1063-6927/04 $20.00 © 2004 IEEE
has been sent along the route to the destination, subsequent
packets need only contain a flow identifier to represent the
route, and nodes along the route maintain flow state to re-
member the next hop to be used along this route based on
the address of the sender and the flow identifier; one flow
identifier can designate the default flow for this source and
destination, in which case even the flow identifier is not rep-
resented in a packet.
DSR divides the routing problem in two p arts: Route
Discovery and Route Maintenance, both of which operate
entirely on-demand. In Route Discovery, a node actively
searches through the network to find a route to an intended
destination node. While using a route to send packets to the
destination, Route Maintenance is the process by which the
sending node determines if the route h as broken, for exam-
ple because two nodes along the route have moved out of
wireless transmission range of each other.
A node that has a packet to send to a destination searches
its Route Cache for a route to that destination. If no cached
route is found, the sending node initiates Route Discovery
by broadcasting a R
OUTE REQUEST packet containing the
destination node address (known as the ta rget of the Route
Discovery), a list (initially empty) of nodes traversed by
this R
EQUEST,andarequest identifier from this source
node. The request identifier, the address of this source node
(known as the initiator of the Route Discovery), and the tar-
get address together uniquely identify this Route Discovery.
A node receiving a R
OUTE REQUEST checks to see if it
has previously forwarded a R
EQUEST from this Discovery
by examining the IP Source Address, target address, and re-
quest identifier, If it has recently seen this identifier, or if
its own address is already present in the list in R
EQUEST of
nodes traversed by this R
EQUEST, the node silently drops
the packet. Otherwise, it appends its address to the node list
and forwards the R
EQUEST.WhenaREQUEST reaches the
target node or a node with a route to the target in its Route
Cache, this node returns a R
OUTE REPLY to the initiator of
the R
OUTE REQUEST.TheREPLY contains a copy of the
node list from the R
EQUEST, and can be delivered to the
initiator node by reversing the node list, by using a route
back to the initiator from its own Route Cache, or “piggy-
backing” the R
EPLY on a new ROUTE REQUEST targeting
the original initiator. When the initiator of the request re-
ceives the R
OUTE REPLY, it adds the newly acquired route
to its Route Cache for future use.
In Route Maintenance, a node forwarding a packet for
a so urce attempts to verify that the packet successfully
reached the next hop in the route. A node can make this
confirmation using a link-layer acknowledgement (such as
is provided in IEEE 802.11 [12]), a passive acknowledge-
ment [19], or by means of a network-layer acknowledge-
ment. A packet is possibly retransmitted if it is sent over
an unreliable MAC, although it should not be retransmitted
if retransmission has already been attempted at the MAC
layer. If a packet is not acknowledged, the forwarding
node assumes that the next-hop destination is unreachable
over this link, and sends a R
OUTE ERROR to the source of
the packet, indicating the broken link. A node receiving a
R
OUTE ERROR removes that link from its Route Cache.
A number of optimizations to the basic DSR protocol
have been proposed [18]. In this paper, we describe only
those optimizations that are affected by the changes we
make to the protocol. One example of such an optimization
is packet salvaging. When a node forwarding a packet fails
to receive acknowledgement from the next-hop destination,
as described above, in addition to sendin g a R
OUTE ERROR
back to the source of the packet, the node may attempt to
use an alternate route to the destination, if it knows of one.
Specifically, the node searches its Route Cache for a route
to the destination; if it finds one, then it salvages the packet
by replacing the existing source route for the packet with the
new route from its Route Cache. To prevent the po ssibility
of infinite looping of a packet, each source route includes
a salvage count, indicating how many times the packet has
been salvaged in this way. Packets with salvage count larger
than some predetermined value cannot be salvaged again.
4. Evaluation within DSR and TCP
This section describes the specific uses of congestion mea-
surements tha t we examined to illustrate the effectiveness
of reacting to congestion information within DSR and TCP
in an ad hoc network. We modified the protocol behavior
based on a combination of two metrics, the measured level
of MAC layer utilization at a node and the network inter-
face transmission queue length at that node; the interface
queue length is the number of packets waiting buffered at
that node for transmission over its wireless network inter-
face. The first of these metrics provides the node with a
view of the current condition of the shared wireless medium
around the node; the second indicates a prediction of the fu-
ture load that this node will place on the wireless medium.
We invoked each protocol optimization when either of these
levels exceeded the threshold chosen for that particular op-
timization.
4.1. Modifications to DSR Route Discovery
In Route Discovery in DSR, a node performs a con-
trolled flood of the network with R
OUTE REQUEST packets,
searching for a route to the target destination node. When
one of the R
OUTE REQUEST packets from this Route
Discovery reaches the destination node or reaches another
node with a route to the destination cached, this node re-
turns a R
OUTE REPLY packet to the originator of the Route
Discovery.
Allowing this flood of R
OUTE REQUEST packets from
a Route Discovery to traverse an area of the network in
which the wireless medium is already particularly busy cre-
ates several risks. First, the additional broadcast packets
Proceedings of the 24th International Conference on Distributed Computing Systems (ICDCS’04)
1063-6927/04 $20.00 © 2004 IEEE
from the Route Discovery flood further increases the use
of the wireless medium in those areas. Second, the route
discovered by a Route Discovery is the sequence of hops
through which the R
OUTE REQUEST packet was forwarded
that generated the R
OUTE REPLY in response, and thus,
any route discovered by forwarding a R
OUTE REQUEST
through an area of the network in which the wireless
medium is already particularly busy can only result in a
discovered route through this same area; such routes are
less desirable than other routes. Finally, the additional traf-
fic resulting from a new flow of data packets using a route
through such an area can cause the wireless medium in this
area to be used even more heavily, possibly leading to per-
formance degradation for all users.
To alleviate these problems, we explored the effect of
modifying DSR so that nodes do not process or forward a
R
OUTE REQUEST packet if the node determines that the
wireless medium around itself is too busy; however, if the
node is the target of the R
OUTE REQUEST, it processes it
and returns a R
OUTE REPLY as usual.
This optimization is simple to implement, although in
this form, it has two limitations. First, it may cause a node
to be unable to discover a route to some destination, even
when a route actually exists, if the only existing routes go
through busy areas of the network. Second, by forcing the
Route Discovery to route around busy areas, it may cause
a node to discover a route that is longer than the minimum
number of hops that could have b een discovered; in saving
overhead within busy areas of the network, this optimiza-
tion may create additional overhead totaled across other ar-
eas of the network.
A modification to this optimization that could be made
to address these limitations, is to add a flag to each R
OUTE
REQUEST, indicating whether or not to use this optimiza-
tion. A node that has a packet to send to a destination would
first check its Route Cache, and if it did not have a route,
would initiate a Route Discovery with the flag off; th at is,
such that nodes in busy areas would not forward R
OUTE
REQUEST packets from that Route Discovery. If the source
node does not receive a R
OUTE REPLY from that Discovery,
it would initiate an other Discovery, this time turning the flag
on, allowing all nodes to forward R
EQUESTS belonging to
this Discovery. This modification is somewhat similar to
an expanding ring search, although the search here expands
into busy areas rather than simply into areas at a greater hop
count from the source. In our simulation, we did not imple-
ment th is modification to the Route Discovery optimization,
since the performance of ordinary Discovery was sufficient.
4.2. Modifications to DSR Packet Salvaging
In DSR, packet salvaging is a mechanism used by an in-
termediate node to avoid dropping a p acket when it detects
that the n ext hop for the packet along its original route is
broken. The intermediate node opportunistically checks its
own Route Cache for a route to the packet’s destination,
contributing its own cache information to enhance the prob-
ability of su ccessful delivery of the packet.
However, the route that this intermediate node may se-
lect from its own Route Cache for salvaging may not be
a valid route to the destination, since the Cache is not ac-
tively maintained and some nodes may have moved since
this route was cached. Packet salving usually is beneficial,
though, because the nodes involved may not have moved
extensively recently and because nodes update their Route
Cache with routing information in forwarded and overheard
packets, but in some cases, the extra overhead caused by for-
warding the packet along the new route may not be worth
the chance that the packet will be delivered correctly rather
than just being dropped.
We explored the effect of modifying packet salvaging to
not salvage a packet at an intermediate node (and to drop the
packet instead when the next hop on the original route has
broken) if the wireless medium around the node is particu-
larly busy. This condition is an indication that attempting to
salvage the packet may create more harm than good, since
sending the packet along the new route will add more over-
head to the wireless medium in the area.
This modification to packet salvaging also addresses two
related potential problems with salvaging in this situation.
First, at a node where the wireless medium has been par-
ticularly busy, packets which could otherwise have been
overheard may have a higher chance of loss, due to fac-
tors such as collision and increased noise floor. As a result,
such a node will have been able to overhear less routing
information from other packets and may thus have lower-
quality rou tes in its Route Cache for any routes for which
it is not directly involved in forwarding, making salvaging
in this case even less desirable. Second, when a node at-
tempts to transmit a packet to a next-hop node that is no
longer a neighbor, an RTS packet is repeated several times
(when using a MAC protocol like IEEE 802.11); each of
RTS packets causes this node’s neighbors to sense virtual
carrier for the intended duration of the intended data packet.
If several RTS attempts are made before determining that
the link to the next hop has broken, possibly further increas-
ing congestion around those nodes.
4.3. Use within TCP
Ramakrishnan and Jain [26] proposed Explicit Congestion
Notification ( ECN) as a mechanism for signaling con-
gestion, in packets traversing congested nodes or links.
Floyd [8] presented a mechanism to use the ECN mecha-
nism to improve the performance of TCP.
We made use of ECN as a mechanism for an interme-
diate node to signal to the TCP sender that the wireless
medium around the node is particularly busy. Using ECN
for TCP provides two benefits: first, it may prevent the loss
Proceedings of the 24th International Conference on Distributed Computing Systems (ICDCS’04)
1063-6927/04 $20.00 © 2004 IEEE
