Sensor Data Management

1
Sensor Data Management In Sensor Networks
2
Towards Sensor Database SystemsBonnet 2001

• I. Introduction
• This paper defines a model for sensor databases
• Stored data are represented as relations while
  sensor data are represented as time series and
  each long-running query formulated over a sensor
  database defines a persistent view, which is
  maintained during a given time interval
• The design and implementation of the COUGAR
  sensor database system is also described
• Applications monitor the world by querying and
  analyzing sensor data

3
Towards Sensor Database SystemsBonnet 2001

• I. Introduction
• Examples of monitoring applications include
• supervising items in a factory warehouse,
• gathering information in a disaster area,
• organizing vehicle traffic in a large city
• These applications involve a combination of
  stored data (a list of sensors and their related
  attributes, such as their location) and sensor
  data
• These will be called sensor databases
• This paper focuses on sensor query processing
  the design, algorithms, and implementations used
  to run queries over sensor databases
• A sensor query is defined as a query expressed
  over a sensor database

4
Towards Sensor Database SystemsBonnet 2001

• I. Introduction
• Factory Warehouse Example
• A sensor query is defined as a query expressed
  over a sensor database
• Each item of a factory warehouse has a stick-on
  temperature sensor attached to it as well as
  other attached sensors are to walls and embedded
  in floors and ceilings
• Each sensor provides two signal-processing
  functions
• getTemperature() returns the measured temperature
  at regular intervals, and
• detectAlarmTemperature(threshold) returns the
  temperature whenever it crosses a certain
  threshold
• Each sensor is able to communicate this data
  and/or to store it locally

5
Towards Sensor Database SystemsBonnet 2001

• Factory Warehouse Example
• The sensor database stores the identifier of all
  sensors in the warehouse along with their
  location and is connected to the sensor network
• The sensor database is used to make sure that
  items do not overheat
• Typical queries that are run continuously may
  include
• Query 1 Return repeatedly the abnormal
  temperatures measured
• Query 2 Every minute, return the temperature
  measured on the third floor
• Query 3 Generate a notification whenever two
  sensors within 5 yards of each other
  simultaneously measure an abnormal temperature
• Query 4 Every five minutes retrieve the maximum
  temperature measured over the last five minutes
• Query 5 Return the average temperature measured
  on each floor over the last 10 minutes

6
Towards Sensor Database SystemsBonnet 2001

• Factory Warehouse Example
• These examples queries has the following
  characteristics
• Monitoring queries are long running
• The desired result of a query is typically a
  series of notifications of system activity
  (periodic or triggered by special situations)
• Queries need to correlate data produced
  simultaneously by different sensors
• Queries need to aggregate sensor data over time
  windows
• Most queries contain some condition restricting
  the set of sensors that are involved (usually
  geographical conditions)
• Queries are formulated regardless of the physical
  structure or the organization of the sensor
  network since the actual structure and population
  of a sensor network may vary over the lifespan of
  a query
• There are similarities with relational database
  query processing most applications combine
  sensor data with stored data

7
Towards Sensor Database SystemsBonnet 2001

• Sensor data differs from traditional relational
  data since it is not stored in a database server
  and it varies over time
• There are two approaches for processing sensor
  queries
• Warehousing approach
• represents the current state-of-the-art
• processing of sensor queries and access to the
  sensor network are separated the sensor network
  is used by a data collection mechanism
• suited for answering predefined queries over
  historical data
• proceeds in two steps (i) data is extracted from
  sensor network in a predefined manner and is
  stored in a database located on a unique
  front-end server (ii) query processing takes
  place on the centralized database

8
Towards Sensor Database SystemsBonnet 2001

• Distributed approach
• this approach is the focus of this paper
• the query workload determines the data to be
  extracted from sensors
• provides flexibility different queries extract
  different data from the sensor network and
  efficient only relevant data are extracted from
  the sensor network
• it allows the sensor database system to leverage
  the computing resources on the sensor nodes a
  sensor query can be evaluated at the front-end
  server, in the sensor network, at the sensors, or
  at some combination of the three
• Sensor database system should deal with sensor
  and communication failures it should consider
  sensor data as measurements with an associated
  uncertainty not as fact it should establish and
  run a distributed query execution plan without
  assuming global knowledge

9
Towards Sensor Database SystemsBonnet 2001

• The paper has the following contributions
• Built on the results of Seshadri 1995 to
  define a data model and long-running queries
  semantics for sensor databases. A sensor database
  mixes stored data and sensor data. Stored data
  are represented as relations while sensor data
  are represented as time series. Each long-running
  query defines a persistent view that is
  maintained during a given time interval.
• Described the design and implementation of the
  Cornell COUGAR sensor database system where
  COUGAR extends the Cornell PREDATOR
  object-relational database system. In COUGAR,
  each type of sensor is modeled as a new Abstract
  Data Type (ADT). Signal-processing functions are
  modeled as ADT functions that return sensor data.
  Long-running queries are formulated in SQL. To
  support the evaluation of long-running queries,
  the query execution engine is extended with a new
  mechanism for the execution of sensor ADT
  functions

10
Towards Sensor Database SystemsBonnet 2001

• II. A Model for Sensor Database Systems
• Build on existing work by Seshadri 1995 to
  define a data model for sensor data and an
  algebra of operators to formulate sensor queries
• II.A. Sensor Data
• A sensor database involves stored data and sensor
  data
• Stored data include the set of sensors
  participating in the sensor database along with
  characteristics of the sensors (e.g., their
  location) or characteristics of the physical
  environment
• These stored data are represented as relations
• The question how to represent sensor data?

11
Towards Sensor Database SystemsBonnet 2001

• II.A. Sensor Data
• Sensor data are generated by signal processing
  functions and the representation chosen for
  sensor data should formulate sensor queries (data
  collection, correlation in time, and aggregates
  over time windows)
• Time is essential -- signal processing functions
  may return output repeatedly over time, and each
  output has a time-stamp
• In addition, monitoring queries introduce
  constraints on the sensor data time-stamps, e.g.,
  Query 3 in Example 1 assumes that the abnormal
  temperatures are detected either simultaneously
  or within a certain time interval. Queries 4 and
  5 on the other hand, aggregates over time
  windows and reference time explicitly

12
Towards Sensor Database SystemsBonnet 2001

• II.A. Sensor Data
• Sensor data is represented as time series
• Representation of sensor time series are based on
  the sequence model introduced by Seshadri 1995
• A sequence is defined as a 3-tuple comprised of
• a set of records R
• a countable totally ordered domain O (ordering
  domain the elements of the ordering domain are
  referred to as positions)
• an ordering of R by O (defined as a relation
  between O and R, such that every record in R is
  associated with some position in O
• Sequence operators are n-ary mappings on
  sequences they operate on a given number of
  input sequences producing a unique output
  sequence

13
Towards Sensor Database SystemsBonnet 2001

• II.A. Sensor Data
• All sequence operators can be composed
• Sequence operators include select, project,
  compose (natural join on the position), and
  aggregates over a set of positions
• Sensor data as a time series is represented with
  the following properties
• The set of records corresponds to the outputs of
  a signal processing function over time
• The ordering domain is a discrete time scale,
  i.e. a set of time quantum where each time
  quantum corresponds a position. Natural numbers
  are used as the time-series ordering domain. Each
  natural number represents the number of time
  units elapsed between a given origin and any
  (discrete) point in time. It is assumed that
  clocks are synchronized and thus all sensors
  share the same time scale

14
Towards Sensor Database SystemsBonnet 2001

• II.A. Sensor Data
• All outputs of the signal processing function
  generated during a time quantum are associated to
  the same position p. In case a sensor does not
  generate events during the time quantum
  associated to a position, the Null record is
  associated to that position
• Whenever a signal processing function produces an
  output, the base sequence is updated at the
  position corresponding to the production time.
  Updates to sensor time series occur in increasing
  position order
• II.B. Sensor Queries
• A sensor database involves stored data and sensor
  data, i.e., relations and sequences
• Sensor query is defined as an acyclic graph of
  relational and sequence operators

15
Towards Sensor Database SystemsBonnet 2001

• II.B. Sensor Queries
• The inputs of a relational operator are either
  base relations or the output of another
  relational operator the inputs of a sequence
  operator are either base sequences or the output
  of another sequence operator, i.e. relations are
  manipulated using relational operators and
  sequences are manipulated using sequence
  operators
• There are three exceptions to this rule three
  operators allow combining relations and
  sequences
• the relational projection operator can take a
  sequence as input and project out the position
  attribute to obtain a relation
• a cross product operator can take as input a
  relation and a sequence to produce a sequence
• an aggregate operator can take a sequence as
  input and a grouping list that does not include
  the position attribute

16
Towards Sensor Database SystemsBonnet 2001

• II.B. Sensor Queries
• Sensor queries are long running
• Each sensor query is associated a time interval
  of the form O, O T where O is the time at
  which it is submitted and T is the number of time
  quantums during which it is running
• During the life of long-running query, relations
  and sensor sequences may be updated
• An update to a relation R can be an insert, a
  delete, or modifications of a record in R,
  whereas, an update to a sensor sequence S is the
  insertion of a new record associated to a
  position greater than or equal to all the
  undefined positions in S

17
Towards Sensor Database SystemsBonnet 2001

• II.B. Sensor Queries
• A sensor query defines a view that is persistent
  during its associated time interval where this
  persistent view is maintained to reflect the
  updates that are repeatedly performed on sensor
  time series
• Jagadish 1995 presented that persistent views
  over relations and sequences could be maintained
  incrementally without accessing the complete
  sequences
• Informally, persistent views can be maintained
  incrementally if updates occur in increasing
  position order and if the algebra used to compose
  queries does not allow sequences to be combined
  using any relational operators
• Both conditions hold in the definition of a
  sensor database used in this paper

18
Towards Sensor Database SystemsBonnet 2001

• III. The COUGAR Sensor Database System
• The initial version of COUGAR system has been
  evaluated in the following aspects
• User representation
• How are sensors and signal processing functions
  modeled in the database schema?
• How are queries formulated?
• Internal representation
• How is sensor data represented within the
  database components that perform query
  processing?
• How are sensor queries evaluated to provide the
  semantics of long-running queries?

19
Towards Sensor Database SystemsBonnet 2001

• III. A User Representation
• In COUGAR, signal-processing functions are
  represented as Abstract Data Type (ADT) and a
  Sensor ADT is considered for all sensors of a
  same type (e.g., temperature sensors, seismic
  sensors)
• The public interface of a Sensor ADT corresponds
  to the specific signal-processing functions
  supported by a type of sensor whereas an ADT
  object in the database corresponds to a physical
  sensor in the real world
• Sensor queries are formulated in SQL with small
  modifications to the language
• The FROM clause of a sensor query includes a
  relation whose schema contains a sensor ADT
  attribute while the expressions over sensor ADTs
  are included in either the SELECT or the
  WHERE clause of a sensor query

20
Towards Sensor Database SystemsBonnet 2001

• III. A User Representation
• The queries introduced earlier are formulated in
  COUGAR as follows
• The simplified schema of the sensor database
  contains one relation R(loc point, floor int, s
  sensorNode), where loc is a point ADT that stores
  the coordinates of the sensor, floor is the floor
  where the sensor is located in the data warehouse
  and sensorNode is a Sensor ADT that supports the
  methods getTemp() and detectAlarmTemp(threshold),
  where threshold is the threshold temperature
  above which abnormal temperatures are returned
• Both ADT functions return temperature represented
  as float

21
Towards Sensor Database SystemsBonnet 2001

• III. A User Representation
• Query 1 Return repeatedly the abnormal
  temperatures measured by all sensors
• SELECT R.s.detectAlarmTemp(100)
• FROM R
• WHERE every()
• The expression every() is introduced as a
  syntactical construct to indicate that the query
• is long-running
• Query 2 Every minute, return the temperature
  measured by all sensors on the third floor
• SELECT R.s.getTemp()
• FROM R
• WHERE R.floor 3 AND every(60)
• The expression every() takes as argument the
  time in seconds between successive outputs of the
  sensor ADT functions in the query

22
Towards Sensor Database SystemsBonnet 2001

• III. A User Representation
• Query 3 Generate a notification whenever two
  sensors within 5 yards of each other measure
  simultaneously an abnormal temperature
• SELECT R1s.detectAlarmTemp(100), R2.s.
  detectAlarmTemp (100)
• FROM R R1, R R2
• WHERE SQRT(SQR(R1.loc.x R2.loc.x) SQR(
  R1.loc.y R2.loc.y)) lt 5
• AND R1.s gt R2.s AND every()
• This formulation assumes that the system
  incorporates an equality condition on the
• time at which the temperatures are obtained from
  both sensors.
• Queries 4 and 5 cannot be expressed in the
  initial COUGAR since aggregates over time windows
  are not supported
• Time interval associated with long-running
  queries in COUGAR is the interval between the
  instant the query is submitted and the instant
  the query is explicitly stopped

23
Towards Sensor Database SystemsBonnet 2001

• III. B Internal Representation
• Query processing takes place on a database
  front-end while signal-processing functions are
  executed on the sensor nodes involved in the
  query
• The query execution engine on the database
  front-end includes a mechanism for interacting
  with remote sensors where a query execution
  engine in each sensor executes signal processing
  functions and sends data back to the front-end
• In COUGAR, it is assumed that there are no
  modifications to the stored data during the
  execution of a long-running query -- strict
  two-phase locking on the database front-end
  ensures verification of this assumption

24
Towards Sensor Database SystemsBonnet 2001

• III. B Internal Representation
• The initial version of COUGAR does not consider a
  long-running query as a persistent view the
  system computes the incremental results that
  could be used to maintain a view where these
  incremental results are obtained by evaluating
  sensor ADT functions repeatedly and by combining
  the outputs they produce over time with stored
  data
• The execution of Sensor ADT functions is
  essential for sensor queries execution

25
Towards Sensor Database SystemsBonnet 2001

• Advantages
• Distributed approach makes it efficient since
  only the relevant data are extracted from the WSN
  under consideration, hence reducing the
  communication and processing overhead
• The representation of the processing function as
  ADT provides controlled access to encapsulated
  data through a well-defined set of functions
• The authors chose not to reinvent the wheel as
  the sensor queries are formulated in SQL with
  little modification to the language
• The use of Virtual Relations introduces more
  flexibility

26
Towards Sensor Database SystemsBonnet 2001

• Disadvantages
• Since the authors are proposing a sensor DB
  system, how does their system adhere to the ACID
  properties of a DB needs to be mentioned
• The protocol assumes that the sensed data is all
  stored in the sensor node this may introduce a
  space constraint in the sensor node
• The sensor data is time variant and after a
  certain time the data would be outdated
• The authors do not suggest any rule for what time
  duration the data should be held in the node

27
Towards Sensor Database SystemsBonnet 2001

• Suggestions/Improvements/Future Work
• Handle multiple copies of same kind of data
  available from nearby resources
• Provide adaptive query processing mechanism
• Handle mobile nodes and sinks

28
Supporting Aggregate Queries Over Ad-Hoc Wireless
Sensor Networks Madden 2002

• Introduction
• The paper discusses the challenges associated
  with implementing the five basic database
  aggregates (COUNT, MIN, MAX, SUM, and AVERAGE)
• The network aggregation approach discussed in
  this paper is driven by a general purpose,
  SQL-style interface that can execute queries over
  any kind of sensor data irregardless of the
  application
• There are two benefits of this approach over the
  traditional network solution which is generally
  application dependent
• Computation can be optimized by defining the
  language that users use to express aggregates
• Since the same aggregation language can be
  applied to all data types, the burden on
  programmers is substantially less they can issue
  declarative, SQL style queries rather than
  implementing custom networking protocols to
  extract the needed data from the network

29
Supporting Aggregate Queries Over Ad-Hoc Wireless
Sensor Networks Madden 2002

• Introduction
• The paper presents a variety of techniques to
  improve the reliability and performance of the
  proposed solution
• In addition, it is shown how grouped aggregates
  can be efficiently computed and offered a
  comparison to related systems and database
  projects
• Two properties of radio communication need to be
  pointed out
• Radio is a broadcast medium such that any sensor
  within hearing distance can hear any message
  irrespective of whether or not it is the intended
  recipient
• Radio links are typically symmetric if a sensor
  a can hear sensor b, it is assumed that sensor b
  can also hear sensor a however, this may not
  hold true in some cases

30
Supporting Aggregate Queries Over Ad-Hoc Wireless
Sensor Networks Madden 2002

• Background
• Messages in the current generation of TinyOS are
  a fixed size preprogrammed into sensors
• Each message type has a message id that
  distinguishes it from other types of messages and
  each sensor has a unique sensor id that
  distinguishes it from other sensors
• All messages specify their recipient (or
  broadcast), allowing sensors to ignore messages
  not intended for them, although non-broadcast
  messages must still be received by all sensors
  within range unintended recipients drop
  messages not addressed to them
• The technique adopted is to build a routing tree
  to route sensor data
• One sensor, typically interfaces the querying
  user to the rest of the network, is chosen to be
  the root from which the tree will be built and
  where the aggregated data will converge

31
Supporting Aggregate Queries Over Ad-Hoc Wireless
Sensor Networks Madden 2002

• Background
• The root broadcasts a message for sensors to
  organize into a routing tree and it includes its
  own id and level (or distance from the root)
• Any sensor hearing this message assigns its own
  level to be the level in the message plus one
  only if its current level is not already less
  than or equal to the level in the message
• It chooses the sender of the message as its
  parent
• Each of these sensors then broadcasts the routing
  message, along with their own ids and levels
• The routing message floods down the tree with
  each node rebroadcasting the message until all
  nodes have been assigned a level and a parent
• Node that hear multiple parents chose one
  randomly

32
Supporting Aggregate Queries Over Ad-Hoc Wireless
Sensor Networks Madden 2002

• Background
• These routing messages are periodically broadcast
  from the root such that the process of topology
  discovery goes on continuously
• This topology maintenance makes adaptation to
  network changes easier since each sensor looks at
  the history of received routing messages, chooses
  the best parent and ensures no routing cycles are
  created
• This method allows efficient route data towards
  the root
• In order a message to reach the root, a sensor
  nodes sends a message to its parent which in turn
  forwards the message on to its parents and so on
• Even though this approach does not address
  point-to-point routing, flooding aggregation
  requests and routing replies up the tree to the
  route is sufficient

33
Supporting Aggregate Queries Over Ad-Hoc Wireless
Sensor Networks Madden 2002

• Aggregation in Database Systems
• Aggregation in SQL-based database systems is
  defined by an aggregate function and a grouping
  predicate
• The aggregate function specifies how a set of
  values should be combined to compute an
  aggregate the standard set of SQL aggregate
  functions is COUNT, MIN, MAX, AVERAGE, and SUM
• These compute functions such as the following SQL
  statement
• SELECT AVERAGE(temp) FROM sensors
• computes the average temperature from some table
  sensors, which represents a set of sensor
  readings that have been read into the system
• Similarly, the COUNT function counts the number
  of items in a set, the MIN and MAX functions
  compute minimal and maximal values, and SUM
  calculates the total of all values

34
Supporting Aggregate Queries Over Ad-Hoc Wireless
Sensor Networks Madden 2002

• Aggregation in Database Systems
• In addition, most database systems allow
  user-defined functions (UDFs) that specify more
  complex aggregates than the five listed above
• Rather than merely computing a single aggregate
  value over the entire set of data values, a
  grouping predicate partitions the values into
  groups based on some attribute
• For example, the query
• SELECT TRUNC(temp/10), AVERAGE(light)
• FROM sensors
• GROUP BY TRUNC(temp/10)
• HAVING AVERAGE(light)
• partitions sensor readings into groups according
  to their temperature reading
• and computes the average light reading within
  each group -- HAVING clause
• excludes groups whose average light readings are
  less than or equal to 50

35
Supporting Aggregate Queries Over Ad-Hoc Wireless
Sensor Networks Madden 2002

• Generic Aggregation Techniques
• There are two approaches
• Server-based centralized approach where all
  sensor readings are sent to host PC that computes
  the aggregates
• In-network distributed approach where
  aggregates are partially or fully computed by the
  sensors themselves as readings are routed through
  the network towards the host PC
• This paper focuses on distributed in-network
  aggregation approach
• Figure 1 illustrates the benefits of in-network
  approach where dotted lines represent connections
  between sensors and solid lines represent the
  routing tree imposed on top of this graph to
  allow sensors to propagate data to the root along
  a single path

36
Supporting Aggregate Queries Over Ad-Hoc Wireless
Sensor Networks Madden 2002

• Generic Aggregation Techniques
• In the centralized approach, each sensor value
  must be routed to the root of the network for a
  node at depth n, this requires n-1 messages to be
  transmitted per sensor
• The sensors in Figure 1(a) have been labeled with
  their distance from the root summing these
  numbers gives a total of sixteen messages
  required to route all aggregation information to
  the root
• The sensors in Figure 1(b) sensors with no
  children transmit their readings to their parents
• Intermediate nodes (with children) combine their
  own readings with the readings of their children
  via the aggregation function f and propagate the
  partial aggregate, along with any extra data
  required to update the aggregate, up the tree

37
Supporting Aggregate Queries Over Ad-Hoc Wireless
Sensor Networks Madden 2002

• Generic Aggregation Techniques

Figure 1 Server-based (a) vs. In-network (b)
aggregation. In (a), each node is labelled with
the number of messages required to get data to
the host PC a total of 16 messages are
required. In (b), only one message is sent along
each edge as aggregation is performed by the
sensors themselves
38
Supporting Aggregate Queries Over Ad-Hoc Wireless
Sensor Networks Madden 2002

• Generic Aggregation Techniques
• Amount of data transmitted depends on the
  aggregate
• For example, AVERAGE function will be calculated
  by the sum and the count of all childrens sensor
  readings while other standard SQL aggregates such
  as COUNT, MIN, MAX, and SUM can be computed by a
  parent node given sensor or partial aggregate
  values at all of the child nodes
• This work focuses on a class of aggregation
  predicates that can be expressed as an aggregate
  function f over the sets a and b such that

39
Supporting Aggregate Queries Over Ad-Hoc Wireless
Sensor Networks Madden 2002

• Injecting a Query
• Computing an aggregate consists of two phases a
  propagation phase, in which aggregate queries are
  pushed down into sensor networks, and an
  aggregation phase, where the aggregate values are
  propagated up from children to parents
• Leaf nodes must find out that they are leaves and
  propagate singular aggregates up to their parents
• When a sensor p receives an aggregate a, it
  transmits a and begins listening
• If p has any children, it will hear those
  children re-transmit a to their children, and
  figure out that it is not a leaf
• After time interval t, if p has not heard any
  children, it means that it is a leaf and
  transmits its current sensor value up the routing
  tree

40
Supporting Aggregate Queries Over Ad-Hoc Wireless
Sensor Networks Madden 2002

• Injecting a Query
• If p has children, they are supposed to report
  within time t, and after time t, it computes the
  value of a applied to its own value and the value
  of its children and forwards this partial
  aggregate to its parent
• It is essential to note that short duration for t
  can lead to missed reports from children, and
  also the proper value of t varies depending on
  the depth of the routing tree

41
Supporting Aggregate Queries Over Ad-Hoc Wireless
Sensor Networks Madden 2002

• Streaming Aggregates
• Since sensor networks are inherently unreliable,
  it is difficult to guarantee that portion of a
  sensor network was not detached during an
  aggregate computation
• The paper proposes pipelined aggregate
• The aggregates are propagated into the network
  and time is divided into intervals of duration i
• During each interval, each sensor that has heard
  the request to aggregate transmits a partial
  aggregate by applying a to its local reading and
  the values of its children reported during
  previous interval
• After the first interval, root hears from one-hop
  away sensors
• After the second, it hears aggregates of sensors
  one and two hops away and so on

42
Supporting Aggregate Queries Over Ad-Hoc Wireless
Sensor Networks Madden 2002

• Streaming Aggregates
• The pipelined solution has the following
  properties
• After aggregates have propagated up from leaves,
  a new aggregate arrives every i seconds
• Total time for an aggregation request to
  propagate down to the leaves and back to the root
  is about t, but the user starts seeing
  approximations of the aggregate after the first
  interval has elapsed
• These properties give users a stream of aggregate
  values that changes as sensor readings and the
  underlying network change
• Continuous results are more useful than a single
  aggregate since they provide users with
  understanding of how the network is behaving over
  time
• Figure 2 illustrates a simple aggregate running
  in a pipelined approach

43
Supporting Aggregate Queries Over Ad-Hoc Wireless
Sensor Networks Madden 2002

• Streaming Aggregates

Figure 2 Pipelined computation of aggregates

• The important drawback of this approach is the
  number of additional messages transmitted to
  extract the first aggregate over all sensors
• The non-pipelined aggregate requires one down and
  one back along with each edge

44
Supporting Aggregate Queries Over Ad-Hoc Wireless
Sensor Networks Madden 2002

• Advantages
• Routing messages for tree building are broadcast
  periodically, thus any changes in the topology
  are updated
• The method of pipelined aggregate overcomes the
  need to have multiple transmissions of
  aggregate queries. Any nodes that miss the query
  in an interval have the time to catch up in the
  successive ones
• Using pipelined aggregates, the user sees
  approximates of the aggregates. This continuous
  results is more useful then one single, isolated
  result

45
Supporting Aggregate Queries Over Ad-Hoc Wireless
Sensor Networks Madden 2002

• Disadvantages
• No suggestions made on any protocol for choosing
  a node as the root
• The node designated as the root will have to cope
  with a lot of data constraining on the battery
  power of the root node
• The radio of the nodes would have to be kept ON
  most of the times to facilitate snooping
• Using pipelined aggregation increases the number
  of messages that are transmitted to the node,
  which contradicts the goal of reducing the number
  of messages

46
Supporting Aggregate Queries Over Ad-Hoc Wireless
Sensor Networks Madden 2002

• Suggestions/Improvements/Future Work
• Introduce hybrid pipeline scheme in order to
  balance tradeoff between robustness,
  incorporating nodes that lose initial aggregation
  requests and number of messages passed
• There is a need to work towards adaptive
  aggregation algorithms that are going to be
  self-configuring
• Introduce a query layer for WSN that will accept
  queries in declarative language, which can be
  optimized to generate efficient query execution
  plan with in-network processing

47
References

• Bonnet 2001 Philippe Bonnet, J.E. Gehrke, and
  Praveen Seshadri, Towards Sensor Database
  Systems, In Proceedings of the Second
  International Conference on Mobile Data
  Management. Hong Kong, January 2001.
• Jagadish 1995 H.V. Jagadish, I.S. Mumick, and
  A. Silberschatz, View Maintenance Issues for the
  Chronicle Data Model, PODS 1995, pp. 113-124.
• Madden 2002 S. Madden, R. Szewczyk, M. J.
  Franklin, and D. Culler, Supporting Aggregate
  Queries Over Ad-Hoc Wireless Sensor Networks, In
  proceedings of the 4th IEEE Workshop on Mobile
  Computing and Systems Applications, 2002.
• Seshadri 1995 P. Seshadri, M. Livny, and R.
  Ramakrishnan, SEQ A Model for Sequence
  Databases, ICDE 1995, pp. 232-239.
• Yao 2003 Y. Yao and J.E. Gehrke, Query
  Processing in Sensor Networks, In Proceedings of
  the First Biennial Conference on Innovative Data
  Systems Research (CIDR 2003), Asilomar,
  California, January 2003.