ResTAG: Resilient Event Detection with TinyDB

Angelika Herbold-Western Washington University

Thierry Lamarre-ENSEIRB

Systems Software Laboratory, OGIAdvisor: Dr. Nirupama Bulusu

Outline

• Part I: Intro to Wireless Sensor Networks– Overview

• Part II: TinyAggregation and TinyDB– TinyAggregation– TinyDB

• Part III: Resilient Event Detection– Resilient Event Detection– Our Implementation– Preliminary Results– Future Work

Part I: Wireless Sensor Networks

• The Ideal: A robust, randomly deployed, self-organizing network of small embedded devices.

• Each unit (“mote”) has a processor, sensor(s), radio, and limited memory

• Operating System: TinyOS• Major issues:

– Localization– Power constraints/Network lifetime– Fault tolerance/Security

WSN Applications

• Princeton ZebraNet– Collar-mounted sensors

monitor zebra movement in

Kenya

• The “Wireless Vineyard”– Sensors monitor temperature,

moisture– Roger the dog

collects the data

Mote Hardware

• WeC mote (Berkeley) – September 1999

• Rene (Berkeley)– October 2000

• Mica2 (Berkeley/XBow)– February 2003– 128kB program memory– 7.3728Mhz ATMEL CPU– 38.4 kBaud data transfer

(radio)

Part II: TinyAggregation/TinyDB

• TinyDB: A query processing system for extracting information from a network of TinyOS sensors

• Query the network like a relational DB• SQL-style queries:

– SELECT MIN(Temp) FROM sensors

• Motivation: – Easy to use– Can easily construct complex queries

TinyDB

• Embedded: nesC/TinyOS• PC: Java GUI or command window • Applications can use TinyDB API as well

Customizing TinyDB

• Some support for user-defined aggregates (e.g. MAX, AVG)

• Support for user-defined attributes• Creating a new aggregate:

– Write/modify existing embedded code– Write Java code

TinyAGgregation

• Aggregation protocol used in TinyDB– Madden, et al. “TAG: A Tiny AGgregation

Service for Ad-Hoc Sensor Networks”

• Motivations: – Radio transmission is power-hungry– Not all data needs to be sent to the sink

• Ideas: – Fuse data as it moves from source to sink– Eliminate wasted radio transmission– Aggregate using a tree structure

TinyAGgregation/TinyDB

• SELECT MAX(temp) FROM sensors

Level 3

35

32

3830

40

SINK node

Leaf nodes

Level 0

Level 1

Level 2

35 40

40 38

40

Result = 40

Part III: Resilient Event Detection

• Problems:– Motes can be physically compromised– Sensor Networks can be intentionally

compromised

• Solutions:– Secure every node

• Encryption and verification are expensive• May be overkill for some applications

– Secure the whole network• High-level fault tolerance/resilience• What confidence do we have in an event report?

Previous Work

• Corroborative Aggregation Protocol– Yuan et al. “Improving the Reliability of Event

Reports in Wireless Sensor Networks”• Exploits redundancy in the network• When an event is reported:

– Sensors that report an event send a p-packet– Nodes whose sensing areas overlap may

dispute the event if they disagree– Sensors that dispute an event send an n-packet– Probability of a disagreeing node sending

dispute: p = area of overlap / total sensing area• Confidence = p-packets / total packets

Corroborative Aggregation Protocol• Probability of

dispute is B/A

p-pkt n-pkt

dispute

Level 2

D

A

B

E

SINK node

Leaf nodes

Level 0

Level 1

event report

p-pktcorroborate

Confidence: 2/3 = 66%

AA B

Total Sensing Area

Our Work

• Premise: TinyDB is a useful tool, but it offers no resilient event detection.

• Can we implement resilient event detection using TinyDB?

• Basic Ideas: – Implement resilient aggregate query

types– Compute disputes only at aggregation

points

Implementation & Experiments

• What we’ve implemented:– Resilient Average (ResAvg): Returns weighted

average and confidence index– Resilient Maximum (ResMax): Returns

maximum and a confidence index• Experiments: Simulate a large network with

varying percentage and type of failure nodes, examine the performance of the resilient queries.

• Additional Tools:– TOSSIM simulator– Java application to automate testing

Methodology (ResMAX):

• 100 non-sink nodes in a regular grid• Radio model: each node

hears up to 12 of its neighbors perfectly

• Non-failure nodes report 25• 3 Failure modalities:

– Correlated:• High: Faulty nodes report 50• Low: Faulty nodes report 0

– Uncorrelated• SELECT ResMAX(TEST) FROM sensors• Record query results for 0%-50% failed nodes

Preliminary Results (ResMAX)

1) False results are less likely to be detected

ResMAX: Percent False Results with High Confidence vs. Percent Faulty Nodes

Correlated Failure Value = 50

0

10

20

30

40

50

60

70

0 10 20 30 40 50

Percent Faulty Nodes

Per

cen

t F

alse

Res

ult

s w

ith

C

on

fid

ence

> 5

0%

Actual Maximum: 25Threshhold of

ResMAX: Percent True Results with Low Confidence vs. Percent Faulty Nodes

Correlated Failure Value = 0

0

5

10

15

20

0 10 20 30 40 50

Percent Faulty Nodes

Per

cen

t T

rue

Res

ult

s w

ith

C

on

fid

ence

<=

50%

Actual Maximum: 25Threshhold of Agreement: 8%

2) True results are more likely to be disputed

As % faulty nodes increases…

Future Work

• Test on a real mote network• Add resilience support for the

WHERE clause in TinyDB– Now: Does not send results up the tree if

they don’t match the “WHERE”– We need all results to compute disputes

• Other implementations of Resilient Event Detection– Basis of comparison

References and Links

• Princeton ZebraNet (project site): http://www.princeton.edu/~mrm/zebranet.html

• Wireless Vineyard (article): http://www.intel.com/labs/features/rs01031.htm

• Crossbow Technology, Inc.: http://www.xbow.com/

• TinyOS Community Forum: http://www.tinyos.net/

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

…. Questions?