Вы находитесь на странице: 1из 13

An Improved Geocast for

Mobile Ad Hoc Networks

Robert J. Hall, Member, IEEE Computer Society
AbstractGeographic addressing of packets within mobile ad hoc networks enables novel applications, including hard real-time
engagement simulation in military training systems, geographic command and control functions in training and emergency
communications, and commercial messaging applications as well. The most scalable implementation of geoaddressing is via a
geocast protocol, where nodes selectively retransmit packets based on local decision rules. Well-designed retransmission heuristics
yield scalable geographic flooding that outperforms alternative geoaddressing approaches. However, previous geocast
implementations, while effective, fall into two categories. Approaches based on flooding are unscalable due to the high load they
generate. Scalable approaches, on the other hand, have trouble in complex environments, lacking sufficient intelligence about the
necessary directionality of packet flow. The present paper defines a novel geocast heuristic, the Center Distance with Priority (CD-P)
Heuristic, which both significantly improves on reliability of existing scalable geocasts and yet also remains scalable as scenario
complexity increases. This paper describes the new technique as well as an evaluation study comparing it to previous approaches.
Index TermsGeocast, MANET, scalability, wireless.

EOGRAPHIC addressing within mobile ad hoc networks
(MANETs [1]) enables interesting new applications.
These include hard real-time engagement simulation in
military training and testing systems, geographic command
and control in areas lacking network infrastructure, emer-
gency communications for disaster response, and commer-
cial geographic messaging applications, such as gaming,
advertising, and traffic services [2]. In engagement simula-
tion by geometric pairing, as is done by the US Armys
One Tactical Engagement Simulation System (OneTESS),
www.peostri.army.mil/PRODUCTS/ONETESS, an instru-
mentation system mounts sensors and a wearable, location-
aware computational device on each human trainee and
weapon. When a trigger is pulled, instead of firing live
rounds, the device sends electronic bullet messages from
the shooter to all nodes in the geographic region defined
by the weapons effect area. The recipients respond with
their positions, and an adjudicator decides who is actually
hit by the simulated round [3], [4]. This geometric pairing
has potential to significantly improve upon laser-based
systems in the variety of weapons that can be simulated as
well as the real-world fidelity of the simulation. Key to this
hard real-time process is the geoaddressing of the electro-
nic bullet message. In geographic command and control
applications, a mobile node wishes to discover and initiate
communications with all nodes in a defined geographic
area at the current time, even when the sender has no
knowledge of which nodes currently occupy the area. This
capability also depends on geoaddressing of packets both
to become aware of which nodes are present and to
establish routes. For example, one could establish commu-
nications with mobile devices in a burning building at a
disaster site in this way.
MANETs for military training must operate at an
unprecedented network scale (up to 10,000 mobile nodes)
without installed infrastructure. Disaster situations can lead
to the need for scalable communications in densely
populated areas with absent or malfunctioning network
infrastructure. Commercial applications must operate in
crowded situations, such as shopping malls, sporting
events, school campuses, and city streets. These types of
situations result in geo-addressing applications stressing
the scale limits of traditional MANET technologies.
The most scalable, responsive, and reliable implementa-
tion of geo-addressing in MANETs is via a geocast protocol,
where location aware nodes broadcast and selectively
rebroadcast packets based on local decision rules. Ap-
proaches based upon simple flooding [5], [6], where every
node within a forwarding zone retransmits every packet,
are well known not to scale beyond a few tens of MANET
nodes [4]. By contrast, geocast based on well-designed
retransmission heuristics yields a limited and scalable
geographic flooding [4]. Geocast also outperforms the
better-known alternative geoaddressing approach based
on caching location information at georouters [7]. In
MANETs, georouters become hotspots [3] and require
strictly better connectivity than geocast (i.e., all nodes must
be connected to the georouter in addition to each other).
Two previous MANET geocast approaches are limited in
meeting the needs of reliable high-scale applications. The
approaches of Ko and Vaidya [5] (discussed below) do not
scale adequately. On the other hand, Tiered Geocast [4]
does scale, but has trouble in complex environments,
lacking sufficient intelligence about the necessary direction-
ality of packet flow. For example, the maze-like character of
. The author is with AT&T Laboratories Research, 180 Park Ave, Bldg 103,
Florham Park, NJ 07932. E-mail: hall@research.att.com.
Manuscript received 27 Apr. 2009; revised 31 Aug. 2009; accepted 28 Feb.
2010; published online 25 Aug. 2010.
For information on obtaining reprints of this article, please send e-mail to:
tmc@computer.org, and reference IEEECS Log Number TMC-2009-04-0145.
Digital Object Identifier no. 10.1109/TMC.2010.56.
1536-1233/11/$26.00 2011 IEEE Published by the IEEE CS, CASS, ComSoc, IES, & SPS
urban Manhattan-style geometries presents difficulties due
to the need for precise selection of relay points. The present
paper makes three primary novel contributions:
. a novel Geocast, based on a new heuristic, the Center
Distance with Priority (CD-P) Heuristic,
. a flexible framework for integrating geocast heur-
istics, including the previously studied M and
T heuristics, with CD-P (and others), and
. an evaluation study comparing CD-P to existing
geocast heuristics and showing empirically that it
outperforms them, while still scaling well. This
study compares many different combined parameter
settings, showing how the integration of heuristics
can lead to better performance on many scenarios.
Throughout this paper, we assume that each mobile node is
location aware, meaning it knows its location at all times, such
as via an onboard GPS unit. Geocast is a network protocol for
sending a packet to all nodes within a defined geographic
region termed as the geocast region. Hall and Auzins [4]
describe a multitiered framework for geocast in MANETs.
The framework comprises a heuristic-based limited flooding
technique, termed a flat geocast, that operates within each
single tier, a tier being a distinct wireless channel. Typically,
distinct tiers will operate at different transmission ranges; for
example, in a military scenario, it may be that vehicles have
two-tier radios capable both of operating on a short-range
channel shared with equipment carried by dismounted
soldiers and also of operating on a longer range channel to
communicate at distance to other vehicles or buildings. In
this way, long-distance geocasts can travel most of the way
via long-range hops on the long-range tier, but still reach
destinations containing short-range-only capable nodes. A
node receiving a packet on a given tier submits it to flat
geocast independently in each tier for which it has an
interface, so the packet may be bridged between tiers at
multi-interface nodes. All flat geocast parameters are defined
independently for each tier. The purpose of having multiple
tiers is to enable long-distance traffic without excessive hop
counts as well as to increase spatial reuse of spectrum.
Spectrumreuse is increased by sending local traffic only over
the short-range tier, avoiding transmitting such messages
unnecessarily over long ranges. By improving a flat geocast,
one, therefore, improves tiered geocast as well. The present
work improves flat geocast by defining a new heuristic. To
understand this, we must first recall the particular flat
geocast approach used, which we term as the Classic Geocast
framework (cf. [4]).
The packet j contains a geocast header containing
information needed for propagating the packet, including
an application type, a geocastID (q11j)), location of sender,
and the center of the targeted geocast region, CG1j). The
application type is used as an index to determine the values
of geocast parameters to use with the packet, including
forwarding zone definitions and parameter values govern-
ing the heuristics. The geocast ID is a unique identifier
assigned by the originator of the geocast and is carried in
each transmission associated with that particular geocast.
The Classic Geocast framework operating at each node is
diagrammed in Fig. 1. When the node receives a packet from
the medium, it checks to see if it has heard one previously
having the same geocast ID. If not, it creates a new record for
the ID and enqueues the packet for (possible) later
retransmission; however, in either case, it updates its
statistics on the packet in the record for the geocast ID.
Any packet received from the local application software via
the network API is allocated a new geocast ID and treated
accordingly by the framework. When a packet reaches the
head of the queue and is ready to be transmitted, ready
meaning any backoff interval has expired and the mediumis
free, a heuristics check is performed. If passed, the packet is
transmitted, otherwise discarded. This late cancelation (i.e.,
checking heuristics after backoff and medium free) allows
the node to suppress extraneous copies of a packet by
reacting to information in the most recent transmissions.
This is critical to geocast scalability.
To allow combining heuristics f/
g, the framework
employs the following structure for the heuristics check,
where j is the packet that is ready to be transmitted:
1o::j 1i1nd7oic?j ^ /
j _ /
j _ . . ..
First, the node must be located physically in the forwarding
zone defined by js application type and other header
information. There are many ways of defining forwarding
zones (e.g., see [5]) appropriate to different assumptions
about terrain, scenario distances, etc. These may differ
based on what application the particular message type is
designed to support, such as long-range artillery simulation
versus short-range command and control. Next, it must
pass at least one of the f/
g heuristic predicates. Of course,
we assume that the stats recording routine keeps informa-
tion necessary to support each of the f/
g. We also assume
that there is an /
which is true whenever the packet is
originated by the node, ensuring that each packet is
transmitted by its originator. We suppress this detail in
what follows.
This framework can be instantiated to yield many
existing geocast types. For example, if all /
are FALSE,
Fig. 1. Classic Geocast framework.
then we get a simple broadcast for each geocast, with no
retransmissions. This is scalable, but unreliable. If, on the
other hand, /
j TRUE, we get simple flooding re-
stricted to forwarding zones. This is exactly the basic Ko-
Vaidya geocast [5]. It is reliable, but unscalable, resulting in
far too many retransmissions per geocast.
Between these two extremes is the flat geocast defined by
Hall and Auzins [4]. They show it to be more reliable than
simple broadcast and more scalable than simple flooding. It
uses two primary heuristics: MinTrans (M) and Threshold
(T). The M Heuristic, /
, counts the number of transmis-
sions heard for each geocast ID. /
is TRUE if and only if
this count is less than the ` parameter. Thus, a node will
retransmit the packet if it has not already heard ` copies.
M is valuable in adding pure redundancy to the propaga-
tion to help combat problems, like collisions, as well as to
help the propagation get out of local minima it might,
otherwise, be stuck in by hill climbing directly toward the
destination (as with the CD heuristic below).
The T Heuristic, /
, is based on the location of each
transmission heard. /
j is TRUE iff the closest among all
transmitters of packets r with gIDr gIDj are at least a
distance T away from this node. T is valuable for spreading
the geocast propagation outward to cover distant areas that
may not have been covered, the idea being that if a node is
relatively far from all previous transmitters, it is more likely
to cover nodes around corners or out of transmission range
of prior transmissions. It pushes outward and can help
geocast propagation get out of local minima.
Fig. 2 shows the transmission sequence for Classic
Geocast (` 2, T 40% of radio range) in a simple
situation with one radio obstacle. The forwarding zone is
elliptical and the geocast region is circular. The geocast
originator is node B. The first transmission reaches nodes A
and C. Node A is out of the forwarding zone, so it does not
retransmit. Because of the M Heuristic, node C does, with
nodes D and E hearing it. These are the nodes in the geocast
region, so they process the packet. However, due to the M
Heuristic, D also retransmits it. E does not. (Ds transmis-
sion was too close for /
, and E had already counted two
transmissions, so /
was not satisfied either.) Forwarding
zone flooding would have led to nodes B, C, D, and E
retransmitting, while simple broadcast would have had
only B transmit, with D and E failing to receive it at all. By
contrast, (` 2. T 40%) avoids exhaustive retransmis-
sions while still traversing the obstacle.
As discussed in [4], Classic Geocast is effective in a wide
variety of situations, more scalable than simple flooding,
and more reliable than simple broadcast. However, recent
experience has exposed a weakness in urban terrain. The
latter is characterized by restricted, maze-like radio lines of
sight (due to buildings, etc.) and multipath effects.
Fig. 3 shows an example urban scenario. In it, nodes are
located in streets and avenues of a Manhattan-style
geometry; the dark squares represent buildings that com-
pletely block radio signals from penetrating through them.
(Thus, connectivity is purely line-of-sight.) The transmis-
sion range of each radio is assumed to be three blocks; so,
for example, node 1 can hear node 3 and vice versa. We
attempt to send a geocast from the node at third and A to
the dark circle centered at first and B. A typical Classic
Geocast transmission sequence is shown. Transmission 1 is
from the originator. It is heard by everyone on A Avenue.
Due to the M Heuristic, transmission 2 is sent from a node
on A between first and second, as shown. Finally, since the
node below first on A is beyond the T Heuristic distance, /
causes transmission 3 as shown. All three transmissions are
heard only by nodes on A Avenue. Unfortunately, nodes off
of A Avenue did not hear them, so the geocast fails to reach
the geocast region.
One can compensate for this within Classic by either
increasing M or decreasing T; however, while increasing
success rate these also increase transmissions. The main
contribution of this paper, the (CD-P) Heuristic, solves this
problem more cost effectively, resulting in a more reliable
Fig. 2. Classic Geocast transmission sequence.
Fig. 3. A geocast difficult for Classic Geocast to handle.
and less costly geocast that also scales up. This section
describes CD-P in two steps.
Step 1: The Center-Distance (CD) Heuristic. To support
the CD Heuristic, we first augment the statistics collection
process as follows: each time a node hears a transmission of
a geocast packet j for geocast ID i, it calculates the distance
from the transmitter of j (whose position is in the geocast
header) to the center of the geocast region CG1j). If this
distance is the least of all such distances for all transmis-
sions it has heard with geocast ID i, then it is recorded.
Denote this recorded minimum value C1i:ti).
Next, we add a new heuristic predicate /
into the
outgoing heuristics check logic shown in Fig. 1. /
j is
true if and only if the nodes own distance to CG1j) is less
than CDist(i). This is added into the Classic Geocast
disjunction, so the other heuristics still operate as well:
InFwdZone?j ^ /
j _ /
j _ /
To illustrate how this helps, Fig. 4 shows a typical
transmission sequence for the same scenario as before, but
with nodes executing the CD heuristic as well. This time,
the first three transmissions are the same as before.
However, the node at first and A realizes that even though
T and M Heuristics do not fire, it is closer to CG1j) than
the previous three transmitters, so it transmits. This is heard
by the nodes on first Street, fulfilling the geocast.
Scalability Problems. As described thus far, the CD
heuristic is similar to Ko and Vaidyas Scheme 2 [5]. The
difference is that under their scheme, the node compares its
own center distance only to that of the transmitter it heard
first. In CD, we compare to all transmitters heard of the
present geocast. This leads to fewer copies of the packet
being transmitted, and hence, better scalability.
However, both approaches still have significant scal-
ability problems. Consider Fig. 5. In this situation, once the
originator transmits, all other nodes in line of sight will
judge themselves closer to the CGR than the originator.
Under Ko-Vaidya Scheme 2, they will all decide to transmit,
so there will be as many transmissions as simple flooding,
which is impractical for more than a few nodes as the
number of transmissions scales up.
Using the CD Heuristic, on the other hand, this flooding
will not occur for a single transmission. Suppose that there
are i nodes, and that the MAC layer implements fair access
to the medium, i.e., each node that is ready to transmit has
an equal probability of being the one to transmit. Because
CD bases its transmit decision on all copies of the packet it
has heard (not just the first as in Ko/Vaidya Scheme 2), each
transmission effectively prevents all transmissions from
nodes to its left in the figure. After the originator transmits,
fair medium access implies that the expectation value of the
number of transmissions prevented by the second transmis-
sion is %i,2, so the number of nodes that could possibly
transmit third is %i,2. Similarly, the third transmission will
be expected to prevent %i,4, leaving %i,4 candidates for
the fourth, etc., until N is the only candidate after %lg i
1 steps. Thus, for a single transmission, on average, we
expect Olg i retransmissions.
So far so good, but there is a more subtle problem that
arises when there is more than one geocast originated
concurrently. For illustration, suppose that all nodes
originate distinct geocasts to the geocast region shown.
All such geocasts will result in node N transmitting, as it is
closest to CGR among all nodes in line of sight of origin. N
will, therefore, have to transmit all geocasts, resulting in a
long queue wait at N. If the queue is FIFO at N, then each
geocast will have a long wait, on average. Consider also the
node immediately to Ns left. This node will also transmit
all geocasts except those for which N happens to transmit
first. Since N is slow, this will be most geocasts.
Continuing this reasoning leftward in the diagram, we see
that each node will transmit all geocasts not transmitted
first by a node to its right. This leads to a quadratic total
number of transmissions for i geocasts.
Fig. 6 illustrates the order of transmissions for CD. In this
five-node example, which uses a random (but fixed, for
illustration) medium-access order (DBECA), each node
initiates one geocast to the circle during a given time unit.
Above each node is the order of processing of packets
(lowest first). Circled nodes are actually transmitted, while
Fig. 4. The geocast of Fig. 3 propagated using the center-distance
Fig. 5. Example showing that CD does not scale well in all cases.
lined out nodes are canceled by the heuristic. By canceled,
we mean that the heuristic predicate /
is false, so the
framework does not transmit the packet. For this example,
we assume the Classic Geocast heuristics (M and T) are not
operating. The subscript numbers indicate transmission
order. Thus, at the outset, each node places its geocast in its
queue; packet a in As queue, b in Bs, etc. Since the random
medium-access order dictates D goes first, D transmits
packet d first. (All of nodes A-E hear each of each others
transmissions in this example.) Packet d is placed in the
queue at each other node, as shown, behind the one already
present. Next in the medium-access order, node B transmits
packet b, the second overall transmission, with b being put
into the queue at each other node. Next in the order, E
transmits its packet e, then C transmits c, and A transmits a.
Each of these packets is enqueued at each of the other nodes
when it is heard. After these first five transmissions, D gets
to transmit again; this time (the sixth overall transmission)
its copy of packet b. Since it is closer to CGR(b) than B itself,
it is not canceled. Next, node B accesses its queue but,
because it is farther from CGR(d) than D itself, it cancels its
copy of packet d. Similarly, it cancels its copies of e and c as
well. However, it finds it is closer to CGR(a) than A, so it
transmits a as the overall seventh transmission. Next in line,
E dequeues and transmits its copy of d, since it is closer to
CGR(d) than node D. Proceeding in this way, C transmits a,
A transmits nothing since it has canceled all other packets
(due to being farthest away), etc.
For the example of Fig. 6, CD produces 14 transmissions
altogether: E transmitted all five packets, D transmitted
four, C and B two each, and A one. Note the tendency of
packets to pile up in the queues of nodes closer and closer
to CGR.
Among all possible medium-access orderings, CD can
produce as few as 9 or as many as 15. While this example
illustrates merely one medium-access order, it is chosen
because it is representative of the average case. To
investigate the average case, we created a small study of
the linear scenario of Fig. 5, but generalizing to i nodes (for
2 i 71). In this study, instead of a fixed access order,
the simulation uses a completely random and fair medium-
access scheme. That is, each time the medium becomes free,
all nodes having a packet to transmit have equal probability
to be the next to transmit. The upper curve in Fig. 7 shows
the results for CD. It graphs transmissions (averaged over
100 runs for each i) versus number of nodes. The marked
points are the simulation results, while the dashed curves
are close-fit descriptions. Clearly, CD results in approxi-
mately 0.25ii 1 transmissions for an i-node linear
scenario, as i gets large, which is i
The evaluation study in the next section provides more
empirical evidence that this CD scalability problem is not
merely theoretical, and that it arises commonly in dense
scenarios. Of course, the case of all geocasts being directed
to the same geocast region is special; however, dense
scenarios often have many instances of these (overlapping
in space and time) as subscenarios.
Step 2: Adding Priority Queuing. To ultimately solve
this scalability problem, the CD-P Heuristic imposes the
additional condition that each node prioritizes its transmit
queue (cf., Fig. 1) by center-distance improvement. For each
packet in a nodes transmit queue, we assign it a priority
Prio as follows: first, any nongeocast packet, such as unicast
traffic, and any geocast packet, which has not been
transmitted at all yet, have 1iio 0. For geocast packets
j, let dj be the distance from the node to CG1j). Then,
1iioj max0. C1i:tq11j dj.
Thus, the greater the improvement (i.e., reduction of
distance to CGR), the higher the priority, and hence, the
sooner the packet will be transmitted.
Intuitively, we wish to transmit sooner those packets that
can most quickly move toward the centers of their geocast
regions. Heuristically, this is because the greater the
progress toward the center, the more other nodes will be
suppressed due to being farther from center.
Fig. 8 illustrates the transmissions resulting from the
same five-node example as above using the CD-P queue
Fig. 6. Example CD transmission order: each node A. . . . . E originates
one geocast to the lower right circle.
Fig. 7. Simulation results for CD and CD-P in i-node instances of the
linear scenario of Fig. 5.
prioritization (and the same medium-access order). The
behavior using CD-P is very different. First, even though
each node enqueues its own packet first, it is not necessarily
the first the node transmits. For example, node E transmits
its copies of packets b, c, d, and a before transmitting its
own (e). This is because the priority of e is zero, while the
priorities of those other packets are greater than zero. The
scenario proceeds as follows: first D transmits its packet
because it is first in the medium-access order. Next, B
transmits b, canceling its copy of d, since d was already
transmitted closer to CGR(d). Next, E transmits its copy of
b, not its own packet, e, and not d either because b is of
higher priority by virtue of the amount of progress toward
CGR (b) being larger than the progress achieved by
transmitting (d). Next, medium-access order is C, which
has canceled its own copies of b and d, so transmits c. Next,
A transmits its own packet, having canceled b, c, and d. D
gets its second turn at the medium and transmits its copy of
a, since that is of higher priority (for it) than c. B has nothing
left to transmit at this point, so E proceeds to transmit c,
which is highest priority among {a, c, d, e}. Note that since a
was transmitted by D, a has dropped in priority below c. At
this point, nodes A, B, C, and D have empty queues, so E
proceeds to transmit the remainder in priority order: d, a,
and, finally, e. This scenario illustrates the nodes transmit-
ting earlier the packets that can cancel the most other
packets at other nodes sooner (e.g., E choosing c at step 7
instead of the others). Overall, CD-P produces 10 transmis-
sions, four fewer than CD produced.
In general, CD-P improves dramatically on CD for these
linear scenarios. The lower curve inFig. 7 shows the results of
simulating CD-P in the linear scenarios. The data points
converge very closely to the function 0.77ilg i, which grows
muchmore slowlythanthe quadratic growthof the CDcurve.
We have focused here on the linear scenarios to illustrate
both the operation of CD-P and its differences with CD as
well as the subtle scalability problem of CD and the fact that
CD-P solves it. The general case, of course, will have more
and varied communication patterns, so one naturally
wonders if, when packets are targeted to many geocast
regions, will the mechanism still work and have the
same benefits? Of course, one can always construct worst-
case scenarios where the more general case reduces the
advantage of CD-P. However, the more interesting question
is how CD-P behaves compared to CD and other scalable
approaches (like probabilistic geocast) in a representative
set of situations. The simulation study in the next section
addresses this.
Implementation Issues. Implementing CD-P and Classic
Geocast over an unaltered IP stack is problematic. This is
because once one commits a packet to the IP system, it
cannot be canceled. Immediately after receiving the first
transmission, having not had time to hear any others, all
nodes in an area would naively commit retransmissions to
IP, resulting in all of them retransmitting. This leads to
unacceptable flooding of every packet. To counter this, one
introduces a randomized transmit delay; that is, each node
waits a random amount of time before committing the
retransmission. This allows latter nodes an opportunity to
hear earlier retransmissions and avoid committing their
own. While this works to reduce transmissions, these
random delays must be on the order of many packet
transmission times (e.g., between 2 and 100 ms), leading to
significantly larger average latency than is possible with a
custom implementation. Note also that once the packet is
committed to IP, there is no way to recompute its priority
on hearing other transmissions. This leads to an approx-
imation to CD-P that can make it less effective.
In previous work, a colleague and I have simulated this
application layer geocast implementation (M and T heuristics
only) and shown that the key transmissions per geocast
statistic rises, placing much stronger limitations on scaling.
In addition, a set of first prototypes using this implementa-
tion were field-tested [8] and shown to bear out these
simulation results: while flooding is avoided, the transmis-
sions per geocast rises by a factor of 2 or more for scenarios
involving up to 70 nodes. End-to-end latency also increases.
These studies motivate a tighter implementation. The
preferred implementation, and the one simulated below, is
to alter the standard 802.11 MAC layer (or indeed whatever
MAC layer one is interested in using) to provide a late
cancelation hook: this is a callback that is executed immedi-
ately prior to start of transmission; if the callback returns 0,
the transmission is canceled. We use this hook to call our
heuristics check (Pass(p) above). Priority queuing requires
another alteration to the standard IP stack. As defined, the
priority is recomputed as each packet is about to leave the
queue, because priority values depend on how close to CGR
all prior transmissions heard took place. Thus, the normal
IP queuing code must be altered to do the priority-based
selection specified above. A new prototype embodying this
preferred implementation is currently being built.
To evaluate scaling and reliability, and to compare to other
geocast approaches, we have implemented a simulation
Fig. 8. The example of Fig. 6 showing CD-Ps transmission order: again
A. . . . . E originate one geocast each, but CD-P uses fewer transmissions
than CD.
model of wireless MANETnodes running Classic Geocast [4]
and both the CD and CD-P heuristics. This model runs in the
QualNet simulator (scalable-networks.com), using
QualNets 802.11b PHYlayer model with a simulated2 Mbps
channel. QualNets 802.11b MAC layer model has been
altered to implement the Geocast framework as described
above, including late cancellation and prioritization.
4.1 Scenario Selection
We have selected 14 scenarios covering a range of complex-
ity measures in numbers of nodes, terrain complexity, and
traffic load. These scenarios represent realistic battlefield
training scenarios envisioned for the OneTESS system, as
well as more abstract random node placements and traffic.
The geocasts in the training-like scenarios are used to
implement engagement simulation of long-range shots, as
well as geographic command and control messaging. Rather
than describing each scenario in detail, we summarize them
in Fig. 9. In the figure, each scenario (numbered 1 . . . 14) is a
numbered box, with number of mobile nodes in the scenario
in parentheses. The position of the box semiquantitatively
represents its position in two other complexity dimensions.
The horizontal position indicates its terrain complexity.
This includes the number of terrain obstacles as well as
geometric relationships among nodes. That is, a scenario
appears farther to the right if it has more radio-blocking
obstacles, and/or less connectivity between nodes due to
distance separation. The vertical axis represents offered load
(geocasts/s). A conscious attempt was made to cover all
combinations of the complexity dimensions.
Each of the 14 scenarios was based on one of the five
geographic layouts depicted in Fig. 10. In all the figures, the
dark gray rectangles (or squares) represent radio-blocking
terrain obstacles, such as buildings or hills. The dots
represent wireless nodes. Thick dark arrows indicate
general direction of node motion during the scenario. (In
layouts d and e, node motion is random, which is not
shown.) The thin arrows that point to circles show typical
geocasts with geocast regions, for illustration; there are far
more geocasts in the scenario than are shown. Area
dimensions are given as nidt/ /ciq/t.
With reference to the horizontal axis of Fig. 9, layout e is
of low complexity, because there are no radio obstacles and
connectivity is high. Layouts a, b, and d are of high
complexity for those scenarios in which geocasts must
traverse long distances, because such geocasts must be
routed around many obstacles and around connectivity
gaps. However, scenario 8 uses layout b and scenario 7 uses
d but these are only of medium complexity, because their
geocasts are biased toward shorter distances. Finally,
layout c is of high complexity, because the geocasts must
traverse physical gaps via long paths around empty
regions. Note that while packets cannot reach horizontally
across the large gaps, the nodes are still completely
connected, because those at the top are within radio range
of some near the top of the central group.
For each geocast, the sender and targeted geocast regions
were chosen in one of two ways. For scenarios 2, 3, 8, 9, 10,
11, 12, and 14, geocasts were those sent during a realistic
OneTESS (simulated) training scenario. These were based
on layouts a, b, and c. The mobility model for these
scenarios was produced by domain specific behavior
generators [9] that modeled realistic movement for the
scenario type. In particular, they attempted to represent
realistic node motion seen in military training; nodes
representing dismounted soldiers executed biased random
walks at an average speed of 2 m/s, while vehicles followed
scripted paths at speeds from 0 m/s to 40 m/s. For the other
six scenarios (based on layouts d and e), geocasts were
generated randomly in two ways: some were generated
uniformly randomly among nodes, while others were
random but biased toward longer (longer than 500 m)
distances. In general, geocast regions were selected to
contain at least one node. Node motion in these scenarios
was a biased random walk between 0 and 2 m/s.
In summary, eight scenarios were based on realistic
usage of real-world, high-scale MANET application (mili-
tary training), while the others are intended to represent
other high-scale applications, such as emergency command
and control messaging, commercial gaming, advertising, or
traffic services. The six nonmilitary scenarios take place
either in a modeled urban area (layout d) or in an open area
such as a marketplace, sporting event, or fairground
(layout e). The geocast patterns in the military scenarios
are chosen to be realistic for the training application, with
both light and heavy traffic rates represented. The geocast
patterns in the other scenarios are either uniformly random
or else random but biased toward longer distances
(increasing the effective complexity of the terrain).
Each scenario was run 36 times (36 separate parameter
settings), for a total of 504 simulation runs. The 36 represent
the cross product of ` 2 f0. 2. 4g, T 2 f1. 40%. 20%. 10%g,
CD 2 fon. offg, and CD-P 2 fon. offg, except that CD and
CD-P were never both on at the same time. M and T are
the Classic Geocast MinTrans and Threshold parameters. T
values are expressed as a percentage of the modeled radio
range. Modeled radio range was 500 m for these runs. In
what follows, the notation i. t. c refers to the parameter
setting with ` i and T t, and c indicating which CD
Fig. 9. Properties of scenarios used in case study; each box represents
one scenario, with the box containing the scenario number above the
number of mobile nodes.
heuristic is active: c NoCD ) both are off; c CD ) CD
is on and CD-P is off; and c CD-P ) CD-P is on and CD
is off.
4.2 Metrics
In the study, we measured Success% of Feasible (Success%)
and Latency. Success% measures the fraction of feasible
geocasts that reached the target node. For this study, we
designated the node closest to the center of the geocast
region as the target node for the geocast. As mentioned
above, each geocast has at least one node in the geocast
region, so the target node is well defined for all geocasts. A
geocast is feasible if and only if a network path exists from
sender to target node at time of sending. Latency measures
average elapsed time from first transmission to reception by
the target node for successful geocasts. The goal of a geocast
implementation is high Success% with low Latency.
4.3 Results
Fig. 11 shows Success% over all geocasts and all scenarios.
Each data point is the result for a particular parameter
setting. The horizontal axis shows variation in settings of M
and T. The middle curve (with diamond-shaped markers)
groups settings with neither CD nor CD-P on (notated
NoCD). The upper curve (squares) groups all settings
with CD-P on. The lower curve (triangles) connects settings
with CD on.
This graph clearly shows that 0. 1. CD-P performs
best. Its result (93.3 percent) is 21.8 percent above the best
NoCD setting 2. 40. NoCD and 12.7 percent above the best
CD setting, 0. 1. CD. Moreover, as M and T are varied by
moving to the right, increasing redundancy, the CD-P
settings are consistently more than 10 percent higher than
Fig. 11. Success% of all geocasts in all scenarios for distinct parameter
settings; uppermost curve is for CD-P.
Fig. 10. Geographic layouts of the five terrain types underlying the 14 scenarios used in the evaluation study.
the CD settings and 20 % higher than all CD settings but
the first. This suggests that CD-P should be on by default.
One may wonder why Success%of CD-PandCDdecrease
with decreasing T or increasing M (e.g., 0. 1. CD-P versus
(0, 40, CD-P)). One might think that by increasing redun-
dancy, one should increase success. This need not always be
true, however, because increased redundancy leads to more
collisions and medium contention, which can reduce
success. A related puzzle surrounds CDs behavior. Since
priority queuing is added primarily to improve scaling
behavior, why does adding it also improve reliability? The
answer is the same as above: CD results in so much extra
traffic that collisions and medium contention lead to more
lost geocasts. This is where our evaluation study benefits
from using a high fidelity simulator capable of modeling
realistic MAC and queuing behavior. These effects are less
likely to be detectable in contention-free perfect-MAC
While encouraging, these aggregate statistics could be
misleading, if performance is erratic across scenarios. To
investigate this, Fig. 12 graphs Success% versus scenario
number for six selected individual parameter settings. The
three groups connected by solid lines are settings with CD-P
on. The three dashed curves are for NoCD settings. Here
again, even though it is not the best for all scenarios,
0. 1. CD-P is consistently high for all 14 scenarios. The
NoCD settings are high for some, but dramatically poor for
others. In order to rank settings relative to one another, we
computed the deficit score for each. The deficit score for a
parameter setting P on a scenario S is the average difference
between the best Success% on S among all settings and the
Success% of P on S, averaged over all scenarios S where P
does not score the highest score. Table 1 shows the rankings
of selected parameter settings. The table shows that
0. 1. CD-P has highest Success% on 8 of 14 scenarios,
while it averages only 2.15 percent below the highest on the
other 6. The best NoCD setting here is 0. 40. NoCD which
ties for best on only two scenarios and averages 19.82 percent
below the best on the other 12. Note that all CD-P settings
rank higher than all NoCD settings. This is further evidence
that CD-P should be used by default. Note, however, that
there do exist scenarios, such as #7, where a NoCD setting
slightly outscores all CD-P settings. CD-P does compara-
tively better than NoCD in more complex terrain, because it
uses the hill-climbing heuristic to add valuable transmis-
sions that the NoCD heuristics do not add, while the priority
queuing acts to avoid the scalability problems that can arise
from pure CD. NoCDs tend to do well in lower terrain
complexity and under higher load. Lower terrain complex-
ity means that geocasts require fewer relays to complete,
whereas high load means that the extra transmissions CD-P
adds tend not only to be superfluous but to cause a small
amount of collision loss.
The combination of M and T with CD-P (2, 40, CD-P)
outperformed CD-P alone on scenarios 8, 9, and 10. As
terrain complexity increases, hill climbing tends to get stuck
in local minima; as long as traffic is not too high, M and T
can help avoid such problems.
Fig. 13 is similar to Fig. 12, replacing NoCD curves with
CD curves. CD performs better than NoCD did, but CD-P
significantly outperforms CD on 7 of 14 scenarios (2, 6, 7, 8,
9, 12, 13). Referring to Fig. 9, these are precisely the higher
Fig. 12. Success% of geocasts in each scenario, with each curve
showing performance of a single parameter setting; dashed curves are
NoCD settings and solid curves are CD-P settings.
Rankings of Parameter Settings (See Text)
Fig. 13. Same as Fig. 12, but dashed curves represent three CD
load scenarios. The best CD setting, 0. 1. CD, has a deficit
score of 14.35 percent. These data show that CD does not
scale well under load, and that CD-P significantly improves
upon it.
Finally, Fig. 14 graphs average latency for three settings,
each, respectively, having the best Success% among either
NoCD, CD, or CD-P. With only one exception (scenario
#12), CD-P has lower or equal latency than the others. CD
has by far the worst latency. Averaging these across all
geocasts of all scenarios for each of the three settings, we
obtain 774 ms for 2. 40. `oC1, 780 ms for 0. 1. CD-P,
and 8,724 ms for 0. 1. CD. Note that CD-P manifests a
91 percent decrease compared to CD, illustrating another
way in which CD-P scales better than CD.
Note that node mobility does not significantly affect the
performance of CD-P, as shown by the consistently high
Success% and low Latency across all scenarios in Figs. 12
and 14. This is not surprising, given its stateless design.
Unlike many geographic routing approaches (Section 5), it
does not depend on cached topology information that
becomes inaccurate as nodes move.
4.4 Summary: Why Does It Work?
This study suggests that CD-P outperforms both NoCD and
CD. In particular, the 0. 1. CD-P setting is ranked highest
under the criterion of Table 1. In addition, it also
demonstrates that CD is inefficient as scenario complexity
scales up, whereas adding priority queuing to form CD-P
fixes that problem. As can clearly be seen from Figs. 12 and
9, the dominance of CD-P over NoCD is large for
scenarios 8-14, which are precisely the set with higher
terrain complexity, meaning that for geocasts to complete,
they must avoid many obstacles (or coverage gaps) by
following the right relay chains. NoCD has no built-in
routing knowledge that could enable it to find paths
through obstacles, whereas CD-P (and CD) uses a hill-
climbing style of search that does much better. Comparing
Figs. 12 and 9, the dominance of CD-P over CD is large for
scenarios 2, 6, 7, 8, 9, 12, and 13, which are precisely those
with highest offered loads. (Note that these are also the ones
where CDs latency becomes a problem as well; see Fig. 14.)
Here, priority queuing reduces traffic redundancy (from i
for CD to lg i per geocast for CD-P in relay chains) and
concomitant contention-related losses resulting from high
loads. This bears out the scalability behaviors illustrated in
Section 3, so the study has borne out that this problem does
arise commonly, does lead to scalability problems for CD,
and is solved by priority queuing (and even though not all
geocasts go to the same place).
4.5 Threats to Validity
An empirical study is limited by its selection of scenarios. We
have attempted to span wide ranges of complexity in at least
offered load, terrain, numbers of nodes, and selection of
endpoints. Of course, as a prediction about the real world, a
simulation study is limited by its chosen level of abstraction.
While this papers QualNet-based simulations are relatively
realistic, Geocast implementation, nevertheless, must be
done carefully in order to achieve similar results.
Geographic routing protocols fall into two broad classes:
those that do not require current neighbor-topology in-
formation and those that do. Generally, topology-based
approaches suffer from three drawbacks in the high-scale
scenarios of interest in this paper. First, we seek scaling to
high geographic density; since topology-packet traffic grows
in proportion to density, this overhead can become
prohibitive. Second, we seek scaling to medium and high
levels of node mobility. This leads to topology information
rapidly becoming stale, which tends to mislead the
algorithms relying on it. Finally, topology-based approaches
depend on link symmetry: if a node hears a packet from a
neighbor, the assumption is that it can be heard by the
neighbor as well. However, this assumption is often not
satisfied due to differences in equipment characteristics
(e.g., antenna), differing battery levels, and radio propaga-
tion phenomena like multipath effects. Several of our
applications of interest (such as military ones) require
robust propagation even under such conditions. Thus, the
primary competitors to our CD-P with Classic framework
are the topology-free approaches. These are most likely to be
applicable to our high-scale application areas of military
simulation, geographic command and control, emergency
messaging, and commercial applications. However, for
completeness, we review several of the others as well.
5.1 Topology-Free Approaches
In a previous paper, Hall and Auzins [4] showed that
Classic Geocast far outperforms simple flooding. (As
mentioned previously, simple flooding is easily emulated
in the Classic Geocast framework; see Section 2.) Even for
moderately scaled scenarios, smaller than some of those
used in this paper, the success% of feasible is drastically less
for simple flooding (e.g., 25 percent on one scenario) than
for Classic Geocast (85 percent on the same scenario). For
larger scenarios, the difference (2 percent for flooding and
99 percent for Geocast) is much larger. This reliability
difference is due to a drastic difference in (re)transmissions
per message: e.g., 220 for flooding versus 11 for Classic
Geocast on the smaller scenario. (Refer to [4] for full details.)
The study in [4] shows that Classic Geocast scales
Fig. 14. Latency comparison for three settings, one CD-P, one CD, and
one NoCD; lower values are better.
significantly better than simple flooding, while the present
paper shows that CD-P shares similar scaling advantages
and improves reliability over (NoCD) Classic Geocast.
As discussed previously, CD is similar to, but more
efficient than, Ko and Vaidyas Scheme 2 [5], which does
not allow a closer retransmission to cancel other repetitions
of a geocast. This leads to higher traffic and worse scaling
than CD and, hence, CD-P as well.
Heissenbuttel et al. [10] describe the BeaconLess Routing
(BLR) protocol. BLR avoids the scaling problems of con-
stantly broadcasting topology information in beacon mes-
sages. The protocol is similar to (but not the same as) the pure
CD heuristic. After a node transmits its message, nodes
within a certain forwarding zone respond if they are closer to
the destination. BLRs trick is that each node delays its
transmission by an amount that varies according to how
much progress it can make toward the destination. The one
computing the shortest delay transmits first, causing all
others to cancel (as in CD). This is better than Ko/Vaidya
Scheme 2, because it uses late cancellation as in our
approach, but it suffers from the scalability problem
described in Section 3: as traffic increases, a potential relay
node will be unable to respond in time to cancel (extra)
transmissions of others, resulting in the quadratic behavior
documented earlier.
Probabilistic Flooding (PF) [11] is another geocast
heuristic that can be replicated within the Classic Geocast
framework. We have modeled a variant that a) counts the
number ` of nodes that are neighbors (i.e., recently heard
from), and b) decides whether to retransmit by a random
coin-flip with success probability minf1. 1,`g, where 1 is a
parameter. Applying this papers evaluation method, 1
12 gave the best performance, with an overall Success% of
46.9 percent, and a deficit score of 28.8 percent with two ties
for best score. Recall that the best CD-P setting had overall
Success% of 93.3 percent and deficit score of 2.15 percent
with eight best scores. PFs deficit score ranks it below all
settings with CD-P on, and below 7 of 12 NoCD and 6 of
12 CD settings. It is particularly weak in scenarios with high
terrain complexity.
Khan et al. [12] describe a different probabilistic flooding
scheme very similar to Classic Geocast using only the T
heuristic. Their scheme computes a probability of retrans-
mission that varies with distance exponentially, with
probability 0 at distance 0 (from sender) and approaching
1 exponentially with greater distance. This is quite similar
to Classic Geocast with T heuristic only, except the latter
substitutes a step function that is 0 out to distance T and
then 1 thereafter. While one can reasonably expect these
two approaches to perform similarly, the present work has
shown how to combine other heuristics (e.g., CD-P, M) with
T-like ones to increase reliability while maintaining scal-
ability. The study in this paper has shown that CD-P
outperforms T (and M) in general, with only a few scenario
types being exceptions.
Zorzi and Rao [13] have proposed Geographic Random
Forwarding (GeRaF). In GeRaF, the sender broadcasts its
location and that of the destination in an RTS message.
Nodes hearing the message then use an iterative MAC-
based resolution protocol to select a unique node, among
those closer to the destination than the sender, to relay it.
The nodes then exchange CTS/RTS pairs until the
randomized resolution protocol selects a unique relay; at
this point, the data are forwarded to the relay. Refer to [13]
for complete protocol details. For comparison purposes,
GeRaFs most salient characteristics are as follows: first, it is
a pure hill-climbing heuristic similar to CD; in particular,
GeRaF is stymied when the relaying encounters a situation
where the direction toward the destination contains a gap
(even if relay paths going other directions exist). A GeRaF-
based geocast system would be outperformed (as was pure-
CD-P) by a mixed Classic/CD-P strategy on several of the
scenarios in our study, such as 8, 9, and 10. In our
framework, CD-P is integrated with the T and M heuristics
precisely to fix this problem: if CD-P does not result in a
relay, T or M may lead to a relay around the problem area,
as occurred, e.g., in scenarios based on the layout of Fig. 10c,
which has large gaps between sender and geocast region.
Second, GeRaF is based upon providing prioritized med-
ium access to nodes closer to the destination, in contrast to
CD-Ps fair-access scheme. This enables the average GeRaF
hop to travel a longer distance than that of CD-P (for dense
scenarios and several-hop messages, %0.771 versus
%0.401, where 1 is the coverage radius of a transmission).
However, this is at the cost of a much higher and less
scalable per-hop overhead and latency. The time cost of a
CD-P hop is essentially just the time to transmit one data
frame. However, the cost of a GeRaF hop is not constant: it
requires approximately 1 2 lg ,1
,8 control messages
(RTS or CTS) plus one data frame, where , is the average
area density of nodes. So GeRaFs overhead grows with
density; e.g., with 32 neighbors, GeRaF needs 5 control plus
1 data, while with 128 neighbors, it takes 9 control plus 1
data. In practice, the authors recommend limiting the
number of RTS/CTS rounds, aborting the message if no
relay is selected. This implies that above a certain density,
GeRaF will not function at all. CD-P has no such upper
limit. For low node densities, GeRaFs overhead is bounded
by 9 control plus 1 data (such as when there is a single relay
very close to the transmitter). Thus, for low traffic,
geographically dense scenarios, GeRaFs latency and over-
head costs are less scalable than those of CD-P. A fuller
comparison of CD-P and GeRaF is beyond the scope of this
paper, but would be quite interesting as future work,
particularly for high load scenarios.
Another proposal by Hughes and Maghsoudlou [14] is
based on each node transmitting in the geocast packet an
estimate of the area already believed covered by copies of
the packet. A node retransmits if and only if its coverage
area includes a grid square that is not indicated as covered
in the packet. As shown in [14], this reduces retransmis-
sions; however, (also as in [14]) the number of retransmis-
sions is still linear in number of nodes, at least for the
critical special case of all nodes having identical radio
ranges. Thus, this method merely improves simple flooding
by a constant factor, so it is still unscalable. The largest
scenario they simulated had 70 nodes.
Chen et al. [15] propose an alternative to GPS-based
geocasting in which they modify simple flooding by
analytically calculating a time-to-live limit for each packet.
Their method does simple flooding, but each packet has the
number of hops it has gone through within it and once the
limit is reached, it is no longer retransmitted. They show
that this improves the number of transmissions over simple
flooding by about 58 percent, for a class of simple radio-
obstruction-free random scenarios. Of course, 0.42 times an
unscalable level of traffic is still unscalable.
Pleisch et al. [16] describe a method of enhancing
flooding algorithms with compensation packets that can
efficiently improve reliability. When a node elects not to
retransmit a flooded packet, it instead adds it to an
exclusive OR of all packets not retransmitted. Once c such
packets are combined, the node transmits this XOR. Any
other node having heard c 1 of the packets and the
compensation packet can then reconstruct the missing one.
While the approach has advantages, it doesnt help in all
cases. For example, in the geocast of Fig. 5, the node in the
geocast region only ever hears packets either transmitted by
N or compensation packets from N (which never contain
packets transmitted by N). Thus, the compensation me-
chanism cannot reconstruct any of the missing packets. CD-
P, on the other hand, does succeed in that situation, as
shown previously.
5.2 Topology-Based Approaches
In Greedy Perimeter Stateless Routing (GPSR) [17], greedy
relay selection is augmented by first computing a planar
graph from gathered topology information and then, when
there is no relay closer to the destination, forwarding the
packet instead to the first node counterclockwise from
the sender around the planar-graph face intersecting the
destination direction. While this heuristic can improve
Success% over pure greedy approaches, it can also select
overly long paths, resulting in high latency or packet drops
due to reaching time-to-live limits. Two factors lead to this
weakness. One is that in planarizing the graph, the
algorithm drops out cross links and tends to keep short
hops, so where one hop in the original graph would suffice,
two or more are needed in the planar subgraph. Second, its
local search heuristic can be tricked into traversing large
dead-end subgraphs that do not lead to the destination
before finally finding its way. For example, for the layout of
Fig. 10c, if the geocast originates on the right edge and has
destination either in the central group or in the left edge
group north of the senders latitude, then GPSR would
forward the packet first north greedily until it reached or
passed the destination latitude, at which point it would
enter perimeter mode; it would then proceed south (by the
right-hand rule) until reaching the end of the chain and then
back north, passing through the original sender node again.
At that point, it may proceed eventually to discover a path
to the destination, but the entire sojourn south of the
originator is wasted. By contrast, the T heuristic would
propagate the packet both directions from the sender,
including northward to the upper edge, where the CD-P
heuristic would take over and move the packet to the
destination using far fewer hops. To be sure, there also exist
scenarios where GPSR would succeed and CD-P with
Classic would fail to find a route. Another potential
weakness of GPSR is its scalability with geographic density.
Its graph planarization algorithm is quadratic in the
number of neighbors. Moreover, this graph must be
recomputed when neighbors change position. Note that
GOAFR+ of Kuhn et al. [18] is very similar to GPSR and so
has similar strengths and weaknesses compared to CD-P
with Classic. Finally, Heissenbutel et al. [10] have docu-
mented a study comparing BLR to GPSR. In it, they show
that beaconless approaches can be expected significantly to
outperform GPSR in success%, latency, and energy perfor-
mance as mobility and density increase. The reason for this
is that the topology information in beacons gets stale and
misleads GPSR, while it also uses up bandwidth and
energy. Since my studies above have shown that CD-P (and
CD-P with Classic) outperform CD, and hence, also BLR,
we can infer evidence that CD-P outperforms GPSR for
scenarios of these types.
In Trajectory-Based Forwarding (TBF) [19], the sender
specifies a parameterized geometric curve (or other one-
dimensional continuously parameterized structure such as a
tree) as a kind of generalized route to the destination(s).
TBF then operates at each node greedily by choosing a relay
closest to this curve but farther along it. In this way, the
algorithm chooses a one-dimensional subset of all nodes
froma dense (2D) scenario to relay a given message. This has
obvious scale advantages over flooding and related techni-
ques, which choose the full 2D neighbor set. Being a
generalization of linear hill climbing (as used in CD-P, GPSR,
et al.), TBF can get stuck when the trajectory encounters a
gap or obstacle. In contrast to GPSR, it is not clear how to fix
this in general for TBF, as discussed in [19]. CD-P with Mand
T can deal with this case, as previously described.
Face Tracing [20] is a generalization of face routing
approaches such as GPSR and GOAFR+ that does not first
planarize the graph. It suffers from similar scalability
problems they do while improving Success% and latency
by eliminating fewer links from the graph. Its scalability is
in question, however, as it requires a preprocessing step of
cluster graph construction that can be problematic in highly
mobile networks, and it also requires topology packets
updating nodes with locations of neighbors.
Lee et al. [21] describe NADV where, instead of using
closeness to destination, they weight it by dividing by a cost
metric for each link. For example, a node can compute a cost
proportional to link loss rates. This metric is then used in
greedy hill climbing (such as CD-P). Zamalloa et al [22] use
this approach in sensor networks having lossy links.
Obviously, given a way to measure link costs, CD-P could
use this metric as well.
Maihofer [6] surveys several geocast protocols. Among
those applicable within dynamic MANETs, the most
relevant is unicast routing with area delivery (URAD),
which uses a unicast-based search approach (such as
position-based hill climbing) to reach a node near the
geocast region. This node then initiates a flood of the
geocast region. This reduces the long-range transport
complexity to i
, the diameter of the network, but depends
on extensive topology information and still involves flood-
ing level complexity near the geocast region.
Lou and Wu [23] describe a method (PDP) for achieving
area coverage with fewer retransmissions than flooding.
PDP sends two-hop neighbor topology information. Each
node then computes a spanning tree in its neighborhood,
determining if it is a part of the tree, and inhibiting
retransmission if not. The algorithms reliability (and the
papers analysis) depends on two idealized assumptions:
that neighbor topology does not change during propagation,
and that the MAC layer is perfect so there is no medium
contention at all. In a real-world system (such as that
modeled in this paper), queuing, MAC delays, and collisions
can disrupt this idealization, leading to unreliability and
high overhead. By contrast, the simulation study in the
present work modeled realistic queuing and MAC behavior.
CD-P is a novel heuristic designed to support geocast in
high-scale MANET applications and integrated into the
Classic Geocast framework, allowing it to complement
other heuristics. It is based upon three key ideas. First, a
node retransmits if it is closer to the center of the geocast
region than all other copies it has heard transmitted.
Second, it listens to other retransmissions continuously
prior to its own retransmission and cancels its own if it
hears another node transmit closer to the center first. And
third, scalability relies on each node prioritizing its send
queue to send soonest those packets that make the most
progress toward the center of their geocast regions. All of
these elements are necessary for scalability; e.g., eliminating
queue prioritization yields CD, which has drastic scaling
failures on many scenarios. Moreoever, the three together
significantly improve geocast performance (21.8 percent
reliability improvement with no significant increase in
latency over NoCD; 12.7 percent reliability improvement
and 91 percent drop in average latency compared to CD and
related approaches). The study has suggested that
0. 1. CD-P is the best parameter setting to use by default,
providing top or near-top performance in all scenarios. Its
integration in the Classic Geocast framework allows
combining it with other heuristics for increased perfor-
mance in more situations. For example, performance can be
increased in complex terrain (which tends to defeat greedy
hill climbing) by varying T and M to increase redundancy,
as in scenarios 8, 9, and 10 (Fig. 12). How to dynamically
vary parameters when conditions change is an interesting
area for future work.
[1] C.S.R. Murthy and B.S. Manoj, Ad Hoc Wireless Networks:
Architectures and Protocols. Prentice Hall, 2004.
[2] R. Morris, J. Jannotti, F. Kaashoek, J. Li, and D. Decouto, Carnet:
A Scalable Ad Hoc Wireless Network System, Proc. Ninth
Workshop ACM SIGOPS European Workshop, pp. 61-65, 2000.
[3] R.J. Hall, Combinatorial Communications Modeling of Real-Time
Tactical Engagement Adjudication Architectures, Proc. IEEE
Military Comm. Conf. (MILCOM 06), vol. 3, pp. 1488-1494, Oct.
[4] R.J. Hall and J. Auzins, A Tiered Geocast Protocol for Long
Range Mobile Ad Hoc Networking, Proc. IEEE Military Comm.
Conf. (MILCOM 06), pp. 1-8, Oct. 2006.
[5] Y.-B. Ko and N. Vaidya, Geocasting in Mobile Ad Hoc Networks:
Location-Based Multicast Algorithms, Proc. Second IEEE Work-
shop Mobile Computer Systems and Applications, pp. 101-110, 1999.
[6] C. Maihofer, A Survey of Geocast Routing Protocols, IEEE
Comm. Surveys and Tutorials, vol. 6, no. 2, pp. 32-42, 2004.
[7] T. Imielinski and J. Navas, Geographic Addressing, Routing, and
Resource Discovery with the Global Positioning System, Comm.
ACM, vol. 42, pp. 86-92, 1997.
[8] R.J. Hall, Forensic System Verification, Proc. 17th IEEE Intl
Requirements Eng. Conf. (RE 09), pp. 111-120, Aug./Sept. 2009.
[9] R.J. Hall, LSS: A Tool for Large Scale Scenarios, Proc. 21st ACM/
IEEE Intl Conf. Automated Software Eng. (ASE 06), pp. 349-350,
Sept. 2006.
[10] M. Heissenbuttel, T. Braun, T. Bernoulli, and M. Walchli, BLR:
Beacon-Less Routing Algorithm for Mobile Ad-Hoc Networks,
Elseviers Computer Comm. J., vol. 27, pp. 1076-1086, 2003.
[11] M.B. Yassein, M. Ould-Khaoua, and S. Papanastasiou, On the
Performance of Probabilistic Flooding in Mobile Ad Hoc Net-
works, Proc. 11th Intl Conf. Parallel and Distributed Systems
Workshops, vol. 2, pp. 125-129, 2005.
[12] I. Khan, A. Javaid, and H. Qian, Distance-Based Dynamically
Adjusted Probabilistic Forwarding for Wireless Mobile Ad Hoc
Networks, Proc. Fifth IFIP Conf. Wireless and Optical Comm.
Networks (WOCN 08), pp. 1-6, May 2008.
[13] M. Zorzi and R. Rao, Geographic Random Forwarding (GeRaF)
for Ad Hoc and Sensor Networks: Energy and Latency Perfor-
mance, IEEE Trans. Mobile Computing, vol. 2, no. 4, pp. 337-348,
Oct.-Dec. 2003.
[14] L. Hughes and A. Maghsoudlou, An Efficient Coverage-Based
Flooding Scheme for Geocasting in Mobile Ad Hoc Networks,
Proc. 20th Intl Conf. Advanced Information Networking and Applica-
tions, vol. 1, pp. 517-522, 2006.
[15] Q. Chen, S. Kanhere, M. Hassan, and Y. Rana, Distance-Based
Local Geocasting in Multi-Hop Wireless Networks, Proc. IEEE
Wireless Comm. and Networking Conf. (WCNC 07), pp. 4074-4079,
Mar. 2007.
[16] S. Pleisch, M. Balakrishnan, K. Birman, and R. van Renesse,
Mistral: Efficient Flooding in Mobile Ad-hoc Networks, Proc.
ACM MobiHoc, pp. 1-12, 2006.
[17] B. Karp and H. Kung, GPRS: Greedy Perimeter Stateless Routing
for Wireless Networks, Proc. ACM MobiCom, pp. 243-254, 2000.
[18] F. Kuhn, R. Wattenhofer, Y. Zhang, and A. Zollinger, Geometric
Ad-Hoc Routing: Of Theory and Practice, Proc. Symp. Principles of
Distributed Computing, pp. 63-72, 2003.
[19] D. Niculescu and B. Nath, Trajectory Based Forwarding and Its
Applications, Proc. ACM MobiCom, pp. 260-272, 2003.
[20] F. Zhang, H. Li, A. Jiang, J. Chen, and P. Luo, Face Tracing Based
Geographic Routing in Nonplanar Wireless Networks, Proc. IEEE
INFOCOM, pp. 2243-2251, May 2007.
[21] S. Lee, B. Bhattacharjee, and S. Banerjee, Efficient Geographic
Routing in Multihop Wireless Networks, Proc. ACM MobiHoc,
pp. 230-241, 2005.
[22] M. Zamalloa, K. Seada, B. Krishnamachari, and A. Helmy,
Efficient Geographic Routing over Lossy Links in Wireless
Sensor Networks, ACM Trans. Sensor Networks, vol. 4, no. 3,
May 2008.
[23] W. Lou and J. Wu, On Reducing Broadcast Redundancy in
Ad Hoc Wireless Networks, IEEE Trans. Mobile Computing, vol. 1,
no. 2, pp. 111-122, Apr.-June 2002.
Robert J. Hall received the PhD degree in
electrical engineering and computer science
from the Massachusetts Institute of Technology.
Since then, he has been a principal investigator
at AT&T Laboratories Research, working in the
areas of automated software engineering, re-
quirements engineering, modeling and simula-
tion, and MANET protocols. He is a fellow of
automated software engineering and serves as
a chairman of the steering committee for the
IEEE/ACM International Conferences on Automated Software Engineer-
ing. He is the editor-in-chief of the Automated Software Engineering
Journal, an ACM Distinguished Scientist, and a member of the I.F.I.P.
Working Group 2.9 on requirements engineering. He is a member of the
IEEE Computer Society.
> For more information on this or any other computing topic,
please visit our Digital Library at www.computer.org/publications/dlib.