Computer Science Technical Report Archive

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

(USC DC Other)

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

PDF

Download a page range

Download transcript

Copy asset link

Request this asset

Transcript (if available)

Content 1 Mobility-Assisted Resolution of Queries in Large-
Scale Mobile Sensor Networks (MARQ)
Ahmed Helmy
Department of Electrical Engineering
University of Southern California
helmy@usc.edu
Abstract
One of the most crucial aspects of the design of sensor networks is provisioning of efficient query resolution
and resource discovery. In many cases sensor networks are expected to be large-scale (i.e., consist of potentially
thousands of nodes), and in some cases these sensors maybe installed on moving objects, rendering the query
resolution problem even more challenging. Flooding techniques, including global flooding or expanding ring
search techniques, may be very inefficient in large-scale networks, especially in wireless (spatial) networks where
the diameter of the network maybe quite high. More so is the case when queries are one-shot and frequent.
In this study, a novel architecture is presented for query resolution in large-scale mobile sensor networks. A
salient feature of our architecture is that it takes advantage of mobility to increase the efficiency of query resolution.
The architecture borrows from the concept of small worlds and introduces the concept of contacts that act as short
cuts to reduce the degrees of separation between the sources of the query and the targeted objects. Contacts are
initially chosen from nearby neighbors, as they move away they discover new neighbors and hence become more
effective in query resolution. Unlike approaches for routing protocols, route or delay optimization is not the
primary design goal of our architecture, but reducing communication overhead is. This is especially true in energy-
constraint environments, as are many sensor networks, particularly for one-shot queries, where no path is
established to be used for further communication. We design our protocol to be scalable, self-configuring, and
highly adaptive to mobility. In fact, it utilizes mobility.
We evaluate our protocol through extensive simulations and present a detailed analysis of its performance. We
further compare our approach to other query resolution protocols. Our results clearly indicate the drastic
improvement obtained by using contacts, especially in high mobility scenarios. For non-replicated objects, we
obtain 60-70% improvement over edge-of-zone flooding, 80-90% improvement in communication overhead over
flooding, and even greater improvements over expanding ring search approaches. Our protocol responds extremely
well to replication, as the number of transmitted packets per query drops significantly.
1. Introduction
‘Sensor networks’ is a new and emerging field with many potential applications. The design of sensor
networks, unlike traditional computer networks, is geared towards specific applications, or classes of applications
that have common characteristics. Those characteristics may vary widely from one application-domain to another,
in terms of communication and query semantics, energy-constraints, capabilities and mobility patterns, among
others. As such it is quite hard (and sometimes even undesirable) to design general protocols for all operating
conditions. Design of sensor networks can, and in fact should, take advantage of domain-specific information.
Many such domain-specific sensor networks are designed to collect and disseminate data upon request, and may be
viewed as databases. Hence, one of the most crucial aspects of the design of sensor networks is provisioning of
efficient query resolution and resource discovery. In many cases sensor networks are expected to be large-scale
(i.e., consist of potentially thousands of nodes), and in some cases these sensors maybe installed on moving objects,
2 rendering the query resolution problem even more challenging. Examples of such cases include networks of
distributed robots, and person or object monitoring/tracking, among others.
Semantics of data collection and query may be quite different for different applications and situations. For
example, queries maybe continuous or one-shot. For continuous queries the interest in the data collected may
extend over periods of time beyond the query time. Also queries may be frequent or infrequent, simple or complex
(asking for multiple pieces of information that may exist on multiple sensors). The data may also be unique ore
replicated.
Our design goal is to provide efficient query resolution for one-shot, frequent, simple queries. In addition our
protocols should be able to respond well to data replication when applicable.
We do not assume dependence on availability or precision of any location or geographic information. That is,
we assume that node, data, and interest location is unavailable, partially available or imprecise (such that
geographic routing cannot be used), or that the boundaries of the network are unknown or dynamic (due to node
mobility) such that consistent location hashes cannot be used to store-retrieve information. In other words, there is
no fixed frame of reference to rendezvous information between producers and consumers of data. Taking advantage
of such information if and when it becomes available/usable is not addressed in our study, and can be potentially
pursued in future work. So, for this work we assume that such information is not available.
In such situations, simple approaches of flooding may be used. Flooding techniques, including global flooding
or expanding ring search techniques, may be very inefficient in large-scale networks, especially in wireless (spatial)
networks where the diameter of the network maybe quite high. More so is the case when queries are one-shot, and
for potentially replicated objects.
In sensor networks, data tend to be of low-bandwidth and volume, and hence communication due to inefficient
control protocols (e.g., query resolution) are likely to dominate the overall cost of communication in such networks.
Also, in many cases of sensor networks, energy consumption of communication far exceeds that of processing
1 . Since wireless sensors, in general, have very limit power, it becomes essential to provide efficient control protocols
for query resolution. This is the problem we address in our study.
We present a novel architecture for query resolution in large-scale mobile sensor networks, for the
aforementioned environments. A salient feature of our architecture is that it takes advantage of mobility to increase
the efficiency of query resolution. The architecture borrows from the concept of small worlds [1] [2] [3] [4] [22] and
introduces the concept of contacts that act as short cuts to reduce the degrees of separation between the sources of
the query and the targeted objects. Degrees of separation in this context represent the number of nodes (or contacts)
to query before reaching the target. Contacts are initially chosen from nearby neighbors, as they move away they
discover new neighbors and hence become more effective in query resolution. Unlike approaches for routing
protocols, route or delay optimization is not the primary design goal of our architecture, but reducing
communication overhead is. This is especially true in energy-constraint environments, as are many sensor
networks, particularly for one-shot queries, where no path is established to be used for further communication.
We make a conscious design choice of trading off route and delay optimality for reduction in overall
communication overhead. We borrow from existing work on zone routing, but extend beyond that work to provide
much more efficient query resolution by using contacts and by changing the design trade- offs as mentioned above.
Major contributions of this work lie in the introduction of the concept of contacts as short cuts in the wireless
network (that attempt to construct a small world), and the proposal of novel mobility-assisted protocols for contact
selection and maintenance. That is in addition to the drastic improvement in query resolution overhead.
We evaluate our protocols through extensive simulations and present a detailed analysis of its performance. We
further compare our approach to other query resolution protocols. Our results clearly indicate the drastic

1 Note that energy to provide mobility may exceed, by far, the communication overhead. In the situations we target, however, we assume
mobility is either provided by the sensor-carrying person or object (e.g., animal), or that provisioning of mobility (e.g., in robots) is done by a
separate source that can not be shared with the wireless sensor.
3 improvement obtained by using contacts, especially in high mobility scenarios. For non-replicated objects, we
obtain 60-70% improvement over edge-of-zone flooding (ZRP-like [18] ), 80-90% improvement in communication
overhead over flooding, and even more over expanding ring search approaches. These improvements are enhanced
significantly even further with replication.
The rest of the paper is outlined as follows. Section 2 provides an overview of the contact-based architecture.
Section 3 introduces the mobility-assisted contact selection protocol. Section 4 gives elaborate description of the
contact-based query mechanisms. Evaluation and comparison simulation experiments and analysis of results is
detailed in Section 5. Related work is discussed in Section 6. Section 7 concludes and provides future work
directions.
2. Contact-based Architecture Overview
First we start by stating our assumptions and the context in which our architecture is applicable then we provide
an overview our contact-based architecture.
2.1 Assumptions
First, we state the assumptions upon which our architecture is built. (1) The source of the query may not know
the ID of the target node that holds the resource. (2) Nodes only have local knowledge of their neighbors (e.g.,
using 1 hop Hello or data link connectivity). (3) Nodes do not know their own location or any other geographical
location of any other node (i.e., our architecture does not require GPS or any other GPS-less distance estimation
techniques)
2 . (4) Infrastructure-less network: We assume there are no well-known servers or landmarks.
These assumptions differentiate our work from other works that require any of the above elements.
2.1 Architectural Overview
We propose what we call a loosely coupled simple hierarchy. It is loosely coupled because each node has its
own view of the network (its zone), and it is simple because there are no complex coordination mechanisms to elect
cluster-heads or leaders. In our architecture, each node knows a number of neighboring nodes in a neighborhood or
zone. The zone may be defined, for example, by a number of hops R . Information about nodes within the zone are
obtained by an intra-zone link state protocol. Outside of the zone, a node may maintain (a small number of)
contacts. A contact is chosen at r hops distance from the selecting node. The contact may be maintained up to r max
hops away. The idea behind the contacts stems from the small world concept, for increased coverage and
reachability of other nodes. A contact outside a node’s zone will also have its own zone, thus providing an extended
view of the network. This is shown in Figure 1 . Our architecture is not to be confused with other cluster-head or
landmark based hierarchies. In our scheme there is virtually no coordination between nodes in a zone. There are no
special nodes, whose failure or movement may incur significant re-configuration overhead. By contrast, we shall
show that our scheme incurs non-significant overhead with mobility.
The main components of our architecture include: (a) zone establishment, (b) contact selection and
maintenance and (c) query processing and forwarding.
Zone establishment is performed by each node independently by sending link state messages to R hops away.
We call R the zone radius. For zone establishment we use mechanisms similar to those used in
ZRP [13] [16] [17] [18] . Alternatively, other energy efficient link state mechanisms may be used (e.g., STAR [21] ).
In this paper, we focus on the remaining components of the architecture; namely contact selection and
maintenance and query processing and forwarding. We think of contacts as short cuts to the outside world (out-of-
zone that is), that provide useful information when needed. To reduce the discovery delay these contacts are

2 Availability of such location information may simplify our architecture. Studying such simplifications is part of on-going and future work.
4 established in anticipation of queries. With network dynamics and mobility it may be quite expensive to establish
and maintain routes to all far away contacts. Instead, we propose to establish candidate contacts from within the
zone. As these candidates move out of the zone they become contacts and can be used in the query process, thus
taking advantage of mobility. One unique feature of our architecture is that its performance improves with
increased mobility, as we shall show in the evaluation section.
R R R R S contact
contact
contact
S : Selector Node
R : zone radius (in hops)
Figure 1 . A node in the contact-based architecture chooses a small number of contacts outside its zone to increase its network view during
query resolution or resource discovery
Not all nodes in the network need to establish contacts. In fact, if all nodes establish contacts this may
constitute a large overhead for large-scale networks. Only a small subset of nodes, called selectors, independently
choose to establish contacts. Selectors are not fixed, but are dynamic and may be chosen (in a distributed manner,
without extra overhead) in a way that achieves load balancing. A selector keeps a list of (a subset of) its zone
borders, and chooses its contacts from those border nodes that move out of the zone. This choice takes advantage of
zone information to attempt to reduce overlap between contact zones. Once the contact is out-of-zone a simple
contact discovery mechanism is invoked to keep track of it. Routes maintained to contacts are loose (perhaps sub-
optimal) routes. Since each node knows about neighboring nodes up to R hops away, the contact route (that has
initial length of R hops) may be extended up to R 2 hops without any extra overhead as the nodes en-route move
away. Once a contact (or one of its en-route nodes) moves too far away, then the contact is dropped and another is
chosen. We investigate the choice of the number of selectors, contacts and the value of R as part of our study.
Once these contacts are chosen they may be used in the query process for resource discovery. A querying node
sends messages to its contacts, and their contacts and their contacts, so on, up to maximum contact level or until the
object is found. We introduce mechanisms to prevent loops and re-visits of already-searched zones.
We evaluate our protocol through extensive simulations and compare it to various other approaches for
resource discovery, including flooding, expanding ring search (and its variants), and the border-casting (or edge
flooding) approach
3 . We evaluate the query success ratio and the total overhead (due to query and the architecture),
and use them as basis of our comparison metrics. We note that the zone and contact establishment and maintenance

3 Border-casting was introduced for the zone routing protocol ZRP [13] . Although designed for routing, we believe that the general approach
is also attractive for resource discovery. We feel, however, that it may be unfair to compare our scheme to a routing protocol (since it
incorporates route quality as a design goal). So, we refer to border-casting as ‘edge flooding’ for the rest of this document.
5 vary with mobility and simulation time and are amortized over the number of queries performed (which is in turn a
function of the query rate). We consider all these factors in our evaluation and show for which range of query rates
and mobility is our approach is best suited.
3. Mobility-assisted Contact Selection (MACS)
One of the main challenges that we need to address in our architecture is the effect of mobility and its dynamics
on contacts. We pose this challenge in the form of the following question. How will contacts be selected with
reasonable overhead under mobility conditions to significantly reduce query overhead? To attempt to answer this
question we propose a mobility-assisted contact selection (MACS) scheme.
The problem of contact selection is challenging for two main reasons. First, mobility seems as an adversary,
providing sometimes random node movement and contributing to link and path failure. Second, the selecting node
is likely to know little or no information about the mobility characteristics and capabilities of nodes in far away
regions of the network, and hence may not be able to make intelligent decisions as to which node may be useful to
resolve a query. We argue that in order to achieve significant reduction of query overhead contacts need not be
randomly placed in the network (a concept that follows from the small world concept
4 ). This argument is
substantiated by our results later in the paper. We instead propose a scheme that selects contacts from the selector’s
zone, and tracks those contacts as they drift out-of-zone. This idea is illustrated in Figure 2 . Border Node
Center Node
Internal Node
Mobility R S 5 1 4 3 6 7 2 Zone Radius
Route

R R R R S 5 1 4 3 6 7 2 contact
contact
contact
R R R R S 5 1 4 3 6 7 2 contact
contact
(a) ( b) (c)
Figure 2 Example of zoning, contacts and effect of mobility: (a) Zone for source node S is shown (with radius R ). Border nodes are numbered
(1-7). Nodes 1,3 and 6 are moving/drifting out of zone. (b) Radii for the drifting nodes are shown. S stays in contact with the drifting nodes,
which enables it to obtain better network coverage with low overhead. (c) After moving away, contact nodes drift up to a point where their
zones no longer intersect with S ’s zone. In this example, S maintains contact with those nodes not more than (2 R +1) hops away, i.e. nodes 3
and 6, and loses contact with node 1 as it drifts farther than the contact zone.
Our proposed scheme takes advantage of mobility . In our approach, a selecting node, S, makes initial selection
of a list of candidate contacts ( CCs) from its own zone. These are nodes that lie within R hops away. S knows
routes to these nodes via intra-zone routing. This way, S may also collect information about CCs’ mobility or
abilities. This information may be piggybacked over the intra-zone link state exchange. The future contacts are to
be chosen from this list of CCs. Once these candidate contacts move out-of-zone, overlap between their zones and

4 In small world analysis on relational graphs it is suggested that adding a few ‘random’ links achieves significant improvement in degrees of
separation. Degree of separation in our case is the number of intermediate contacts to query before reaching the target. In wireless networks
(that belong to spatial graphs with boundaries) placement of contacts may be restricted in distance while still achieving significant reduction
in degrees of separation [22] . Treatment of this problem is out of scope of this document.
6 S’s zone will be reduced and the added network view (or coverage) will be significant, as shown in Figure 2 . Following we describe in more detail the contact selection, maintenance and their integration.
3.1 Contact Selection
A selector node, S, starts selecting a list of candidate contacts ( CCs) from the zone (i.e., within R hops). Based
on its mobility pattern, a node on the CCs list may get promoted to contact or get dropped (or evicted) from the
candidacy list based on promotion/eviction rules. By mobility pattern we mean the sequence of distances (in hops)
between these candidates and the selecting node, over time. When and if a candidate crosses the promotion
boundary (PB) it is considered a contact and may be queried during searches. Once a contact crosses the upper or
lower eviction boundaries (UEB, LEB) it is evicted from the contact list and is not queried in further searches (see
Figure 3 ). That is, if a node moves too far away (beyond the eviction boundary) it is harder to maintain, whereas if
it comes closer to S its new zone may overlap with that of S, and is evicted in both cases. We investigate two
contact selection protocols called border-based and neighbor prediction-based contact selection protocols . Border based contact selection protocol: Selection of candidate contacts is done from nodes at R hops, i.e., at
the border of the zone. Nodes R hops away are tracked, i.e. , S keeps track of its movement/distance over time. If
border nodes move closer to S , they are evicted. If they cross the promotion boundary, those candidates become
contacts. When the contacts cross an eviction boundary they are evicted.
S Lower Eviction Boundary
(LEB)
Upper Eviction Boundary (UEB)
Promotion Boundary (PB)
Contact
Evicted
A t1
A t2
A t4
A t3
B t1
Contact
B t2
B t4
Evicted
Figure 3 Promotion and Eviction boundaries for S: nodes A and B originally in S’ s zone, get promoted at time t2 when they cross the
promotion boundary (PB), then they get evicted from the contact list at time t4 when they cross the lower or upper eviction boundary.
Neighbor prediction based contact selection protocol: This protocol takes advantage of the fact that S readily
knows the routes/hop distance to nodes within its zone (i.e., within R hops away). It also takes advantage of the
likelihood that (even in random way point movement) mobility often remains constant for short whiles. In this
protocol, node S selects neighbors (those nodes that are 1 hop away) to track their movement. When a neighbor
node becomes at 2 hops away, then 3 hops away, this sequence may indicate that this neighbor is heading out of
zone and has a high probability to continue moving away. Other neighbors, that do not show this consistency in
mobility, may take longer (if ever) to get to the desirable region and thus waste more resources before becoming
useful, and so are evicted from the CCs list. We expect this simple prediction scheme to help identify good
candidates that have higher probability of becoming contacts in the case where there is regular mobility pattern. But
in case of random movement, as our initial results show [22] this prediction scheme may not prove advantageous
over the border selection scheme, but will lead to delays in contact selection. For the rest of this paper we use
border based contact selection scheme.
7 3.2 Contact Maintenance
As the CCs move, S keeps track of their distance (in hops) through intra-zone routing, and when they move out-
of-zone a lightweight local route discovery mechanism is used (see Figure 4 ) . The precise route need not be kept at
all time, but only a loose route is maintained to reduce maintenance overhead. So long as every node en-route to the
contact has the next node en-route in its zone (i.e., at most R hops away) , then S can route to the contact.
R S Z A B C R R S Z contact
A B C R R S Z contact
A B R (a) ( b) (c)
Figure 4 The local route discovery protocol (a) Z is at the border of S ’s zone with a route ‘ S-A-B-Z’. Z is moving out-of-zone. (b) Z is no
longer within S’ s zone, but it highly likely to exist in B’ s zone. The route ‘S-A-B-C-Z’ is identified and Z is selected as a contact. (c) Only
loose routing may be kept by S without the need to update the exact route, so long as each node en-route has the next node en-route in its
zone, then S can route to Z . This dampens route oscillations and reduces overhead.
3.3 Integrating Selection and Maintenance
In order to reduce overlaps and gaps between S’ s zone and the zones of its contacts we use two heuristics. First,
we note that the initial route to the contact is of R hops (e.g., S-A-B-Z as in Figure 4 , (a)), which may be allowed to
grow up to R 2 hops without extra overhead (as shown in Figure 4 , (c)). On average, a contact will be at R+ ( R 2 -R)/2
hops away, with overlap or gap (between S’ s zone and the contact’s zone) of |( R 2 -3R)/2| . So in order to minimize
the overlap or gap we set R=3 (this also incurs very reasonable link state overhead for the zone [18] ) . Second, in
order to reduce overlap between the contacts zones S chooses contacts to which it has disjoint routes.
Based on this scheme we use a simplified version of the border selection scheme that incurs very low overhead
and proved to perform very well. We use a promotion boundary and lower eviction boundary of R , and an upper
eviction boundary (of at most R 2 ) depending on the connectivity between nodes en-route to the contact. In this
version, a selector node keeps track of the border nodes; nodes that are exactly R hops away. This information is
readily available through the intra-zone exchange. Every time a link state update changes route information about a
border node, the new information is checked against the old information. If the update leads to a previous border
(say node Z ) disappearing from S ’s routing tables, then this indicates that Z has moved out-of-zone and it becomes a
potential contact. The local route discovery protocol (described previously) is performed to establish a new route to
the contact, Z . The selector node, S , sends a self-monitoring message to what used to be the (last hop) node leading
to Z , say node B , if reachable . The self-monitoring message creates state in the nodes en-route to Z (e.g., nodes A and B in Figure 4 ). It is highly likely that Z will be in B ’s zone, and the self-monitoring state will be established in
about R nodes. As the nodes move, the path leading to Z may be kept up to R 2 hops, without the need to exchange
any additional messages. If Z is not in B ’s zone then B sends a remove monitor message back to the selector. The
self-monitoring state established in the nodes contains the next and previous hops on the path to Z , e.g., the self-
monitoring state in B includes A as the previous hop and Z as the next hop. If the self-monitoring state exists in a
node, it is checked with every route change. If the previous node on the path is not in-zone, then the node removes
the self-monitoring state. Otherwise, if the next node on the path is out of zone, a remove monitor message is sent
8 to the previous node. This message is propagated back to the selector node and eradicates the self-monitoring state
in the previous nodes on the path. It causes the selector, S , to evict the contact, Z . Also, if Z moves back into S ’s
zone, it is evicted. Once the desired number of contacts has been selected the border check procedure need not be
performed until and unless some of the existing contacts get dropped (or evicted).
4. Contact-based Query
In order to perform contact-based queries, selector nodes must be chosen, then they select and maintain their
contacts (as described above), a policy is decided upon to perform the query (either level-by-level or single-shot),
then the query is forwarded and processed. We detail these mechanisms in this section.
4.1 Choosing Selectors
The simplest scheme for choosing selectors is that every node becomes a selector with probability 1. This
means, however, that the selection and maintenance overhead grows linearly with the number of nodes in the
network and the number of contacts per selector. Instead, we propose that only a small number ( x% ) of nodes in the
network become selectors to decrease the selection overhead. Our study shows that after a certain point (about 10%
of the nodes or 2% of the links), creation of new contacts in the network adds very little to improve performance
(we shall discuss this further in the evaluation section). For robustness reasons we may also want multiple selectors
(e.g., 3 on average) to be accessible by every node. The selection may also be a function of available energy, or
capability (for example, in some sensor networks a few nodes may be designated to collect information), or other.
For simplicity, we do not assume prior knowledge of such heterogeneity and use a simple probabilistic method
where every node independently chooses itself as a selector with probability (5%-10%). A selector node sets a
selector bit in the intra-zone information such that other nodes in the zone may use its contacts. Possible
improvement of the protocol would be to allow nodes that do not have selectors in their zones to select their own
contacts. A node running out of energy (or is overloaded) may stop advertising itself as a selector thus triggering
other nodes to select contacts, and achieving load balancing.
4.2 Query Policy
When a node issues a query, it first checks if the target resource exists in its zone (readily available through the
intra-zone link state exchange). If not, then it issues a query message to a selector node (either itself is a selector or
another selector in its zone)
5 , that in turn forwards the query message to its contacts. The process by which the
search sequence progresses depends on the query policy. We present two policies for query sequence: ( i) the level-
by-level contact query, and (ii) the single-shot contact query.
In the level-by-level contact query approach the querying node, Q , sends the query message to its contacts (or
those of a selector in its zone), called the 1
st
level contacts. If the target is not found (i.e., no positive reply is
returned to Q within a period t ), then Q issues a new query that extends to the contacts of the previously visited
contacts, called the 2
nd
level contacts. Unless the target is found, the process repeats up to the n th
level contacts.
[For our study we set n =5. Our study shows that for n>5 we get diminishing returns; i.e., query success rate almost
saturates and overhead rises sharply.] If the target is still not found, a fall-back mechanism is used, such as flooding
or border-casting edge-flooding (i.e., ZRP-like [18] ); both alternatives are investigated in the evaluation section. At
any point in the search, if the target is found, a response is sent back to Q , and the search terminates at that level.

5 For this study we assume that if a node is not a selector and does not have other selectors in its zone then it resorts to flooding (or edge
flooding as described later). This represents an upper bound on our overhead. In enhanced versions of the protocol a node may select contacts
on-the-fly using TTL of 2 R , but this may entail using contacts with unknown capabilities, energy, etc.
9 (ii) In the single-shot contact query the same query is propagated from the 1
st
level contacts to the 2
nd
, and so on
until the n th
level contacts.
These two different policies have different merits. The level-by-level approach ends search when a target is
found, and so may take advantage of object replication by reducing query overhead drastically (as we will show).
The single-shot approach incurs less delay, and has very comparable per query overhead to the level-by-level
approach with the proper setting, in case of no replication. We shall investigate both approaches.
4.3 Query Forwarding and Processing
The same rules of query processing are applied in both query plicies. Each new query issued by Q is given a
new sequence number, SN . As the query is passed on from contact to contact, nodes en-route (and their neighbors
for single channel networks) process it hop-by-hop. Hop-by-hop processing includes a lookup in the zone table to
check if the target is in zone. We call this type of processing ‘sweeping queries’. In addition, each node processing
the query records its SN and Q . This record is needed for the expected completion of the query, and so is timed out
after a few seconds to be robust to SN wrap- arounds and failure of Q. If the target is found by the destined contact,
a node en-route, or any of its neighbors, a response is returned to Q . Each contact, upon receiving a query message
(to which it is the destination), checks its records for SN and Q , if found then the query message is simply dropped.
We call this scheme loop prevention. The same cannot be done for en-route nodes, because the query message
maybe destined to far away contacts, the zones of which have not been covered before. For en-route nodes, upon
reception of a query message, the records are checked for SN and Q , if found, then another check is performed on
the destination of the query message. If the destination lies within less than 3 hops away, then the query message is
dropped, otherwise it is propagated. This reduces search overhead leading to contacts, the zones of which heavily
overlap with zones that have been investigated before. We call this scheme re-visit reduction. These schemes
proved effective in reducing the query overhead while having very little effect on query success.
5. Evaluation and Comparison
In this section we describe a set of simulation experiments used to evaluate our proposed contact-based query
schemes. We analyze the overhead and success rate of our architecture over various dimensions; mobility, network
size, query rate, degree of replication and various numbers of contacts. In addition, we simulate several other query
mechanisms and compare their performance to the contacts approach, including flooding, expanding ring search
and several of its variants, and the border-casting approach (which we refer to as edge-flooding).
For the overhead analysis, we investigate the different overhead components of our schemes in detail.
Particularly, we study overhead of the contact selection and maintenance, the zone establishment and maintenance
and the query overhead. We also introduce new metrics, based on the call-to-mobility ratio ( CMR ), to capture the
effects of the overall traffic as function of query rate per mobility unit. This facilitates our comparisons.
5.1 Simulation Setup
The networks simulated vary in size from 200 to 1000 nodes over 1km x 1km area and varying radio range
(55m for the 1000 node topology, 70m for 500 node, and 105m for the 200 node topology) to keep the node density
almost constant. By node density we mean the average node degree or number of nodes per zone. The nodes are
randomly distributed over the area. For mobility we use the random way point model, in which a node chooses a
random destination and picks a random velocity from [0,Vmax]. Once the destination is reached another destination
and velocity are picked randomly, so on. We use a pause time of 0, i.e., continuous mobility. Vmax was varied
10 from 2m/s to 40m/s. A single channel model was used in which a broadcast message may be heard by all neighbors
within range. We do not simulate MAC layer protocols
6 . We use a discrete event simulator that borrows code from
NS-2 (mainly mobility and route computation) in addition to our own protocol modules for implementing the
various query mechanisms. We present overhead in terms of packet transmission
7 . Most contact-based simulations
were run using 5%-10% selectors (i.e., 50 selectors for the 1000 node topology, 37 selectors for the 500 node
topology and 20 selectors for the 200 node topology), usually using 4 maximum contacts each unless stated
otherwise. Average values shown were averaged over 9 different runs of varying random seeds.
5.2 Contact Selection & Maintenance Overhead
The contact selection and maintenance overhead reflects the packets sent during the contact selection,
promotion and eviction procedures described above. This is expected to be a function of node mobility and the
number of total contacts selected (i.e., number of selectors and maximum number of contacts per selector).
Therefore, we use metrics that attempt to capture per contact, per node and per mobility measures. Also we
investigate how the contact selection process is affected by mobility.
As shown in Figure 5 (a), the contact selection protocol becomes more efficient (meaning it selects more
contacts) with the increase of velocity. In Figure 5 (b) the overhead of contact selection and maintenance is shown
for two measures: ( i) the overhead per contact second and (ii) the overhead per node per second. The former
measure ( i) indicates number of messages transmitted to keep a contact for 1 second; calculated as the ratio of the
total packets transmitted to the sum of contacts through the simulation (counted every second). Both measures show
linear relationship between overhead and velocity. The difference between the measures (almost a factor of 5)
reflects the ratio of nodes to contacts. One additional overhead measure of interest is the packets per node per
second per (m/s), where (m/s) is the average node velocity (Vmax/2 in our case). This measure captures overhead
regardless of the mobility degree. We refer to such measure as the normalized overhead of selection and
maintenance (or SM for short). Our simulation results consistently show that SM for our scheme is 0.02
packets/node/sec/(m/s), for all velocities and over various topologies. This will be used later on in our comparisons.
Simulation results are shown for 1000 node topology with 55m range, 50 selector nodes and 4 contacts per selector
over 100 seconds of simulation time. Similar SM overhead results were obtained for the other topologies.
0 20
40
60
80
100
120
140
160
180
200
0 20 40 60 80 100
Simulation time (sec)
Selected contacts 40 m/s
5 m/s
2 m/s
0 0.5
1 1.5
2 2.5
0 10 20 30 40
Velocity [Vmax] m/s
Contacts Overhead Overhead per contact sec
Overhead per node per sec
(a) ( b)
Figure 5 . Contact selection and maintenance analysis: (a) The number of selected contacts over time for different mobility degrees, the higher
the mobility the more efficient the contact selection. (b) Overhead of selection and maintenance of contacts with various degrees of mobility,
the overhead increases linearly with mobility. Solid line represents the overhead per contact second (the total packets transmitted during the
simulation for contact selection and maintenance over the cumulative count of contacts through the simulation), dashed line represents the
overhead (packets transmitted) per node per second.

6 Collisions at the MAC layer will be exacerbated by the excessive query traffic (especially broadcast traffic). Not modeling collisions
actually works in favor of flooding-based protocols, that would have shown even worse performance had collisions been modeled.
7 We have conducted studies that consider both transmission and reception and got similar comparison results.
11 5.3 Zone Overhead
The intra-zone information dissemination protocol uses link state to update routes to nodes within R hops
away. The overhead incurred by this protocol is a (linear) function of mobility as shown in Figure 6 (a). Hence, we
use a per mobility metric to capture overhead independent of mobility degree, the packets per node per second per
(m/s). Figure 6 (b) shows this metric for different radii of link state exchange
8 . Let us call these values LS(h) , where
h indicates the hops extent of link state exchange. We are particularly interested in the case where R=3 . For our
scheme LS(3) is needed to establish a zone of radius R=3 , and the overhead incurred is ~3 packets/node/sec/(m/s).
For edge flooding ( Efld) or ZRP R=3 translates into 2R-1=5 link state exchange to perform the early termination
(ET) algorithm. Hence, for R=3 , Efld incurs LS(5)=9 packets/node/sec/(m/s) overhead. More on this in the
comparison section for total overhead.
0 10
20
30
40
50
60
0 10 20 30 40
Velocity [Vmax] m/s
Overhead (Tx packets per sec per node) 0 5 10
15
20
25
30
35
40
3 5 7 9 11 13
Link state extent (hops)
packets per node per second per (m/s) (a) ( b)
Figure 6 Overhead of the zone establishment for link state: (a) Exchange over R=3 . The overhead increases linearly with mobility. (b)
Overhead per (m/s) of mobility for various settings of R . 5.4 Query Overhead and Success Rate
The overhead is measured in transmitted packets per query. Success is the number of successful queries (or
reachable nodes) in the network. Because the query success of contact-based query may be lower than the other
schemes, we propose a fall-back (or penalty) scheme. For every unsuccessful contact-based query, we trigger a
flooding or Efld message. This achieves the same reachability for all schemes. We refer to the contact based
scheme as ‘ c ’, and the fall-back schemes as ‘ c+flood ’ and ‘ c+Efld ’, respectively. We first show results for the
level-by-level contact query, then discuss the single-shot contact query. In this subsection we study effects of
mobility, number of contacts, number of nodes; i.e., network size (or topology), and effect of replication. For
single-shot contact query we study the effect of varying the maximum contact level.
Performance with mobility
In this experiment the velocity ( Vmax) was varied from 0 to 40m/s (note that 0 velocity means that only nodes
within a zone are reachable and out-of-zone nodes can only be reached through fall-back)
9 . Results are shown in
Figure 7 for 1000 node topology, with 25 second simulation, for the first 15 seconds no queries were triggered to
stabilize the network then queries were triggered with a rate of 0.15 query per node per second generating 1500
queries. It is very clear that the query overhead decreases drastically with increase of mobility. This is explained by

8 A similar study was conducted for ZRP [18] and similar results were obtained.
9 Further enhancement of the contact-based query may be achieved by integrating a non-mobility based contact selection as
in [33] [34] , or through another heuristic. This is part of future work.
12 investigating the contact-based reachability; i.e., success rate. With low mobility, less number of contacts are
selected, and hence there is a higher percentage of failures, and hence a higher percentage of fall-backs, and vice
versa for high mobility. Note that the reachability curve shown is for the contact-based scheme only. After using
fall-back the success rate is same as the other protocols. The overhead per query shown is for both contact-
based+fall-back mechanism (i.e., that achieving maximum success rate). Figure 7 (b) shows the overhead ratio for
contact- based+fall-back over the fall-back; mainly illustrating the advantages in query overhead obtained by using
contact-based queries (70% improvement over flooding and 50% improvement over Efld, in high mobility).
0 100
200
300
400
500
600
700
800
900
0 5 10 15 20 25 30 35 40
Velocity [Vmax] m/s
c+ flood overhead
c+ Efld overhead
c success
0 0.2
0.4
0.6
0.8
1 0 5 10 15 20 25 30 35 40
Velocity [Vmax] m/s
Overhead ratio (c+flood)/flood
(c+Efld)/Efld
(a) ( b)
Figure 7 . Effect of mobility on query overhead for the contact-based query with fall-back, c+flood uses flooding as a fall-back
mechanism while c+Efld uses the edge-of-zone flooding as fall-back: (a) Reachability ; i.e., query success of the contact-based
scheme (without fall-back) increases, while the overall query overhead decreases, (b) Reduction in query overhead obtained by
using contact-based queries. The best ratio achieved at high speeds (70% over flooding and 50% over Efld). Ratios shown for
contact-based queries with fall-back (i.e., achieving the same success rate as the other schemes).
Varying number of contacts
In order to understand the performance improvement due to addition of contacts we conduct experiments with
varying number of overall contacts in the network. As shown in Figure 8 , the success rate increases (and
subsequently the query overhead decreases) with the increase in number of contacts up to a certain point (around
200) then it saturates. Increase in number of contacts beyond this point does not lead to increase in performance,
but leads to increase in contact selection and maintenance overhead (not shown in the figure) ; the SM overhead
discussed earlier.
0 100
200
300
400
500
600
700
800
900
0 50 100 150 200 250 300 350 400
Number of Contacts
c + flooding overhead
c + Efld overhead
c success
Figure 8 . Effect of increasing the number of contacts in the network. After a certain value (around 200 contacts) there is
saturation in the success rate and the per query overhead. (Simulation results shown for 1000 node topology, at 40m/s)
13 Varying Topologies
0 200
400
600
800
1000
1200
200 500 1000
Topology
Packets transmitted per query ERS
ERS-1
ERS-10
ERS-20
Flood
Efld
Contacts+Efld
Contacts
0 0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
1 200 500 1000
Topology (number of nodes)
Saving % in Overhead c vs. ERS
c vs. ERS-1
c vs. Flood
c vs. E-fld
(a) ( b)
Figure 9 Comparing overhead per query for the various query schemes: (a) the query overhead of various query techniques, (b) improvement
margin of using contacts over other approaches. ‘ c vs. ERS’ means (1- overhead of ‘c’/overhead of ‘ ERS’), similarly the others)
We have conducted extensive simulations to compare our contact-based approach to other approaches for query
such as flooding, expanding ring search and its variants, and border-casting (i.e., flooding between zone borders) as
employed by ZRP (we call it Efld in our study). This first set of comparison results is shown in Figure 9 . Every
point on the graph represents average of 9 runs of 500 random queries each. Results are shown for three of the
topologies used with 200 (with 105m range), 500 (with 70m range) and 1000 nodes (with 55m range), respectively.
This kept the node density (i.e., number of neighbors per node or number of nodes in a zone) almost constant.
Random way point mobility model was used with a maximum speed ( Vmax) of 40m/s. For the contact-based
mechanism 5-10% of the nodes were randomly chosen to select four contacts each. For our mechanism (called
simply Contacts ) the zone radius, R , the LEB and PB were set to 3 and the UEB to 9. All the flooding techniques
used implemented loop prevention and multi-transmission suppression (each node upon receiving a query, records
its sequence number and does not forward another query with the same sequence number). Efld incorporated loop
prevention, and two levels of query detection and early termination
10
. The same zone radius (3) is also used for
Efld. Expanding ring search techniques varied the step by which the TTL is chosen; for ERS it is simply
incremented by 1 for every re-try. For ERS-1 is it incremented exponentially starting with 1 (i.e., TTL increases
with every try as 1, 2, 4, 8, etc.), for ERS-10 the TTL is also incremented exponentially but starting from 10, and
similarly for ERS-20, starting from 20. The results show a very clear advantage of using Contacts mechanisms over
any other approach we have studied. Contacts results in query overhead savings ranging from 80-90% over
flooding, and 60-70% over Efld, as shown in Figure 9 (b). The savings are even greater for all other expanding ring
search techniques studied. Expanding ring search ( ERS) performs particularly poorly due to the large network
diameter (around 35). Note however, that the average query success rate for Contacts (82.6%) was lower than the
other schemes (96%) ( unreachability was introduced by the highly dynamic mobile network). Although the
parameters of Contacts (e.g., number of contacts or selectors) may be tuned to improve reachability, it is hard to
obtain such optimal setting in a highly dynamic environment. Instead we propose to use Efld as a fallback
mechanism when a query fails using Contacts . We call such an extended mechanism Contacts+Efld . This extended
mechanism has savings over Efld ranging from 38-54% in query overhead.

10
In [18] the querier, Q , sends the request to its borders, and the borders send it to their borders, so on . Query control mechanisms are used to
reduce redundant querying. Query detection mechanisms QD-1 (and QD-2) indicate that intermediate nodes along the forwarding path (and
their neighbors) record the request information. Upon receiving a request sent to a border that has been previously visited, the intermediate
node terminates such request. The intermediate node has knowledge of the previously visited borders in its zone by maintaining intra-zone
information of up to 2 R -1 hops (instead of the basic zone of R hops). Hence, the redundant request can be terminated early. This scheme is
called early termination (ET).
14 Effect of Replication
In many cases, object replication may be performed in a sensor network, and hence reachability; i.e., success
rate, of the Contacts scheme alone may be sufficient for successful queries without having to fall-back. We have
conducted several replication experiments to estimate the per query overhead incurred by level-by-level contact
based query and its success rate as a function of the replication ratio. Replication ratio represents the number of
times the object is inserted into the network; ratio of 1 means only 1 copy (no replication), which was the case in
our discussions above, ratio of 2 means the object is inserted in 2 randomly selected nodes in the network, so on.
Results in Figure 10 are shown for 1000 node topology, at 40m/s, with 50 selectors and 4 contacts per selector. We
notice a drastic improvement in performance. Adding only 1 copy of the objects results in over 60% reduction in
query overhead, and increase of success rate from 81.5% to 92.2%. Note that except for ERS and its variants,
overhead of the other schemes (flooding and Efld) per query does not change with replication. For ERS and its
variants the overhead is still very high (even with replication ratio of 4 the best ERS variant, ERS-1, is still well
above 500 packets per query). For replication ratio of 4, the contact-based query incurs only 2.2% per query
overhead as does flooding, and 5.5% as does Efld, for about 3.5% less success rate (92.2% vs. 96%).
0 20
40
60
80
100
120
140
1 2 3 4 Replication ratio (1: no replication)
Packet transmitted per query overhead/query
75
80
85
90
95
100
1 1.5 2 2.5 3 3.5 4 Replication ratio
Query Success Rate (%) query success
Figure 10 . Effect of replication on the query overhead and the success rate of level-by-level contact-based query
Effect of Contact Level
For the above experiments we set the maximum level ( n th
) of contacts to 5. We did not attempt to optimize this
value thus far because it had little effect on level-by-level contact query because the search terminates when the
object is found. For single-shot contact query, however, this value may be important because the search does not
terminate when an object is found, but it continues until the n th
level (or before if looping is detected on all search
branches). Hence, we conducted a set of experiments to investigate the effect of varying the maximum contact level
on query overhead and reachability. We also investigated the change in number of contacts per selector. Simulation
results shown in Figure 11 for 1000 node topology, with 50 selectors at 40m/s. Figure 11 (a) shows the results for
single-shot contact ( c1 for short) with flooding as fall-back, while (b) shows results for c1 with Efld as fall-back
(notice the difference in y-axis scale). It is quite clear that there are optimum operating points for combinations of
number of contacts ( NoC for short) and contact level. This is equivalent to solving the following optimization
problem: minimize c1+(1-success) .fallback, where c1 is the average overhead for the single-shot contact query,
success is the rate of success for the single-shot contact query, and fallback is the average overhead for the fall-back
mechanism. It is surprising that the results for optimum single-shot contact are quite close to those for level-by-
level contact, with the caveat that for the single-shot scheme the parameters (contact level and NoC ) need to be
optimized. If we over-estimate the parameters this may cause the single-shot scheme to perform poorly. (Similar
15 curves (i.e., against contact level and NoC ) for level-by-level contacts show that performance does not degrade if
we over-estimate, but it almost saturates due to termination of search for found objects).
0 100
200
300
400
500
600
700
800
900
1000
0 1 2 3 4 5 6 Max Contact Level [c1+flood]
Overhead (Tx packet per query) NoC 1 10
9 8 7 6 5 2 4 3 0 100
200
300
400
500
0 1 2 3 4 5 6 Max Contact Level [c1+E fld]
Overhead (Tx Packets per query) 2 3 4 5 1 6 7 8 9 10
NoC
(a) ( b)
Figure 11 : Effect of contact level and number of contacts per selector: Performance of single-shot contacts ( c1 ) + flooding, (b)
Performance of single-shot conatcts ( c1 ) + Efld
5.5 Total Overhead
The total overhead of the Contacts protocol includes components other than query overhead, such as ( i) zone
maintenance, and (ii) contact selection and maintenance. The link state overhead repairs link failures due to
mobility and hence is a function of mobility (as we have shown). A general way to represent such overhead is per
node per m/s of mobility. For link state exchange over R= 3 (what we called LS(3) ) hops we get 3 packets per
second per node per m/s of mobility. The contact selection and maintenance is also a function of mobility. Hence,
the effectiveness of our scheme depends on the call-to-mobility ratio (CMR), or the query rate per m/s (called q ).
The cost to select and maintain contacts and zones must be amortized by the query rate or CMR. For very small
CMR the benefits of the contacts architecture may not show. We plot the relationship between the CMR query rate
q , and the overhead normalized by the overhead of flooding. q represents the average per node query per km; q is
small for very high mobility.
The equation for the total overhead (in packets/sec/node/(m/s)) as function of q is as follows:
- Total flooding overhead ( T fld
)= q.fld , where fld is the overhead per query in packets for flooding
- Total Efld overhead ( T Efld
)= LS(2R-1)+ q.Efld , where Efld is the overhead per query in packets for Efld
- Total Contacts overhead ( T c )= LS(R)+ q.c+SM , where c is the overhead per query in packets for contact-
based query (if this was an extended contacts with fallback, then we replace c with ce (short for contacts
extended or c extended) in the above equation, where ce=c+(1-success )fallback, the resulting total
overhead is called T c+Efld
when having Efld as the fallback mechanism).
For R=3 , we get LS(3)=3 and LS(5)=9 , and for the settings on our study for the contact-based scheme, we have
SM=0.02 . fld, Efld and c (or ce ) are obtained in our simulations for the different topologies. We plot the ratios
( T c / T fld
) ( T c+Efld
/ T fld
) and ( T Efld
/ T fld
) in Figure 12 . As shown in Figure 12 benefits of Contacts over flooding start to show at q between 5 and 10 query/km. For higher
values of q (around 400queries/km) the ratio of the total Contacts overhead to the flooding overhead approaches
14-20% for the Contacts approach and 22-28% for the extended Contacts+Efld approach.
16 0.1
1 10
0 100 200 300 400 500
query rate "call-mobility ratio" (CMR) [query/km]
Total traffic (normalized by flooding) 200 Efld
200 c+ Efld
200 c
0.1
1 10
0 100 200 300 400 500
query rate "call-mobility ratio" (CMR) [query/km]
Total traffic (normalized by flooding) 500 Efld
500 c+ Efld
500 c
0.1
1 10
0 100 200 300 400 500
query rate "call-mobility ratio" (CMR) [query/km]
Total traffic (normalized by flooding) 1000 Efld
1000 c+ Efld
1000 c
Figure 12 Benefits of Contacts compared to flooding and Efld as function of the call-mobility-ratio q for different topologies [200, 500 and
1000 nodes] (c: Contacts, c+Efld: is the extended Contacts)
6. Related Work
We address the problem of query resolution and resource discovery in infrastructure-less wireless mobile
sensor networks. Hence, architectures that require infrastructure (e.g., DNS) or that assume existence of underlying
routing are not suitable for our problem. Centralized approaches are neither robust nor scalable.
Perhaps the simplest form of resource discovery is global flooding. This scheme does not scale well as we have
shown. Hence, it is our design goal to avoid global flooding. Expanding ring search uses repeated flooding with
incremental TTL. This approach and its derivatives also do not scale well as we have shown.
Other related work lies in the areas of sensor networks and ad hoc wireless networks.
Approaches in ad hoc networks that address scalability employ hierarchical schemes based on clusters or
landmarks (e.g., LANMAR [10] and [9] ). 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. Furthermore, usually the cluster-head becomes a bottleneck. Hence, in general we
avoid the use of complex coordination schemes for hierarchy formation, and we avoid using cluster-heads.
In GLS [11] an architecture is presented that is based on a grid map of the network (that all nodes know of).
Nodes recruit location servers to maintain their location. Nodes update their location using an ID-based algorithm.
Nodes looking for location of a specific ID use the same algorithm to reach a location server with updated
information. This is a useful architecture when a node knows the network grid map, knows its own location
(through GPS or other), and knows the ID of the node it wishes to contact. These assumptions may not hold in our
case. Especially that a source node has to know the specific ID of the target node and uses that ID to locate the
17 traget’s location servers. By contrast, in our architecture, a source node may be looking for a target resource
residing at a node with an ID unknown to the source node.
The algorithm proposed in [4] and [12] uses global information about node locations to establish short cuts or
friends, and uses geographic routing to reach the destination. It is unclear how such architecture is feasible with
mobility. Also, such work does not specify the number of short cuts to create. In addition, the destination ID (and
location) must be known in advance, which may not be the case in resource discovery.
In ZRP [13] [18] [16] [17] the concept of hybrid routing is used, where link state is used intra-zone and on-
demand routing is used inter-zone. Border-casting (flooding between borders) is used to discover inter-zone routes.
A good feature in ZRP is that a zone is node-specific. Hence, there is no complex coordination susceptible to
mobility as in cluster-head approaches. We use the concept of zone in our architecture. However, we avoid border-
casting by using contacts out-of-zone. The main concepts upon which contacts were designed (small world graphs
and mobility-assisted contact selection) are fundamentally different than ZRP’s bordercasting. Also, as a routing
protocol, ZRP attempts to search for shortest paths and minimize the response time for route discovery. In our
design we make a clear trade-off between route optimality (that is not the primary goal in query resolution) and
communication overhead. We have compared the performance of ZRP and the contact-based approach through
simulations. The contacts based approach incurs significantly lower overhead and has much more desirable
scalability characteristics than ZRP for query resolution. Detailed comparisons against ZRP-like approach (that we
refer to in this paper as edge-of-zone flooding, or Efld) were presented in Section 5.
For object tracking, in SCOUT [20] an architecture was presented that is based on hierarchy formation. Using
concepts borrowed from landmark hierarchy [18] , 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. These mechanisms
are susceptible to major re-configurations with mobility. This is mentioned clearly in their work. The root nodes of
the hierarchy use global flooding to send advertisements. These advertisements are sent periodically. 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. The work presents two schemes that may be supported
by the hierarchy, called SCOUT-AGG and SCOUT-MAP. In SCOUT-AGG object information is aggregated up the
hierarchy. Queries travel up the hierarchy tree until the object is found. This query scheme may degenerate to
flooding if the object summaries in many devices in the hierarchy indicate that they may have the object. SCOUT-
MAP uses indirection through a device locator. A hashing scheme is used to route to the device locator (which has
information about the tracking device). The hash depends on the number and identity of children of each device in
the hierarchy that will be involved in this routing. Hence, a change in the number or identity of children for any of
the en-route devices will cause re-hashing. Children for any devices at any level often change with mobility. A re-
hash of the objects and their device locators is needed with mobility, in addition to re-configuration of the
hierarchy. The performance of the SCOUT architecture degrades drastically with node mobility and network
dynamics.
Directed diffusion [23] [24] provides a data dissemination paradigm for sensor networks. This scheme 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 re- inforced 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 in such situations, our contact-based architecture can be integrated with directed diffusion to
discover resources in a scalable manner instead of using flooding mechanisms.
18 In [29] a data-centric storage architecture was proposed for sensor networks. The architecture uses distributed
hash tables that map objects into locations in the network. The object/data is stored in the node nearest to that
location. Gegoraphic routing is used to route the data to that location. Nodes interested in the data use consistent
hashing on that object’s identifier and get the location at which the data is stored. Data is replicated in nodes near to
that location in case of movement of the node nearest to that location. This scheme may be well-suited for scenarios
in which geographic information and routing are available, and in which the network boundary is fixed and known
a priori such that consistent hashing leads to a location within the boundaries of the network. This scheme was not
designed for situations where geographic information is not available. These are situations we address in this paper.
In [26] [27] [28] approaches are proposed that treat the sensor network as a database. Concepts of data-centric
and in-network processing are emphasized, and query resolution is presented as one of the essential mechanisms for
sensor networks. The MARQ architecture presented in this paper fits in that model, and provides a very efficient
alternative for query resolution of one-shot, simple queries for potentially replicated data.
Rumor routing is proposed in [32] as an alternative to reduce flooding overhead for interests in directed
diffusion. It was designed for continuous (long-term) queries.
In [25] diffusion mechanisms are presented in which sensors are selectively queried for correlated data based
on gain vs. cost.
Other data dissemination protocols for sensor networks include SPIN [30] , Gossiping, and LEACH [31] . These
protocols are designed for data dissemination (not query resolution for potentially replicated data that we address in
our scheme). Also, these protocols do not utilize mobility to increase performance. This seems to be a unique
feature of our MARQ scheme that has proven to be quite valuable in high mobility scenarios.
7. Conclusions and Future Work
In this paper we have presented a novel architecture for efficient query resolution in sensor networks, for one-
shot, simple queries of potentially replicated data. Our architecture is uses concepts of zones in which link state
message exchange is performed, and introduces concepts of contacts that extend beyond zones by utilizing
mobility. Contacts represent short cuts in the wireless network that attempt to reduce the degrees of separation
between the queriers and the targets. Contacts are initially selected from within the zone, and become more
valuable with mobility as they move out of zone. This allows the selecting node a chance to intelligently choose its
contacts from nodes it already knows.
Mechanisms for efficient, mobility-assisted, contact selection and maintenance have been presented and
evaluated. Our evaluation shows that performance of these mechanisms improves with mobility ; a feature that is
unique to our MARQ architecture.
Detailed evaluation of the performance (in terms of overhead and success rate) was carried out, for various
mobility degrees, network sizes, and degrees of replication. The results were compared to several other well-known
query resolution schemes (including flooding, expanding ring search and its variants, and edge-of-zone flooding).
For non-replicated objects, results indicate improvement of 70-90% over flooding, 60-70% over edge-of-zone
flooding, and greater for expanding ring search mechanisms. For replicated objects, the savings are even more
drastic with our level-by-level contact-based query mechanism; for 3 randomly placed object replicas savings of
over 90% are obtained.
Our mechanisms do not assume availability of geographic information and are totally distributed and self-
organizing. Robustness to failures is obtained by using a loosely coupled simple hierarchy scheme based on
independent node-specific zones.
Plans of our future work include further improvement of our mechanisms by introducing heuristics for contact
selection for static networks. One possible direction that is currently being investigated is to actively send selection
messages out of zone (e.g., up to 2R hops) using borders to which the selecting node has disjoint routes.
19 Other related research issues to investigate include mobility-assisted object replication to improve per query
overhead. The main idea is to replicate the data by sending it to nearby nodes that are moving away. This idea also
utilizes mobility and reduces the overhead of replication in the sensor network.
Referernces
[1] S. Milgram, “The small world problem”, Psychology Today 1, 61 (1967)
[2] D. J. Watts. In Small Worlds, The dynamics of networks between order and randomnes s. Princeton University
Press, 1999.
[3] D. Watts, S. Strogatz, “Collective dynamics of ‘small-world’ networks”, Nature 393, 440 (1998).
[4] J. Kleinberg, “Navigating in a small world”, Nature, 406, Aug. 2000.
[5] C. E. Perkins, P. Bhagwat, Highly Dynamic Destination-Sequenced Distance Vector Routing (DSDV) for
Mobile Computers, Comp. Commun. Rev., Oct. 1994, pp. 234-44.
[6] C. E. Perkins, E. M. Royer, Ad-hoc On-Demand Distance Vector Routing, Proc. 2
nd
IEEE Wksp. Mobile
Comp. Sys. And Apps ., Feb. 1999, pp. 90-100.
[7] D. B. Johnson, D. A. Maltz, Dynamic Source Routing in Ad-Hoc Wireless Networks, Mobile Computing,
1996, pp.153-181.
[8] S. Lee, M. Gerla, C. Chiang, “On-demand multicast routing protocol”, IEEE WCNC, p. 1298-1302, vol. 3,
1999.
[9] B. Das, V. Bharaghavan, “Routing in ad-hoc networks using minimum connected dominating sets”, in Proc.
IEEE ICC ’97.
[10] P. Guangyu, M. Gerla, X. Hong, “LANMAR: landmark routing for large scale wireless ad hoc networks
with group mobility”, MobiHOC ’00, p. 11-18, 2000.
[11] J. Li, J. Jannotti, D. Couto, D. Karger, R. Morris, "A Scalable Location Service for Geographic Ad Hoc
Routing", ACM Mobicom 2000.
[12] L. Blazevic, S. Giordano, J .-Y. Le Boudec “ Anchored Path Discovery in Terminode Routing”.
Proceedings of the Second IFIP-TC6 Networking Conference (Networking 2002), Pisa, May 2002.
[13] M. Pearlman, Z. Haas, “Determining the optimal configuration for the zone routing protocol”, IEEE JSAC,
p. 1395-1414, vol. 17, 8, Aug 1999.
[14] J. Liu, Q. Zhang, W. Zhu, J. Zhang, B. Li, “A Novel Framework for QoS-Aware Resource Discovery in
Mobile Ad Hoc Networks”, IEEE ICC ’02.
[15] A. Helmy, "Architectural Framework for Large-Scale Multicast in Mobile Ad Hoc Networks", IEEE ICC
’02.
[16] Z. Haas, M. Pearlman, "The Zone Routing Protocol (ZRP) for Ad Hoc Networks", IETF Internet draft for
the Manet group, June '99.
[17] Z. Haas, M. Pearlman, "The Performance of Query Control Schemes for the Zone Routing Protocol", ACM
SIGCOMM '98.
[18] Z. Haas, M. Pearlman, “ZRP: A Hybrid Framework for Routing in Ad Hoc Networks”, Book Chapter in
Ad Hoc Networks, Editor C. Perkins, Addison Wesley, pp. 221-254, 2001.
[19] P. F. Tsuchiya, "The Landmark Hierarchy: A new hierarchy for routing in very large networks", CCR, Vol.
18, no. 4, pp. 35-42, Aug. 1988.
[20] S. Kumar, C. Alaettinoglu, D. Estrin, “SCOUT: Scalable object tracking through unattended techniques”,
ICNP 2000.
[21] J.J. Aceves, M. Spohn, “Bandwidth-Efficient Link-State Routing in Wireless Networks”, Book Chapter in
Ad Hoc Networks, Editor C. Perkins, Addison Wesley, pp. 323-350, 2001.
[22] A. Helmy, "Small Large-Scale Wireless Networks: Mobility-Assisted Resource Discovery", USC-TR and
ACM-LANL-NCSTRL, July 2002.
[23] C. Intanagonwiwat, R. Govindan and D. Estrin, “Directed Diffusion: A Scalable and Robust
Communication Paradigm for Sensor Networks,” ACM/IEEE International Conference on Mobile Computing
and Networks ( MobiCom 2000) ,August 2000, Boston, Massachusetts.
20 [24] C. Intanagonwiwat, D. Estrin, R. Govindan, and J. Heidemann, “Impact of Network Density on Data
Aggregation in Wireless Sensor Networks ” , In Proceedings of the 22nd International Conference on
Distributed Computing Systems (ICDCS’02), Vienna, Austria. July, 2002.
[25] M. Chu, H. Haussecker, F. Zhao, “ Scalable information-driven sensor querying and routing for ad hoc
heterogeneous sensor networks.” Int’l J. High Performance Computing Applications, to appear, 2002. Also,
Xerox Palo Alto Research Center Technical Report P2001-10113, May 2001.
[26] 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.
[27] P. Bonnet, J. E. Gehrke, and P. Seshadri, “Querying the Physical World, ” IEEE Personal Communications,
Vol. 7, No. October 2000.
[28] P. Bonnet, J. Gehrke, P. Seshadri, “Towards Sensor Database Systems,” Mobile Data Management, 2001.
[29] S. Ratnasamy, B. Karp, L. Yin, F. Yu, D. Estrin, R. Govindan, S. Shenker, “GHT – A Geo-graphic Hash-
Table for Data-Centric Storage,” First ACM International Workshop on Wireless Sensor Networks and their
Applications, 2002.
[30] W.R. Heinzelman, J. Kulik, and H. Balakrishnan “Adaptive protocols for information dissemination in
wireless sensor networks,” Proceedings of the Fifth Annual ACM/IEEE International Conference on Mobile
Computing and Networking ( MobiCom ’99), pp. 174-185, Seattle, WA, August 1999.
[31] W.R. Heinzelman, A. Chandrakasan, and H. Balakrishnan “Energy-efficient communication protocol for
wireless microsensor networks,” 33rd International Conference on System Sciences (HICSS ’00), January
2000.
[32] David Braginsky and Deborah Estrin, “Rumor Routing Algorithm For Sensor Networks,” First Workshop
on Sensor Networks and Applications (WSNA), September 2002.
[33] N. Nahata, P. Pamu, S. Garg, A. Helmy, "Efficient Resource Discovery for Large Scale Ad hoc Networks
using Contacts", ACM SIGCOMM Conference , August 2002, Pittsburgh. (poster) (Abstract in ACM SIGCOMM
Computer Communications Review (CCR), July 2002).
[34] S. Garg, P. Pamu, N. Nahata, A. Helmy, " Contact Based Architecture for Resource Discovery (CARD) in
Large Scale MANets", USC-TR, July 2002.

Linked assets

Computer Science Technical Report Archive

Conceptually similar

PDF

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

PDF

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

PDF

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

PDF

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

PDF

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

PDF

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

PDF

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

PDF

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

PDF

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

PDF

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

PDF

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

PDF

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

PDF

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

PDF

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

PDF

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

PDF

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

PDF

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

PDF

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

PDF

USC Computer Science Technical Reports, no. 734 (2000)

PDF

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

Description

Ahmed Helmy. "Mobility-assisted resolution of queries in large-scale mobile sensor networks (MARQ)." Computer Science Technical Reports (Los Angeles, California, USA: University of Southern California. Department of Computer Science) no. 781 (2002).

Asset Metadata

Creator Helmy, Ahmed (author)

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

Alternative Title Mobility-assisted resolution of queries in large-scale mobile sensor networks (MARQ) (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 20 pages (extent), technical reports (aat)

Language English

Unique identifier UC16270980

Identifier 02-781 Mobility-Assisted Resolution of Queries in Large-Scale Mobile Sensor Networks (MARQ) (filename)

Legacy Identifier usc-cstr-02-781

Format 20 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)