1

The Design of An AcquisitionalQuery Processor for Sensor

Networks

SamuelMadden

MichaelFranklin

JosephHellerstein

Wei HongOriginal Slides by:

Presented by: Rick Correa

Sensor Networks

Small computers with:Radios

Sensing hardware

Batteries

Remote deploymentsLong lived

10s, 100s, or 1000s

Mica “Mote”4Mhz, 8 bit Atmel RISC uProc

40 kbit Radio

4 K RAM, 128 K Program Flash,512 K Data Flash

AA battery pack

Sensor board expansion slot

Typical monitoring scenario:Each mote samples sensorsReduces, combines samplesTransmits to root

IssuesMulti-hop radio

Tree based routing20 packets/S, max BW

May need to reduce dataPower conservation

Particularly: radio, sensors

Data Collection In SensorNetworks

A

B C

D

FE

QQ

Q

QQ

QQQ

Q:SELECT …

Storm Petrel(ugly bird)

Example: habitat monitoring on Great Duck Island

Power Consumption

Perform Aggregation to Save Power!

Idea: use declarative queries to specify dataof interest

TinyDB, Cougar

What’s really different?

Power constrained?

Low-bandwidth communication?

Limited CPU, RAM?

Sensor DBMS

Sensor DBMS must control data acquisition

Acquisitional QueryProcessing (ACQP)

Traditional DBMS: processes data already in the systemCentralized System performs queries

Acquisitional DBMS: generates the data in the system!

Nodes perform basic aggregate functions to perform queries

An acquisitional query processor controls

– when,

– where,

– and with what frequency data is collected

Versus traditional systems where data is provided a priori

TinyDB makes dynamic decisions to maximize battery life

2

ACQP: What’s Different?Basic Acquisitional Processing

Continuous queries, with rates or lifetimes

Events for asynchronous triggering

Avoiding Acquisition Through Optimization

Sampling as a query operator

Choosing Where to Sample via Co-acquisition

Index-like data structures

Acquiring data from the network

Prioritization, summary, and rate control

Declarative Queries forSensor Networks

•SELECT nodeid, nestNo, light•FROM sensors•WHERE light > 400•EPOCH DURATION 1s

Epoch Nodeid nestNo Light

0 1 17 455

0 2 25 389

1 1 17 422

1 2 25 405

SensorsExample:“Find the sensors in bright nests.”

System: TinyDBQueries posed from PC, distributed and executed in-network

Queries locate and “activates” sensors

Aggregation Queries

Epoch region CNT(…) AVG(…)

0 South 3 360

0 North 3 520

1 North 3 370

1 South 3 520

“Count the number occupiednests in each loud region ofthe island.”

SELECT region, CNT(occupied) AVG(sound)

FROM sensorsGROUP BY regionHAVING AVG(sound) > 200EPOCH DURATION 10s

Regions w/ AVG(sound) > 200

SELECT AVG(sound)

FROM sensors

EPOCH DURATION 10s

Tiny AGgregation System - presented last week by Svilen

Lifetime QueriesLifetime vs. sample rate•SELECT …•EPOCH DURATION 10 s

•SELECT …•LIFETIME 30 daysSystem chooses sample rate

Statically, at query issue time, orDynamically, via continuous voltage monitoring

TinyDB dynamically can adjust query parametersto meet lifetime goals (i.e. change sampling rates)

(Single Node) Lifetime EvaluationSELECT nodeid,lightLIFETIME 24 Weeks

With constant load,alkaline cells (shouldand do) decay linearly

Event Based ProcessingEpochs are synchronous

Might want to issue queries in response toasynchronous events

Avoid unneccessary “polling”

Events are local to host, not system

ON EVENT bird-enter(…) SELECT b.cnt+1 FROM birds AS b OUTPUT INTO b ONCE

CREATE TABLE birds(uint16 cnt) SIZE 1 CIRCULAR In-network storage

Placement subjectto optimization

3

Event Based Processing

05101520253035

1 51 101 151 201 251 301 351 401 451Sample Number

Cu

rren

t (m

A)

Time v. Current Draw

0

5

10

15

20

25

30

35

Cu

rren

t (m

A)

Event-based detection

Polling-based detection

Bird Enters

Bird Enters

Run 1 - Event Driven, Using Interupts

Run 2 - Polling

Text

ACQP: What’s Different?Basic Acquisitional Processing

Continuous queries, with rates or lifetimes

Events for asynchronous triggering

Avoiding Acquisition Through Optimization

Sampling as a query operator

Choosing Where to Sample via Co-acquisition

Index-like data structures

Acquiring data from the network

Prioritization, summary, and rate control

• E(sampling mag) >> E(sampling light)1500 uJ vs. 90 uJ

Operator Ordering: Interleave Sampling +Selection

•SELECT light, mag•FROM sensors•WHERE pred1(mag)•AND pred2(light)•EPOCH DURATION 1s

σ(pred1)

σ(pred2)

mag light

Non-ACQP

ACQP

The “unDBMS” way(unless pred1 is “very”

selective and pred2 is not):

σ(pred1)

σ(pred2)

mag

light

σ(pred1)

σ(pred2)

mag

lightCheap

Costly

At 1 sample / sec, total power savingscould be as much as 3.5mW Comparable processor power!

Polling light sensor is cheap, Magnetic sensor is expensive!Re-order polling to short-circuit when possible

Exemplary AggregatePushdown

•SELECT WINMAX(light,8s,8s)•FROM sensors•WHERE mag > x•EPOCH DURATION 1s

• Novel, generalpushdown technique

• Mag sampling is themost expensiveoperation!

• Avoid expensive mag sampling when possible - return if light < MAX

ACQPγWINMAX

σ(mag>x)

mag light

Non-ACQP

light

mag

σ(mag>x)

γWINMAX

σ(light > MAX)

8 s window, slides every 8 s

Polling light sensor is cheap, Magnetic sensor is expensive!Re-order polling to short-circuit when possible

ACQP: What’s Different?Basic Acquisitional Processing

Continuous queries, with rates or lifetimes

Events for asynchronous triggering

Avoiding Acquisition Through Optimization

Sampling as a query operator

Choosing Where to Sample via Co-acquisition

Index-like data structures

Acquiring data from the network

Prioritization, summary, and rate control

Attribute Driven NetworkConstruction

Goal: co-acquisition -- sensors that sample togetherroute together -- only send queries to parties involved

Observation: queries often over constrained areaOr some other subset of the network

E.g. regions with light value in [10,20]

Idea: build network topology such that like-valued nodesroute through each other

For range queriesRelatively static attributes (e.g. location)

Maintenance Issues (see paper)

4

Tracking Co-Acquisition Via SemanticRouting Trees

Idea: route range queries only to participating nodes

Parents maintain ranges of descendants

1 2 3

4

a:[1,10] a:[7,15] a:[20,40]

• Precomputedintervals

• Reported bychildren as they join

Excluded from querybroadcast and result

collection!

SELECT …WHERE a > 5 AND a < 12

1 2 3

0

Parent Selection for SRTs

[3,6] ∩ [1,10] = [3,6]

[3,6] ∩ [7,15] = ø

[3,6] ∩ [20,40] = ø

[1,10] [7,15] [20,40]

4

[3,6]

• Idea: Node picks parent whoseancestors’ interval most overlap itsdescendants’ interval

Simulation ResultACQP: What’s Different?

Basic Acquisitional Processing

Continuous queries, with rates or lifetimes

Events for asynchronous triggering

Avoiding Acquisition Through Optimization

Sampling as a query operator

Choosing Where to Sample via Co-acquisition

Index-like data structures

Acquiring data from the network

Prioritization, summary, and rate control

Data PrioritizationAggregate sample rate > channel bandwidth?

Need to xmit most valuable data. How?

Domain Dependent

E.g., largest, average, shape preserving,frequency preserving, most samples, etc.

Simple idea for time-series:

Given buffer of to-be-delivered samples

Order biggest-change-first

Allow out of order delivery

5 105

6 107

7 155

# light

2 1043 107

4 106

Server

Motelight#

5 105

6 107

7 155

ACQP Summary

• Lifetime & event based queries– User preferences for when data is acquired

• Optimizations for– Order of sampling

• Semantic Routing Trees– Query dissemination– Co-acquisition

• Runtime prioritization– Which samples to send

5

Conclusions

Declarative queries are the right interfacefor data collection in sensor nets!

Easier, faster, & more robustThere’s lots of room for DB contributions!

Acquisitional Query ProcessingFramework for addressing many new issues thatarise in sensor networks, e.g.

Order of sampling and selectionLanguages, indices, approximations that give user controlover which data enters the system

Many problems left unsolved!

TinyDB URL - http://telegraph.cs.berkeley.edu/tinydb

Questions?