ResTAG: Resilient Event Detection with TinyDB Angelika Herbold -Western Washington University Thierry Lamarre -ENSEIRB Systems Software Laboratory, OGI Advisor: 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 SINK node Leaf nodes Level 0 Level 1 Level 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-pkt corroborate 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 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): Wireless Vineyard (article): Crossbow Technology, Inc.: TinyOS Community Forum: TinyDB: …. Questions?