The Design of an Acquisitional Query Processor For Sensor Networks

Samuel Madden, Michael J. Franklin, Joseph M. Hellerstein, and Wei Hong

Presentation by Xin Liu

Outline

Introduction Acquisitional Query Language Query Optimization Query Dissemination and Routing Query Execution Summary Discuss

Introduction

A sensor node is a battery-powered, wireless computer, which power is extremely low. So reducing power consumption is important.

ACQP (ACquisitional Query Processor):

use acquisitional techniques to reduce power consumption compared to traditional passive systems.

Introduction (cont.)

What is meant by acquisitional techniques? Where, when, and how often to acquire data.

Four related questions: When should samples be taken? What sensors have relevant data? In what order should samples be taken? Is it worth to process and relay a sample?

Introduction (cont.)

TinyDB (ACQP engine) is a distributed query processor which runs on each of the nodes in a sensor network.

TinyDB runs on the Berkeley Mica mote platform, on top of the TinyOS operating systems.

Acquisitional Query Language Data Model

Entire sensor network viewed as one single, infinitely-long logical table: sensors

Columns consist of all the attributes defined in the network. Rows are individual sensor data.

Queries as a Stream Sensors table is an unbounded, continuous data stream. Operations such as sort and symmetric join are not allowed.

SQL-like queries in the form of SELECT-FROM-WHERESELECT nodeid, light, temp FROM sensors SAMPLE INTERVAL 1s FOR 10s

Acquisitional Query Language Event-Based Queries Instead of continuous polling for data, query runs only when

interesting events happens. Example:

ON EVENT bird-detector(loc) SELECT AVG(light), AVG(temp), event.loc FROM sensors AS s WHERE dist(s.loc, event.loc) < 10m SAMPLE INTERVAL 2s FOR 30s

Acquisitional Query Language Lifetime-Based Queries

Example:

Nodes perform cost-based lifetime estimate to determine data rate.

Nodes must transmit at the root’s rate or at an integral divisor of it.

SELECT nodeid, accel FROM sensors LIFETIME 30 days

Query Optimization

Query optimization is power-based, the goal is to yield lowest overall power consumption.

Queries are optimized by base station before dissemination.

Power consumption dominated by: sampling transmitting

Query Optimization Metadata Management

Each node contains metadata about its attributes.

Nodes periodically send metadata to root.

Information about cost, time to fetch, and range is used in query optimization.

Query Optimization Ordering of Sampling and Pridicates

Consider the query:

1s

Three options: sample accel and mag, then process select sample mag, filter, then sample accel sample accel, filter, then sample mag

First option is always more expensive. If Smag is more selective than Saccel , then second is cheaper. If Saccel is highly selective, the third can be cheaper.

SELECT accel, mag FROM sensors WHERE accel > c1 AND mag > c2 SAMPLE INTERVAL 1s

Query Optimization Event Query Batching

Consider the following query:

Maybe multiple instances of query run at the same time. Thus, the independent sampling and delivering results will consume significant energy.

What can we do with this?

ON EVENT e(nodeid) SELECT a1

FROM sensors AS s WHERE s.nodeid = e.nodeid SAMPLE INTERVAL d FOR k

Query Optimization Event Query Batching

Solution: convert external events into a stream of events, and rewrite the query as a sliding window join between events and sensors.

When an event arrives, add it to the buffer of events. When a sensor tuple s arrives, events older than k seconds

are dropped from the buffer and s is joined with the remaining events.

SELECT s.a1 FROM sensors AS s, events AS e WHERE s.nodeid = e.nodeid AND e.type = e AND s.time – e.time <= k AND s.time > e.time SAMPLE INTERVAL d FOR k

ON EVENT e(nodeid) SELECT a1

FROM sensors AS s WHERE s.nodeid = e.nodeid SAMPLE INTERVAL d FOR k

Dissemination and Routing

Intuition: if a node knows that none of its children will satisfy

the selection predicate, say because they have constant attribute values outside the predicate’s range, it need not forward the query down.

What can we do?

SELECT light FROM sensors WHERE loc.x > 3 AND loc.x < 7

Dissemination and Routing Semantic Routing Tree

Semantic Routing Tree

Each node stores a interval representing the range of A values beneath each of its children. (A is a constant attribute)

When a query q with a predicate over A arrives at node n, n checks if any child’s value of A overlaps with the range of A in q. If so, forwards the query and prepares to receive results. Otherwise, the query is not forward.

Dissemination and Routing Semantic Routing Tree

The gray nodes participate in the query, while white nodes doesn’t.

Dissemination and Routing Semantic Routing Tree

Building Semantic Routing Tree Flooding SRT building request. This request includes the name

of the attribute A over which the tree should be built.

Each node forwards the request to the children. The leaf node selects a parent, and reports the value of A to its parent.

When a node heard from all of its children, it choose a parent and sends a selection message indicating the range of values of A which it and its descendents cover.

The parent records this interval with child node id and proceeds to choose its own parent in the same manner, until root.

SRT are limited to constant attributes, but maintenance is required.

Query Execution Prioritizing Data Delivery

The radio queue of sensor node could be overflow, how to deal with this?

Approach: prioritize data that need to be sent. Three simple prioritization schemes:

Naive – no tuple is considered more valuable, just FIFO

Winavg – average two results at head of queue when queue fills.

Delta – each tuple is assigned a score relative to its difference form the most recent value successfully transmitted, delivery the tuple with the highest score first, discard the lowest when queue fills.

Query Execution Prioritization Comparison

Sample rate was K times faster than delivery rate. In this example, K = 4

Query Execution Adapting Rates

Adaption based on Network contention TinyDB monitors channel contention and adaptively

reduces the number of packets transmitted as contention rises.

Adaption based on Power consumption Goal: adapting tuple delivery rate to meet specific

lifetime requirements. Approach:

Compare current voltage to predicted voltage Re-estimate power consumption characteristics of device Re-run lifetime calculation to determine rates

Summary

Discuss important aspects of an acquisitional query language, introducing event and lifetime clauses.

Query optimization Ordering the sampling operators Event query batching

Use semantic routing tree to disseminate query.

Query execution Prioritizing data according to quality Techniques to adapt the transmission and sampling rate

Discuss

Main Contribution: TinyDB and other early work are an important first step

to investigate some Database research issues in Sensor Network.

Provide simple extensions to SQL for controlling data acquisition.

Proposed a series of acquisitional techniques which provide significant reductions in power consumption.

Related Work: TAG (Tiny AGgregation Service) – UC Berkeley Cougar Sensor Database Project – Cornell Directed Diffusion – UCLA and ISI

Discuss (cont.)

Future Work: Ordering exemplary aggregate in query optimization

Better re-optimization of sample rate based upon acquired data

More sophisticated prioritization schemes

Mechanisms allowing users to express their prioritization preferences

References TinyDB http://telegraph.cs.berkeley.edu/tinydb/

Query processing challenges in sensor networks http://telegraph.cs.berkeley.edu/tinydb/tinydb_tutorial.ppt

Query Processing For Streaming Sensor Data, Samuel R. Madden, Ph.D Quilifying Exam Proposal, May 2002

Fjording the Stream: An Architecture for Queries over Streaming Sensor Data, Samuel R. Madden, Michael J. Franklin, ICDE 2002

TAG: a Tiny Aggregation Service for Ad-Hoc Senser Network, Samuel R. Madden, Michael J. Franklin, etc., OSDI, Dec. 2002

Telegraph Research Project http://telegraph.cs.berkeley.edu/

Cougar http://www.cs.cornell.edu/database/cougar/

Appendix

A stable release of TinyDB is included with the TinyOS 1.1 release.

TinyDB provides a PC interface written in Java.

Appendix in the UC Berkeley Botanical Garden, 50 "micromote" sensors

are dangled like earrings from the branches of 3 redwood trees to monitor their growth.

The Design of an Acquisitional Query Processor For Sensor Networks

Thanks!

Thanks!