Computer Science Technical Report Archive

USC Computer Science Technical Reports, no. 788 (2003)

(USC DC Other)

USC Computer Science Technical Reports, no. 788 (2003)

PDF

Download a page range

Download transcript

Copy asset link

Request this asset

Transcript (if available)

Content 1
Rendezvous Regions: A Scalable Architecture for
Self-Configuration and Data-Centric Storage in Sensor Networks

Karim Seada, Ahmed Helmy
Electrical Engineering Department
University of Southern California, Los Angeles, CA 90089
{seada, helmy}@usc.edu

Abstract

Sensor networks are large-scale, self-organizing, distributed networks of small sensing devices embedded in the
physical world. Due to the limited resources of the devices and the uncertainty of the environment, efficient and
robust data-access mechanisms are both essential and challenging. Rendezvous-based data-access mechanisms
provide an efficient and valuable solution for provisioning a wide range of services. In this paper, we describe
Rendezvous Regions (RRs) - a novel scalable rendezvous-based architecture for sensor networks. RR is a general
architecture proposed for data-centric storage, in addition to bootstrapping, resource discovery, configuration, and
task assignment of sensor nodes. In RR the network topology is divided into rendezvous regions. Rendezvous regions
are geographical regions dividing the network topology space, where each region is responsible for a range of keys
representing the data or information of interest. A hash-table-like mapping scheme maps a key to its region. Inside a
region, a simple local election mechanism is used to dynamically promote servers that are responsible for
maintaining the mapped information. Replication between servers in the region is provided to deal with mobility and
failures. We run extensive detailed and high-level simulations to investigate the design space, and study the
architecture in various environments including node mobility and failures. We evaluate it against other approaches
(e.g., GHT) to identify its merits and limitations. The results show high success rate with low overhead in networks
with low to moderate mobility. The overhead increases moderately with the dynamics to preserve a high success
rate. RR scales to large number of nodes and is highly robust and efficient with failures and localized movements.

1 Introduction
Sensor networks are unattended distributed networks of large number of small devices that are intended for
applications such as environment monitoring and object tracking. Each device is capable of some computation,
wireless communication, and sensing under energy-constrained conditions. Communication in sensor networks is
typically application-specific and data-centric, and it consists mainly of the tasks sent to nodes and the data recorded
by nodes about the environment. Most approaches for communication rely on either flooding or centralized external
storage. Both could suffer from scalability and efficiency problems. In this paper, we describe Rendezvous Regions
(RRs) - a novel scalable rendezvous-based architecture for sensor networks. A rendezvous-based architecture will be
valuable for a wide range of services. RR is a general architecture proposed for data-centric storage, in addition to
bootstrapping, resource discovery, configuration, and task assignment of sensor nodes. Our objective is to provide
an architecture that is self-configuring, scalable, efficient and robust.
Our architecture is based on defining Rendezvous Regions (RRs). Rendezvous regions are geographical regions
dividing the network topology, where each region is responsible for a range of keys representing the data or
resources of interest. A hash-table-like mapping scheme is used for mapping keys into their regions. The mapping is
known by all nodes and is used during the insertion and lookup operations. A node wishing to insert or lookup a key
obtains the region responsible for that key through the mapping, then uses geographic-aided routing to send an
insertion or lookup message to the region. By using regions instead of points, our scheme requires only approximate
location information. We predict that our scheme, by virtue of using regions (instead of points), will be more robust
to errors and imprecision in location measurement and estimation than schemes depending on exact location
information. Inside a region, a simple local election mechanism is used to dynamically promote servers that are
responsible for maintaining information about the mapped resources. Replication between servers is provided to deal
with mobility and failures. Regions also provide a dampening factor in reducing the effects of mobility. Server re-
election is not invoked as long as current servers move inside the same region and hence the overhead due to
mobility updates is quite manageable.
We run extensive detailed and high-level simulations to investigate the design space, and study the architecture in
various environments including node mobility and failures. We evaluate it against other approaches; flooding,
centralized storage and GHT [15], to identify its merits, limitations, and the conditions under which it is preferable.
2
The results show that RR is scalable to large number of nodes and highly efficient and robust with node mobility
and failures.
The rest of the paper is outlined as follows. In Section 2 we discuss related work. In Section 3 we provide the
context and assumptions under which our architecture operates. Section 4 explains the design and section 5 contains
the detailed evaluation of the architecture. Conclusions are presented in Section 6.

2 Related Work
In wireless sensor networks, the simplest form of data dissemination and resource discovery is global flooding.
This scheme does not scale well. Other approaches in sensor networks that address scalability employ hierarchical
schemes based on cluster-heads or landmarks. These architectures, however, require complex coordination between
nodes, and are susceptible to major re-configuration (e.g., adoption, re-election schemes) due to mobility or failure
of the cluster-head or landmark, incurring significant overhead.
Communication in sensor networks is identified as data-centric based on the content of data rather than node
identities. A data-centric routing scheme presented is directed diffusion [7]. Directed diffusion provides a data
dissemination paradigm that targets continuous queries in sensor networks. Without availability of geographic
information about the sensors or the sensed information, directed diffusion uses flooding to advertise the interests
from sinks to sources throughout the network. Data delivery occurs over diffusion paths reinforced by the sources.
Interests are periodically refreshed by the sinks. For continuous queries the cost of flooding may be amortized over
the amount of information exchanged over possibly extended periods of time. For high mobility or for short-
lived/one-shot queries, however, directed diffusion may incur excessive overhead especially in large-scale networks,
where flooding is quite costly. We believe that our rendezvous-based architecture can be integrated with directed
diffusion to discover resources in a scalable manner instead of using flooding mechanisms.
A data-centric storage scheme related to our work is GHT [15]. GHT is presented for data-centric storage in sensor
networks. It is a geographic hash table system that hashes keys into geographic points, and stores the key-value pair
at the sensor node closest to the hash of its key. GHT requires nodes to know their exact geographic location and
uses geographic routing to reach the destination. In GHT, even slight movement of the home node – the node closest
to the hash point – may lead to storage refreshes. GHT uses GPSR [8] for geographic routing. GPSR is a geographic
routing protocol that uses greedy forwarding to forward the packet to the neighbor closest to destination. In cases
where greedy forwarding fails (no closer neighbors), GPSR uses perimeter routing to get around dead-ends. GPSR
constructs planar graphs to implement the perimeter routing. GHT uses GPSR perimeter routing in a novel way to
identify a packet home node (the node closest to the geographic destination). Packets enter perimeter mode at the
home node (since no neighbor could be closer to destination), and traverse the perimeter that enclose the destination
(home perimeter) before returning back to home node. GHT uses a perimeter refresh protocol to replicate keys at
nodes in the home perimeter. The perimeter refresh protocol refreshes keys periodically using also perimeter routing
to deal with topology changes after failures or mobility. GHT is suitable for an event model, where a large number
of events of a certain type are detected and aggregated at their hash point. Detailed comparison with GHT is
provided later in this paper.
Another related system is GLS [12]. GLS provides a scalable location service by using a predefined geographic
hierarchy and a predefined ordering of node identifiers to map nodes to their locations. GLS assumes that node
identifiers are known and it is presented for locating nodes. GLS can be augmented to provide other services, but
this will cause an extra level of indirection. GLS is also combined with geographic routing.
SCOUT [11] is an architecture for object tracking that is based on landmark hierarchy formation, where wireless
devices self-configure in a multi-level hierarchy of parent nodes and children nodes. Each level is associated with a
radius to which the device advertises itself. To configure the hierarchy complex mechanisms for promotion,
demotion, and adoption are used. The root nodes of the hierarchy use global flooding to send advertisements. If the
root nodes fail or move, new root nodes may be elected, and all nodes in the network may need to re-map all tracked
objects. This does not scale well under dynamic conditions.
Location-awareness is essential for most sensor network applications, so it is expected that sensor nodes will be
equipped with localization techniques. In addition, sensor networks could use the inherent geographic information to
support basic functions such as routing and resource discovery, leading to higher scalability and performance.
Example of geographic-based systems are [9], [10], and [8]. In this work we use GPSR to perform geographic
routing. In future work we shall investigate alternative designs for routing with approximate geographic information.
Several techniques exist for location sensing such as GPS, proximity or triangulation using radio signals, acoustic
signals, or infrared. These techniques differ in their localization granularity, range, deployment complexity, and
cost. GPS requires visibility to its satellites and so is ineffective indoors or under coverage. In addition, the high
cost, size, and power requirements make it impractical to deploy on all nodes. Triangulation techniques estimate the
3
distance to multiple reference points based on signal measurements such as signal strength or time of flight. General
localization systems such as Active Bat [17], RADAR [1], and Cricket [14] use these techniques for estimating
locations. These systems are designed to work inside buildings and they either have a coarse-granularity of several
meters or require a costly infrastructure. There are also localization systems proposed targeting sensor networks. In
[4] reference nodes with overlapping regions of coverage transmit periodic beacons, which other nodes use to infer
their proximity to the reference points. The accuracy depends on the distance between the reference points and their
transmission range. In [16] sensor nodes discover their locations using distributed iterative techniques starting from
certain nodes that know their exact locations. [5] presents self-configuring localization systems for sensor networks
that autonomously adapt to the dynamics of their environment. In our design we attempt to provide a design that
requires only approximate location information.

3 Context
In this section, we present the data models we consider in our study. We introduce two models, the service model
and the event model. We then give a brief statement about the geographic requirements of rendezvous regions and
present our assumptions.

3.1 Data Model
RR provides a general architecture for data-centric storage and resource discovery. Data operations could be
viewed as general insertions and lookups of keys. Data models of different applications differ in the number and
characteristics of their insertions and lookups. We will also differentiate whether a single external node sends the
query, or any node could be sending the query. Aggregation is also an important factor in the model, which will
depend on the type of insertions. The ratio between lookups and insertions will affect the performance of our
architecture; we will call it LIR (Lookup-to-Insertion Ratio). We will define two models and identify data services
and applications suitable under these models.

3.1.1 Service Model
In this model, the number of lookups is much larger than the number of insertions. Hence, this model has a large
LIR. Stored data are long-lived and will be queried continuously by large number of nodes. Any node in the network
can perform insertion or lookup. Inserted items are assumed to be independent and not instances of certain classes,
so aggregation is not considered in this model. This model is viewed as a general service location model and several
applications could be mapped to it:
- Bootstrapping, configuration, and task assignment: During the startup of the network operation, it is assumed
that nodes’ configuration and tasks are flooded to the entire sensor network. Global flooding is inefficient if
nodes are not joining simultaneously, new nodes are added, or tasks of different nodes are changing with time.
RR provides a flexible way for nodes to get this information. Each node will get its task from a rendezvous
region computed as a hash of the node location or other properties of the node environment (e.g. RRi = hash
(location or properties)). Operators assign tasks to nodes by sending them to RRi using the same hash function.
- Service location: Nodes with special capabilities such as computing power, storage capacity, gateway access, or
sensing capabilities can advertise their services which can be used by other nodes. The node hashes the key for
its service to a region and stores its information (e.g. location) there. Other nodes interested in the service use
the same hash to get the information from the region.
- Data-centric storage for events that do not change frequently once detected, such that the number of detected
events is lower than the number of queries sent by nodes. For example, detecting a certain phenomenon in an
area, which is required by other sensors to perform their computations, or required by actuating devices in order
to decide on certain actions.
- Providing global properties of the network or environment that are of interest to many nodes.
- Database querying: There are several research going on viewing the sensor network as a database and using
declarative SQL-like queries for retrieving information [6][2]. RR can provide an in-network storage
component in this architecture. For example, temperature sensors will send the temperatures of their regions to
‘RRi = hash (temperature)’ and a node interested in the max temperature will send a query ‘Select MAX
temperature’, which will retrieve this information from RRi.

3.1.2 Event Model
This model has a large number of insertions with a lower number of lookups. An example is data-centric storage
with many events detected from a set of event types. A query looks for the events detected of a certain type. This is
similar to the model presented in GHT [15]. Each event type is hashed into a rendezvous region and all events
4
detected of that type are forwarded there. Events detected represent the insertions, while queries for events are the
lookups. Aggregation could be valuable in this model, where a query for a certain type will return an aggregation for
all events detected for that type. We will assume that any node in the network can detect and insert events, while
external nodes send queries through specific access points.

3.2 Geographic Requirements
A main objective of our architecture is to relax the requirements for exact geographic information. Nodes need
only to know their regions and so the exact location position may not be required. We design our system as an
overlay that can run over different routing protocols. The routing protocol need not be a geographic routing protocol
that requires the exact geographic position of nodes. It can be any routing protocol augmented to provide
approximate routes toward regions. The relaxation of geographic information dependence will be valuable for
different reasons. Geographic information may not be always available and it is not accurate. Obstacles and non-
symmetry between nodes can cause many problems to current geographic routing schemes. In addition, mobility
will increase the inaccuracy of location updates. We predict that our scheme will be more robust to errors and
imprecision in location measurement and estimation than schemes depending on exact geographic routing. This is
subject to future research.

3.3 Assumptions
We assume that the geographic space and boundaries of the network are known and that the nodes have some
mechanism to detect their geographic region. The regions are initially assumed of equal size. Our design also allows
us to relax the exact boundaries requirements by having boundary regions instead of boundary points. Nodes are
assumed to be homogenous having the same range. Capabilities can be taken into account during server election, for
example, to give more weight to nodes with certain capabilities (power, storage). For obtaining the mapping
function, the same rendezvous mechanism may be used to provide a bootstrap overlay to publish dynamic mappings.
A node sends request to a well-known region for obtaining the mapping function of a certain resource. We currently
assume that the network is connected and has no partitions by using appropriate density and transmission range. We
assume also that each region has nodes in it. To solve problems of partitions and empty regions, we plan to use
multiple hash functions to provide alternate regions, when the original region is not available.

4 Design Overview
The network topology space is divided into geographical regions (RRs), where each region (e.g., RR
j
) is
responsible for a range of keys representing the resources or data items. The resource key space is divided among
these regions, such that each resource key (K
i
) is mapped to a region. The key-range to RR mapping (KSet
i
↔ RR
j
) is
known by all nodes. Inside each region, a set of elected servers is responsible for holding these resources’
information. Insertions and lookups for a key, access the servers of the region in charge of that key. We introduce
additional mechanisms to maintain consistency in cases of mobility and failures.
The Rendezvous Regions scheme can be built on top of any routing protocol that can route packets toward
geographic regions. The only requirement of the routing protocol is to maintain approximate geographic
information, such that given an insertion or lookup to a certain region, it should be able to obtain enough
information to route the packet toward that region. Given that the packet is able to reach the region, there are several
design options inside the region itself. These design options affect the operation of insertions, lookups, server
election, and replication inside the regions. They also affect the consistency operations for mobility and failures. In
our experience, it is usually the case that no one design option gives best performance under all operating
conditions. The design choices depend on many factors such as the environment, application, and the pattern of
insertions and lookups. In this work we attempt to investigate and study several design options to identify their
strengths and weaknesses. There are mainly three options for forwarding packets inside the region: (a) Geocast, (b)
Anycast, and (c) Unicast.
(a) Geocast: By geocast we mean sending the packet to all nodes in a geographic region. Geocasts suffer from
a high overhead, but are practical when we want to send the packet to several non-determined nodes (in our case
to the servers) within a specific geographic region. It is also robust in the face of dynamics and does not depend
on the underlying routing protocol
(b) Anycast: Anycasts are used when it is sufficient to reach any node of a set of nodes (any server). It has
similar advantages to geocasts and can be implemented by using expanding ring search techniques or by
caching previously known servers.
5
(c) Unicast to servers: Direct unicasts can be used when the servers’ locations are well-known, either because
they are stable and fixed or because servers coordinate to keep their information up-to-date. This has the
advantage of low overhead during insertions and lookups, but if the servers are dynamic, it needs extra periodic
overhead for maintaining the servers’ information. It may also depend on the underlying routing protocol to
keep track of nodes’ locations. The additional periodic overhead can be acceptable if the insertion or lookup
rates are high enough.

In our current design we use geocasts for insertions and anycasts for lookups. These design choices are simple to
implement, robust to dynamics, and do not require tracking of nodes’ locations. We plan to investigate more
complex server coordination techniques in future work. Following we describe the main components of our
architecture.

4.1 Region Detection
Each node needs to know its geographic region using approximate geographic localization techniques, and it needs
to keep track of its region as it moves (Figure 1). The node uses this information to detect packets forwarded to its
region and potentially participates in server election in its region (if and when needed). One important factor in our
design is the size of the region. The larger the region, the more relaxed will be our geographic requirements and the
less overhead due to updates and server re-elections after mobility. On the other hand larger regions lead to more
coordination overhead for server election and more geocast overhead. We study this trade-off in detail later in the
paper. Region size may also depend on the number of hops we want the region to cover and the region node density.

RR1 RR2 RR3
RR4 RR5 RR6
RR7 RR8 RR9
Get location ~(x,y)
RR
1
KSet
1

RR
2
KSet
2
… ...

RR
n
KSet
n

(x,y)∈RR
i
↔KSet
i

Elected Server Node

Figure 1: By knowing their approximate location ~(x,y), and hence region (RR), nodes in every region (shown in
RR3) conduct local elections. Only a few nodes (the elected servers) maintain information about the resource keys
(KSet
i
) mapping to RR3. Nodes keep a (potentially algorithmic) mapping RR
i
↔ KSet
i
.

4.2 Server Election
A simple local election mechanism is used inside the region to dynamically promote the servers. Each node elects
itself with a certain probability, p, depending on the required number of servers and the region’s condition. We shall
revisit this point in later sections. The number of servers required in the region is called S. As S increases, the
robustness to mobility and failures increase, but also the storage overhead increases. Servers are elected on-demand
during insertions. When a data insertion operation is issued, the first node in the region that receives the insertion,
known as the flooder, geocasts the insertion inside the region. Each server receiving the geocast insertion sends Ack
back to the flooder. The flooder keeps track of the servers and if it does not get enough Acks, it geocasts again and
includes a self-election probability (p
2
) in the goecast message, such that p
2
>p. The flooder increases the self-
election probability based on a back-off mechanism until the required number of servers reply. When servers move
out of the region or fail, new servers are elected in the same way. After the new servers are elected, they request the
stored resources information from other servers.

4.3 Insertion
A node inserts a key, K
i
, by first mapping the key to its rendezvous region, RR
j
, where K
i
∊ KSet
i
↔ RR
j
. Then the
node generates a packet containing the region identifier in its header (Figure 2). Nodes routing the packet toward its
6
region, check the region identifier to determine whether they are in or out of region. The first node inside the
rendezvous region to receive the packet, the flooder, geocasts the packet and servers inside the region receive the
geocast, store the key and data, then send Acks back to the flooder (Figure 3). The flooder collects the Acks and
sends an Ack back to the original sender. If no Ack is received by the sender, it timeouts and retransmits the
insertion up to a fixed number of times until an Ack is received.

RR1 RR2 RR3
RR4 RR5 RR6
RR7 RR8 RR9

Insertion
RR
1
KSet
1

RR
2
KSet
2
… ...

RR
n
KSet
n

K∈ KSet
i
↔ RR
i
S

RR1 RR2 RR3
RR4 RR5 RR6
RR7 RR8 RR9

Geocast
S
flooder
Figure 2: Insertion (step I): Node S wishing to insert (or store)
resource key K that belongs to KSet
i
, gets the corresponding RR
(in this case RR3) through the mapping (Kset
i
→RR
i
).
Figure 3: Insertion (step II): Node S sends the resource information
towards RR3, where it is geocast by the flooder and stored by the
servers.
4.4 Lookup
Lookups are similar to insertions except that nodes and previous-flooders inside a region cache routes to the recent
servers they hear from, and send the lookups directly to the closest server (anycast). The server replies to the flooder
and the flooder replies back to original sender (Figure 4). If the flooder receives no reply it timeouts and geocasts the
lookup. The lookup is also retransmitted a fixed number of times.

4.5 Replication
Replication is inherent in this architecture since several servers inside the region store the key and data. This is
valuable to achieve robustness with failures and mobility. For extra robustness against severe dynamics such as
group failures and partitions, multiple hash functions could be used to hash the key to multiple regions.

4.6 Mobility
If node movement does not lead to change in its region, then no mechanisms are triggered. Hence, local
movements of nodes and servers have negligible effect and overhead on our architecture as long as servers stay
within their regions. The only condition we need to consider is when a server moves out of its region. The server
detects when it gets out of its region and sends an insertion packet toward that region so that new servers are elected.
The server then deletes its stored keys and stops being a server, until and unless it gets elected again.

4.7 Failures
Since each region contains several servers, and insertions and mobility may invoke new server elections, it is
unlikely that independent reasonable failures will cause all servers to vanish. In order to avoid this case anyway,
servers use a low frequency soft-state periodic mechanism during silent (low traffic) periods, to detect failing servers
and promote new servers. Each server runs a low frequency timer, which is reset each time an insertion geocast is
received. When the server times out, it geocasts a packet checking for other servers. Other servers will reset their
timers upon receiving this check and reply back demonstrating their existence.

4.8 Bootstrap
One question remaining is how the mapping function is obtained. Similar systems normally assume that it is pre-
known or provided by out-of-band mechanisms. In our architecture, using the same rendezvous mechanism, we
provide a bootstrap overlay to publish dynamic mappings. Using the mapping for a well-known key, a node sends
request to a well-known region to obtain the mapping function of a certain service. These mappings however are not
7
expected to change frequently. This introduces more flexibility for providing different mappings for different type of
services and changing them when required. (Figure 5)

RR1 RR2 RR3
RR4 RR5 RR6
RR7 RR8 RR9
S
R

Lookup
K∈KSet
i
↔ RR
i

RR1 RR2 RR3
RR4 RR5 RR6
RR7 RR8 RR9

WKK∈KSet
j
↔ RR
j
Resource Initiator
RI
RS
Resource Seeker
WKK∈KSet
j
↔ RR
j
Figure 4: Lookup: Node R looking for a resource key K, that
belongs to KSeti, gets the corresponding RR (RR3) through the
mapping (Kseti→RRi). It sends the resource lookup towards
RR3, where it is anycast to any server holding the information.
Figure 5: Providing resource directory service: the bootstrap
mechanism for initiating (and obtaining) new resource mappings
using well-known key(s) (WKK).

5 Performance Evaluation
In this section, we evaluate our architecture using detailed NS-2 simulations with detailed models of the wireless
MAC and physical layers. We run extensive simulations to investigate the design space, and study the architecture in
various environments including node mobility and failures. RR is running as an overlay over the routing layer and
we are using GPSR as the wireless routing protocol. We verify the correct operation of RR and evaluate its
performance under different scenarios. In addition, we run similar detailed experiments for GHT in order to compare
the performance of both systems and identify their characteristics and limitations.
We conducted simulations with up to 400 nodes using the detailed model. To study the scalability of the
architecture to higher number of nodes, we perform also higher-level simulations (without MAC and physical
layers) for networks with up to 100,000 nodes and compare it to GHT, flooding (local storage), and centralized
storage (external storage).
We evaluate two models, the service model with high lookup-to-insertion ratio (LIR) and the event model with low
LIR. There is a wide range of parameters we consider during the evaluation. The environment parameters include the
network dimensions, number of nodes (density), transmission range, and the expected number of queries per second.
The design parameters that we study are mainly the number of regions and the number of servers per region. The
performance metrics studied are the success rate of lookups, message overhead per insertion, message overhead per
lookup, and total storage/insertion, in addition to the maximum node overhead of these metrics. We also study
mobility, failure, and refresh overheads. Latency is not included, since it is not critical for these kinds of applications
and we noticed that it does not show significant variations. We mainly show the simulations of the parameters that
lead to interesting characteristics.

5.1 Detailed Simulation Results
We implemented RR in NS-2 [13] as an overlay that runs over any wireless routing protocol that has the ability to
route towards geographic regions. Currently, we are using GPSR as the routing protocol with detailed 802.11 MAC
and physical layers. The GPSR beacon interval is 1 sec and the beacon expiration is 4.5 sec. The density is fixed to
1/1024m
2
and the number of nodes is 100, 200, or 400. We explored several transmission ranges between 60m and
120m; the results shown are for 80m unless otherwise stated. For convenience, in most results we show, we will
focus on of 100-200 nodes topologies and 80m transmission range. The rate of lookups is 2 per second and the
number of retransmissions for both insertions and lookups is 3. The periodic failure check interval is 20 seconds.
Keys are uniformly distributed at random over the space. The results are the average of 5 random runs over 5
different topologies. GHT was already implemented in NS-2. The refresh interval for GHT is set to 10 seconds. A
common problem in GHT that affects its performance, is when a key hashes to a point outside the external
8
perimeter. In this case, perimeter routing may move around the whole external perimeter during insertions, lookups,
or refreshes. To reduce the effect of this problem during evaluation, we will have a second version of GHT, we call
it GHT*, where we avoid mapping the keys to points close to the space boundary. We do that by excluding 10% of
each side (left, right, top, bottom) of the space during hashing.

5.1.1 Number of Servers in Region
First, we study the effect of the number of servers in a region. In the simulations, a value is set for the minimum
number of servers, below which flooders ask for new servers. Since the server self-election is probabilistic, the
actual number of servers in a region could exceed this value. The following results show the message
overhead/insertion, message overhead/lookup and storage overhead/insertion with different number of servers. The
experiment is run over a 100 node static topology with 4 regions and a LIR equal to 10. The number of insertions
varies between 10, 30, and 50.
In Figure 6, the message overhead per insertion consists of three parts: geocasts for insertions, extra geocasts for
server election if number of servers is below minimum, and ACKs by servers to flooder and back to sender. In a
static network the server election geocasts will be independent of the number of insertions such that,
TotIns = ElecGeo + Ins * nIns
where TotIns is the total insertion overhead, ElecGeo is the overhead of the initial geocasts for server election, Ins is
the overhead/insertion (including the Acks), and nIns is the number of Insertions. As shown in the figure, the total
overhead increases with the number of servers due to the extra initial geocasts asking for more servers. With lower
number of insertions, the increase is larger since this initial overhead has a larger effect. In order to reduce the
impact of initial geocasts and compute the message overhead/insertion independent of the number of insertions, we
use the following formula to deduct the initial overhead:
b a
b Ins a Ins
Ins
−
−
=
) ( ) (

where Ins(x) is the total overhead for x insertions. As shown in Figure 6, the formula is close to the high number of
insertions since the effect of initial election geocasts is canceled. In Figure 7, the message overhead per lookup
(including the back replies) is independent of the number of lookups (LIR is fixed to 10) and it decreases by
increasing the number of servers, since more (closer) servers can reply the anycast. The reduction slows down with
higher number of servers. Since, the optimum number of servers depends on LRI (the ratio of lookups to insertions),
we show in Figure 8, for different values of LIR, the normalized message overhead computed as
0
10
20
30
40
50
60
70
12 345 67 89 10
Number Of Servers
Total Messages per Insertion
10 Insertions
30 Insertions
50 Insertions
formula

0
1
2
3
4
5
6
7
8
12 345 67 8 9 10
Number Of Servers
Total Messages per Lookup
10 Insertions
30 Insertions
50 Insertions
Average

Figure 6: Insertion overhead for different number of servers Figure 7: Lookup overhead for different number of servers
0
20
40
60
80
100
120
140
160
12 34 5 6 7 8 9 10 11
Number Of Servers
Normalized Total Messages
LIR
2
4
6
8
10
12
14
16
18
20

0
2
4
6
8
10
12
14
123 45 6 7 8 9 10
Minimum Number Of Servers
Total Storage per Insertion

Figure 8: Normalized overhead for different number of servers Figure 9: Storage overhead for different number of servers
9
Norm = Ins + Lookup * LIR
where Ins and Lookup are the overhead/insertion and overhead/lookup. With low LIR, low number of servers causes
lower overhead, while high LIR favors more servers. As we see, 3-4 servers give a good compromise. Figure 9
shows the storage required by insertions. The total storage overhead increases with the number of servers. On the
other hand, more servers lead to higher robustness in cases of mobility or failures.

In the coming experiments, the number of servers is set to 3. We use the service model where nodes are chosen at
random for insertions and lookups. The simulation run is 200 seconds with 30 insertions at the beginning and 300
lookups at a rate of 2 new lookups per second. The number of regions varies from 4, 9, 16, to 25. We will start with
static networks, then look at failures and mobility.

5.1.2 Static and Stable Networks
The number of regions in the space is an important design parameter that indicates the region size and the average
number of nodes in region. Ideally we like to have regions with low number of nodes to reduce the geocast overhead
and at the same time to have the region size large enough to relax the geographic accuracy and reduce the effects of
mobility. In static networks, the success rate for both RR and GHT is almost 100%, so we consider only the
overheads in this section. In Figure 10, increasing the number of regions reduces the message overhead for
insertions, since region geocasts cover a smaller region. Higher transmission range reduces the overhead only
slightly, since the geocast overhead in a region is the major factor and it will not be affected by transmission range.
Figure 11 shows the insertion overhead of RR compared to GHT and GHT*. RR overhead decreases by increasing
the number of regions due to the region geocast overhead. At low number of regions, GHT has lower insertion
overhead, but they become closer as we increase the regions. In Figure 12, the region size has less effect on RR
lookup overhead, since the main factor here in reducing the overhead is caching the servers and anycasting them.
Higher transmission ranges (not shown in the figure) reduce the overhead because of the reduction in the number of
hops required for unicasts and anycasts to cached servers. As we see also in this figure, both GHT and GHT* have a
significantly higher overhead than RR. GHT* has a lower overhead than GHT, since it excludes hashing points close
to the boundary, which can cause the external perimeter traversal, but it is still higher than RR. Insertion and lookup
overhead in GHT are similar, since they are using the same mechanism.
The high overhead of GHT is due to long perimeter traversals. Each packet in GHT (insertion, lookup, or
refreshment) goes to the home node (closest node to destination point), then it traverses the entire perimeter (home
perimeter) that encloses the destination, before returning to the home node. The average perimeter length is
somewhat long, which can be noticed also from Figure 14, where the average storage overhead for 100 Nodes is
around 8 in GHT* (18 in GHT), which means that on average 8 nodes are in the home perimeter and store the
packet. This is consistent with the insertion and lookup overheads, which are around 15 messages (including the
forwards to home node and back replies). By looking at the randomly generated topology in Figure 17 we can
understand why average perimeters are so long: 1) even with avoiding the surrounding boundary points in GHT*
and using only the internal 64% (.8*.8) of the space for hashing, there are still many areas where a hash point there
could cause external perimeter traversal, 2) even with random uniform distributions there are still somewhat large
internal areas without nodes. Key hash points in these areas have long home perimeters, 3) this may be the most
interesting, which is the effect of planarization by GPSR. Planarization (in this case Gabriel Graph) removes cross-
links during perimeter routing, which means that even in higher dense networks this problem would still exist, since
packets have to traverse dense perimeters because shortcuts between the perimeter nodes are not included in the
planar graph. (We are using a density of 1/1024m
2
with an 80m transmission range; in GHT [15] the density was
1/256m
2
with a 40m transmission range, which gives the same connectivity. In order to verify that, we run the same
experiment with the higher density and lower transmission range of [15] and we got the same results.)
Figure 13 shows the periodic failure check overhead in RR compared to the refreshment overhead in GHT. In RR
it is almost equal to the number of nodes since in each region, where there are keys stored, one of the servers
geocast. In GHT it is higher because refreshment is sent for every key around the perimeter, so it depends also on
the number of keys stored. For example, in this case we have 30 keys with an average perimeter of 8 in GHT* (18 in
GHT) for 100 node topologies, which gives around 240 messages as shown in the figure (GHT* around 250 and
GHT around 500).
These results show that the total overhead depends on the data model and the LIR. For example in the service
model, RR has a lower overhead due to the large LIR, while in the event model with larger number of insertions,
GHT may have lower overhead. In order to evaluate the total overhead taking into account the insertions, lookup,
and periodic overhead, we compute the normalized total overhead as
10
len
Per
lRate Lookup iRate
LIR
Ins
Norm + + = * *

where Norm is the normalized total overhead per second, Ins is the overhead/insertion, Lookup is the
overhead/lookup, iRate and lRate are the insertion and lookup rates respectively, Per is periodic overhead in an
interval, and len is the length of the interval. Plotting this equation at different LIRs, we show in Figure 15 the point
where RR and GHT* overhead intersect. This is beneficial in deriving which system is more efficient in a certain
situation. The overhead ratio between RR and both GHT and GHT* is shown in Figure 16, for different lookup rates
(LR). For LIR>0.1, RR incurs less overhead than GHT*, with the savings approaching 80% for LIR>10.

0
20
40
60
80
100
120
140
160
4 9 16 25
Number of Regions
Number of Messages
1 00 Nodes, 80
200 Nodes , 80
400 Nodes , 80
1 00 Nodes, 1 20
200 Nodes , 1 20
400 Nodes , 1 20

0
10
20
30
40
50
60
70
80
4 9 16 25
Number of Regions
Number of Messages
RR 1 00 Nodes
RR 200 Nodes
GHT 1 00 Nodes
GHT 200 Nodes
GHT* 1 00 Nodes
GHT* 200 Nodes

Figure 10: Insertion overhead for different number of regions in RR Figure 11: Insertion overhead RR vs. GHT & GHT*
0
5
10
15
20
25
30
35
4 9 16 25
Number of Regions
Number of Messages
RR 100
Nodes
RR 200
Nodes
GHT 100
Nodes
GHT 200
Nodes
GHT* 100
Nodes
GHT* 200
Nodes
0
100
200
300
400
500
600
4 9 16 25
Number of Regions
Number of Messages
RR 100
Nodes
RR 200
Nodes
GHT 100
Nodes
GHT 200
Nodes
GHT* 100
Nodes
GHT* 200
Nodes

Figure 12: Lookup overhead for RR vs. GHT & GHT* Figure 13: Periodic (refresh, failure check) overhead for RR vs. GHT & GHT*
0
5
10
15
20
25
4 9 16 25
Number of Regions
Storage
RR 100 Node
RR 200 Node
GHT 100 Nodes
GHT 200 Nodes
GHT* 100 Nodes
GHT* 200 Nodes

10
100
1000
10000
0.01 0.1 1 10 100
Lookup to Insertion Ratio (LIR)
Normalized Messages
RR
GHT
GHT*

Figure 14: Storage overhead (per insertion) RR vs. GHT & GHT* Figure 15: Normalized total overhead per second for different LIR
11

0
0.2
0.4
0.6
0.8
1
1.2
0.01 0.1 1 10 100
Lookup-to-Insertion Ratio (LIR)
Overhead Ratio
____ RR/GHT*
_ _ _ RR/GHT
LR=10
LR=1
LR=0.1
LR=10
LR=1
LR=0.1

hash
point

Figure 16: Overhead ratio for different LIR Figure 17: Example of random uniform topology where perimeter
and different lookup rates (LR) traversing (in a planarized graph) may take many hops
5.1.3 Failures
In this section, we show the robustness of RR with node failures. Robustness is achieved by the replication among
servers and the periodic failure check mechanism. We run simulations of 100 nodes where 10%, 30%, or 50% of the
nodes fails at random times.
In Figure 18, the success rate remains high with failures, in both GHT and RR (around 97% when 50% of the
nodes fail). With 25 regions and 100 nodes in RR, the success rate falls down because on average we have only 4
nodes per region, and less than that with failures. By running this simulation with 200 nodes, that problem does not
exist and the success rate remains high. This shows one of the requirements of RR; we need to set the region size
large enough to have enough nodes to serve the keys there. Figure 19 shows the periodic overhead with failures; RR
overhead increases slightly but remains around the number of nodes and it is almost independent of the failure rate,
while GHT overhead increases due to the extra perimeter traversals for keys replication after node failures.
86%
88%
90%
92%
94%
96%
98%
100%
4 9 16 25
Number of Regions
Success Rate
RR 10%
RR 30%
RR 50%
GHT 10%
GHT 30%
GHT 50%

0
100
200
300
400
500
600
700
800
900
1000
4 9 16 25
Number of Regions
Number of Messages
RR 10%
RR 30%
RR 50%
GHT
10%
GHT
30%
GHT
50%
GHT*
10%
GHT*
30%
GHT*
50%

Figure 18: Lookup success rate for different node failure rates Figure 19: Periodic overhead for different node failure rates
5.1.4 Mobility
One of the main strengths of RR is its robustness to node mobility. The main reason is that local movements, as
long as the servers remain in the region, do not require change of servers or any extra overhead. Mobility updates
happen only when a server moves out of region. Nodes are moving using the random waypoint model [3], with a
maximum rate of 1m/s, 2m/s, or 5m/s. There is no pause time, all nodes are moving continuously. Figure 20 shows
the high success rate of RR under mobility. It drops only with higher number of regions, because of the low number
of nodes per region, which is also the reason for the insertion and lookup overhead increase in Figure 21 and Figure
22, because of the extra geocasts and retransmissions looking for servers in a certain region. This problem does not
exist with higher number of nodes and can be avoided by setting an appropriate region size. For example, with 100
nodes moving at 5m/s, 9 regions give a success rate above 99%. GHT success rate drops faster with mobility, since
12
any small movements can cause changes in the key storage, and lookup packets reach home nodes (nodes closest to
destination point) that do not have the key, due to changes in topology. In addition, perimeter traversal with mobility
is susceptible to loops, which may cause the packet to exhaust its TTL. We used a 2 second replanarization timer
with GHT to reduce this effect. In [15] they limited also the TTL during refreshments to reduce the overhead if
looping happens, but we have not included this change here, since it is not clear how the TTL can be set dynamically
without extra overhead and what is its effect on other functions of the protocol. In Figure 23, we show the mobility
update overhead during an interval equivalent to GHT refreshment interval, since both of them reflect the overhead
due to mobility (in addition, GHT performs refreshes when new node joins or leaves are discovered). RR has much
lower overhead, since only the servers send updates when they move out of region. In Figures 24 and 25, we fix the
number of regions in RR to 9 and change the pause time of nodes moving with a maximum random-waypoint
velocity of 5m/s. We notice the high success rate and the low lookup overhead compared to GHT and GHT*.
0%
10%
20%
30%
40%
50%
60%
70%
80%
90%
100%
4 9 16 25
Number of Regions
Success Rate
RR 1 m/s
RR 2 m/s
RR 5 m/s
GHT 1 m/s
GHT 2 m/s
GHT 5 m/s
GHT* 1m/s
GHT* 2m/s
GHT* 5m/s
0
50
100
150
200
250
300
350
4 9 16 25
Number of Regions
Number of Messages
RR 1 m/s
RR 2 m/s
RR 5 m/s
GHT 1 m/s
GHT 2 m/s
GHT 5 m/s
GHT* 1m/s
GHT* 2m/s
GHT* 5m/s

Figure 20: Lookup success rate for different node mobility rates Figure 21: Insertion overhead for different node mobility rates
0
20
40
60
80
100
120
140
160
4 9 16 25
Number of Regions
Number of Messages
RR 1 m/s
RR 2 m/s
RR 5 m/s
GHT 1 m/s
GHT 2 m/s
GHT 5 m/s
GHT* 1m/s
GHT* 2m/s
GHT* 5m/s
0
500
1000
1500
2000
2500
3000
4 9 16 25
Number of Regions
Number of Messages
RR 1 m/s
RR 2 m/s
RR 5 m/s
GHT* 1m/s
GHT* 2m/s
GHT* 5m/s

Figure 22: Lookup overhead for different node mobility rates Figure 23: Mobility update (refresh) overhead in RR and GHT
0%
20%
40%
60%
80%
100%
0 204060
Pause Time (sec)
Success Rate
RR
GHT
GHT*

0
20
40
60
80
100
120
140
160
020 40 60
Pause Time (sec)
Number of Messages
RR
GHT
GHT*

Figure 24: Lookup success rate for different node pause times Figure 25: Lookup overhead for different node pause times
13
5.2 High-Level Simulation Results
To evaluate the scalability of RR with higher number of nodes, we perform high-level simulations without the
wireless MAC and physical details. We mainly compute the total message overhead and the maximum node
overhead in a static network, since those represent the energy consumption of a sensor node and the lifetime of the
network. Without errors or dynamics, the success rate need not be computed (always 100%). We compare RR to
GHT, flooding (local storage), and centralized storage (external storage). We will count only the insertion and
lookup overhead. The periodic refreshment overhead in GHT and the failure check overhead in RR are not included
in these simulations, but we can easily compute an estimate for them based on the detailed simulations results. In
GHT, we do not use hash points that lead to long perimeter traversal (more than square root the number of nodes) to
avoid the high overhead of the external perimeter traversal.
We will first do some approximate analysis for the communication overhead of the mechanisms we will compare.
We will assume the general service model and consider general insertion and lookup operations, where n is the
number of nodes and any node can send insertion or lookup, I the number of insertions, L the number of lookups, R
the number of regions in RR, and S is the average number of servers per regoin. We will use the asymptotic
expression of ) (n O for flooding the whole network, ) ( n O for point-to-point routing, and ) / ( R n O for region
geocasts. In flooding we assume that the nodes store (insert) their keys locally and other nodes flood (lookup) to get
them. In centralized storage, we assume a centralized node, normally external to the sensor network, storing all the
keys, so that all insertions and lookups are forwarded to it. The following table shows the asymptotic insertion and
lookup message overhead:

The total message overhead in RR includes the insertion overhead, where an insertion is composed of a point-to-
point route to reach the region and a geocast inside the region. The lookup is anycast to a cached server, so it can be
considered as a point-to-point route. In the hotspot message overhead of GHT, we assume lookups are uniformly
distributed over keys so that for each key inserted, its home node will have O(L/I) lookup. In RR, we assume also
the keys are uniformly distributed over regions and lookups are uniformly distributed over keys, so that the overhead
of a server is the insertions of keys in its region and the lookups (anycasted) are distributed between the S servers in
the region. The term min(I,R) takes care of the case when the number of insertions is less than the number of
regions, so that lookups are distributed only over those regions that have insertions. In GHT the refresh overhead per
interval is equal to ‘the number of keys stored (I) * average perimeter length’. In RR, failure check overhead per
interval is at most ‘n/R * minimum (number of keys stored (I), R)’, since we do not need to geocast in regions that
has no keys. In addition, failure check timers are suppressed by insertions and mobility updates in the region. From
this simple analysis and also from detailed simulation results, it would be beneficial for RR to increase the number
of regions with the number of nodes, such that n/R remains constant. In this case, the asymptotic overhead at large
number of nodes for RR will be similar to centralized storage and GHT. We can see that also in the simulations,
where we increase the number of nodes from 100 to 100000 with different LIRs. The number of insertions is 10.
The density is similar to the detailed simulations and the region size in RR is set to have an average of 100 nodes.
The results are the average of 10 random simulations with 10 random topologies. In Figure 26, we see flooding has
the highest message overhead since each lookup is flooded. Centralized, GHT, and RR have close total overhead.
Figure 27 shows the hotspot message overhead, which is computed as the maximum message overhead at a single
node. Centralized and flooding have a high hotspot overhead compared to GHT and RR. RR has lower hotspot
overhead than GHT in these scenarios, because the lookups for a key in RR are distributed over multiple servers in
the region, while in GHT the same home node get all lookups for a certain key. As we notice also from the table the
hotspot overhead of RR is low when I is small compared to R. As I increase above R, the hotspot overhead will
increase. For GHT lower LIR is preferred.
Total message overhead Hotspot message overhead
Flooding
L n O × ) ( ) (L O
Centralized
) ( ) ( n O L n O I × + ×
) ( I L O +
GHT
) ( ) ( n O L n O I × + ×
) (
I
L
O , {for L > I}
RR
) ( ) ( n O L
R
n
n O I × + + × )
) , min(
(
S R I
L
R
I
O
×
+
14
In Figure 28 and Figure 29, we perform the comparison in the event model. We assume 100 event types, 10
detected events per type, and 50 queries. This gives a .05 LIR. Events are detected at random nodes, while all
queries are from a single node representing the network gateway. We assume aggregation is performed at all of
them, such that a lookup query returns results as a single reply. We do not consider the structured replication version
of GHT. This technique could be used similarly in both GHT and RR. The figures show that RR will have higher
overhead at low number of nodes, because of the insertion geocast overhead with large number of insertions. As the
number of nodes increase, RR will be similar to Centralized and GHT, since the unicast hops will dominate the
overhead in large networks, which confirms the asymptotic overhead shown by the table equation.
1
10
100
1000
10000
100000
1000000
10000000
100000000
100 1000 10000 100000
Number of Nodes
Number of Messages
Flooding
Centralized
GHT
RR
1
10
100
1000
10000
100000
1000000
10000000
100 1000 10000 100000
Number of Nodes
Number of Messages
Flooding
Centralized
GHT
RR

(a) LIR = 100. (b) LIR = 10
Figure 26: Total message overhead with increasing number of nodes and different LIR
0
200
400
600
800
1000
1200
100 1000 10000 100000
Number of Nodes
Number of Messages
Flooding
Centralized
GHT
RR
0
20
40
60
80
100
120
100 1000 10000 100000
Number of Nodes
Number of Messages
Flooding
Centralized
GHT
RR

(a) LIR = 100 (b) LIR = 10
Figure 27: Hotspot message overhead with increasing number of nodes and different LIR
1
10
100
1000
10000
100000
1000000
10000000
100 1000 10000 100000
Number of Nodes
Number of Messages
Flooding
Centralized
GHT
RR
0
200
400
600
800
1000
1200
100 1000 10000 100000
Number of Nodes
Number of Messages
Flooding
Centralized
GHT
RR

Figure 28: Total message overhead in the event model, LIR=.05 Figure 29: Hotspot message overhead in the event model, LIR=.05

15
6 Conclusions
This paper presents the design and evaluation of RR, a scalable rendezvous-based architecture for sensor networks.
RR facilitates bootstrapping, configuration, task assignment, and general service location in sensor networks, in
addition to data-centric storage. We considered applications for two data models that differ in their lookup to
insertion patterns and aggregation properties. We evaluated RR using detailed simulations of a realistic wireless
environment including the physical details and node dynamics. We compared its performance and robustness to
GHT. We studied also the scaling properties of RR using a high level-simulation, and compared its scalability to
GHT, flooding, and a centralized approach. The results reveal the following benefits of RR:
- RR has low lookup overhead due to anycasting, which makes it efficient in applications with high lookup-to-
insertion ratios, such as the service model applications presented.
- RR is highly efficient and robust with node mobility, since regions provide a dampening factor to the effects of
mobility. Results show that it has a high success rate with low lookup, insertion, and mobility update overheads.
- RR is also robust and efficient with failures using a low frequency and low overhead failure checking
mechanism.
- RR is scalable with high number of nodes and the overhead of geocasts is diminished in large networks. It also
has a low hotspot overhead compared to other methods in the service model.
We also plan to study other design options for RR to make it more efficient in applications with high number of
insertions, such as the event model. By using coordination between servers, and low frequency checks for keeping
track of severs in the region, we can avoid geocasts during insertions and support robust aggregation in the event
model.
Although, we suppose that relaxing the requirements for the geographic accuracy of node positions and network
boundaries is one of the main benefits of RR, we have not studied that specifically in this paper. In future work, we
plan to investigate this issue in detail by studying the effect of inaccuracy on geographic-based systems and how far
we can relax it. We will also investigate alternative designs for routing with approximate geographic information.

References
[1] Paramvir Bahl and Venkata Padmanabhan. “RADAR: An In-Building RF-based User Location and Tracking System”. In Proceedings of
IEEE INFOCOM, March 2000.
[2] P. Bonnet, J. E. Gehrke, and P. Seshadri, "Querying the Physical World, " IEEE Personal Communications, Vol. 7, No. 5, October 2000.
[3] J. Broch, D. A. Maltz, D. B. Johnson, Y.-C. Hu, J. Jetcheva. “A performance comparison of multi-hop wireless ad hoc network routing
protocols”. Proceedings of the Fourth Annual ACM/IEEEInternational Conference on Mobile Computing and Networking, ACM, October
1998.
[4] Nirupama Bulusu, John Heidemann, Deborah Estrin. “GPS-less Low-Cost Outdoor Localization for Very Small Devices”. IEEE Personal
Communications, Special Issue on Smart Spaces and Environments, October 2000.
[5] Nirupama Bulusu, John Heidemann, Deborah Estrin, Tommy Tran. “Self-configuring Localization Systems: Design and Experimental
Evaluation”. ACM Transactions on Embedded Computing Systems (TECS), Special Issue on Networked Embedded Computing, 2003. To
appear.
[6] R. Govindan, J. Hellerstein, W. Hong, S. Madden, M. Franklin, S. Shenker. “The Sensor Network as a Database”. Technical Report 02-771,
Computer Science Department, University of Southern California, September 2002.
[7] Chalermek Intanagonwiwat, Ramesh Govindan, Deborah Estrin. “Directed Diffusion: A Scalable and Robust Communication Paradigm for
Sensor Networks”. In Proceedings of the Sixth Annual International Conference on Mobile Computing and Networks (MobiCOM 2000),
Boston, Massachusetts, August 2000.
[8] B. Karp and H.T. Kung. “GPSR: greedy perimeter stateless routing for wireless networks”. Proceedings of the Sixth Annual ACM/IEEE
International Conference on Mobile Computing and Networking (Mobicom) 2000.
[9] Young-Bae Ko and Nitin H. Vaidya. “Location-Aided Routing (LAR) in Mobile Ad Hoc Networks”. Proceedings of the Fourth Annual
ACM/IEEE International Conference on Mobile Computing and Networking (Mobicom) 1998.
[10] Young-Bae Ko and Nitin H. Vaidya. “Geocasting in Mobile Ad Hoc Networks: Location-Based Multicast Algorithms”. IEEE Workshop on
Mobile Computing Systems and Applications (WMCSA) 1999.
[11] Satish Kumar, Cengiz Alaettinoglu, Deborah Estrin. “Scalable Object-tracking through Unattended Techniques (SCOUT)”. In Proceedings
of the 8th International Conference on Network Protocols(ICNP), Osaka, Japan, November 2000.
[12] J. Li, J. Jannotti, D. Couto, D. Karger, R. Morris. “A Scalable Location Service for Geographic Ad Hoc Routing (GLS/Grid)”. Proceedings
of the Sixth Annual ACM/IEEE International Conference on Mobile Computing and Networking (Mobicom) 2000.
[13] NS Network Simulator. http://www.isi.edu/nsnam/ns.
[14] Nissanka B. Priyantha, Anit Chakraborty, Hari Balakrishnan. “The Cricket Location-Support System”. In Proceedings of MOBICOM 2000,
Boston, MA, August 2000.
[15] Sylvia Ratnasamy, Brad Karp, Li Yin, Fang Yu, Deborah Estrin, Ramesh Govindan, Scott Shenker. “GHT: A Geographic Hash Table for
Data-Centric Storage”. First ACM International Workshop on Wireless Sensor Networks and Applications (WSNA) 2002.
[16] A. Savvides, C.-C. Han, M. B. Srivastava. “Dynamic Fine-Grain Localization in Ad-Hoc Networks of Sensors”. Proceedings of the Seventh
Annual ACM/IEEE International Conference on Mobile Computing and Networking (Mobicom 2001), Rome, Italy, Jul. 2001.
[17] A. Ward, A. Jones, A. Hopper. “A New Location Technique for the Active Office”. IEEE Personal Communications, October 1997.

Linked assets

Computer Science Technical Report Archive

Conceptually similar

PDF

USC Computer Science Technical Reports, no. 837 (2004)

PDF

USC Computer Science Technical Reports, no. 797 (2003)

PDF

USC Computer Science Technical Reports, no. 801 (2003)

PDF

USC Computer Science Technical Reports, no. 757 (2002)

PDF

USC Computer Science Technical Reports, no. 812 (2003)

PDF

USC Computer Science Technical Reports, no. 755 (2002)

PDF

USC Computer Science Technical Reports, no. 743 (2001)

PDF

USC Computer Science Technical Reports, no. 814 (2004)

PDF

USC Computer Science Technical Reports, no. 806 (2003)

PDF

USC Computer Science Technical Reports, no. 887 (2007)

PDF

USC Computer Science Technical Reports, no. 884 (2006)

PDF

USC Computer Science Technical Reports, no. 781 (2002)

PDF

USC Computer Science Technical Reports, no. 804 (2003)

PDF

USC Computer Science Technical Reports, no. 749 (2001)

PDF

USC Computer Science Technical Reports, no. 790 (2003)

PDF

USC Computer Science Technical Reports, no. 803 (2003)

PDF

USC Computer Science Technical Reports, no. 841 (2005)

PDF

USC Computer Science Technical Reports, no. 789 (2003)

PDF

USC Computer Science Technical Reports, no. 692 (1999)

PDF

USC Computer Science Technical Reports, no. 644 (1997)

Description

Karim Seada, Ahmed Helmy. "Rendezvous regions: A scalable architecture for self-configuration and data-centric storage in sensor networks." Computer Science Technical Reports (Los Angeles, California, USA: University of Southern California. Department of Computer Science) no. 788 (2003).

Asset Metadata

Creator Helmy, Ahmed (author), Seada, Karim (author)

Core Title USC Computer Science Technical Reports, no. 788 (2003)

Alternative Title Rendezvous regions: A scalable architecture for self-configuration and data-centric storage in sensor networks (title)

Publisher Department of Computer Science,USC Viterbi School of Engineering, University of Southern California, 3650 McClintock Avenue, Los Angeles, California, 90089, USA (publisher)

Tag OAI-PMH Harvest

Format 15 pages (extent), technical reports (aat)

Language English

Unique identifier UC16270901

Identifier 03-788 Rendezvous Regions A Scalable Architecture for Self-Configuration and Data-Centric Storage in Sensor Networks (filename)

Legacy Identifier usc-cstr-03-788

Format 15 pages (extent),technical reports (aat)

Rights Department of Computer Science (University of Southern California) and the author(s).

Internet Media Type application/pdf

Source 20180426-rozan-cstechreports-shoaf (batch), Computer Science Technical Report Archive (collection), University of Southern California. Department of Computer Science. Technical Reports (series)

Access Conditions The author(s) retain rights to their work according to U.S. copyright law. Electronic access is being provided by the USC Libraries, but does not grant the reader permission to use the work if the desired use is covered by copyright. It is the author, as rights holder, who must provide use permission if such use is covered by copyright.

Repository Name USC Viterbi School of Engineering Department of Computer Science

Repository Location Department of Computer Science. USC Viterbi School of Engineering. Los Angeles\, CA\, 90089

Repository Email csdept@usc.edu

Inherited Values

Title Computer Science Technical Report Archive

Description Archive of computer science technical reports published by the USC Department of Computer Science from 1991 - 2017.

Coverage Temporal 1991/2017

Repository Email csdept@usc.edu

Repository Name USC Viterbi School of Engineering Department of Computer Science

Repository Location Department of Computer Science. USC Viterbi School of Engineering. Los Angeles\, CA\, 90089

Publisher Department of Computer Science,USC Viterbi School of Engineering, University of Southern California, 3650 McClintock Avenue, Los Angeles, California, 90089, USA (publisher)