Beacon Location Service A Location Service for Point-to-Point Routing in Wireless Sensor Networks Jorge Ortiz, Chris R. Baker, Daekyeong Moon, Rodrigo Fonseca, Ion Stoica University of California, Berkeley {jortiz,crbaker,dkmoon,rfonseca,istoica}@eecs.berkeley.edu ABSTRACT In this paper we present Beacon Location Service (BLS): a location service for beacon-based routing algorithms like Beacon Vector Routing (BVR) [7]. The role of a location service is to map application-specific identifiers to virtual coordinates. BLS resolves the destination node’s identifier to BVR coordinates and then uses BVR to route the source message to the destination node. Together, BVR with BLS offers a complete solution for scalable point-to-point routing in sensornets. We describe our design and it’s implementation and evaluate BLS in sim- ulation and on a sensornet testbed. Our results show it can sustain high look-up and routing success rates (greater than 90% ) over various send rates and network sizes. We also compare our results to two existing point-to-point routing schemes for sensornets, and show that BLS+BVR performs better or comparably to state of the art point-to-point rout- ing protocols. Finally, we also demonstrate a simplified dis- tributed hash table application implemented over BLS. 1. INTRODUCTION While one-to-many and many-to-one routing techniques clearly provide much of the routing needs for wireless sen- sor networks, point-to-point routing is still important for many applications. One examples is the purser-evader-game (PEG) described in [6], where the nodes of the wireless sen- sor network build a tracking tree with the root as the evader. The pursuer may use a point-to-point routing scheme to tra- verse the tracking tree when searching for the evader. This type of routing may also be used for data-centric storage [19], where data is stored in specific locations in the net- work based on its name. In the original proposal a geo- graphic hash table is proposed, but if the network can route directly to names, this primitive can be used instead. Beacon Vector Routing, or BVR, is an existing point-to- point routing scheme for wireless sensor networks [7] that has guaranteed delivery, is robust with respect to a dy- namic network, and is simple and efficient. In BVR, nodes Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Copyright 200X ACM X-XXXXX-XX-X/XX/XX ...$5.00. have topology-derived virtual coordinates, defined as a vec- tor of distances to a subset of the nodes called beacons. Each beacon is the root of a minimum spanning tree. Rout- ing is accomplished by using greedy forwarding. The next hop is determined by a distance function over the current node’s and the destination node’s coordinates. On occasion, the forwarding mechanism reaches a local minimum for the distance function. At that point BVR resorts to routing the message to the beacon nearest the destination. This is known as fall-back mode. If the message cannot make progress towards the destination from the beacon, BVR re- sorts to scoped flooding to guarantee delivery. Additional details along with performance analysis in simulation and on a wireless sensor network testbed may be found in [7]. One of the main advantages of coordinate-based routing is its scalability, as nodes only need to know the coordinates of their neighbors. However, a node needs to obtain the coordinates of a destination before sending a message to it. Moreover, in the case of virtual coordinate based schemes, these may change over time as connectivity changes. We address this problem by presenting a location service which maps application-specific identifiers to virtual coordinates. Together, BVR and our Beacon Location Service (BLS) of- fers a complete solution for scalable point-to-point routing in sensornets. BLS is different from previous schemes for two main rea- sons: first, because it is adapted to the constraints of a sen- sor network. Memory capacity, processing power, and com- munication bandwidth are factors limiting the design and implementation which are not present or as severe in other systems such as the Internet or mobile ad-hoc networks. Sec- ond, because of particularities of BVR. BLS takes advantage from the fact that all nodes know how to reach all beacons. On the other hand, it cannot use schemes that hierarchi- cally divide the coordinate space, for it is not know how to do that for the BVR coordinate space. Lastly, because BVR’s coordinates are based on topology and connectivity, they may change over time, and there is an added complexity in maintaining appropriate state with minimal overhead, as opposed to other coordinate-based schemes (i.e. which use static geographic coordinates). The rest of this paper is organized as follows: related re- search efforts are discussed in §2. Following this, we discuss the design (§3) and implementation (§4) of the BLS. We present our evaluation in §5, and §6 concludes the paper. 2. RELATED WORK There are several research efforts focused on point-to-
Transcript
Beacon Location Service
A Location Service for Point-to-Point Routing in Wireless Sensor Networks
Jorge Ortiz, Chris R. Baker, Daekyeong Moon, Rodrigo Fonseca, Ion StoicaUniversity of California, Berkeley
ABSTRACTIn this paper we present Beacon Location Service (BLS):a location service for beacon-based routing algorithms likeBeacon Vector Routing (BVR) [7]. The role of a locationservice is to map application-specific identifiers to virtualcoordinates. BLS resolves the destination node’s identifierto BVR coordinates and then uses BVR to route the sourcemessage to the destination node.
Together, BVR with BLS offers a complete solution forscalable point-to-point routing in sensornets. We describeour design and it’s implementation and evaluate BLS in sim-ulation and on a sensornet testbed. Our results show it cansustain high look-up and routing success rates (greater than90% ) over various send rates and network sizes. We alsocompare our results to two existing point-to-point routingschemes for sensornets, and show that BLS+BVR performsbetter or comparably to state of the art point-to-point rout-ing protocols. Finally, we also demonstrate a simplified dis-tributed hash table application implemented over BLS.
1. INTRODUCTIONWhile one-to-many and many-to-one routing techniques
clearly provide much of the routing needs for wireless sen-sor networks, point-to-point routing is still important formany applications. One examples is the purser-evader-game(PEG) described in [6], where the nodes of the wireless sen-sor network build a tracking tree with the root as the evader.The pursuer may use a point-to-point routing scheme to tra-verse the tracking tree when searching for the evader. Thistype of routing may also be used for data-centric storage[19], where data is stored in specific locations in the net-work based on its name. In the original proposal a geo-graphic hash table is proposed, but if the network can routedirectly to names, this primitive can be used instead.
Beacon Vector Routing, or BVR, is an existing point-to-point routing scheme for wireless sensor networks [7] thathas guaranteed delivery, is robust with respect to a dy-namic network, and is simple and efficient. In BVR, nodes
Permission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies arenot made or distributed for profit or commercial advantage and that copiesbear this notice and the full citation on the first page. To copy otherwise, torepublish, to post on servers or to redistribute to lists, requires prior specificpermission and/or a fee.Copyright 200X ACM X-XXXXX-XX-X/XX/XX ...$5.00.
have topology-derived virtual coordinates, defined as a vec-tor of distances to a subset of the nodes called beacons.Each beacon is the root of a minimum spanning tree. Rout-ing is accomplished by using greedy forwarding. The nexthop is determined by a distance function over the currentnode’s and the destination node’s coordinates. On occasion,the forwarding mechanism reaches a local minimum for thedistance function. At that point BVR resorts to routingthe message to the beacon nearest the destination. Thisis known as fall-back mode. If the message cannot makeprogress towards the destination from the beacon, BVR re-sorts to scoped flooding to guarantee delivery. Additionaldetails along with performance analysis in simulation andon a wireless sensor network testbed may be found in [7].
One of the main advantages of coordinate-based routingis its scalability, as nodes only need to know the coordinatesof their neighbors. However, a node needs to obtain thecoordinates of a destination before sending a message to it.Moreover, in the case of virtual coordinate based schemes,these may change over time as connectivity changes. Weaddress this problem by presenting a location service whichmaps application-specific identifiers to virtual coordinates.Together, BVR and our Beacon Location Service (BLS) of-fers a complete solution for scalable point-to-point routingin sensornets.
BLS is different from previous schemes for two main rea-sons: first, because it is adapted to the constraints of a sen-sor network. Memory capacity, processing power, and com-munication bandwidth are factors limiting the design andimplementation which are not present or as severe in othersystems such as the Internet or mobile ad-hoc networks. Sec-ond, because of particularities of BVR. BLS takes advantagefrom the fact that all nodes know how to reach all beacons.On the other hand, it cannot use schemes that hierarchi-cally divide the coordinate space, for it is not know howto do that for the BVR coordinate space. Lastly, becauseBVR’s coordinates are based on topology and connectivity,they may change over time, and there is an added complexityin maintaining appropriate state with minimal overhead, asopposed to other coordinate-based schemes (i.e. which usestatic geographic coordinates).
The rest of this paper is organized as follows: related re-search efforts are discussed in §2. Following this, we discussthe design (§3) and implementation (§4) of the BLS. Wepresent our evaluation in §5, and §6 concludes the paper.
2. RELATED WORKThere are several research efforts focused on point-to-
point routing in ad-hoc wireless sensor networks. Each pro-posal can be categorized into a specific type of scheme:shortest path based (e.g. AODV [5], DSDV [17]), geographiccoordinates-based (e.g. GPSR [11], GOAFR+ [13]), vir-tual coordinate-based (e.g.No-Geo [18], GEM [16], BVR [7]),hierarchical (e.g. Landmark [22]), and DHT-Based (e.g.VRR [4]). Of these, all but the shortest path and the DHTschemes need a location service to route to names.
The recently proposed Virtual Ring Routing (VRR) [4]scheme borrows from overlay routing algorithms in DistributedHash Tables (DHT). VRR does not require a location ser-vice. All node identifiers are mapped to a logical ring ofidentifiers. When a sender wants to send to a destinationnode, the packets are routed using these identifiers over thelogical ring. To maintain the ring, each node keeps paths toits two logical successors and two logical predecessors in thering. Packets make greedy progress throughout the networkby minimizing the difference between the next hop’s id andthe destination node’s id until the packet reaches the des-tination. VRR is quite effective in providing scalability inpoint-to-point routing for sensor networks. Although quitedifferent from our location service it is directly comparablein flexibility, workloads, overhead, and routing success rate.In the evaluation section we address these comparisons di-rectly through experimentation. We refer the reader to [7]for more details on point-to-point routing related work, andnow focus on work related to location services.
One way to determine a destination node’s location isthrough a service that relies on flooding of information.There are many works that take this approach (e.g. AODV[5], DREAM [3], and LAR [12]). In general flooding is notscalable for large distributed systems; several studies haveshown a large variance in broadcast reliability in low-powernetworks [20, 23, 24]. We believe that a location servicewhich relies on flooding has too high a cost for the limitedresources of sensornets. Therefore, we do not pursue thisclass of routing/location service protocol further in this sec-tion. However, we will revisit this in our evaluation whenwe compare our location service with the ZigBee [2] stan-dard routing protocol, AODV. The remainder of this sectionwill focus on work related to location services not relianton flooding. We cite three representative examples: VRR,GLS, and Landmark.
The Grid Location Service (GLS) [15] is a scalable loca-tion service for geographic ad-hoc routing. It is designedprimarily for mobile cell phones with GPS. GLS takes adecentralized approach by distributing the location infor-mation about the network through local decision making.All nodes act as location servers. Each node periodicallypublishes its location-to-id mapping to a set of nodes in thenetwork. It chooses these nodes based on a predeterminedgrid hierarchy. Nodes wishing to send to a destination usethe same hierarchy to find the closest location server. Thelocation server forwards the packet to the destination; uponreceiving the packet, the destination node can reply with itscoordinates.
There are several key differences between GLS and ourapproach. First, the coordinate system created in BVR isnot amenable to a grid hierarchy1 Second, GLS has a dif-ferent model for it’s nodes. The nodes are assumed to be
1BVR does not lend itself to straightforward decompositionof space because BVR coordinates are not Cartesian. GLSdepends on spacial decomposition.
mobile, GPS enabled, compute and memory capable, andnot power constrained. Third, location servers in BVR arethe beacons themselves, not arbitrary nodes. Finally, in ourlocation service, beacons do not forward queries but insteadreturn the location of the requested node.
The Landmark [22] routing system employs a similar lo-cation service to GLS. The location service maps node idsto coordinates. These coordinates, or Landmark Address, isa set of node identifiers of designated landmarks (in orderof decreasing area covered by each landmark) to which thenode is positioned closest. Each node publishes its land-mark address information to a location server by hashingits own id and using the result as the landmark address forthe location server. If no location server exists at that land-mark address, the node with the closest landmark addressacts as the location server. Similar to GLS, a node wisingto send a packet uses the same process (when the mappingwas published) to find the location server.
Landmark routing’s location service is more similar to ourapproach than GLS, however, again, beacons are the loca-tion servers because all nodes automatically know how toroute to beacons. We adopt the same method of queryingthe location server and sending directly, however we add ad-ditional optimizations to combat look-up latency and nodefailure.
3. DESIGNThe simplest way to implement the location service would
be to use a single node as the location server responsible formaintaining coordinates. All nodes know the coordinates ofthis server and retrieve the mapping from this server di-rectly. Alternatively, the location service could take theflooding approach to determine destination coordinates on-demand. The problem with these schemes is that they don’tscale to large sensor networks.
Instead we adopt a distributed approach. We leveragethe fact that BVR has a subset of the nodes that all othernodes know how to get to: the beacons2. The design is reallysimple: nodes that need to be reached periodically publishtheir coordinates to a beacon, deterministically chosen fromthe node’s ID. When node A wants to reach a node withid B, it uses the same algorithm to chose a beacon basedon B, and sends a look-up message to the beacon. Thebeacon replies to A, which can then send a message to B.As we describe below, we use consistent hashing to choosebeacons. This is a rendezvous scheme, and is illustrated inFigure 1.
3.1 Beacon ResolutionBeacon resolution is important for the location service in
two ways: for nodes to query the destination node’s coordi-nates given a node identifier, and to publish their coordinatesto beacons.
To avoid undesirable effects when adding new beaconswe use a simple implementation of consistent hashing [10]for beacon resolution. This algorithm uses a simple hashfunction to map the node identifier as a key into a hashvalue. Each of the beacon identifiers are also hashed andthen sorted in a logical ring similar to Chord [21]. The nodeidentifier hash value is used to find the appropriate beacon
2This may also be true in other beacon based routing algo-rithms, in which case BLS could also be used
A B
1
send(B_coords,data)
query(B) publish(B,B_coords)
reply(B_coords)
Figure 1: Rendezvous scheme of BVR location ser-vice. Node A is sending to node B; each rendezvousat beacon 1.
responsible for that node: the first beacon identifier whosehash value is greater than or equal to the node identifier’shash value. If all hash values are less than the node iden-tifier’s hash value, then the mapping wraps around to thebeacon with the lowest hash value. Simply stated, the firstbeacon hash value in the clockwise direction from the hashvalue of the node is the beacon responsible for storing thatnode’s coordinates.
Our implementation of consistent hashing uses the bea-con identifier (which is a different name-space from the nodeidentifier) as the key. The advantage of hashing on the bea-con identifier, rather than node identifier, is that upon thebirth of a new beacon (in the case of a previous beacon fail-ure), the beacon identifier does not change. Beacon electionis discussed in §3.5. The new beacon simply takes the oldbeacon’s place with respect to the beacon identifier. All ofthe nodes that mapped to the old beacon would map to thenew beacon. Furthermore, this implementation has the ad-vantage of minimal movement of mappings if new beaconsare added dynamically (in addition to original beacons)3.
3.2 Coordinate PublishingNodes must publish their coordinates to beacons. Pub-
lishing, and sending updates, is triggered by three events:a timer expires, a beacon is added to the network, or thelocal coordinates change. The first is motivated by the factthat the beacons keep the id-to-coordinate mappings as soft-state. Furthermore, mappings may also be evicted from thebeacon’s cache. The expiration of the timer (with randomjitter) ensures the local coordinates remain fresh with theappropriate beacon and do not synchronize with other up-dates. Another reason for sending updates is when a beaconis added to the network. The node may have to republish it’scoordinates to a new beacon. Finally, when a node’s coordi-nates change, it must publish to the beacon to ensure correctrouting. Since BVR is robust enough to handle slightly stalecoordinates we can reduce the coordinate publishing rate tominimize BLS-related traffic.
The beacon processes updates of node mappings. Thebeacon will store these values in a small table. If the id-to-coordinate mapping already exists, the coordinates arerefreshed; otherwise an entry is replaced in the cache.
3.3 Coordinate Look-upCoordinate look-up is the part of the location service by
which a node desiring to send a message to a destination
3Under a constant number of beacons, simple modulo andthis implementation of consistent hashing have the same ef-fect.
receives the destination node’s coordinates given the desti-nation node’s identifier.
Beacons act as location service repositories. The basiclook-up algorithm consists of the node sending a query tothe appropriate beacon via the network. Because of thenature of the BVR coordinate system, all nodes can auto-matically route to any beacon. The appropriate beacon isdetermined using beacon resolution described in §3.1. Oncea beacon receives a query packet, it searches through its localcache and returns coordinates of a matching entry. If thereis no matching entry, an error is returned to the sendingnode. Instead of the location service querying the beacon,the following simple techniques can be employed locally asan optimization to the basic look-up algorithm:
1. The Neighbor Table contains nodes which are consid-ered neighbors by BVR’s link estimation. By lookingup the destination in the neighbor table, the sendingnode may short-circuit more expensive retrieval froma local cache (i.e. if implemented in FLASH memory)or the network (via beacons).
2. The Local Cache stores mappings between node co-ordinates and identifiers which have previously beenqueried from the beacons.
3.4 EavesdroppingThe purpose of using distributed look-up servers is to dis-
tribute traffic and processing overhead across the network.The more beacons we assign in a given network, the bet-ter the load will spread across multiple paths. However,increasing the number of beacons also increases the packetsize, since BVR coordinates have the same number of com-ponents as beacons. Therefore we must be careful to balancethe network load across more routes and maintain a reason-able packet size. Because this is not easy to configure and itis unclear how to optimize, we are not convinced that addingbeacons is the correct solution.
With beacons as look-up repositories, we introduce a con-gested paths problem, whereby the route to each beaconbecomes congested with look-up queries. This is a prob-lem often encountered on the Internet, when a server withlimited capabilities has an object of interest to many peopleand machines along the path to the server become congested.We address this problem with BLS eavesdropping: an inter-mediate node learns (caches locally) coordinate informationfrom reply and publish packets when forwarding locationservice traffic. If a node has the answer to a query directedto a beacon it may send a reply on behalf of a beacon ratherthan forwarding the query along the path.
The opportunistic caching takes advantage of reply andpublishing traffic that traverses the nodes along the path toa beacon. This may be best for workloads where the numberof destinations is larger than the local cache so that nodesare often performing look-ups to the beacons. Furthermore,if a node fails to receive a reply for a query, upon resend itmay set a flag such that intermediate nodes do not intervene,and the reply may only originate from the beacon. Thetrade-off for eavesdropping is reduced query-reply latencyand more evenly distributed location service traffic, versus“staleness” of coordinates and increased memory footprint.
3.5 Beacon Election
Beacon election is the process by which a new beaconis elected when a current beacon fails. Beacon election isimportant to both BVR and the location service becausewithout a sufficient number of beacons, routing (and the lo-cation service) may fail. Beacons fail due to many factors,some of which may include poor link quality or running outof energy. How does the network determine that a beaconshas failed? A beacon is assumed to have failed if its neigh-bors have not heard from it over some period of time. Oncea beacon has failed its neighbors initiate the beacon electionprocess to determine the failed beacon’s successor.
The beacon election algorithm is as follows: upon time-out, nodes which are one-hop neighbors of the failed beaconbegin broadcasting their election key to elect themselves asa new beacon. The election key is a value used to establishpriority in determining an election winner. Intermediatenodes receive beacon election broadcasts and accept the an-nouncement of the candidate nodes with the highest priorityelection key. For a period of time, the network is attempt-ing to converge on a new beacon. During this period eachnode ages the current candidate beacon and their electionkey, while repeating this information with their own periodicupdates of their coordinates to the network. If at any timethe beacon and election key are replaced, then the agingstarts over. When a sufficient age is reached, the intermedi-ate nodes cease repeating the newly elected beacon and it’selection key. At this point the network has likely convergedon a new beacon. However, if a new message with a highpriority and new beacon is received, the node falls back tobeacon-election mode. The time-out mentioned earlier is setsuch that nodes more likely to become beacons (i.e. thosewith higher priority election keys) will begin the electionfirst.
Nodes that hear new beacon-election packets suppress theircampaign messages (with their election key) if any messagecontains a higher election key than their own. If that nodedoes have a higher priority election key, then it will begincampaigning. Eventually lower priority nodes will hear thehigher priority candidate beacon and quit campaigning.
Currently, the beacon election key is set such that thenewly elected beacon will cause the least disruption to theexisting coordinates of nodes in the network. BVR managesa spanning tree for each beacon in the network. Choosinga neighbor of a beacon as a replacement means choosingamong the root nodes of subtrees in the spanning tree. Ourheuristic gives higher priority election keys to those subtreeroot nodes with the most connections to other subtree roots.The reasoning is that if the newly elected beacon also hasan edge to another subtree root, then the coordinates of thenodes in that subtree will not change with respect to thatparticular beacon.
4. IMPLEMENTATIONOur prototype uses TinyOS [1, 9] and approximately 3500
lines of NesC [8] code. The location service and BVR com-bined occupy approximately 3700 bytes of RAM. The localand beacon caches are small fully-associative cache contain-ing node identifier-to-coordinate mappings. Once the cacheis full, entries are replaced using a LRU-clock replacementpolicy. When a node performs a look-up and is waitingfor a reply from the beacon, the message is queued to asend buffer in the location service, each with it’s own querytimer. The query timer is responsible for checking if a pre-
vious query has completed and signaling the interface withthe appropriate result for the layer above the location ser-vice (e.g. an application). If the query is still busy, it isassumed the query was lost and a new query is sent. Onlyone additional re-send is made before the interface signalsfailure. Each time a resend occurs, the time-out interval isincreased exponentially.
5. EVALUATIONOur goal is to evaluate BLS in a simulation environment
to verify its functionality, establish the necessary param-eters for operation, and motivate potential improvements.We also use simulations to evaluate the scalability of ourdesign. Then we deployed BLS/BVR on a sensornet testbedto further validate those results. On the testbed we performtwo experiments: 1) to measure the location service perfor-mance given the parameters established in simulation, and2) compare the performance of BLS/BVR to two point-to-point routing schemes – tinyAODV and VRR. Finally, wedemonstrate an application running on our system and showsome performance results.
5.1 MetricsTo evaluate our location service, we use the following per-
formance metrics:
• Location Service Traffic BLS introduces additionalnetwork traffic due to publishing, queries, and replies.With this metric we evaluate the amount of overheadin the number of messages sent and received (includingforwarding) by all nodes in the network. Our goal isto minimize this metric and distribute it evenly acrossall the nodes.
• Total Hopcount Per Route Query For our exper-iments, this measure is actually evaluated in the worstcase. Because we do not use local caching, all sendrequests require a coordinate look-up before routingthe data packet to the intended destination. The useof local caching and eavesdropping is to minimize theaverage hopcount per route query to an amortized costsimilar to a normal BVR route query.
• Location Service Success Rate This is the numberof replies divided by the number of queries, not count-ing resent queries, and duplicate or late replies. Thismetric illustrates the ability of BLS to supply the re-quired coordinates (implies success in publish attempt,query, and reply) without routing to the destination.
• Total Routing Success Rate Finally, this metricshows, from the application’s perspective, the successrate when routing to a destination; it includes thesuccess rate of BLS (publish, query, reply) and BVR(routing with given coordinates to the destination).
5.2 MethodologyAll experiments for BLS are with look-ups in the local
cache and neighbor table turned off; this represents theworst case for BLS because every request to send to a desti-nation results in a look-up query. The cache at each beaconis sized such that all nodes which publish to that beacon willfit in the cache. This setup allows us to focus on the perfor-mance of BLS without the added complexity in dealing with
caching policy or cache sizing. BLS performance can be ar-bitrarily improved by increasing the cache size, at the costof memory footprint and look-up latency. For each exper-iment a warm-up period of several minutes allows the linkestimators, BVR coordinate system, and node publishing tostabilize.
Our simulation results are generated using a TinyOS, bit-level radio simulator [14] known as TOSSIM. We use fivenetwork sizes (25, 50, 100, 200, and 400 nodes) with thefollowing properties: constant number of randomly placedbeacons, each network is routable by plain BVR with at leasta 90% success rate, and each network has approximatelythe same node density. We use the lossy radio model toapproximate testbed conditions.
Our testbed experiments consisted of 35 Berkeley mica2dot
(Chipcon CC1000 433MHz radio, 4KB RAM, 128KB ROM)wireless sensor motes. All motes are connected via an Ether-net back-channel enabling remote programming, debugging,and logging. The send rate is the aggregate rate at whichnew queries are introduced into the network as a whole,measured in queries per second or q/s. Successful queries(which reach the beacon and reply with a positive result)result in a dummy data packet sent to the destination.
5.3 BLS with BVR: Results in TOSSIMThe experiments in this section are designed to measure
BLS performance and overhead with respect to our evalua-tion metrics in the TOSSIM simulator. Due to space limi-tation we do not present the results for beacon election andseveral performance-tuning experiments we ran in simula-tion.
5.3.1 Parameter TuningWe tuned the system parameters in simulation until we
achieved adequate performance to run in a testbed environ-ment. Table 1 shows a short summary of the tuned parame-ter values in TOSSIM. These values were set to balance theperformance with the memory footprint as we were limitedto only 4KB of RAM on the mica2dot motes.
Memory constraints have a direct impact on the efficacyof both the routing layer’s performance as well as the perfor-mance of BLS. For example figure 2 shows the transmissionstretch in BVR as you increase the number of beacons. In-creasing the number of beacons causes the average stretch todecrease and the routing performance to improve (for moredetails refer to [7]). However, increasing the number of bea-cons increases the amount of state each node must keep andincreases the memory footprint. Furthermore, the perfor-mance of BVR directly affects the performance of BLS, asit sits directly above BVR.
5.3.2 Simulation PerformanceWe ran BLS in simulation over various send rates and
network sizes to determine the performance range of BLS.Specifically we were concerned in the third bullet in our listof evaluation metrics: location service success rate. Figure3(a) were the first set of results collected from TOSSIM.For these experiments we turned of both eavesdropping andlocal cache/neighbor table look-ups. Therefore all send re-quests initiated a look-up query/reply in BLS in additionto a normal BVR data packet to the destination. For theseexperiments we attempted to improve the performance byadding more beacons for larger networks and spread out the
1
1.2
1.4
1.6
1.8
2
10 20 30 40 50 60 70 80
Tra
nsm
issi
on S
tret
ch
Number of Beacons
Low Density, w floodHigh Density, w flood
Low Density, w/o floodHigh Density, w/o flood
Figure 2: The average number of message sent perroute query in the testbed.
Figure 3: BLS location service success rate resultsobtained in simulation.
message load in congested paths. However the results re-mained poor; the added BLS message load was too muchfor the network to handle.
Figure 3(b) was collected with the same experimentalsetup but with the eavesdropping feature turn on. The re-sults were dramatically different and shows the efficacy ofeavesdropping in improving overall BLS performance. With-out needing to increase the number of beacons larger than 8,we were able to route BLS query/reply packets with greaterthan 85% success rate for a 400 node network.
5.3.3 Effects of EavesdroppingWe performed two experiments in simulation to demon-
strate the effects of eavesdropping to reduce the BLS mes-sage overhead. One experiment use 35 nodes (similar toour testbed size), and the other experiment used 100 nodes.Both experiments where set up with the same parametersand sent a total number of messages proportional to thenetwork size. Our hypothesis was that eavesdropping wouldreduce the total number of BLS messages, where BLS mes-
Table 1: Parameter values tuned in simulation.
Parameter Value Notes
Update Frequency 100sec 95% registration within 2 updatesInitial Query Timeout 5sec Exponential IncreaseQuery Resends 1 More resends minimally effect performanceServer Reply Buffer Entries 4 Beacons may handle concurrent queriesServer Cache Size #motes/#beacons
Table 2: Statistics showing effects of eavesdroppingon BLS message overhead in simulation.
sages consist of the query and reply messages sent and re-ceived for each node. Figure 4(b) and Figure 4(c) showthe CDF for the number of BLS messages sent by a per-centage of nodes in the network for the 35 and 100 nodenetworks. For each experiment, one can see that eavesdrop-ping did reduce the number of BLS messages. Table 2 givesthe statistics showing the effects of eavesdropping on BLSmessage overhead in simulation. On average, the reductionof BLS messages was 26.8% for the 100 node network ver-sus only a 16.4% reduction on the 35 node network. Thisdemonstrates while eavesdropping reduces the BLS messageoverhead per node, that larger networks reap more dramaticimprovements with eavesdropping than smaller networks.
5.4 BLS with BVR: Results in TestbedThe results with eavesdropping were so compelling that
we decided the run all of our experiments on the testbed witheavesdropping enabled. Therefore, unless otherwise stated,eavesdropping is enabled for all of the testbed results pre-sented in this section.
5.4.1 BLS Success RateFor these experiments, three independent trials were run
each with the same send rate. The results of each trialfor a particular send rate are averaged. Source and des-tination motes are chosen randomly. Figure 5 shows theresults from these experiments. As shown in Figure 5, thelocation service can maintain a high success rate (greaterthan 85%–both routing and total) over a range of send rates(0.1 − 2q/s). The total routing success rate will always beless-than or equal to the location service success rate be-cause it includes the routing of data packets (which mayfail).
BLS success rate and total routing success rate decrease asthe send rate increases, due to increased load in the network.The load in the network is observed as “stuck” or “con-tentious” routes. Contention is caused by the send or for-ward interfaces of a node being busy when a packet needs tobe sent. Stuck routes are those which cannot make progress;
0
0.2
0.4
0.6
0.8
1
0 50 100 150 200 250 300 350
Per
centa
ge
of
No
des
BLS Messages (sent + received)
w/ Eavesdroppingw/o Eavesdropping
(a) Testbed result with and withouteavesdropping.
0
0.2
0.4
0.6
0.8
1
0 50 100 150 200 250 300 350
Per
centa
ge
of
Nod
es
BLS Messages (sent + received)
w/ Eavesdroppingw/o Eavesdropping
(b) Simulation result with and with-out eavesdropping (35 nodes).
0
0.2
0.4
0.6
0.8
1
0 200 400 600 800 1000 1200
Per
centa
ge
of
Nodes
BLS Messages (sent + received)
w/ Eavesdroppingw/o Eavesdropping
(c) Simulation result with and with-out eavesdropping (100 nodes).
Figure 4: Effect of eavesdropping on BLS messageoverhead (queries and replies sent and received) insimulation and on the testbed
0
0.2
0.4
0.6
0.8
1
0 0.2 0.4 0.6 0.8 1 1.2 1.4 1.6 1.8 2
Succ
ess
Rat
e
Send Rate (q/s)
Total Success RateLS Success Rate
Figure 5: BLS query/reply success rate as well asthe overall routing success rate from the perspectiveof the application (Total Success Rate).
Table 3: Statistics showing effects of eavesdroppingon BLS message overhead in testbed.
either the BVR coordinate system has broken down, or theparticular node cannot route to any of its neighbors. In bothcases, the packet is dropped. Also, due to the increase in net-work congestion, the latency (not shown) between sending aquery and receiving a reply increases linearly with the sendrate. These problems are part of the much larger questionof resource sharing (e.g. congestion avoidance or control) insensornets.
5.4.2 Effects of EavesdroppingWe wanted to show the effects of eavesdropping in the
testbed as well, however, we only have a relatively smallnetwork to work with. We set up the same experiment as be-fore and measured the BLS messages overhead. Figure 4(a)shows the CDF plot of the number of BLS messages sentby a percentage of nodes. This data backs up the findingsgiven in §5.3.3. Table 3 summarizes the statistics of theeavesdropping effects on this small testbed network. Again,there is a slight improvement with eavesdropping: 11% re-duction in the average number of BLS messages per node.We believe that if we were to run this same experiment ona larger testbed, we would expect to see similar results tothose shown in Figure 4(c).
5.4.3 BLS HopcountWe set out to evaluate hopcount distributions for a BLS
when routing to a destination node. This consists of queriesand replies, to and from the beacon, as well as the data routeto the destination. We wanted to determine the hopcountdistribution of these three types of BLS messages, as well as,how the overall hopcount changed with varying send rates.Again, we ran these experiments with local-caching turnedoff so that each route request requires a coordinate look-upquery to a beacon4.
Figure 6(a) shows the hopcount distribution over various
4Therefore, in the best case, the minimum total hopcountto a destination is 3 (i.e. one query, one reply, and one dataroute).
1
1.5
2
2.5
3
3.5
4
4.5
5
0 1 2 3 4 5 6 7 8 9 10
Aver
age
Hop C
ou
nt
Send Rate (q/s)
TotalQueryReply
Data
(a) Average hopcount distributionper send rate.
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
1 2 3 4 5 6 7 8 9
Rat
io
Hop Count
QueryReply
Data
(b) Representative hopcount distri-bution run (10q/s).
Figure 6: BLS Hopcount distributions for differentmessage types.
send rates. Notice that the average hopcount for all threemessage types changes very little. BVR is fairly consistentin the routes it chooses to get to and from beacons. Theoverall average hopcount stays relatively consistent around4.8 hops per route, indicating that on average an attempt toroute to a destination takes 1.8 additional hops more thanthe absolute minimum of 3. Figure 6(b) shows the hopcountdistribution for various BLS traffic for a specific, but rep-resentative, run on the testbed. The hop count values foreach type (e.g. Query) are normalized to the total numberof messages of that type. This figure shows approximately70% of the Queries and Replies require only 1 hop.
5.5 BLS/BVR vs. tinyAODVThe goal of this experiment is to compare the perfor-
mance of BVR (with the location service) to a sensornet im-plementation of Ad-hoc On-demand Distance Vector rout-ing (tinyAODV). The code for tinyAODV has previouslybeen tested in simulation; we deployed and debugged iton the testbed for this comparison. Despite that fact thattinyAODV uses flooding we included it in the evaluationbecause it is the ZigBee standard routing protocol.
5.5.1 Experimental Setup for ComparisonOur experiments for comparison between the two proto-
cols consisted of routing packets between sources and desti-nations in such a way so as to highlight the actual routingperformance and not the effects of caching policies in ei-ther protocol. Since the destination cache size in the AODVcode was 7, we chose a destination set of size 7 and testedthe routing success from a random source to a destinationnode. Clearly the cache size can be easily adjusted to fitthe number of destinations you wish to set up routes to,
but whatever value you choose is mostly inconsequential, asdemonstrated below.
The components of the experiment consists of a destina-tion set, a sub-destination set, a source set, and a sub-sourceset. The destination set D is a static set of nodes cho-sen randomly from the testbed. It is the set of all possibledestinations where packets may be routed to. There are 7nodes in the destination set (the same size as the cache intinyAODV). The sub-destination set (d) contains randomlychosen subset of destinations from the destination set D;the sub-destination set varies in size from 1, 2, . . . 7. Theremaining 28 nodes are in the source set S. These nodes allgenerate traffic to be routed to a node in the destination set.The sub-source set (s) contains a randomly chosen subset ofsources from the source set; the sub-source set varies in size(|s| = {1, 5, 15, 28}).
For this experiment we attempted to route 20 messagesfrom each source in the sub-source set to each destinationin the sub-destination set at the send rate of 1q/s. FortinyAODV, we did not count the first send request to eachdestination as this request was used to establish a route(by flooding) to the destination address in the send requestpacket. For this experiment, local caching in the locationservice is enabled with the cache size set to 7 entries. Thesuccess rate is determined by the total number of send re-quests made divided by the total number of unique packetsreceived at the destination.
5.5.2 ResultsFigure 7 shows the results of these experiments. The sub-
destination set size is varied along the x-axis while the y-axisshows the total routing success rate. There are separatecurves for each sub-source set size. From Figure 7(a) onecan see that BVR with the location service is minimally af-fected by the size of either source or destination subsets,enabling it to route with greater that 90% success rate forall cases. Figure 7(b) shows the results for the same experi-ment using tinyAODV. Here we see that for a single source,the performance is the best over a range of destination sub-sets, however, when additional sources begin sending to thedestination subset, the performance drops significantly.
The underlying reason for the bad performance of tinyAODVis the use of flooding to establish routes between sources anddestinations. When we examined the cache hit rate in the lo-cal tinyAODV cache, we noticed the plot closely resembledthe overall success rate. We also noticed that the successrate was above 90% when a route was in the local cache.This suggests that the routing success rate is driven by theefficacy of route establishment. Since routes are establishedwith network floods, as you increase the number of sourcestrying to establish routes, you decrease the likelihood thata route will be successfully established. Unfortunately wecould not include those graph due to space constraints.
Overall these experiments demonstrate that BVR withthe location service allows for more flexibility in the behav-ior of applications requiring point-to-point routing. UsingtinyAODV, applications are forced to send from one sourceto a small destination set; however, with BVR the sourceand destination sets can be small or large without fear of aperformance penalty.
5.6 BLS/BVR vs. VRRVirtual Ring Routing [4] is a point-to-point routing scheme
0
0.2
0.4
0.6
0.8
1
1 2 3 4 5 6 7
Success
Rate
Destination Set Size (|d|)
|s|=1|s|=5
|s|=15|s|=28
(a) Total routing success rates forBVR (with location service).
0
0.2
0.4
0.6
0.8
1
1 2 3 4 5 6 7
Su
ccess
Rate
Destination Set Size (|d|)
|s|=1|s|=5
|s|=15|s|=28
(b) Total routing success rate fortinyAODV.
Figure 7: BVR with location service and tinyAODVtotal routing success comparison while varying sizeof source (s) and destination (d) sets.
that uses a distributed hash function to map individual nodeid’s to a logical ring of values. If a source node wishes tosend a packet to a specified destination, the source nodesimply computes the hash value of the destination node andsend the packet to the next logical successor in the ring thatis closest to the computed value.
At startup each node computes it’s hash value and send ajoin request to it’s nearest neighbors. After several minutes(convergence time is dependent on network size), the ringconverges and every node in the network is now routable.The location service is implicit in this design as the dis-tributed hash function actually performs the mapping tothe destination node when the hash value it computed.
For these experiments we simply chose a random sourceand random destination over various send rates. AlthoughVRR does outperform our system we are encouraged bythe fact that BLS/BVR is indeed comparable. Since theseare preliminary results there are still questions that needto be addressed in order to fully understand this compari-son. For future work we intend to run BLS/BVR and VRRover larger networks in simulation and a testbed environ-ment. VRR also keeps more state about the the networkthan BLS/BVR. In fact, our system only maintains local in-formation, such as nearest neighbors, BLS local cache map-pings to coordinates, and other local state. Running a statecomparison would also be beneficial for comparing the twosystems. Finally, BLS is highly dependent on BVR for goodperformance. The performance would greatly be improvedwith a more efficient beacon-based routing layer.
5.7 Application: Distributed Hash TableFinally, we implemented a “correctness” version of Chord
0
0.2
0.4
0.6
0.8
1
0 0.2 0.4 0.6 0.8 1 1.2 1.4 1.6 1.8 2
Suc
cess
Rat
e
Send Rate (q/s)
VRRBVR-LS
(a) Total routing success rates forBVR (with location service) in com-parison with VRR.
0
0.1
0.2
0.3
0.4
0.5
0.6
1 2 3 4 5 6 7 8 9 10
Rat
io
Hop count
VRR
(b) VRR hopcount distribution overvarious send rates.
Figure 8: Two Comparison of BVR and VRR. Fig-ure a shows the overall routing success over varioussend rates while figure b shows the hopcount distri-bution over various send rates in VRR.
[21] (i.e. only successor list, look-up, join, and stabilize; nofinger table, etc.) which we call tinyChord. This implemen-tation of Chord is not meant to be the most efficient or highperformance. Instead, this experiment is meant simply toshow a working application using the location service. Asalluded to earlier, the location service is the interface topoint-to-point routing using BVR. This experiment success-fully demonstrates an application using the entire protocolstack. Our simple experiment consisted of three trials, eachtrial performed 100 DHT look-ups; only a single look-up inthe DHT was active in the network at once. This resultedin a 99% DHT look-up success rate, and a look-up latencyplotted in Figure 9 over various network sizes.
6. CONCLUSIONS
0
2000
4000
6000
8000
10000
12000
14000
16000
18000
100 50 45 40 35 30 25
Av
erag
e L
aten
cy (
ms)
Network Size (# of Nodes)
Lookup Latency
Figure 9: Demonstration of working distributedhash table on top of location service.
We presented the Beacon Location Service, BLS: a loca-tion service for Beacon Vector Routing (BVR), a point-to-point routing scheme for wireless sensor networks. BLS isan important part of BVR because it allows nodes to useunique identifiers for their destination, rather than keepingtrack of dynamic coordinate information. Our scheme usesthe beacons as location servers which map identifiers to co-ordinates. Sending and destination nodes rendezvous at thebeacon through queries and updates, respectively. Once thesending node has the reply from the beacon it may routedirectly using BVR.
We have tuned BLS in simulation as well as demonstratedit’s performance on large sensor networks. Furthermore, wehave deployed the location service on a sensornet testbedto validate its performance. We compared our BLS/BVRagainst two existing point-to-point routing solutions tinyAODVand VRR on the sensornet testbed. Finally, we demon-strated a simplified version of Chord DHT using the BLS.
From our experiments, we show that BLS/BVR performswell with random source and destinations over various sendrates. Eavesdropping reduces the overall traffic in the net-work and improves the performance of the location service.When comparing BLS/BVR to tinyAODV, we find that itcan sustain a very high routing success rate over varioussizes of source and destination subsets, where tinyAODVcan not. We also find that despite running a non-optimizedversion of BLS we got relatively comparable results to themore integrated VRR design. Overall we believe our con-tribution is in the design of a well-performing, simple, androbust location service design for a class of routing proto-cols that uses a set of anchors to create a virtual coordinatesystem over the network. With more efficient routing BLSwould certainly continue to improve in performance.
There are several opportunities for future work with re-gard to the location service.
• Study the effects of caching, for both local node andbeacons, under different organizations and policies, onupdate frequency, and location service success rate.
• To reduce look-up latency and increase resilience tofailure, publish coordinates to multiple beacons underdifferent beacon resolution mechanisms. The trade-off between the increased traffic in the network (forpublishing and querying) will need to be balanced withthe need for replication.
[3] S. Basagni, I. Chlamtac, V. R. Syrotiuk, and B. A.Woodward. A distance routing effect algorithm formobility (DREAM). In MobiCom ’98: Proceedings ofthe 4th annual ACM/IEEE international conferenceon Mobile computing and networking, pages 76–84,New York, NY, USA, 1998. ACM Press.
[4] M. Caesar, M. Castro, E. Nightingale, G. O’Shea, andA. Rowstron. Virtual ring routing: Network routinginspired by dhts. In Special Interest Group on DataCommunications (SIGCOMM), pages 351–362. ACM,2006.
[5] S. Das, C. E. Perkins, and E. M. Royer. Ad hoc ondemand distance vector (AODV) routing.Internet-Draft Version 4, IETF, October 1999.
[6] M. Demirbas, A. Arora, and M. Gouda. Apursuer-evader game for sensor networks. In SSS ’03:Sixth Symposium on SelfStabilizing Systems, pages1–16, 2003.
[7] R. Fonseca, S. Ratnasamy, J. Zhao, C. T. Ee,D. Culler, S. Shenker, and I. Stoica. Beacon vectorrouting: Scalable point-to-point in wireless sensornets.In Proceedings of the 2nd Symposium on NetworkedSystems Design and Implementation (NSDI ’05),pages 329–342. USENIX, 2005.
[8] D. Gay, P. Levis, R. von Behren, M. Welsh, E. Brewer,and D. Culler. The nesc language: A holistic approachto networked embedded systems. In PLDI ’03:Proceedings of the ACM SIGPLAN 2003 conferenceon Programming language design and implementation,pages 1–11, New York, NY, USA, 2003. ACM Press.
[9] J. Hill, R. Szewczyk, A. Woo, S. Hollar, D. Culler, andK. Pister. System architecture directions fornetworked sensors. In ASPLOS-IX: Proceedings of theninth international conference on Architectural supportfor programming languages and operating systems,pages 93–104, New York, NY, USA, 2000. ACM Press.
[10] D. Karger, E. Lehman, T. Leighton, M. Levine,D. Lewin, and R. Panigrahy. Consistent hashing andrandom trees: Distributed caching protocols forrelieving hot spots on the world wide web. In ACMSymposium on Theory of Computing, pages 654–663,May 1997.
[11] B. Karp and H. T. Kung. GPSR: greedy perimeterstateless routing for wireless networks. In MobiCom’00: Proceedings of the 6th annual ACM/IEEEinternational conference on Mobile computing andnetworking, pages 243–254, New York, NY, USA,August 2000. ACM Press.
[12] Y.-B. Ko and N. H. Vaidya. Location-aided routing(LAR) in mobile ad hoc networks. In MobiCom ’98:Proceedings of the 4th annual ACM/IEEEinternational conference on Mobile computing andnetworking, pages 66–75, New York, NY, USA, 1998.ACM Press.
[13] F. Kuhn, R. Wattenhofer, Y. Zhang, and A. Zollinger.In the proceeding of the 22nd symposium on theprinciples of distributed computing (podc). InGeometric Ad-hoc Routing: Of Theory and Practice,New York, NY, USA, 2003. ACM Press.
[14] P. Levis, N. Lee, M. Welsh, and D. Culler. TOSSIM:accurate and scalable simulation of entire tinyosapplications. In SenSys ’03: Proceedings of the 1stinternational conference on Embedded networkedsensor systems, pages 126–137, New York, NY, USA,2003. ACM Press.
[15] J. Li, J. Jannotti, D. S. J. De Couto, D. R. Karger,and R. Morris. A scalable location service forgeographic ad hoc routing. In MobiCom ’00:Proceedings of the 6th annual ACM/IEEEinternational conference on Mobile computing andnetworking, pages 120–130, New York, NY, USA,August 2000. ACM Press.
[16] J. Newsome and D. Song. In the proceedings of the
first sensys (2003). In GEM: Graph EMbedding forRouting and Data-Centric Storage in Sensor NetworksWithout Geographic Information, New York, NY,USA, 2003. ACM Press.
[17] C. E. Perkins and P. Bhagwat. Highly dynamicdestination-sequenced distance-vector routing (DSDV)for mobile computers. In SIGCOMM ’94: Proceedingsof the conference on Communications architectures,protocols and applications, pages 234–244, New York,NY, USA, 1994. ACM Press.
[18] A. R. S. Ratnasamy, C. Papadimitriou, S. Shenker,and I. Stoica. In the proceedings of the first sensys(2003). In Geographic Routing Without LocationInformation, pages 76–88, New York, NY, USA, 2003.ACM Press.
[19] S. Shenker, S. Ratnasamy, B. Karp, R. Govindan, andD. Estrin. Data-centric storage in sensornets.SIGCOMM Comput. Commun. Rev., 33(1):137–142,2003.
[20] F. Stann and J. Heidemann. Rmst: Reliable datatransport in sensor networks. In In the Proceedings ofthe First IEEE International Workshop on SensorNetwork Protocols and Applications, pages 102–112.IEEE, May 2003.
[21] I. Stoica, R. Morris, D. Karger, M. F. Kaashoek, andH. Balakrishnan. Chord: A scalable peer-to-peerlookup service for internet applications. In SIGCOMM’01: Proceedings of the 2001 conference onApplications, technologies, architectures, and protocolsfor computer communications, pages 149–160, NewYork, NY, USA, 2001. ACM Press.
[22] P. F. Tsuchiya. The landmark hierarchy: a newhierarchy for routing in very large networks. InSIGCOMM ’88: Symposium proceedings onCommunications architectures and protocols, pages35–42, New York, NY, USA, 1988. ACM Press.
[23] A. Woo, T. Tong, and D. Culler. Taming theunderlying challenges of reliable multihop routing insensor networks. In In Proceeding for the FirstInternational Conference on Embedded NetworkedSystems (Sensys ’01), pages 14–27, 2001.
[24] J. Zhao and R. Govindan. Understanding packetdelivery performance in dense wireless sensornetworks. In In Proceeding for the First InternationalConference on Embedded Networked Systems (Sensys’01), pages 1–13, 2001.
