density-independent, scalable search in ad hoc...

Density-Independent, Scalable Search in Ad Hoc Networks

Zygmunt J. Haas1,2

and Rimon Barr1

We analyze the asymptotic cost of discovering a route within a flat ad hoc network and we

show that one can discover a route with cost that is proportional only to the area of thenetwork, which is independent of the number of network nodes. Furthermore, we show thatthis is optimal and that bordercasting (a query propagation protocol where a node retransmits

a query to a set of nodes at some hop-distance away) possesses this density-independenceproperty. We present the design of bordercast and the associated maintenance protocols, andwe evaluate their performance. In particular, we highlight that the aggregation of local

information by bordercasting at each network node is a fundamental building block for theconstruction of scalable protocols in flat ad hoc networks.

KEY WORDS: Ad hoc networks; routing; flooding; bordercasting; scalable routing; route discovery;service discovery; scalability; zone routing protocol; ZRP; sensor networks

1. INTRODUCTION

Research into dynamic, self-organizing, multi-hop wireless networks, the ad hoc networks, attemptsto improve network performance, for instance, theefficiency and coverage of wireless communication, byincreased network connectivity. The idea is wellknown; rather than tether wireless devices to thewired world via a single wireless hop to a base station,a device within an ad hoc network may be connectedvia multiple, shorter hops across other wirelessdevices that function as routers (and, in some cases,as repeaters). In general, the devices may alsocommunicate with each other (as peer-to-peer) andeven operate in isolation; i.e., without global connec-tivity (e.g., through a base station). Regardless of thetraffic pattern, since in most practical cases the powerstrength of a radio signal is attenuated more than thesquare of the distance traveled, while supporting thesame throughput as a single long wireless hop,multiple shorter wireless links use overall less power,a scarce resource in mobile settings. Furthermore, theoverall effective capacity of the airspace may beincreased, because these lower power, shorter range

transmissions generate less interference. (For a studyassociated with such tradeoffs, the reader is referredto [1, 2, 3].) Alternatively, with the same power, onecan achieve greater capacity or coverage.

The vision of extending the reach of wirelesscommunication in this manner is enticing. However,routing and transmitting packets efficiently becomeincreasingly difficult as the ad hoc network grows. Ingeneral, increasing the scale of ad hoc networks tosizes greater than a few hundred nodes still remainsan important research challenge. One of the obstaclesis the fact that as the number of nodes grows, theaverage path length (measured as number of hops)increases as well, resulting in a significant reductionin network capacity, as each packet is now transmit-ted numerous times in the network.

In this article, we address an essential compo-nent of this problem. The following are the contri-butions of this work. We analyze the cost ofdiscovering a route within a flat ad hoc network inthe absence of any information about the desireddestination node, except for its unique address. Weshow that one can discover a route with costproportional only to the area of the network andindependent of the number of nodes in the network(i.e., independent of the network density). Further-more, we show that this is optimal; i.e., that this cost

1 Wireless Networks Laboratory, Cornell University, Ithaca, NY,

14850, USA2 E-mail: [email protected]

International Journal of Wireless Information Networks, Vol. 14, No. 2, June 2007 (� 2007)DOI: DOI: 10.1007/s10776-006-0055-9

931068-9605/07/0600-0093/0 � 2007 Springer Science+Business Media, LLC

is a lower bound on any possible route discoveryprotocol that does not rely on additional informationabout the destination node. Finally, we considerbordercasting, a query propagation protocol where anode resends the query to nodes at some distanceaway. We show that bordercasting, which was pro-posed as part of the Zone Routing Protocol (ZRP)framework [4, 5], is, indeed, density-independent.

A key message of this article is that the aggre-gation of zone-wide information at each networknode can lead to more efficient and scalable networkprotocols. We discuss how to collect this zone-wideinformation efficiently, and we focus on how it can beused to perform scalable route discovery. Neverthe-less, the results of this work are extendable to otherprotocols, such as service discovery and more com-plicated situations, such as is the case in multicastinggroup membership maintenence, for example.

2. BACKGROUND AND RELATED WORK

Prior research has produced numerous routingprotocols designed for mobile ad hoc wireless net-works; some examples include DSR [6], AODV [7],TBRPF [8], and OLSR [9].

Each of these protocols is often designed andoptimized under different networking assumptions,such as the expected traffic pattern or the rate oftopological changes in the network. For example, theOLSR protocol is proactive in its route discovery,which is a feature suitable for more static networks,while AODV is reactive, and thus is more efficient inhighly mobile settings. The differences in applicabilityof these protocols to various networking settingsmotivated the introduction of hybrid protocols, suchas ZRP [4,5], ZHLS [10], SHARP [11], and HARP[12]. Additionally, the various protocols also differ intheir use of route caching techniques, their mecha-nisms for detecting route failures, and their capabil-ities for maintaining routes.

At one time or another, either due to limitedcache sizes, changes in the network that invalidateexisting information, or the arrival of a new query foran unknown destination, each of these protocols isforced to send a query into the network in search of anode or of information about a node, informationthat might be available at some other, nearby nodes.Because it is such a fundamental operation, efficientquery propagation is, therefore, of significant impor-tance when performance is considered. Flooding is afrequently used, albeit naı̈ve, query propagation

protocol, whereby each node, upon receiving a queryfor the first time, merely rebroadcasts it to all itsneighbors, possibly with some jitter to reduce theprobability of congesting the network. Reception of apreviously seen query is ignored. Excluding failures,every node with a path to the source receives thequery at least once and transmits it exactly once.Truncating the flood by using an expanding ring(such as TTL-based ring [13]), as is done, forexample, in AODV, is merely a stop-gap measurethat is useful only when the destination node orcached information happens to exist nearby. Ingeneral, as the number of network nodes increases,the cost of the flood increases in proportion as well.

In the absence of any information about thedestination node, including cached information oreven general location information, a route discoveryquery should be propagated to all nodes that areconnected to the source of the query. But the basicobservation is that it is certainly not necessary forevery node to transmit the query, as is the case withflooding. This observation allows for significantimprovements of many existing ad hoc networkrouting protocols. When operating in dense net-works, the flooding-based propagation component ofthese protocols causes unnecessary transmissions,frequently referred to as ‘‘broadcast storms’’ [14].

Various ideas have been proposed to address theunnecessary transmissions, including probabilisticbroadcast protocols [15], gossip-based schemes [16],planar-geometric optimizations [17], and distributedalgorithms that compute cluster-heads or connecteddominating sets [18, 19], among many others. Excel-lent surveys on this topic could be found in [14], [20],and [21]. We submit that each of these protocolsshares the same basic density-independent property.Indeed, this density-independent property has beenintroduced by some of the earlier protocols; forexample, by the Zone Routing Protocol (ZRP) andmore specifically, by its bordercast operation. Fur-thermore, we emphasize that aggregation of zone-wide state at each network node is a fundamentalbuilding block upon which efficient and scalablenetwork protocols can be built. In the followingsection, we briefly describe this zone-wide informationand how it could be used for scalable route discovery.

3. ZONE MAINTENANCE

Our network model is that of a flat ad hocnetwork. Our network consists of n independently

94 Haas and Barr

moving nodes within an area of A[m2]. Nodes candirectly communicate with other nodes that arelocated within their transmission radius of r [m].(We assume here the protocol reception model. Exten-sion of this work to the physical reception model is leftfor future work.) All nodes are equal in theircapabilities, trusting one another, co-operating par-ticipants in the network, and there is no central‘‘coordinator’’ node. (Indeed, the lack of a centralentity is one of the biggest advantages of the ad hocnetworking technology, as this prevents a single pointof failure.) For the communication medium, weassume a single, shared channel and, for simplicity,that links are bi-directional.

A zone is defined per every node; the zone of aparticular node A consists of the set of nodes that arewithin R network hops from A. R is referred to as thezone radius. Each node knows what are the nodeswithin its zone, as well as the links among thosenodes. We assume in this article that R is a network-wide constant. However, in principle, the zone radiusmay change over time and need not be homogeneousacross the entire network (see, for example [5]). Theborder of a zone is defined as the set of nodes that areexactly R hops away.

Zone-wide information is collected and main-tained at each node by a protocol called IARP(IntrA-zone Routing Protocol). The result of execut-ing an IARP protocol is local knowledge of the zone;i.e., the identity of all the nodes, Nz, that are within Rhops as well as the state of the links, Ez, among them.For a sparse network, |Ez| = O(|Nz|). However, asthe network density increases the size of links� setgrows quadratically, – i.e. |Ez| = O(|Nz|

2) – as doesthe cost of the zone maintenance protocol. Thisplaces a limit on the size of the zone, particularlywhen the membership of the zone and its links� stateschange rapidly, such as is the case with high nodemobility. Therefore, it is important for the zonemaintenance protocol to be as efficient as possible.We propose here two possible zone maintenanceprotocols: IARP-node and IARP-zone.

The zone maintenance protocol receives infor-mation about its immediate neighbors and link statesfrom the Neighbor Discovery Protocol (NDP). NDPcan be either a simple heartbeat-based node discoveryprotocol running at the network layer, or some othermechanism operating lower on the protocol stack,such as the MAC layer. It provides information aboutthe first hop with Link-Up and Link-Down notifica-tions whenever a link to a neighbor is discovered or islost, respectively.

The IARP-node protocol broadcasts these locallink state changes in update packets with the TTL setto R hops. Each such update packet is sequenced at itssource. Every node that receives such a packet for thefirst time, simply decrements the TTL and rebroad-casts it to all its neighbors, unless the remaining TTLhas reached zero. In this manner, the entire zone learnsof the zone�s topological changes. The protocol couldalso incorporate a jitter delay, so as to lower theprobability of congestion; such congestion could leadto collisions at the MAC layer and to buffer overflowat the network layer. Furthermore, addition of thejitter delay can also allow accumulation of a fewadditional changes at the source node before sendingthe update packet. For nodes that join the network,there is a mechanism to acquire zone state from aneighbor. Finally, there is also a periodic broadcast ofthe full links� state at a larger time interval, whichallows to update the topology with changes thatotherwise would have not been propagated, such as,for example, expiration of links whose both endpointshave either left the network or have failed.

When the zone is stable, the IARP-node proto-col is silent, except for the infrequent periodicbroadcasts. However, in the worst case, for a zoneof k nodes and l links that are changing all the time,each of the k nodes will transmit a packet containingO(l) link changes that will be rebroadcast by k)1other nodes in the zone. In other words, the worstcase of the IARP traffic load per ‘‘update period’’ isO(k2l) information and O(k2) packets per zone, orO(kl) information and O(k) packets per node, wherek and l are functions of the zone radius R, the averagenetwork density n/A, and the transmission radius r.(Note that although there is no set ‘‘update period’’ inIARP-node, we refer here to this term as the averagetime between two conscutive updates, which may berestricted by the delay jitter mentioned above.)

The IARP-zone protocol takes a differentapproach. Every node broadcasts only a single packetat every update period, if there has been any changeto the link state. Each packet has a TTL of 1, butcontains the known changes of the entire zone-widelink state since the last transmission. The same packetis received by neighbors from multiple directions, buteach one prunes out the information relevant for itszone, based on shortest network distance calcula-tions. As in the IARP-node protocol, each linkupdate is sequenced at the link source, there is aforced periodic update at a longer time interval thatpermits link expiration, and the protocol is otherwisesilent if the zone is stable. In the worst case of an

95Scalable Search in Ad Hoc Networks

all-changing zone, there is still O(kl) information sentper node, but now only in a single packet. This largerpacket may be readily sub-divided into a few inde-pendent, smaller packets, if the information happensto exceed the link MTU. However, the advantage oftransmitting zone-wide changes in batches is retained:multiple links updates contain common endpoints,permitting a more efficient encoding. More specifi-cally, within each packet, we build a table of end-points, which contains IP addresses, link sourcesequence numbers, and any query-specific node state.The packet then contains a list of source endpointindices, each with a sub-list of destination endpointindices, representing all of the links. Bi-directionallinks are encoded using a reversal bit. We will evaluatethe gain of this efficient encoding in this article.

Finally, though we have not studied it in thisarticle, it may be possible to further improve theperformance by intentionally omitting some links indense networks. Beyond a certain threshold, addi-tional links will, with high probability, not affect theconnectivity within the zone, nor appreciably degradethe bordercast performance.

4. BORDERCAST-BASED ROUTE DISCOVERY

In this section, we overview the bordercastprotocol, which can be used in place of the flood-ing-based query propagation found in many existingad hoc network routing protocols. We show howbordercasting uses the zone information to efficientlypropagate a route discovery query. Our discussionhere is based on [5].

Like flooding, the bordercast protocol propa-gates the query across the entire network. However,while flooding attempts to iteratively relay the queryto any neighbors that have not heard it yet, thebordercast protocol seeks to iteratively relay the queryto any of its border nodes that have not seen the queryyet. Thus, while all the neighbor nodes receive thequery broadcast, not all of them need to retransmit iton its way to the border nodes. If we consider thenodes within the zone to be a micro-ad hoc networkwith approximate area of Az = p(Rr)2, it is clear thatthe cost of propagating the query across the zone is afunction of its area and not of the number of nodeswithin it. Therefore, because of the broadcastingnature of wireless communications, the bordercastprotocol broadcasts the query to all its neighbors, butselects only a few to re-bordercast the message. Theother neighboring nodes are silent recipients.

It is important to understand that bordercastingdoes not actually attempt to deliver the query to everynode within its zone. Rather, its objective is to relaythe query only to all border nodes that have not yetreceived the query. The protocol still works correctly,because each node in the network maintains infor-mation about all the nodes within its zone and cananswer queries about them or, at the very least,forward the query directly to the desired node. Thus,we say that a node is covered if the query has beenreceived by any node within its zone. The border-casting protocol ensures that every node in thenetwork is covered by the query. With larger zoneradii and at larger network densities, a significantfraction of the network may be covered withoutactually receiving the propagating query.

We present in Figure 1 the proposed bordercastalgorithm, which is executed independently in everynode. A bordercast query propagation is initiatedwith a call to BORDER-CAST, and incomingmessages are processed by RECEIVE-BORDER-CAST. The ZONE and BORDER functions returnthe sets of zone and border nodes, respectively,around a given node, based only on the localinformation.

The local state of each node consists of the zone-wide information as well as information regardingwhich nodes within the zone have already beencovered by a query coverage. This query coveragestate maintained by each node lies at the heart of theprotocol and directs its behavior. As with flooding, abordercasting node should transmit a query at mostonce. To ensure this property, the protocol marks allthe nodes of its zone, including the border nodes, ascovered after a query has been relayed. (Note thatthis is a local operation, which updates coverage inthe local node state.)

When all the border nodes are covered, there isno need to relay the query. Similarly, when a nodereceives a bordercast message from some neighbor wemark all the locally known nodes in the zone of thatneighbor as covered. In other words, we update ourlocal query coverage state to indicate that all nodeswithin our zone that are within R hops of the sendernode have been covered by the query. Thus, thecoverage state directs the query outward, toward anexpanding border.

Each bordercast message contains the query tobe relayed, a source address, and a list of targetaddresses. The bordercast message is always broad-cast and the list of target addresses is always selectedfrom among the neighbors of the recipient. If the

96 Haas and Barr

receiving node is not one of the selected targets, it isimplied that it is not required for the query to reachthe border nodes of the recipient. Furthermore, bythe definition of a zone and the manner by whichtargets are selected, each of receiver�s border nodesmust be a border node of one of the targetedneighbors. Thus, when a node receives a bordercastmessage and is not in the target set, the protocolmarks its entire zone as covered. The effect is, asabove, to ensure that a non-targeted node will remainsilent, since it is not required for query propagation.

In contrast, a targeted neighbor node thatreceives a query is responsible for re-bordercasting itto any of its uncovered border nodes. The protocolpauses for a short random interval before doing so tolower the chances of congestion. It also allows thenode to receive other bordercasts that may be occur-ring at neighboring nodes during this time. Learning

that the query was processed at other nodes, maypartially or completely cover the remaining uncoveredborder nodes and either reduce the number of targetsrequired or perhaps eliminate the need to relay thequery entirely.

Finally, before broadcasting the query, theprotocol must select the target neighbors: SELECT-NEIGHBORS(). For each uncovered border node,there must be at least one neighbor chosen in thedirection of that border node. In other words, thenetwork distance between the selected target neigh-bor and the uncovered border node must be R)1hops. There may be many sets of nodes that meet thiscriterion, and we would like to find the smallest suchset. Since this matching problem between closestneighbors and their uncovered border nodes is NP-complete, we implement a greedy approximation. Theneighbor node that covers the greatest number ofuncovered border nodes is chosen first. We cover theborder nodes closest to the chosen target and iterateuntil all the border nodes have been covered. Thequery is then broadcast with this list of targets.

Figure 2 depicts a bordercast in progress. Thezone radius is equal to 2. Our query was initiatedfrom node S, and it arrived via G and B to node A.Note that node B targeted only nodes A and C withits query broadcast, in order to reach its border nodeset {H, D, E}. Node F is not targeted since node Aalready covers it, in addition to covering D. Thus,when F receives the query from B, it processes it,notes that its entire zone is covered (since F is not atarget of the query), and, therefore, remains silent.Similarly, G receives the query from B and remainssilent, since G has already forwarded the query (to B,in this case) and marked all the nodes of its zone ascovered. When A receives the query from B, it locallymarks all the nodes of B as covered. Covered nodesare represented as black nodes in the figure. S is notmarked, since A does not know about it. I, J, and Kare also not marked, since they lie outside the zone ofB. Thus, out of A�s border set, which is {G, H, I, J, K},only {I, J, K} remain uncovered. Assuming that noother bordercasts are heard while A pauses, A willbroadcast the query with {D, E} as targets.

5. THEORETICAL BOUNDS ON OPTIMAL

PROPAGATION

Given a network, G = ÆN, Eæ, where N denotesthe set of nodes distributed uniformly across an areaA, and E denotes the links between them, we wish to

Fig. 1. The bordercast query propagation protocol.


determine the optimal number of transmissions, t,required to propagate a route query from a sourcenode, n02N, to all the other n0)connected nodes,Nc

n0� N. Note that we refer to the term ‘‘connected’’

in the graph-theoretic sense, i.e., possibly throughmultiple network hops. Clearly, t � jNc

n0j, since this

is the cost of flooding; i.e., each n0)connected nodetransmits the query once.

As network nodes are placed at random loca-tions, in the worst case, we need to cover the entirearea with query broadcasts. A single wireless broad-cast can be received over an area a = p r2 around thetransmitter, where r is the transmission radius, asdefined above. Thus, even if we could place ourtransmitters at will, we still would need at leastt � ð1þ �ÞA=a transmitters, where � accommodatesfor the packing inefficiency of the transmission cov-erage circles. For convenience, let q = (1 + �)A/a.

As we increase the size of the network, by addingnodes at random locations within A, a number ofthings occur. The density of the network increases inproportion. The network becomes fully connectedwith high probability, so that Nc = N. And, theprobability of having a node within d distance of anychosen transmitter point, Pd(t) = 1)(1)pd2/A)|N|,approaches 1. To propagate our query over theentire area A, we select transmitter points uniformlyacross A, such that the distance between any two is atmost r. We can already cover the entire area with qcircles of radius r. Now place nodes at the centers ofthose circles and connect those nodes with anadditional q)1 intermediate nodes. Thus, even asthe number of nodes in the network increases, we canstill flood the entire network at a cost of t � 2q� 1transmissions! Thus, t = Q(A).

The upper bound we have just derived may notbe achievable, since we selected transmission pointsthat may not actually correspond to location of nodeswithin the original network. Therefore, consider thedominating set over G, ~N. (A set of nodes, ~N, isdominating over G, if and only if every node in G iseither an element of ~N or is a neighbor of some nodein ~N.) The dominating number of our network, or thesize of the minimum dominating set, is cðGÞ � q. Ifthere are any more nodes in a dominating set thanthis upper bound, then at least one member nodecovers an area around it that is already completelycovered by the remaining nodes in the set, and thatnode can be removed to form a smaller dominant set.We then construct a minimum connected dominatingset, ~Nþ. A connected dominating set is a dominatingset with nodes from G added to connect the existingdominating nodes, whenever those nodes are con-nected in G. Again, as stated above, we refer to theterm ‘‘connected’’ in the graph-theoretic sense, i.e.,possibly through multiple network hops. Thus, byconstruction, the number of connected componentsin the connected dominating set will be equal to thenumber of connected network components in G.Note, also, that by the definition of the dominatingset, we will need to add at most two nodes for everydominating node to form the connected dominatingset: the neighbors of the two dominating nodes we areconnecting. Thus, j ~Nþj � 3j ~Nj, and the minimumconnected dominating number of G is cþðGÞ � 3q.Finally, since the minimum connected dominating setcontains all the nodes that must transmit the query inorder to completely propagate it through G, we retainthat t = Q(A).

To summarize, the minimal number of trans-missions required to propagate a query is propor-tional to the area, A, of the network. It is independentof the number of network nodes, or equivalently, ofthe network density. Adding a node in an area that isalready covered by an existing set of propagatingnodes, should not increase the number of transmis-sions required. Next, we show that the performanceof the bordercast (Figure 1) protocol is optimal.

6. PERFORMANCE EVALUATION

The evaluation of bordercast was done using theSWANS simulator [22, 23], because of its scalabilityproperty of being able to simulate very large networks.To the best of our knowledge, the scale of thesimulations required for this work exceeds the capa-

AB

C

D

EF

G

H

I

J

K

S

zone(B)

zone(A)

R=2Fig. 2 A bordercast in progress: dark circles represent nodes that

node A believes are covered, nodes within ZoneðAÞTZoneðBÞ.

The query will now proceed towards the non-covered border nodes

of A, namely I, J, and K.

98 Haas and Barr

bility of most other publicly available general purposesimulation tools by at least an order of magnitude.

In the first experiment, we measure the relativeunit cost of each of the zone maintenance and querypropagation protocols discussed in Section 3 fornetworks of different sizes, but at constant density.We generate the network by placing wireless nodesrandomly within a square area and increase the areasize in proportion to the number of nodes. Eachnetwork node is turned on at time t = 0 with noinformation other than its own unique address. Theprotocol stack at each node comprises a wirelessradio, the 802.11b MAC, IPv4 network, UDP1

transport, and our test application components thatgenerate traffic. Other relevant protocols, such asNDP, for example, have also been implemented aspart of the simulation. Note that since the variousprotocols perform link-level broadcasts, the 802.11collision avoidance and retransmission mechanismsdo not play a role in these simulations. However,each of the simulated protocol incorporates jitter toreduce the probability of congestion and is alreadyresilient to point failures, either due to repetition(NDP) or due to a flooding-like behavior (IARP andBRP). The simulator accounts for signal interference,but neither for shadow fading nor for Raleigh fading.

We measure the unit packet cost of a protocol,which is defined as the number of packets sentthroughout the network to perform a single round oroperation. The unit cost of the IARP protocols is thenumber of packets for the protocol to quiesce, suchthat every node has learned its complete zone state.Since the nodes begin with no information, thismeasurement represents the worst case (or, alterna-tively, the largest mobility case) for the protocol,which is when the information about all the zonelinks must be communicated. The unit cost of abordercast operation is the number of packets trans-mitted to cover the entire network with a query. Forany fixed density, both of these protocols growlinearly with the area of the network or, equivalently,linearly with the number of nodes in the network,since we keep the density constant.

In Figure 3, we compare the performance ofquery propagation of flooding and bordercasting as afunction of node density. Each point represents theaverage of at least 10 runs. The graph shows how aflooding-based propagation grows in proportion to

the number of nodes, but that bordercast is densityindependent. In other words, adding more nodes tothe network does not increase the cost of bordercast-ing. Note that the left side of the curves represents avery sparse network that is poorly connected. In thiscase, both flooding and bordercast are simply notable to span the area because of the lack ofintermediate nodes. The x-axis shows both the totalnumber of nodes, as well as the network density interms of the expected average number of neighborsper node. This number of neighbors is computedfrom the node density and the transmission radius,i.e., E[l/k] = p r2(n/A). It matches the values reportedby NDP in simulation. Finally, we observe that bysetting the zone radius to 1, the performance ofbordercast degenerates to flooding. This is expected,since with R = 1 the border set becomes the neigh-bor set. The slight advantage of bordercast overflooding is merely an edge effect: edge nodes do notretransmit the query under the bordercast protocol,because all of their neighbors are already covered.

Increasing the zone radius improves the perfor-mance of bordercast only minimally, as shown inFigure 4. To eliminate the impact of the edges, theresults in the figure were obtained with opposite edgeswrapped around to create a torus.

Some smaller improvements due to larger zoneradii can be seen within the core of the network,where the protocol can sometimes ‘‘avoid’’ regionsthat are sufficiently sparse. These are, in some sense,‘‘internal edges’’ of the network. To highlight thisphenomenon, we present Figure 5, a spatial plot ofone of the smaller (n = 800, R = 4) simulationsplotted in Figure 4. The heavy circle at the bottomright highlights the query source. The circle�s radius

0,0 5,6.1 10,12.2 15,18.4 20,24.5 25,30.7 30,36.80

50

100

150

200

250Bordercast cost versus network density (wrapped)

network size (nodes in hundreds), network density (neighbour nodes)

pac

kets

sen

t p

er b

ord

erca

st

R=2R=3R=4

Fig. 3. Unlike flooding, for fixed network area, the bordercast cost

of query propagation is independent of the network density.

1 The results are not expected to be significantly different for

other transport-layer protocols.


equals the transmission radius, and lighter circlessurround nodes that transmitted the query. Thus, allnodes within circles receive the propagating query.Arrows represent the targeted neighbors, which mayrelay the query, if necessary. Notice that many nodesare not within these circles, which means they neverreceive the query. However, all the nodes are con-tained within 4 hop-sized circles around nodes thatactually receive the query, a close approximation of

the actual zones, indicating that the protocol iscovering the whole network. (Zone circles are omittedto improve the clarity of the figure.) One can also seean example of internal nodes in the center that arecovered, but without receiving the query.

Another interesting phenomenon shown by thespatial plot is that the targeted neighbors are usuallyfound near the boundaries of the transmission circles,even though there is no location information avail-able to the protocol. This occurs because the border-cast protocol tries to minimize the number of targetedneighbors by selecting those neighbor nodes that arecloser to (i.e., R)1 hops from) the largest number ofuncovered border nodes. A beneficial consequence isthat the chosen targets are more likely to be found atthe outer limits of the transmission range of the queryrelaying node.

We now turn to the cost of maintaining therequired zone state at each node. Shown in Figure 6is the effect of increased density on the number ofpackets sent by our two zone maintenance protocols:IARP-node and IARP-zone. We have plotted thecold-start scenario, where all the links in a zone mustbe discovered and added. In other words, thisrepresents the worst case in terms of mobility in the

Fig. 4. Discounting edge effects, bordercast cost is not significantly affected by increased zone radius.

0,0 5,6.1 10,12.2 15,18.4 20,24.5 25,30.7 30,36.80

5

10

15

20

25

30

35Zone maintenance cost versus network density


tota

l ban

dw

idth

to

qu

iesc

e (i

n M

byt

es)

IARP−node, R=2IARP−zone, R=2IARP−zone, R=2, compress

Fig. 5. An example 800-node, R = 4 bordercast plot.

100 Haas and Barr

network. As expected, the total number of the IARP-node packets (left axis) increase quadratically withthe density, i.e., O(k2), where k is the number ofnodes within the zone: each node sends O(k) packetsand there are more nodes in the network. In turn, thenumber of nodes within a zone increases quadrati-cally with the zone radius, and thus the total numberof packets in the network increases with the fourthpower of the zone radius! The R = 4 curve is actuallysignificantly lower than expected due to the largenumber of collisions caused by the flurry of link stateupdates in the large zone. However, since IARP-nodeis a flooding protocol, lost packets are often retrans-mitted by other neighbors and, with high probability,

any loss of information is local only. Nevertheless, itis interesting that the missing link state does notappreciably affect the bordercast performance dis-cussed earlier. As expected, the number of IARP-zone packets (right axis) increases linearly with thedensity, since each node sends a constant number ofpackets, forwarding the ‘‘waves’’ of new informationtraveling in each direction. The number of IARP-zone packets is not affected by the zone radius, sinceit merely passes along more information within thesame packet.

In Figure 7, we compare the average packet sizesof the two zone maintenance protocols. IARP-nodepackets (left axis) are very small, because they containthe link states of only a single node. In contrast,IARP-zone packets (right axis) contain informationabout changes to the entire zone. The size of thesepackets is proportional to the number of links, whichgrows quadratically with density and with the fourthpower of the zone radius. However, the more efficientencoding of this information saves around 60% ofthe packet size at the density of 30 neighbors pernode, independent of the zone radius. The compres-sion ratio increases with increasing network density,since the proportion of common link endpointsincreases with the density.

In Figure 8, we show the total bandwidthconsumed by each of the zone maintenance protocolsto quiesce starting from cold-start state. As before,this represents the worst case in terms of networkmobility. This figure integrates the two trends:

0,0 5,6.1 10,12.2 15,18.4 20,24.5 25,30.7 30,36.80

10

20

30

40

50

60

70

80

90

100

110



tota

l IA

RP

−no

de

pac

kets

to

qu

iesc

e (i

n t

ho

usa

nd

s)

0

1

2

3

4

5

6

7

8

9

10

tota

l IA

RP

−zo

ne

pac

kets

to

qu

iesc

e (i

n t

ho

usa

nd

s)

IARP−node, R=2IARP−node, R=3IARP−node, R=4

IARP−zone

Fig. 6. Cost of zone maintenance increases dramatically with

increased density and zone radius.

0

50

100

150

200

250

300

350

400

aver

age

log

ical

IAR

P−n

od

e p

acke

t si

ze (

byt

es)

0,0 5,6.1 10,12.2 15,18.4 20,24.5 25,30.7 30,36.80

1

2

3

4

5

6

7

8

9



aver

age

log

ical

IAR

P−z

on

e p

acke

t si

ze (

Kb

ytes

)

IARP−zone, R=2IARP−zone, R=2, compressIARP−zone, R=3IARP−zone, R=3, compress

IARP−node

Fig. 7. Aggregated link state can be encoded efficiently to reduce the average size of update packets.


smaller number of packets but larger average packetsize of the IARP-zone protocol. The two protocolstransmit the same amount of information, but IARP-zone outperforms IARP-node through efficientencoding of the update packets. The plotted datashow the packet payloads, not including packetheaders, to allow a meaningful comparison. Includ-ing packet header overheads would further benefit theIARP-zone results, since it transmits fewer, largerpackets.

We have considered, until now, the cost of ourprotocols under the worst case mobility scenario. Wenow discuss the behavior at lower topological rate ofchange. Both, the node discovery and the border-casting protocols are unaffected by the rate oftopological change in the network. However, mobil-ity can change the zone link state and its membership,which will necessitate zone maintenance. To measurethis cost, we create a random network and allow thezone maintenance protocols to quiesce. We thenmove each node a fixed distance in a randomdirection and measure the number of packetsrequired to update the zone information. This pro-vides us with a unit cost for zone maintenance as afunction of mobility. Figure 9 shows the total num-ber of IARP-node and IARP-zone packets for anetwork of 10,000 nodes. We see that the number ofpackets grows in proportion to the number ofchanges in the zone, but has an upper-bound thatcorresponds to the total amount of zone information.The lower line below each curve is the unit cost ofeach respective zone maintenance protocol from coldstart, shown in the previous figures. The upper line

above each curve is twice this value. The additionaltransmissions above the lower line are due to linkstate drop notifications, which do not occur from coldstart. Notice, however, that the IARP-zone costactually tends to decrease toward the lower line. Thispeculiar phenomenon results from IARP-zone prun-ing its link state after incorporating each updatepacket. This pruning is essential, because underIARP-zone, nodes will receive some link state thatis not relevant for their zone. And, if this new linkstate is forwarded on, the zone information at eachnode will eventually include the entire network. Anadded bonus of this pruning is that link failurenotifications are suppressed when a node has traveledso far out of its original zone as to be irrelevant.

To summarize, there exists an upper bound onthe zone maintenance cost, and this bound is inde-pendent of the rate of mobility. The incremental zonemaintenance cost, albeit a function of node density, isexpected to be very low. And, the route discovery costis, as shown earlier, independent of the node density.

7. DISCUSSION OF RESULTS

In what follows, we draw certain inferences andmake recommendations regarding the use of border-casting in ad hoc networks:

7.1. Bordercast rather than flood

Bordercast propagates queries with cost propor-tional to the the area of an ad hoc network (orequivalently, the network diameter), regardless of thedensity of nodes (or equivalently, the number of

0 0.5 1 1.5 2 2.5 3 3.5 4 4.5 50

25

50

75

100

125

150

175

200

225

250Zone maintenance cost under mobility

movement distance (in multiples of transmission radius)

tota

l pac

kets

to

qu

iesc

e (i

n t

ho

usa

nd

s)

IARP−nodeIARP−zone

Fig. 8. Comparing the two zone maintenance protocols shows that

zone-widelink update aggregation and efficient encoding can be

highly beneficial.

0,0 5,6.1 10,12.2 15,18.4 20,24.5 25,30.7 30,36.80

200

400

600

800

1000

1200

1400

1600

1800

2000Bordercast versus flooding


tota

l pac

kets

sen

t p

er p

rop

agat

ion

FloodBordercast, R=1Bordercast, R=2

Fig. 9 Mobility increases the cost of zone maintenance.

102 Haas and Barr

nodes). It can replace the flooding-based querypropagation found in many ad hoc routing protocols,as well as in other network querying operations, suchas resource discovery and some sensor network data-aquisition operations.

7.2. Set the zone radius to 2 hops

Setting a larger zone radius results in littlebordercast improvement and substantially increasesthe cost of zone maintenance, especially at highernetwork densities. Note that there may be otherreasons to have a larger zone, including proactiveroute maintenance and a high rate of route requestsrelative to the rate of link changes (i.e., a mostlystationary network). However, one of the contribu-tions of this article is the finding that bordercastperformance is not among those reasons.

7.3. Aggregate and compress link state updates

IARP-zone outperforms IARP-node, because itaggregates link state updates, thus transmitting fewerpacket headers and reducing the average packet sizethrough efficient encoding of links.

7.4. Properly set the transmission power

The transmission power should be set to reducethe transmission radius, while maintaining networkconnectivity. On the one hand, shorter transmissionradius settings reduce the zone membership and thecost of zone maintenance both in terms of packetsand in terms of transmission power per packet.However, on the other hand, a shorter transmissionradius implies a larger network diameter (in hops),which in turn implies longer latencies and morebordercast packets to cover the same area! (Note thatthe setting of the transmission radius also affects thecapacity of the network due to interference.)

This final point raises the question of whetherbordercast is necessary at all. In essence, bordercastingreduces the number of neighbors at the network level,rather at the physical level. If one can set thetransmission radius small enough, such that the(physical) network degenerates into a tree (i.e., anaverage of two neighbors per node), then floodingwould be equivalent to bordercasting in this case. Ofcourse, one ill effect of such a network is that theaverage route length along such a tree may increase

dramatically. In general, the benefits of bordercaststem from its ability to silence neighbors that are notrequired to propagate the query. If all the neighborsare required to relay the query, due to sparseness of thenetwork, then, indeed, bordercast would not exceedthe performance of flooding. However, lowering thetransmission radius is not always possible for anumber of reasons. These include fixed hardwarepower settings, increased probability of link breakageand route failure, overhead of power adaptationprotocol, increased number of hidden terminals,increased network diameter, increased average routelength and packet latencies, and decreased routediversity. Thus, if the number of neighbors cannotbe reduced at the link level, bordercast presents aviable alternative to do so at the network level,preventing unnecessary transmissions and ‘‘broadcaststorms’’ during propagation.

In this article, we have focused exclusively onwireless ad hoc networks. Other networking environ-ments that utilize flooding primitives may benefitfrom bordercast as well. The primary requirementsare only that multi-hop propagation is used and thatmore neighbors receive a message than are requiredto relay it to achieve complete network coverage.

8. CONCLUDING REMARKS

The scalability of ad hoc networks – the abilityto efficiently route and transmit packets across adhoc networks as they grow in size – is a key researchchallenge. In this article, we analyzed the cost ofdiscovering a route to some desired destination nodeusing only its unique address. We have presented thedesign of a bordercast protocol, a query propagationprotocol that is density-independent, and haveproven that it is optimal. Bordercast can improvethe performance of many existing routing protocolsin dense networks by replacing their flooding-basedquery propagation. Our results also show that:optimal bordercast performance does not requirezone radii larger than two hops; the cost of zonemaintenance is proportional to network mobility andis bounded; and, that aggregating and efficientlyencoding link state updates can substantially reducethe overhead of zone maintenance. Finally, we havehighlighted the importance of efficient zone-wideaggregation as a building block for scalable ad hocnetwork protocols.


ACKNOWLEDGMENTS

The work on this project was supported in part bythe U.S. National Science Foundation under the grantnumbers ANI-0329905 and CNS-0626751, by theDoD MURI (Multidisciplinary University ResearchInitiative) Program administered by the Office ofNaval Research (ONR) under contract N00014-00-1-0564, and by the MURI Program administered by theAir Force Office of Scientific Research (AFOSR)under contract F49620-02-1-0217. The authors thankRobbert vanRenesse, Benjamin Atkin, andChaitanyaSwamy for their ongoing help andvaluable suggestionsregarding this work. We also acknowledge KelwinTamtoro, Clifton Lin, Ben Viglietta, and Mark Fongfor their work on various SWANS and JiST compo-nents.We are indebted toAlinDobra andPaul Francisfor allowing us to use their computational resources torun simulations.

REFERENCES

1. P. Gupta, and P. Kumar, The capacity of wireless networks,Trans. on Info. Theory, Vol. 46, pp. 338–404, March 2000.

2. M. Grossglauser, and D. Tse, Mobility increases the capacityof wireless adhoc networks, IEEE/ACM Transactions on Net-working, Vol. 10, pp. 477–486, Aug 2002.

3. O. Arpacioglu and Z. J. Haas, On the Scalability and Capacityof Wireless Networks with Omnidirectional Antennas.IPSN�04, Berkeley, CA, April 26–27, 2004.

4. P. Samar, M. Pearlman, and Z. Haas, Hybrid routing: Thepursuit of an adaptable and scalable routing framework for adhoc networks. in Handbook of Ad Hoc Wireless Networks,CRC Press, 2003.

5. P. Samar, M. R. Pearlman, and Z. J. Haas, Independent zonerouting: An adaptive hybrid routing framework for ad hocwireless networks, IEEE/ACM Transactions on Networking,Vol. 12, No. 4, pp. 595–608, August 2004.

6. D. B. Johnson and D. A. Maltz, Dynamic source routing in adhoc wireless networks. inMobile Computing, Kluwer AcademicPublishers, 1996.

7. C. E. Perkins and E. M. Royer, Ad hoc on-demand distancevector routing, in Workshop on Mobile Computing Systems andApplications pp. 90–100, Feb. 1999.

8. B. Bellur and R. G. Ogier, A reliable, efficient topologybroadcast protocol for dynamic networks, in IEEE INFOCOM�99, March, 1999.

9. T. Clausen, P. Jacquet, A. Laouiti, P. Muhlethaler, A.Qayyum, and L. Viennot, Optimized link state routing proto-col, in IEEE INMIC, 2001.

10. M. Joa-Ng, I. -T. Lu, A peer-to-peer zone-based two-level linkstate routing for mobile ad hoc networks, IEEE Journal onSelected Areas in Communications, Vol. 17, No. 8, pp. 1415–1425, August, 1999.

11. V. Ramasubramanian, Z. J. Haas, E. Sirer, SHARP: A hybridadaptive routing protocol for mobile ad hoc networks, in ACMInternational Symposium on Mobile Ad Hoc Networking andComputing (MOBIHOC), June 2003.

12. N. Navid, W. Shiyi, and C. Bonnet, HARP: Hybrid Ad hocRouting Protocol International Symposium on Telecommunica-tions (IST).

13. Z. Cheng and W. Heinzelman, Flooding strategy for targetdiscovery in wireless networks, in ACM MSWiM, Sept. 2003.

14. S.-Y. Ni, Y.-C. Tseng, Y.-S. Chen, and J.-P. Sheu, Thebroadcast storm problem in a mobile ad hoc network, in ACM/IEEE International Conference on Mobile Computing and Net-working (MOBICOM), ACM Press, pp. 151–162, August1999.

15. Y. Sasson, D. Cavin, and A. Schiper, Probabilistic broadcastfor flooding in wireless mobile ad hoc networks, in IEEEWireless Communications and Networking Conference, March2003.

16. Z. J. Haas, J. Y. Halpern, and L. Li, Gossip-based ad hocrouting, in IEEE INFOCOM �02, June 2002.

17. V. K. Paruchuri, A. Durresi, D. S. Dash, and R. Jain, Optimalflooding protocol for routing in ad hoc networks, in IEEEWireless Communication and Networking Conference, March2003.

18. S. Guha, and S. Khuller, Approximation algorithms for con-nected dominating sets, Algorithmica, Vol. 20, pp. 347–387,1998.

19. J. Wu, H. Li, A dominating set based routing scheme in ad hocwireless networks, in International Workshop of DiscreteAlgorithms and Methods for Mobile Computing and Communi-cations, August 7–14, 1999.

20. B. Williams and T. Camp, Comparison of broadcasting tech-niques for mobile ad hoc networks, in ACM InternationalSymposium on Mobile Ad Hoc Networking and Computing(MOBIHOC), pp. 194–205, 2002.

21. I. Stojmenovic, M. Seddigh, and J. Zunic, Dominating sets andneighbor elimination-based broadcasting algorithms in wirelessnetworks, IEEE Transactions on Parallel and Distributed Sys-tems, Vol. 13, No. 1, pp. 14–25, 2002.

22. R. Barr, Z. J. Haas, and R. van Renesse, JiST: an efficientapproach to simulation using virtual machines. SoftwarePractice & Experience. Vol. 35, No. 6, pp. 539–576, John Wiley& Sons, May, 2005.

23. R. Barr, Z. J. Haas, JiST/SWANSwebsite http://jist.ece.cornell.edu, 2004.

Zygmunt J. Haas received his B.Sc. in EE in 1979 and M.Sc.

in EE in 1985. In 1988, after earning his Ph.D. from Stanford

University, he joined the AT&T Bell Laboratories, Network

Research Department. There he pursued research on wireless

communications, mobility management, fast protocols, optical

networks, and optical switching. From September 1994 till July

1995, Dr. Haas worked for the AT&T Wireless Center of

Excellence, where he investigated various aspects of wireless and

mobile network technologies. In August 1995, he joined the faculty

104 Haas and Barr

of the School of Electrical and Computer Engineering at Cornell

University, where he is now a Professor and the Associate Director

for Academic Affairs.

Dr. Haas is an author of numerous technical conference and

journal papers and holds eighteen patents in the areas of high-

speed networking, wireless networks, and optical switching. He

has organized several workshops, delivered numerous tutorials at

major IEEE and ACM conferences, and serves as editor of several

journals and magazines, including the IEEE Transactions on

Networking, the IEEE Transactions on Wireless Communica-

tions, the IEEE Communications Magazine, and the ACM/

Kluwer Wireless Networks journal. He has been a guest editor of

IEEE JSAC issues on ‘‘Gigabit Networks,�� ‘‘Mobile Computing

Networks,�� and ‘‘Ad-Hoc Networks.�� Dr. Haas served as a Chair

of the IEEE Technical Committee on Personal Communications

and is currently serving as the Chair of the Steering Committee of

the IEEE Pervasive Computing magazine. Dr. Haas is an IEEE

Fellow. His interests include: mobile and wireless communication

and networks, performance evaluation of large and complex

systems, and biologically inspired networks. His e-mail is:

[email protected] and his URL is: http://wnl.ece.cornell.edu.

Rimon Barr received an Honors B.Sc. from the University

of Toronto combining studies in Computer Science and Immunol-

ogy. At Cornell University, he received his M.Sc. for the design and

development of MagnetOS, a distributed operating system for

sensor networks, and his Ph.D. in Computer Science for demon-

strating a novel technique that permits the transparent optimiza-

tion and efficient execution of discrete event simulations over

virtual machines. His research interests lie in the areas of databases,

languages, distributed systems, and ubiquitous computing. In

tandem with his research, Rimon completed an MBA at Cornell’s

Johnson Graduate School of Management, and became interested

in micro-economics and quantitative finance. He currently works

on Wall Street, building high-performance data analysis tools,

researching predictive financial models, and trading.


density-independent, scalable search in ad hoc...

Documents