restag: resilient event detection with tinydb angelika herbold -western washington university...
TRANSCRIPT
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?