design of a wireless sensor network platform for detecting rare, random, and ephemeral events
Post on 24-Feb-2016
44 Views
Preview:
DESCRIPTION
TRANSCRIPT
Sep 29, 2005 1
Design of a Wireless Sensor Network Platformfor Detecting Rare, Random, and Ephemeral Events
Prabal Dutta
with Mike Grimmer (Crossbow), Anish Arora, Steven Bibyk (Ohio State)
and David Culler (U.C. Berkeley)
Sep 29, 2005 2
Origins : “A Line in the Sand”
Put tripwires anywhere – in deserts, or other areas where physical terrain does not constrain troop or vehicle movement – to detect, classify, and track intruders
Sep 29, 2005 3
Evolution : Extreme Scale (“ExScal”) Scenarios
• Border Control– Detect border crossing– Classify target types and counts
• Convoy Protection– Detect roadside movement– Classify behavior as anomalous– Track dismount movements off-road
• Pipeline Protection– Detect trespassing– Classify target types and counts– Track movement in restricted area
ExScal Focus Areas: Applications, Lifetime, and Scale
Sep 29, 2005 4
Common Themes
• Protect long, linear structures• Event detection and classification
– Passage of civilians, soldiers, vehicles– Parameter changes in ambient signals– Spectra ranging from 1Hz to 5kHz
• Rare– Nominally 10 events/day– Implies most of the time spent monitoring noise
• Random– Poisson arrivals– Implies “continuous” sensing needed since event arrivals are
unpredictable• Ephemeral
– Duration 1 to 10 seconds– Implies continuous sensing or short sleep times– Robust detection and classification requires high sampling rate
Sep 29, 2005 5
The Central Question
How does one engineer a wireless sensor network platform to reliably detect and classify, and quickly report, rare, random, and ephemeral events in a large-scale, long-lived, and wirelessly-retaskable manner?
Sep 29, 2005 6
Our Answer
• The eXtreme Scale Mote– Platform
• ATmega128L MCU (Mica2)• Chipcon CC1000 radio
– Sensors• Quad passive infrared (PIR)• Microphone• Magnetometer• Temperature• Photocell
– Wakeup• PIR• Microphone
– Grenade Timer• Recovery
– Integrated Design• XSM Users
– OSU, Berkeley, MIT, UIUC, UVa, Vanderbilit
– MITRE/NGC/Kestrel/SRI– Others (now sold by Xbow)
Why this mix? Easy classification:– Noise = PIR MAG MIC– Civilian = PIR MAG MIC– Soldier = PIR MAG MIC– Vehicle = PIR MAG MIC
Sep 29, 2005 7
The Central Question : Quality vs. Lifetime
How does one engineer a wireless sensor network platform to reliably detect and classify, and quickly report, rare, random, and ephemeral events in a large-scale, long-lived, and wirelessly-retaskable manner?
Sep 29, 2005 8
Quality vs. Lifetime : A Potential Energy Budget Crisis
• Quality– High detection rate– Low false alarm rate– Low reporting latency
• Lifetime– 1,000 hours– Continuous operation
• Limited energy– Two ‘AA’ batteries– < 6WHr capacity– Average power < 6mW
• A potential budget crisis– Processor
• 400% (24mW)– Radio
• 400% (24mW on RX)• 800% (48mW on TX)• 6.8% (411W on LPL)
– Passive Infrared• 15% (880W)
– Acoustic• 29% (1.73mW)
– Magnetic• 323% (19.4mW)
• Always-on requires ~1200% of budget
Sep 29, 2005 9
Quality vs. Lifetime : Duty-Cycling
Processor and radio• Has received much attention in the literature• Processor: duty-cycling possible across the board• Radio: LPL with TDC = 1.07 draws 7% of power budget
– Radio needed to forward event detections and meet latency
Sep 29, 2005 10
Quality vs. Lifetime : Sensor Operation
Low(<< Pbudget)
Medium(< Pbudget)
High( Pbudget)
Short(<< Tevent)
Duty-cycleor
Always-onDuty-cycle Duty-cycle
Medium(< Tevent)
Duty-cycleor
Always-on? ?
Long( Tevent) Always-on ? Unsuitable
Power Consumption(with respect to budget)
Star
tup
Late
ncy
(with
resp
ect t
o ev
ent d
urat
ion)
Sep 29, 2005 11
Quality vs. Lifetime : Sensor Selection
Key Goals: low power density, simple discrimination, high SNR
2,200 x difference!
Power density may be a more important metric than current consumption
Sep 29, 2005 12
Quality vs. Lifetime : Passive Infrared Sensor
• Quad PIR sensors– Power consumption: low– Startup latency: long– Operating mode: always-on– Sensor role: wakeup sensor
Sep 29, 2005 13
Quality vs. Lifetime : Acoustic Sensor
• Single microphone– Power consumption: medium (high with FFT)– Startup latency: short (but noise estimation is long)– Operating mode: duty-cycled “snippets” or triggered
Sep 29, 2005 14
Quality vs. Lifetime : Magnetic Sensor
• Magnetometer– Power consumption: high– Startup latency: medium (LPF)– Operating mode: triggered
Sep 29, 2005 15
Quality vs. Lifetime : Passive Vigilance
• Trigger network includes hardware wakeup, passive infrared, microphone, magnetic, fusion, and radio, arranged hierarchically
• Nodes: sensing, computing, and communicating processes• Edges: < E, PFA> < E, PFA>
FalseAlarmRate
EnergyUsage
HighLow
LowHigh
Energy-Quality Hierarchy
Multi-modal, reasonably low-power sensors that areDuty-cycled, whenever possible, and arranged in anEnergy-Quality hierarchy with low (E, Q) sensorsTriggering higher (E, Q) sensors, and so on…
Sep 29, 2005 16
Quality vs. Lifetime : Energy Consumption
• How to Estimate Energy Consumption?– Power = idle power + energy/event x events/time– Estimate event rate probabilistically: p(tx) =
from ROC curve and decision threshold for H0 & H1
• How to Optimize Energy-Quality?– Let x* = (x1*, x2*,..., xn*) be the n decision boundaries
between H0 & H1. for n processes. Then, given a set of ROC curves, optimizing for energy-quality is a matter of minimizing the function f(x*) = E[power(x*)] subject to the power, probability of detection, and probability of false alarm constraints of the system.
Sep 29, 2005 17
The Central Question : Engineering Considerations
How does one engineer a wireless sensor network platform to reliably detect and classify, and quickly report, rare, random, and ephemeral events in a large-scale, long-lived, and wirelessly-retaskable manner?
Sep 29, 2005 18
Engineering Considerations: Wireless Retasking
• Wireless multi-hop programming is extremely useful, especially for research
• But what happens if the program image is bad?
No protection for most MCUs!
• Manually reprogramming 10,000 nodes is impossible!
• Current approaches provide robust dissemination but no mechanism for recovering from Byzantine programs
Sep 29, 2005 19
Engineering Considerations: Wireless Retasking
• No hardware protection• Basic idea presented by
Stajano and Anderson• Once started
– You can’t turn it off– You can only speed it up
• Our implementation:
Sep 29, 2005 20
Engineering Considerations: Logistics
• Large scale = 10,000 nodes!• Ensure fast and efficient human-in-the-loop ops
– Highly-integrated node• Easy handling (and lower cost)
– Visual orientation cues• Fast orientation
– One-touch operation• Fast activation
– One-listen verification• Fast verification
• Some observations– One-glance verification
• Distracting, inconsistent, time-consuming– Telescoping antenna
• “Accidental handle”
Sep 29, 2005 21
Engineering Considerations: Packaging
Sep 29, 2005 22
Evaluation
• Over 10,000 XSM nodes shipped• 983 node deployment at Florida AFB• Nodes
– Survived the elements– Successfully reprogrammed wirelessly– Reset every day by the grenade timer– Put into low-power listen at night for operational reasons
• Passive vigilance was not used
• PIR false alarm rate higher than expected– 1 FA/10 minutes/node– Poor discrimination between person and shrubs
Sep 29, 2005 23
Conclusions
• Passive vigilance architecture– Energy-quality tradeoff – Beyond simple duty-cycling– Extend lifetime significantly (72x compared to always-on)– Optimize energy, quality, or latency
• Scaling Considerations– Wirelessly-retaskable – Highly-integrated system– One-touch– One-listen
• DARPA classified the project effective 1/31/05• Crossbow commercialized XSM (MSP410) on 3/8/05
Sep 29, 2005 24
Future Work
• “Perpetual” Deployment– Evaluate year-long deployment – 1,000 node sensor network– Areas surrounding Berkeley
• Trio Mote– Telos platform– XSM sensor suite– Grenade timer system– Prometheus power system
Sep 29, 2005 25
Closing Thoughts
Data Collection
Phenomena Omni-chronic Signal Reconstruction
Reconstruction FidelityData-centric
Data-driven MessagingPeriodic Sampling
High-latency AcceptablePeriodic Traffic
Store & Forward MessagingAggregation
Absolute Global Time
Event Detection
Rare, Random, EphemeralSignal DetectionDetection and False Alarm RatesMeta-data Centric (e.g. statistics)Decision-driven MessagingContinuous “Passive Vigilance”Low-latency RequiredBursty TrafficReal-time MessagingFusion, ClassificationRelative Local Time
vs.
Sep 29, 2005 26
Discussion
top related