5. APPLICATION TECHNIQUES FOR
SENSOR NETWORKS
We next consider application techniques in more detail. These
techniques illustrate how topology-independent low-level naming
and in-network processing can be used to build efficient applications
for sensor networks. The first approach we examine is filterdriven
data aggregation, an example of how in-network processing
can reduce data traffic to conserve energy. We also consider two
approaches to provide nested queries where one sensor cues another.
Finally, we briefly describe several other applications that
have been implemented.
5.1 Innetwork
data aggregation
An anticipated sensor application is to query a field of sensors
and then take some action when one or more of the sensors is activated.
For example, a surveillance system could notify a biologist
if an animal enters a region. Coverage of deployed sensors will
overlap to ensure robust coverage, so one event will likely trigger
multiple sensors. All sensors will report detection to the user,
but communication and energy costs can be reduced if this data is
aggregated as it returns to the user. Data can be aggregated to a
binary value (there was a detection), an area (there was a detection
in quadrant 2), or with some application-specific aggregation
(seismic and infrared sensors indicate 80% chance of detection).
Although details of aggregation can be application-specific, the
common systems problem is the design of mechanisms for establishing
data dissemination paths to the sensors within the region,
and for aggregating responses. Consider how one might
implement this kind of data fusion in a traditional network with
topologically-assigned low-level node names. First, in order to
determine which sensors are present in a given region, a binding
service must exist which, given a geographical region, lists the
node identifiers of sensors within that region. Once these sensors
are tasked, an election algorithm must dynamically elect one or
more network nodes to aggregate the data and return the result to
the querier.
Instead, our architecture allows us to realize this using opportunistic
data aggregation. Sensor selection and tasking is achieved
by naming nodes using geographic attributes. As data is sent
from the sensors to the querier, intermediate sensors in the return
path identify and cache relevant data. This is achieved by
running application-specific filters. These intermediate nodes can
then suppress duplicate data by simply not propagating it, or they
may slightly delay and aggregate data from multiple sources. We
are also experimenting with influencing the dynamic selection of
aggregation points to minimize overall data movement.
Opportunistic data aggregation benefits from several aspects of
our approach. Filters provide a natural approach to inject application-
specific code into the network. Attribute naming and matching
allow these filters to remain inactive until triggered by relevant
data. A common attribute set means that filters incur no network
costs to interact with directory or mapping services.
In prior work we analyzed the performance of diffusion with
and without aggregation through simulation [23]. In Section 6.1
we evaluate our implementation of this over real sensor nodes and
validate our initial results with laboratory tests.
5.2 Nested queries
Real-world events often occur in response to some environmental
change. For example, a person entering a room is often correlated
with changes in light or motion, or a flower’s opening with
the presence or absence of sunlight. Multi-modal sensor networks
can use these correlations by triggering a secondary sensor based
on the status of another, in effect nesting one query inside another.
Reducing the duty cycle of some sensors can reduce overall energy
consumption (if the secondary sensor consumes more energy
than the initial sensor, for example as an accelerometer triggering a
GPS receiver) and network traffic (for example, a triggered imager
generates much less traffic than a constant video stream). Alternatively,
in-network processing might choose the best application
of a sparse resource (for example, a motion sensor triggering a
steerable camera).
user
user
b)
a)
Figure 6: Two approaches to implementing nested queries.
Squares are initial sensors, gray circles are triggered sensors,
and the large circle is the user. Thin dashed lines represent
communication to initial sensors; bold lines are communication
to the triggered sensor.
Figure 6 shows two approaches for a user to cause one sensor
to trigger another in a network. In both cases we assume sensors
know their locations and not all nodes can communicate directly.
Part (a) shows a direct way to implement this: the user queries the
initial sensors (small squares), when a sensor is triggered, the user
queries the triggered sensor (the small gray circle). The alternative
shown in part (b) is a nested, two-level approach where the
user queries the triggered sensor which then sub-tasks the initial
sensors. This nested query approach grew out of discussions with
Philippe Bonnet and embedded database query optimization in his
COUGAR database [5].
The advantage of a nested query is that data from the initial sensors
can be interpreted directly by the triggered sensor, rather than
passing through the user. In monitoring applications the initial
and triggered sensors would often be quite close to each other (to
cover the same physical area), while the user would be relatively
distant. A nested query localizes data traffic near the triggering
event rather than sending it to the distant user, thus reducing network
traffic and latency. Since energy-conserving networks are
typically low-bandwidth and may be higher-latency, reduction in
latency can be substantial, and reductions in aggregate bandwidth
to the user can mean the difference between an overloaded and
operational network. The challenges for nested queries are how to
robustly match the initial and triggered sensors and how to select
a good triggered sensor if only one is desired.
Implementation of direct queries is straightforward with attributeaddressed
sensors. The user subscribes to data for initial sensors
and when something is detected he requests the status of the triggered
sensor (either by subscribing or asking for recent data). Direct
queries illustrate the utility of predefined attributes identifying
sensor types. Diffusion may also make use of geography to optimize
routing.
Nested queries can be implemented by enabling code at each
triggered sensor that watches for a nested query. This code then
sub-tasks the relevant initial sensors and activates its local triggered
sensor on demand. If multiple triggered sensors are acceptable
but there is a reasonable definition of which one is best (perhaps,
the most central one), it can be selected through an election
algorithm. One such algorithm would have triggered sensors
nominate themselves after a random delay as the “best”, informing
their peers of their location and election (this approach is inspired
by SRM repair timers [17]). Better peers can then dispute
the claim. Use of location as an external frame of reference defines
a best node and allows timers to be weighted by distance to
minimize the number of disputed claims.
In Section 6.2 we evaluate nested queries with experiments in
our testbed.
5.3 Other applications
In addition to these approaches we have explored at ISI, our
system has been used by several other research efforts.
Researchers at Cornell have used our system to provide communication
between an end-user database and application that represents
and visualizes a sensor field and query proxies in each sensor
node [5]. This application used attributes to identify sensors
running query proxies and to pass query byte-codes to the proxies.
They also originated the idea of using a nested approach for
nested queries. Future work includes understanding what network
information is necessary for database query optimization and alternative
approaches for nested queries.
Researchers at BAE Systems and Pennsylvania State University
have used our system for collaborative signal processing. BAE
systems contributed signal processing code and systems integration,
while PSU provided sensor fusion algorithms [8]. The combined
system used our system to communicate data between sensors
using named data and diffusion. At the time our filter architecture
was not in place; interesting future work is to evaluate how
sensor fusion would be done as a filter.
0 comments:
Post a Comment