Sensor Networks

A word of thanks to our sponsors*
Sensor Networks
Ramesh Govindan and Jim Kurose
Infocom 2009, Rio de Janeiro
*Workshop and travel grant sponsors, and sponsors requesting support be given to student workshop and tutorial
Acknowledgements
Andrew Campbell Andrea Gaglione Omprakash Gnawali Shuai Hao Young-Jin Kim Nupur Kothari Victor Lesser Nilesh Mishra Jongkeun Na Jeongyeup Paek Sumit Rangwala Moo Ryong Ra Abhishek Sharma Marcos Vieira
Slides Available at
http://sruti.usc.edu/tutorial.pdf
without whose help this tutorial would not have been possible!
Many Definitions
Networks of tiny battery-operated sensors
Wireless Sensor Networks Focus of most of the tutorial
A Systems Perspective
Systems approach
Will talk about components, architectures, programmability etc. More breadth, rather than depth
Emerging broader definitions

Sense-and-Response
e.g, Wide-area atmospheric sensing
Theory is important
Lots of interesting work in theory, especially for wireless sensor networks Theory based on deployed systems and components (or evolution thereof) can have impact
Urban participatory sensing

Cellphones as sensors
Body sensors
Embedded (in-situ) network sensing

Micro-sensors, onboard processing, wireless interfaces feasible at very small scale--can monitor phenomena up close Enables spatially and temporally dense environmental monitoring Embedded Networked Sensing will reveal previously unobservable phenomena
Slide courtesy D. Estrin
Remote networked sensing

multiple sensors collaborate to observe remote phenomena
Video security/ surveillance
Seismic Structure response
Contaminant Transport
Hazardous weather detection
Marine Microorganisms
Ecosystems, Biocomplexity
data ingest, analysis, actuation: realtime control, tasking of sensor
www.objectvideo.com
Vehicle tracking
In-situ versus remote sensing

sensor type
Wide range of sensor nets: embedded
data rates
Remote sensing sense data at remote location e.g., radar, lidar, camera single sensor
In situ sense data at senor location e.g., temperate, pressure,chemical single sensor
networked sensors
power constrained sensors mostly data push, retasking possible low bit rate data network design: from scratch
available power
actuation, configurability
Wide range of sensor nets
Wide range of sensor nets

habitat monitoring animal tracking microclimate monitoring vehicle tracking in sensor field auto traffic monitoring radar/weather video surveillance satellite observation (EODIS) network traffic monitoring
data rates
powered radars rapidly steerable beams data rates: 2 Mbps - 100 Mbps per radar multiple data consumers network design space: above IP
available power
actuation, configurability
others??
in spite of differences, commonalities as well!
The Old View

Collaborative Event Processing Querying, Triggering Monitoring Security
Wireless Sensor Networks
Data-centric Routing
Aggregation and Compression Collaborative Signal Processing
Data-centric Storage
Localization
Time Synchronization
Medium Access
Calibration
Operating Systems Processor Platforms Radios Sensors
The Old View of the Network

Thousands of sensors
sprinkled by aircraft!
Where are we?
All of them self-configure, and magically produce an interesting result A challenging vision that drove much of early research
Lots of deployments Designed for one purpose, little code reuse
Where are we going?
What do we need to get there?

Reuse as much code as possible Leverage investment in large network to do many things
A General-Purpose, Multi-User, Reactive Observing System

Larger spatial coverage Reactive mobile elements System does more than just sense!
Complex sensing modalities
The New View of the Network

Masters 32-bit CPUs (e.g. PC, Stargate) Provide greater network Higher-bandwidth radios capacity, largerpowered reach Larger batteries or spatial
The New View

Applications DataIntegrity Programming
Transport
Some deployments will have mobile elements in one or both tiers
Motes Low-power, short-range radios Enable flexible deployment Contain sensing and actuation of dense instrumentation
Dissemination Routing
Time Localization Synchronization
Security and Management
EnergyManagement RadioMediumAccess SensorInterfaces
Sensor Node Architecture

Enclosure
Energy Harvesting Unit Processing Unit Memory ADC MCU
Mote
SensingUnit
Sensors
Hardware Platforms
Power Battery
Communication Unit Radio
Connectivity Unit USB/Serial
OperatingSystem andApplication+ Storage
NetworkProtocols
USB/SerialData Transfer
FiltrationandData Fusion
Power Management
Enclosure
Top
Top
A Sensor Node
CPU
Bottom
Bottom
Source:Tmoteskydatasheet
Top
Top
Radio
Memory
Bottom
Bottom
CPU
Top
Sensors
Bottom
Dominated by microcontrollers due to integrated CPU core, memory (RAM + FLASH) and peripherals (ADC, USART, DAC) Low power operation desired with fine grained control over power states Fast wakeup, sleep state, integrated controllers, on board programming Alternatives: FPGAs (difficult to program), DSP (narrow scope), Microprocessors (too power hungry)
CPU
(upto)8MHz16bitMCUwithDMA 10KBRAMwith48KBFlash 12bitADC,2DAC,3timers,2USART,I2CHardware watchdog 1.83.6Voperationrangewith6swakeuptime 330A(activepower@1MHz,2.2V),1.1A(standby), 0.2A(Offmode:RAMretention)
Communication
Primarily radio communication in free ISM band (868MHz, 902MHz and 2.4GHz) Popular radios: 802.15.4 and Bluetooth Low data rate (30Kbps1Mbps) and low power operation (10100mA @ transmit, 2-20mA @ receive ) Communication range governed by transmit power (0-23 dBm) and receiver sensitivity (-95 to 101 dBm) Use of external and directional antenna Alternatives: Laser (alignment), Hydrophones (Under water), Powerline Ethernet
13416MHzfrequencyrange 256KBSRAM,32MBFLASH,32MBSDRAM 3xUART,I2C,2xSPI,SDIO,I2S,AC97,USBhostand slave,CameraI/F,GPIO Upto0.85Voperation <31mA (activepower@13MHz),<387A(deep sleepmode)
Radio
2.4GHzDSSSoperationwith802.15.4compliance 250Kbpseffectivedatarate Lowcurrentconsumption(RX:18.8mA,TX:17.4 mA).1.6 3.6Voperation 0dBm maxtx power,95dBm rx sensitivity ~100mrangewith2dBi antenna
Memory
Integrated RAM and Flash Memory RAM range: 512 B 32 MB Integrated Flash range: 0 32 MB
Flash becoming cheaper Different energy tradeoffs
902MHzto928MHz FHSSoperation 10kbpseffectivedatarate TX:265mA,Rx:65mA.33.6Voperation 22dBmmaxtx power,106dBm rx sensitivity 9.6Kmrangewith2dBi antenna
Additional memory via on-board chips (1 MB) or SD /CF card adapters (up to 2GB)
Sensors
Any device which produces electrical response to a physical condition Range of sensors:
Temperature and Humidity Camera, light, infrared Accelerometer, gyroscope, magnetic sensors RFID readers, Radio as RF sensor
Sensors
InfraredMotion sensor
Lightsensors
RFIDtagreader withmote
Magneticsensor
Primary requirement is low power operation

Some sensors can be quite power-hungry
Additional sensor boards connected to nodes using expansion slots/pins
Accelerometerand Gyroscope
Temperatureand Humiditysensor
Camerasensors
Battery
Needed for remote deployments Battery type governed by:
Energy needs and deployment time Cost Use of energy harvest techniques (Solar cells) or easy node access (rechargeable batteries) Environment concern Weight and peak current drain
Battery
Conventional Emerging
UltraCapacitors
Rechargeable
FlexibleSolarCells
Popular Batteries: Alkaline-MnO2 (AA, D-cell), Li-ion (solar cells) and Ni-MH (rechargable) Alternative: Fuel cell (not mature), Super capacitors (costly)
NonRechargeable FuelCells
Power Management
Crucial for long term survival of motes in deployments. Close knit control by software of hardware feature. Power Management support in hardware:
Low power operation state for radio and microcontrollers (sleep state) Dynamic voltage scaling (Imote2) Selective turn off of unused devices (ADC, sensors) at compile and runtime.
Energy harvesting: variability

Harvested energy rate varies over time Battery: buffer
store: energy harvest rate > energy use rate drain: energy harvest rate < energy use rate
24 W Ray Marine radar
Energy harvesting: modeling variability

Leaky bucket-like model E(t) = energy harvest rate at t E(t) is (,1,2)-source if
Energy harvesting: theorem

Given:
(,1,2)-source battery > 1 + 2 drain rate
Then: Question: given (,1,2)-source. How big a battery

ensures no depletion? ensures given sensing rate can be supported drain rate always supported system can operate forever
generalizes to variable rate consumption

A Kansal, D Potter and MB Srivastava,Performance Aware Tasking for Environmentally Powered Sensor Networks, ACM SIGMETRICS 2004.
Enclosures
Sensors need to be deployed in harsh environments:
Moisture or immersion in water/soil. Curious animals and humans Lightening, strong winds, dust.
Enclosures
Asimpleenclosure
Hard plastic (transparent/opaque), Metal (Aluminum or Cast Iron) Needed for isolation from electromagnetic interference for sensitive sensors and mote electronics Provision for sun light (in case of solar cells)
TenetdeploymentatVincent ThomasBridge @USC
Enclosures
Enclosures
Compartments Electromagnetic shielding
Heliomote @ UCLA/MSR Shakebox @USC
MiniMote (1998)
Mote Universe MicaDot

(2002)
Imote (2005) TelosB (2004)
Mote Universe
250kbps 2.4GHz IEEE 802.15.4 Radio with integrated antenna 8MHz 10k RAM, 48k Flash CPU < 6 s wake up time 21A (sleep) 23 mA (full op) ~ 80m LOS range 31mm x 65 mm
Rene (2000)
SunSpot (2008)
Mica (2001)
MicaZ (2004)
Spec (2003) weC (1999)
Imote2 (2006)
EpicMote (2007)
250kbps2.4GHzIEEE802.15.4Radiowith integratedantenna 13416MHz256kSRAM,32MBRAM, 32MBFLASH 387A(sleep) 66mA(Active) ~80mLOSrange 36mmx48mm
Future
More emphasis towards modular design
Imote2s stackable design Epic modular design
Support and Popularity

Platform life dependent on community/commercial support, availability and popularity. Ease of programming and availability of programming tools important factor. Use of mass produced COTS and open source programming tools (and hardware schematics). Some popular platforms: TelosB (and modified schematics), MicaZ, Imote2
Hierarchical power management using low power cpu for controlling main cpu
Leap2 SunSpot
Cell phones as sensor nodes
Gateway Nodes
Gateway nodes interface the mote universe with existing networks (LAN, WLAN) or internet. Nodes characterized by presence of multiple network interfaces Higher computation and storage ability and more bandwidth
Gateway Node Examples

400 MHz, Marvel PXA255 Processor Embedded Linux 3.5 x 2.5 Form Factor 51-pin Expansion Connector for IRIS/MICAz/MICA2 Motes Ethernet, Serial, JTAG, USB connectors
Stargate eBox
800MHzVIAEdenN256MBDDRRAM CompactFlashbasedHDD MiniPCI 802.11LAN,Ethernet,Serial,USB, Keyboard,monitor 6.7 x4.8 x2.2
Testbeds
Testbed Motes (Total number of motes) Gateway device Area covered Motelab Tmote-Sky (190) Tmote-connect 70,000 sq. ft Tutornet TelosB (96) Twist Tmote-Sky (100) + eyesIFXv2 (100) Tmote-connect ~ 16,000 sq. ft Edgar Mines Tmote-Sky (10) Tmote-connect Linear topology in Underground mine ----
RFID vs Sensor Network

RFID is one-hop vs Sensor Network which can be potentially multi-hop Passive RFID devices need energy to be induced into them through the reader But the distinctions are being blurred..
eBox ~ 27,000 sq. ft
Public/Private
Public
Private
----
RFID vs Sensor Network

RFID Wireless Sensor Network One hop connectivity with the reader A node is a sensor as well as a router Passive RFID need energy to be induced Have their own energy source into them by the reader Communication range from cm to a few Range from few meters to 100s of meters meters Mature and deployed in industry Under development and in startup phase Standardized hardware and closed source Mostly open source hardware and development software implementation No sensor attached Can have many types of sensors attached Low cost due to mass production Still to reach scale for mass production Active RFID close to wireless sensor nodes (single hop)
Smartphones as Sensor Nodes

Smartphones share the same processors and memories as some advanced sensor nodes (Imote2/Sunspot). Low power design and presence of multiple NICs give excellent opportunity for acting as sensor or gateway node. Additional sensors can communicate with Bluetooth or WiFi radio. Need for open programming platform and access to lower layers
10
Overview: radar remote sensor
IP1 Radar Node Tower-Top Subsystem

Parabolic Reflector Dual-Pol Feed Transceiver Data Acquisition System
Radome
Elevation Actuator
Azimuth Positioner
Main Power
Gigabit Eth. Switch
Position Controller Outlet Strip (Eth.)
A/C Register
Web-cam
IP1 Radar Node Transceiver

RF Receiver Front-end
FPGA Data Acquisition System

real-time data acquisition, processing and storage. FPGA: re-configurable hardware ARM embedded processor Standard communication interfaces : Ethernet (Gigabit and 10/100 Mbps), USB & Serial Ports. dual channel inputs: 2 MHz - 50 MHz IF signals
Computer HV Modulator IF down-conversion Magnetron Power Supplies
Connectors
Duplexer
Sensing Node Storage and Processing Computer (SNSPC)

collects data from FPGA data acquisition board via gigabit link. collects low bandwidth health data from embedded health system executes range-Doppler ambiguity, clutter mitigation algorithms on raw data from FPGA, computes moment data, sends to SOCC stores raw data on RAID storage (retrieved in background)
Embedded Radar Controller

Altera board, hosting hardware routines for controlling radar timing and operation. PC104 based system running Linux to interface with Altera. receives commands from SOCC and MC&C. control signals to radar subsystem control signals to FPGA control signals to positioner
11
Meteorological Sensor Systems: Scale
Off The Grid (OTG) Radars OTG: energy become dominant design, operational constraint energy input: solar energy harvesting energy expenditure: sensing, computing, communication
?
Gauges, motes (in situ) Small Scale Medium Scale NETRAD Large Scale NEXRAD 0 - 100 m 0 - 15 km 0 - 30 km 0 - 240 km Observation Domain Size
low-power, short distance radars low power processors, storage communication using long-distance wireless with directional antenna
balancing act: energy input/expenditure

adapting functionality to environmental conditions
Prototype Node
4 kW (incoherent) Marine Radar low power embedded PC 60 W solar panel 110 Ah battery
Marine Radar
802.11b/g
Medium Access
MAC Protocol Design

Typical wireless MACs
Optimizing throughput, fairness, and latency
IEEE 802.15 Standard

Wireless Personal Area Networks (WPANs)
Short Range, Low Power, Low Cost, Ad hoc Wireless Networks
Sensor MACs
Focusing on energy efficiency
Should consider energy-performance tradeoff Designed to reduce energy wastage on

Idle listening, overhearing, collisions, and control packet overhead
Scalability Adaptability
IEEE 802.15.1 Bluetooth IEEE 802.15.2 Coexistence of WLAN and WPAN IEEE 802.15.3 High data rate WPAN IEEE 802.15.4 Low data rate WPAN
Ultra-low complexity, Ultra-low cost Extremely low power consumption Data rates: 20-250 kbps Off-the-shelf devices E.g. Sensor Motes
Telos Motes, Sun SPOTS platform, MicaZ motes
Further MAC design considerations [ali06]

Standardized radio hardware (IEEE 802.15.4 compliant) Cross-layering in sensor architecture Multi-channel, mobility support
12
MAC Protocols for WSN

TDMA-based scheduled access
Centralized
IEEE 802.15.4 Beacon Enabled
Sensor MACs
CSMA TDMA
Distributed
AI-LMAC, Crankshaft, Y-MAC
Periodic listen and sleep Contention during listening Scheduled Listening Maintain synchronization S-MAC(2002),T-MAC(2003) Low Power Listening Asynchronous listening B-MAC(2004)
Only listen in assigned slots Sleep in other slots
CSMA-based random access

Synchronous
S-MAC, T-MAC, SCP-MAC
Asynchronous
B-MAC, X-MAC, RI-MAC, IEEE 802.15.4. Non-Beacon Enabled
Z-MAC(2005) SCP-MAC(2006) X-MAC(2006) Funneling-MAC(2006)
Hybrid access (TDMA/CSMA)

Use scheduled access in high contention regions e.g. around sink
Z-MAC, Funneling-MAC
RI-MAC(2008)
Scheduled Listening (SL)

Synchronized wake-up mechanism
Low duty-cycle is achievable but
Increased collision probability Synchronization overhead
N1 N2 N3 T
S-MAC [Ye04b]
Periodic Listen & Sleep
Listen Sleep Listen Sleep Listen
Frame = listen interval + sleep interval

Duty cycle = listen Interval / frame length
Frame scheduling
Nodes are free to choose their listen/sleep schedule Requirement: neighboring nodes synchronize together Exchange schedules periodically (SYNC packet)
Synchronization period (SP)
sleep
Nodes communicate in receivers scheduled listen times
S-MAC: Collision Avoidance

Contention Problem in Listen Interval
Use of RTS/CTS Virtual carrier sense: IEEE 802.11 NAV
B-MAC: Low Power Listening (LPL)

[Polastre04a]
Basedonpreamblesamplingtechnique
Simpleandscalablebut...
Theexcessivelongpreambleisused Theunnecessaryoverhearingisunavoidable
Sender
RTS
DATA
S
ACK Contend for medium access
Preamble
T
Data
Receiver
CTS
NAV (based on RTS) Other Sensors defer access NAV (based on CTS) From [Ye04b]
Overhearing
78
13
SCP-MAC (SenSys06)
[Ye06a]
SCP-MAC Performance
Optimal energy consumption
Analysis of LPL vs. SCP
SCP piggyback - time sync info.
Scheduled Channel Polling (SCP)

Only a short wake-up tone is required Synchronization reduces the cost of overhearing Two-phase contention lowers the collision probability
Experimentalevaluation
Optimalsetupwithperiodictraffic 10nodes,eachnodeperiodically broadcastsamessage
3~6times
Moreinformationisavailableathttp://www.isi.edu/ilense/software/scpmac/
Figures from [Ye06a] Figures from [Ye06a]
X-MAC (SenSys06)
Basic idea
Using short preambles
Embedding the Target ID Early acknowledgement
[Buettner06a]
X-MAC Performance
Experimental evaluation
One receiver, multiple senders Sleep interval (preamble length) : 500ms A packet is sent out every 5s from senders
Reducing excessive preamble and overhearing This short preamble approach is adopted in current TinyOS 2.x LPL implementation [Moss08]
From [Buettner06a] From [Buettner06a] From [Moss08]
preamblelisteningtimeatreceiver overhearingtimeatsenders
Lowdutycycle ofXMAC
RI-MAC (SenSys08) [Sun08]

Receiver-Initiated Approach
Rendezvous mechanism
Receiver sends beacon periodically Sender waits receivers beacon
Funneling-MAC (SenSys06)
Funneling effect in WSNs
All traffic to one sink (many-to-one)
[Ahn06]
Key observation
Network-wide CSMA
Contention problem
Short medium occupation time

Network capacity increased
Adaptive sleeping
Receivers beacon interval
Network-wide TDMA
Scalability problem
In case of packet collision

Use backoff mechanism
Hybrid approach
Network-wide CSMA Localized TDMA at intensity region
From [Sun08] From [Ahn06]
14
Long-distance 802.11 networks

802.11 standard NIC with directional antenna design: omni-directional, multi-access use: directional, point-topoint (similar to Ethernet design vs switched use) Questions:
do-able? interference between send/receive? packet loss rates, channel behavior?
Long-distance 802.11 measurements
Digital Gangetic Plains Testbed

K. Chebrolu, B. Raman, S. Sen, Long-Distance 802.11b Links: Performance Measurements and Experience, 2006 ACM Mobicom

Allen = Deviation
xi = loss rate in
interval i
Error rate vs SNR UDP packets sharp fall off: works well, or not at all
Error rate dependence on rate (for given SNR) increasing error rate with increasing transmit rate, as expected
Time correlation in packet errors negligible
Suggests adaptive control of transmit rate as function of SNR
802.11: adaptive modulation

10-1 10-2 10-3
10-4 10-5 10-6 10-7
Goal: adaptively choose modulation technique (802.11 PHYlayer) that provides highest throughput subject to BER constraint
10 20 30 40
BER
Energy Management
SNR(dB)
Lucent WaveLAN II
after 10 successful frame transmissions (ACKs) or timeout, increase rate. after 2 unsuccessful frame transmissions in a row, decrease rate similar to TCP bandwidth probing
QAM256 (8 Mbps)
throughput
QAM16 (4 Mbps) BPSK (1 Mbps)
distance
15
Sleep Scheduling
Idle-listening causes significant drain of energy
1pkt/min requires just 10ms of radio on-time every minute.
Approaches
Approach
MAC Network Cross-layer
Examples
SCP-MAC, LPL, LPP FPS Dozer, Koala
Turn the radio off whenever possible

and be able to re-establish connectivity on wakeup
Application-informed AEM
Beyond MAC layer research

other approaches possible
91
Flexible Power Scheduling

Network-layer coarse-grained scheduling Reserve T/R slots based slot on supply and demand of bandwith Pair-wise reservation time
T I I R I
FPS Protocol
Demand = number of pkts to be forwarded Supply = bandwidth available supply > demand, => offer reservations demand > supply, => request reservations
Broadcast Receiver ADV Sender
From [Hohlt, 2005]
cycle
Rx Tx REQ CONF
T Transmit, R Receive, I - Idle

From [Hohlt, 2005]
Tx Rx
Dozer
Low-power data gathering system Combines
TDMA MAC Routing
Dozer Details
Broadcast and Data schedules No global TDMA
Parent-child negotiation
TX Bcast
Achieves 0.2% duty-cycle on realistic settings Deployed for permafrost monitoring
RX TX Data R X
RX
RX
RX
TX Data
R X
16
Koala
Low-power bulk-data gathering system Ultra-low duty-cycle as its goal Sink orchestrates the network
Builds routing tree Requests sensors to report data
Application-Informed Energy Management

Radio duty-cycling tailored to applications Application analysis to infer workload Workload guides duty-cycling configuration Synchronized duty-cycling with elastic slots
Bulk data download Uses LPP as its MAC Achieves 0.2% duty-cycle
AEM Overview
wait(2)periodic(10s)sense(LIGHT)send() dataframe(start=2, period=10s) Task Analysis
AEM Schedules
Control schedule RadioState Data schedule
Controlframe Dataframe
Setup Schedules
[on=2] [on=2]
On
ooo
Data Delivery
[on=2] [on=2] [on=2]
99
Off Time
100
AEMs Elastic Frame

Pacekt TX RXRX
AEM Duty-cycle
RadioState
On Off Time
Low duty-cycle with AEM
17
Schedules Across Nodes

Radio
Schedules in a node
On Off Time Task1 Task2 Control
B A
B
On
Combined
103 104
Off
Wake-on-Wireless
even when idle, device consumes energy (e.g., wireless NIC listening) idea: power device completely off, except for low-power wake/control channel requires additional hardware (2nd radio)
MiniBrick turns on the iPAQ by toggling the Data Carrier Detect (DCD) line on serial port
Wake-on-wireless: more
cell-phone user: wake on wireless
can be signaled from base station
Low Power (2nd) Channel
trace-based evaluation
Constantly Aware Mode (CAM)

from Shi et al, Wake on Wireless, 2002 ACM Mobicom
Power Saving Mode
from Shi et al, Wake on Wireless, 2002 ACM Mobicom
Routing
Find paths from source to destination
Sensor data Commands
Routing
Energy-efficient routes are desired Typical classes of routing

One source -> all destination (dissemination) All sources -> one destination (collection) Point-to-point routing
18
Routing Approaches
Approach
Data-centric Coordinate-space Ad-hoc Collection Tree Standard (in progress)
Point-to-point Routing
Ad-hoc routing
Route to a node TinyAODV, TYMO State overhead too high
Protocols
Directed Diffusion GPSR, BVR TinyAODV,TYMO MultiHopLQI, CTP IETF
Route on a coordinate-space
Route to a location GPSR (Geographical coordinates) BVR (Virtual coordinates)
Geographic Routing
Greedy Forwarding
Keep a table of positions of neighboring nodes Forward to the nearest neighbor
Geographic Routing
Greedy traversal sometimes fails
From [Karp, 2001]
From [Karp, 2001]
Geographic Routing
Face Traversal using right hand rule
Cross links
GPSR only works on planar graphs Detect and remove cross links Nodes probe for p[crossings of(S,A)?] cross-links B
A
p[(B,C)crosses(S,A)!] p[crossings of(S,A)?]
Failswhentherearecrosslinksinthegraph!
p[(B,C)crosses(S,A)!]
19
Removing Cross Links

Networkpartition!
A B
Beacon-Vector Routing
B
Crosslinks!
A
Scalable like GPSR without geographical location Coordinate space

Small set of beacon nodes Dimensions = number of beacons Position = vector of distance to each beacon
caseA
caseB
Keepalinkiftheprobereturnsonthelinkit wassentouton Facetraversalstillguaranteedtosucceed
Greedy forwarding on the coordinate space

Forward to the neighbor closest to the destination
Data-Centric Networking
Networking for application-specific data
Combine routing, storage, and compression
Continuous Data Collection

All information sensed in the network are sent to sinks Pure push or use gradients established by queries.
Categorization of applications:
Push-based: continuous data collection Pull-based: distributed storage and query
(e.g. Directed Diffusion)
Aggregation/Compression Gains of energy and throughput Distributed source coding Spatial correlations on routing with compression
Data-Centric Routing
Internet routing: route to address sensor net routing: route data to consumers
often more than one consumer (1-many)
Data-centric routing: Diffusion Routing

Naming
Data is named using attribute-value pairs
Interests
A node requests data by sending interests for named data
publication/subscription (pub/sub) paradigm:

publishers: data producers (sources) subscribers: data consumers (sinks)
Gradients
Gradients is set up within the network designed to draw events, i.e. data matching the interest.
Reinforcement
Sink reinforces particular neighbors to draw higher quality ( higher data rate) events
20
Data-centric routing: Diffusion Routing in-network data processing (e.g., aggregation, caching) distributed algorithms using localized interactions application-aware communication primitives
expressed in terms of named data
Naming
Content based naming Tasks are named by a list of attribute value pairs Task description specifies an interest for data matching the attributes Animal tracking:
Request Interest ( Task ) Description Type = four-legged animal Interval = 20 ms Duration = 1 minute Location = [-100, -100; 200, 400] Reply Node data Type =four-legged animal Instance = elephant Location = [125, 220] Confidence = 0.85 Time = 02:10:35
Interest
sink periodically broadcasts interest messages to each of its neighbors every node maintains an interest cache each item corresponds to a distinct interest no information about the sink interest aggregation : identical type, completely overlap rectangle attributes each entry in the cache has several fields timestamp: last received matching interest several gradients: data rate, duration, direction
Publish/subscribe systems
Publisher Adv.
Broker Broker Adv. Adv.
Subscriber
event
Filtering and composing: in-network processing

Publisher: Orbitz.com Publisher: Weather.com
Setting Up Gradient
Source
Salvador:$220 Rio:$300 Phuket:$300
Salvador: sunny Rio :sunny Phuket:sunny
Broker Broker apply: (price<250)(Sunny weather)
Salvador :$220, sunny
Neighbors choices : 1. Flooding 2. Geographic routing 3. Cache data to direct interests
Sink
Subscriber
Interested in vacation in Brazil package weather in Brazil apply: (price<250)(Sunny weather)
Interest = Interrogation Gradient = Who is interested (data rate , duration, direction)
21
Data Propagation
sensor node computes the highest requested event rate among all its outgoing gradients when a node receives a data:
find a matching interest entry in its cache
examine the gradient list, send out data by rate
Reinforcing the Best Path

neighbor reinforces a path:
1. At least one neighbor 2. Choose the one from whom it first received the latest event (low delay) 3. Choose all neighbors from which new events were recently received Source
cache keeps track of recent seen data items (loop prevention) data message is unicast individually to the relevant neighbors
Sink
Low rate event
Reinforcement = Increased interest
Local Behavior Choices

For propagating interests (publication)
In the example, flood more sophisticated behaviors possible: e.g. based on cached information, GPS
Local Behavior Choices

For data transmission
Multi-path delivery with selective quality along different paths probabilistic forwarding single-path delivery, etc.
For setting up gradients (subscription)

data-rate gradients are set up towards neighbors who send an interest. others possible: probabilistic gradients, energy gradients, etc.
For reinforcement
reinforce paths based on observed delays losses, variances etc.
NB: routing on content, not on address!
Initial simulation study of diffusion

key metric: average dissipated energy per event delivered
indicates energy efficiency and network lifetime
Diffusion Simulation Details

Simulator: ns-2 Network Size: 50-250 Nodes Transmission Range: 40m Constant Density: 1.95x10-3 nodes/m2 (9.8 nodes in radius) MAC: Modified Contention-based MAC Energy Model: Mimic a realistic sensor radio [Pottie 2000] 660 mW in transmission, 395 mW in reception, and 35 mw in idle
compare diffusion to
flooding centrally computed tree (omniscient multicast)
22
Diffusion Simulation
Surveillance application
5 sources are randomly selected within a 70m x 70m corner in the field 5 sinks are randomly selected across the field High data rate is 2 events/sec Low data rate is 0.02 events/sec Event size: 64 bytes Interest size: 36 bytes all sources send same location estimate for base experiments
Average Dissipated Energy

0.018
Average Dissipated Energy (Joules/Node/Received Event)
0.016 0.014 0.012 0.01 0.008 0.006 0.004 0.002 0 0 50 100 Diffusion
Flooding
Omniscient Multicast
150
200
250
300
Network Size
Diffusion can outperform flooding and even omniscient multicast. (suppress duplicate location estimates)
Directed Diffusion [Mobicom00]
Diffusion Routing: Push

Good for few publishers but many subscribers Steps
Source
Aggregation/Compression Distributed algorithms using localized interactions Application-aware communication primitives expressed in terms of named data
1. Sources publish data and flood the network 2. Subscribers setup a state to match incoming data with local queries 3. Matching data is forwarded to the subscribers
Data Sink
Diffusion Routing: Pull

Good for many publishers but few subscribers
- Avoid exploratory data messages
Source Interest
Distributed Storage and Query

Not interested in all information sensed in the network and Not immediately after sensing Store sensed information to nodes within networks Transmit it in response to queries issued by sinks
Sensor Networks Peer-to-peer Database Systems Systems
Steps
1. Interest is flooded to the network 2. Nodes maintain gradient towards the sink Source 3. Source picks the best path locally and forwards data to it 4. Gradient in the nodes guides data to the sink
Sink Data Gradient
Sink
23
Storage
Local Storage: couple storage location from where information is sensed. Query-intensive processing Distributed-Centric Storage (DCS): decouple storage location from where information is sensed. Eliminate Flooding by Queries (or Events) Scalability and Robustness against Failures
Querying
Flooding: Directed Diffusion Controlled Flooding: Extended Ring Search Regional Flooding: Active query forwarding Greedy Search: Information-driven sensor query Flooding & Greedy Search: Fingerprint gradients Rendezvous between queries and events:
Rumor Routing (WSNA02), Comb-Needle technique(Sensys04)
The Comb-Needle Technique

Constrained geographical flooding
Comb-Needle: Query-Event Reverse Comb-Needle: Event-Query
Distributed-Centric Storage (DCS)

Simple primitives: put(), get() Challenges
Geographic routing Robustness to failure
put() get()
Sink
Query Event
Hash-table based approaches

GHT (Monet02), DIM (Sensys03), PathDCS(NSDI06) DIFS (SNPA03), DIMENSIONS (Sensys03)
Rendezvous approaches
Reverse Comb-Needle, Double-Rulings (Mobicom06)
Comb Needle
Geographic Hash Tables

DHT: hash the name of the data to a geographic location Geographic routing: store data and retrieve it
Put (elephant, data) Hash (elephant)=(12,24) (12,24)
Double-Rulings
Hash data to a circle, instead of a point
Distance-sensitive Retrieval (GHT may hash to far way nodes)
Sink Get (elephant) Hash (elephant)=(12,24) Source: www.cs.sunysb.edu/~jgao/paper/dbruling-slides.pdf
24
Collection Routing
Collectdatafromthenetworktooneora smallnumberofroots Treerouting
CTP: Collection Tree Protocol

Goals
Minimize energy consumption High reliability Quick response to dynamics Platform independent
Features
4-bit Link Estimator Exponential-timer based beacons Data transmission as topology probe
145
The Four-bit Link-Quality Estimator

PIN
Keepthislinkin thetable
CTP Beacon Timing
COMPARE
Isthisauseful link?
ACK
Apackettransmission wasacknowledged
WHITE
Apackethasalow probabilityof decodingerror
CTP Reliability
IETF Routing Protocol

Need a standard for commercial applications Progress
87 nodes, 18 hrs @ 1 pkt/10s Delivery ratio = 0.986
55 nodes, 5 hrs @ 1 pkt/5s Delivery ratio = 0.979
6lowpan : IPv6 frame specified (RFC 4944) Identify routing requirements for applications Determine no current IETF protocol meets the requirements
Likely direction
Collection for upstream data Source route for downstream and point-to-point
25
Dissemination
Service for reliably delivering data/information to every node in the network
Allows administrators to reconfigure, query, command, task, and reprogram a network.
Dissemination
Challenges
Consistent
All nodes should agree on same information
Design space - 1
Size of the disseminated object
Three categories
Large program binary for reprogramming (Deluge, PSFQ) Medium size binary or task (Tenet, TOSThread/TinyLD) Small values for configuration parameters (Drip, RBP)
Method Configuration Parameters Scripts/ Tasks New Binary Flexibility Low Med Very High Cost Low Med Very High Frequency High Med Very Low
Up-to-date
All nodes should agree on the most new/updated information
Robust/Reliable
Should be robust to temporary disconnections or high packet loss Eventual consistency:
The network should eventually reach consensus on the newest information as long as the network is not disconnected
In theory, transfer service of any large object can be built on top of transfer service of smaller objects at the cost of efficiency.
Design space - 2
Reliability guarantees
Re-programming or re-tasking requires 100% reliability
Ex> Deluge, TRD, PSFQ, RMST
Taxonomy
Small data, commands, config. parameters Re-tasking, program updates Re-programming
Dissemination of smaller data may sacrifice reliability for

Protocol complexity (Ex> Flooding) Energy Efficiency (Ex> RBP)
Reliable
Drip Dip Sprinkler, GARUDA
Tenet-TRD PSFQ RMST
Deluge Typhoon MNP
Performance optimization
Channel switching (Ex> Typhoon) Sender selection (Ex> Sprinkler, Infuse, GARUDA) Tiered network with multiple points of dissemination adds extra complexity (Ex> Tenet)
Non-Reliable
RBP Flooding
Size of data
26
Drip
Disseminating small (smaller than a single packet payload) pieces of data for reconfiguration
establishes eventual consistency on a shared variable and tells an application when the variable changes
Deluge
Network programming
provides the ability to wirelessly install a new program image by propagating a program binary over the wireless network and having each node program themselves with the new image.
Object
1-level data representation No separate control messages
3-level data representation Separate control messages Selective NACK
Page
1 2 3 4 N
Packet
TRD
Tasking
Small pieces of programs that can be dynamically loaded or deleted, and run concurrently.
Conclusion
Dissemination is an important service in wireless sensor networks that enables the user to control the behavior of large number of devices
2-level data representation Separate control messages

+ distinguish the source
Task
1 2 3 4 N
Packet
Selective NACK
Synchronize clocks of nodes across network GPS
Not always available, Energy, $
Useful service for

Data time-stamping TDMA
Requirement
Desired sub-ms, sometimes 10s accuracy
27
Timing Challenges
Cheap clocks drift up to 50ppm
Each clock is unique
Time-Synchronization Approaches
Approach
On-demand Data-sync Relative Clocks Online Hierarchical Online Flat
Protocols
TSS RBS TPSN FTSP
Non-deterministic delays in timestamping

Channel access Interrupt handling Send/receive
Minimize synchronization traffic
Time-stamp Synchronization
Track time a packet spends on each hop Time of origin = now total time in transit
App
{Pkt,T} T1 T2 T3 T4 {Pkt,T} T5 Timeoforigin =T5 T
Reference Broadcast Synchronization

Maintain local locks Track clock drift of neighbors Algorithm
Reference broadcasts when needed Receivers time-stamp on reception Nodes compare the time-stamps
Multi-hop synchronization through nodes that can receive multiple reference broadcasts
T=T2T1
T=T +T4T3
TPSN: Time-Synch for Sensornets

A single reference clock
Possible to synchronize to an external clock
Time Synchronization using FTSP

Synchronize clocks to a single elected leader Error per hop
Avg 1.6 s Max 6.1 s
Synchronize clocks of all the nodes Algorithm

Construct a minimum spanning tree Synchronize across each edge starting at the root
Mechanism
Accurate sender and receiver time-stamps Linear interpolation after n samples
Most robust and widely used protocol
28
FTSP Time-stamps
Sender Time-stamp
Global clock Non-deterministic delays: Send, MAC
sender: send access propagation receiver: reception receive transmission
FTSP Algorithm
Leader election
Leaders reference clock Smallest node ID Robust
Receiver Time-stamp
Receivers clock Non-deterministic delay: disabled interrupt
From [Maroti, 2004]
Periodic time synchronization beacons Linear regression

N (typically 8) <local,global> time-stamp samples Estimate offset and skew between local and global clocks
Improve time-stamp accuracy

On byte-radios, statistics on multiple timestamps per packet to compute single time-stamp Sender time-stamp after channel access
Use coefficients to translate local to global time
FTSP Performance
Localization
Occasional desynchronization
Localization
A mechanism for discovering spatial relationships among objects
Goal
Determine the location of wireless sensor nodes
Known Location Unknown Location
Many other proposed approaches not covered
29
Motivation
Support Location Aware Applications
Track Objects Report event origins Evaluate network coverage Assist with routing, GF Support for upper level protocols.
A Taxonomy of Localization Schemes Location discovery approaches consist of three phases:

1.
2.
3.
Ranging phase (distance estimation) Each node estimate its distance from its neighbors Initial Estimation phase (distance combining) Nodes use ranging information and beacon node locations to estimate their positions Refining estimation iteratively refining the position estimate
Phase1
Step1estimation of distance to an anchor. There are two classes of approaches to estimating distance to anchors: topological and geometric. Topological approaches: DV-dist and DVhop. Geometric approaches: Relative localization scheme and Euclidean scheme.
Phase1
Distance measuring methods Signal Strength
Uses RSSI readings
Time based methods (ToA)

Used with radio, acoustic, ultrasound
Angle of Arrival (AoA)

Measured with directional antennas
Ranging Techniques
Approaches Acoustic ranging (time of flight) A. Sound B. Ultrasound Radio signal strength (RSS) GPS Differential GPS Infrared light Magnetic field Radio Interferometric Ranging range (30m) accurate (9cm), stealthy no extra HW, stealthy single node, global time very accurate (1cm) inexpensive accuracy (1mm) accurate (5cm), stealthy, long range, no extra HW
Taken fromRadio Interferometric Geolocation
Phase1
Cons extra HW (actuator, detector), line of sight not stealthy, echoes limited range, directionality imprecise beyond few meters, extensive calibration Extra HW, outdoors only, inaccurate extra HW, outdoors only, very expensive extra HW, accuracy, direct line of sight, sunlight range (3m), metal interference multipath
Taken fromRadio Interferometric Geolocation
Pros
Time of flight
acoustic ranging: sound tens of meters range; 10cm accuracy; ultrasound 5m range, 6cm accuracy;
Radio signal strength

RSSI: MS RADAR 35m range; 3m accuracy; Calamari 20m range; 2m accuracy;
Radio interference
RIPS: 170m range; 4cm accuracy;
RF Time of flight:
GPS anywhere outdoors;
30
Phase 1 - Time of flight

ToA using RF and Ultrasound
The time difference between RF and ultrasound
Phase 1 - Time of flight

Speed of sound is much slower (approximately 331.4m/s) Disadvantages:
Line of sight path must exist between sender and receiver. Unidirectional Short range Medusa node
RSSI
RSSI approach is based on the radio path loss model:
radio signal attenuates during its transmission
RSS
RSS is susceptible to environmental interference: Irregularity Multipath Fading Attitude of antenna
RSS
PS dn
Radio Interferometric Ranging

Interference: superposition of two or more waves
Radio Interferometric Ranging

CD= (dAD-dBD+dBC-dAC) mod Senders transmit simultaneously pure sinusoid waves, with small frequency difference Receivers measure find beat frequency use 1 s timesync to correlate phase offsets can estimate distance from phase offset differences, known signal
Interferometry: cross-correlate signals received at two different nodes; many other applications Key idea: utilize two transmitters to produce low frequency interference signal directly
From: Maroti et al.
31
Phase 2
Hyperbolic Trilateration Triangulation
B
b Sines Rule c
A B C = = sin a sin b sin c
C 2 = A2 + B 2 + 2 AB cos(c)
Multilateration
The basic idea of Multilateration is to minimize differences between estimated distances and measured distances from an unknown node to beacons Maximum Likelihood Estimation (MLE) is one approach to solving the problem
P0 = arg min ( P0 Pi di ) 2
P0 i =1 n
C
Cosines Rule
B 2 = A 2 + C 2 2 BC cos(b) C 2 = B 2 + C 2 2 BC cos(a)
Multi-lateration
Considers all available beacons
Phase 3
Refinement
Least-Mean-Squared Refinement (LMSR)
Phase 3 Collaborative Multilateration Unknown node may never have three neighboring beacon nodes One node estimates its position by considering use of location information over multiple hops
(xi x j )T ( xi x j ) rij = 0
LMSR attempts to minimize the objective function,
(1)
T J = ij2 (xi xj ) (xi xj ) rij eijE
(2)
Mobility
Problem definition: keep track of location and velocity of cooperating moving objects continuously over time. Key idea:
Estimate Doppler shift using interferometry
Measuring Doppler shift
430MHz+300Hz T
430MHz A
2 nodes T, A transmit sine waves at same frequency When one of them, say T is moving, Doppler shift induces beat frequency at S Can estimate distances as before
Si
300Hz + fi,T
From: Tracking Mobile Nodes Using RF Doppler Shifts
32
Summary
All the efforts in the research of sensor network localization are to achieve sufficient positioning accuracy based on the limited resources available from sensor networks. Various approaches have been published to satisfy different application requirements by adopting a different tradeoff between accuracy and costs. Challenges are to deploy sensor localization algorithms to a complex terrain.
Transport: Congestion Control
Congestion in Wireless Sensor Networks

Congestion
Congestion occurs when demand exceeds the capacity
Congestion degrades channel quality
Challenges
Time varying channel conditions Interference Achievable rates highly sensitive to topology
55nodenetwork
4/19/2009 195 4/19/2009
Courtesy:MitigatingCongestioninWirelessSensorNetworks,Hulletal.,SenSys2005
196
Congestion degrades efficiency and fairness
Addressing Congestion
Two design perspectives
Congestion Control
11 12 10
Routes Neighbor
f11
Assign fair and efficient rate to all the flows
f13
f15 f19
Congestion Mitigation
Avoid starvation and improve network efficiency
No notion of target fairness or efficiency 55nodenetwork
4/19/2009
From:MitigatingCongestioninWirelessSensorNetworks,Hullet al.,SenSys2005
13
14
15
f20
16 17 18 19
20
21
197
4/19/2009
198
33
Taxonomy
Cong. Mitigation Distributed Fusion,CODA Cong.Control Cong.Control Cong.Control (Fairnessand (Fairness) (Efficiency) Efficiency) Ee etal. IFRC
Taxonomy
Cong. Mitigation Distributed Fusion,CODA Cong.Control Cong.Control Cong.Control (Fairnessand (Fairness) (Efficiency) Efficiency) Ee etal. IFRC,WRCP
Centralized
RCRT
ESRT
QCRA
Centralized
RCRT
ESRT
QCRA
4/19/2009
199
4/19/2009
200
Fusion (Congestion Mitigation)

Congestion Detection
Queue occupancy and thresholding
Fusion: Efficiency
Congestion Mitigation
Hop by Hop backpressure
Non-congested neighbors refrain from sending packets
Congestion aware MAC

Higher transmission priority to congested node
Rate Limiting
Send packets after parent forwards n (number of descendents) packets
At all times
Gracefuldegradationofefficiency withincreasingload
4/19/2009 201 4/19/2009
Courtesy:MitigatingCongestioninWirelessSensorNetworks,Hulletal.,SenSys2005
202
IFRC: Interference-aware Fair Rate Control Goal

Design a distributed algorithm to dynamically allocate fair and efficient rate to each flow
IFRC: Overview
Congestion detection
Locally for a link, based on queue length calculated as
qavg = wq * qinst + (1- wq) * qavg
10
Routes
Neighbor
f11
Design space
Distributed Fairness and Efficiency
Congestion Signaling
To all flow traversing the neighborhood
f13
11
12
f15 f19
Rate adaptation
Additive Increase during no congestion
rf = rf + / rf
13
14
15
f20
16 17 18 19
Multiplicative Decrease on local congestion

rf = rf / 2
4/19/2009 203 4/19/2009
20 21
204
34
IFRC: Per Flow Goodput and Packet Reception
IFRC: Comparison with Empirically Determined Optimal

Fair
Unfair
Averagegoodput foreachnode
Numberofpacketsreceivedw.r.t. time
Averagegoodput foreachnode
IFRCachieves80%of theoptimalfairrate
IFRCachieves60%of theoptimalfairrate
Averagegoodput aswellasinstantaneousgoodput isfair

4/19/2009 205 4/19/2009
IFRCachieves6080%oftheoptimalfairrate
206
RCRT: Rate-controlled Reliable Transport

Goal
RCRT is a protocol that reliably transports sensor data from many sources to one or more sinks without incurring congestion collapse
ESRT: Event-to-Sink Reliable Transport

Observed event reliability, (ri)
The number of received data packets in decision interval i at the sink
Desired event reliability (R)

The number of data packets required from each node at i the sink for reliable event detection. (application determined)
Design Space
Centralized Fairness, Efficiency not a goal
Goal
Configure the sending rate, f, of source nodes so as to achieve the required event detection reliability, R, at the sink with minimum resource utilization.
4/19/2009
207
4/19/2009
208
Characteristic Regions
NoCongestion, HighReliability OptimalOperatingPoint HighCongestion, HighReliability
RCRT: Overview
CongestionDetection
Basedontimetorecover endtoendlossatthe sink The network is not congested as long as end-to-end losses are repaired quickly enough
R(t ) = ri (t )
i =ri/R
R (t + 1) = R (t ) + A
R (t + 1) = M (t ) R (t )
NoCongestion LowReliability
HighCongestion, LowReliability
4/19/2009
From:ESRT03
209
4/19/2009
210
35
RCRT: Fairness
In-network congestion control: Intelligent Discard for MPEG

Principle: P, B frames depend on I frames
Frames spread over many packets GOP = (typically) one I frame, few P frames, many B frames
Discard approaches:
Discard application-layer units (e.g. Frames, GOPs) Static priorities (e.g., I frame higher than P, B) Drop P, B if corresponding I already dropped Evict P, B from queue to make room for I
Instantaneousfairrate
AveragepernodeFairness
Evaluation metrics:
Inaddition,achieves100%reliability
4/19/2009 211
Application-layer quality (e.g., SNR, I-frames received) Network impact (e.g., Received bytesCalvert, IWANN 2005 discarded)
Application-directed congestion control for meteorological data

ALF: application-based dataframing application-level congestion control discard backlogged data at source, in response to congestion similar to multimedia congestion control
Application-directed congestion control

depending on sensing goal (reflectivity, wind) different discard policies perform better many open issues: dependence on tolerable time constraint? API? alternate schemes: multilayer (drop low order bits)? interaction with compression?
Std reflectivity
% packet loss
Std wind velocity
% packet loss
Discard, framing for uniform loss
Discard, framing for contiguous loss
RCRT: Efficiency
Reliabletransportwithout congestioncontrol RCRT
Distributed Sensing: Hierarchy
RCRTachieves88% ofsustainablereliableandfairrate
4/19/2009 215
36
Distributed Sensor Nets: Example Problem

small 2D Doppler radar units (30s) scan one of three 120 sectors commodity processor associated with each radar communicate short messages using one of 8 radio channels triangulate radars to do tracking
Representative of Adaptive Distributed Sensor Network Issues need for coordination/distributed resource allocation
multiple sensors need to collaborate on tasks
view objects of interest from multiple angles with different types of sensors sensing time windows need to be closely aligned
environmental dynamics
Sensor configuration changes as target moves
potential for resource overloads

multiple target in overlapping sensor regions limited communication channels
Representative of DSN Issues, cont.

soft real-time
limited time window for sensing must anticipate where target is moving in order to effectively allocate sensor resources time for coordination affects time for sensing
Structuring the distributed sensor net

decompose environment to form a partitioned organization.
each partition (sector) will contain a set of sensor nodes, each with its own controlling agent. individual sectors are relatively autonomous.
distribution: communication latency/limited bandwidth precludes global knowledge/control

distributed data fusion
scalability: need to be able to handle large numbers of sensor nodes robustness: local failures should not induce global collapse
handle uncertain information, sensor/processor/communication failures
specialize members of the agent population to dynamically take on multiple, different goals/roles.
individual agents become managers of different aspects of the problem. managers form high-level plans to address their goals, and negotiate with other nodes to achieve them.
DSN Organizational Control

Partitioned Environment Sectors Constrains info. propagation Reduces information load Exploits locality Agents take on roles Sensor(Scan/Track) Sector Manager Track Manager Limits sources of information Facilitates data retrieval
Sectored-Based Agent Organization

Agents Multiplex among Different roles
Sector Manager
Tracking Manager
Scanning Agent
Tracking Agent
37
Typical Node Layout
Partitioning of Nodes
Nodes are arranged or scattered, and have varied orientations. One agent is assigned to each node.
The environment is first partitioned into sectors. Sector managers are then assigned.
Competition for Sensor Agents
Track Manager Selection
Sector members send their capabilities to their managers. Each manager then generates and disseminates a scan schedule.
Nodes in the scan schedule perform scanning actions. Detections reported to Manager and a Track Manager selected.
Managing Conflicted Resources
Data Fusion (Track Generation)
Track Manager discovers and coordinates with tracking nodes. New tracking tasks may conflict with existing tasks at the node.
Tracking data sent to an agent which performs the fusion. Results sent back to track manager for path prediction.
38
Managing Conflicted Resources: Sensors, Processors, Communication

Sensors Conflicting Scanning Tasks from different Sector Managers
Locally resolved by agent connected to sensor
Centralizing Information in Sector Manager

Handling Data Correlation with Multiple Tracks
targets are represented by uncertainty bounds bounds affected by speed of target, age of supporting measurements bounds shared with sector manager, who in turn shares them with other track managers Sector manager uses target uncertainty bounds to determine if new target detections (from scanning) are known targets data from known target detections used to focus attention of relevant track manager track managers prevents data fusion if estimated resolved position is within another targets bounds
Tracking Tasks wanting same sensor resources

Negotiation among track managers
Communication Communication Degradation due to lack of Locality

Track manager migration among sectors
Communication Channel Overload

Sector manager assignment of track manager roles
Processors Data Fusion Overload/Knowledge locality

Sector manager assignment of data fusion/track manager roles
Multiplexing Roles
discard ambiguous measurements that intersect another targets bounds
Fault Tolerance
sensor node information is propagated through use of directory services (x, y, orientation, etc.).
sensors provide sector managers with their information. track managers query sector managers for sensor details. this information is cached for future use at each step
directory held in sector manager maintains historical query information

new data are analyzed for relevance to those queries relevant information is automatically propagated to the query source
Security
process quickly updates agents beliefs, allowing them to adapt to change
Motivation & security challenges

Openness of wireless channels lets anyone monitor or participate in communications Lots of WSN applications require security mechanisms Very limited resources
limited memory and storage space power limitations
Attacker model and desired properties

Lets consider (for now) the Dolev-Yao attacker model
overhear, intercept, alter, inject arbitrary messages
Desired properties of a secure sensor network communication architecture

Data authentication
allows a receiver to verify that data really was sent by the claimed sender Broadcast authentication
Unreliable communication
unreliable transfer conflicts (due to the broadcast nature of WSN) latency
Data confidentiality
protect information traveling through the network
Data integrity
ensures the receiver that the received data has not been altered in transit by an adversary achieved through data authentication
Unattended operations
exposure to physical attack remote management makes impossible to detect physical tampering and physical maintenance issues
Data freshness
implies that the data is recent ensures protection against replay attack
39
Symmetric Key Encryption (SKE)
TinySec (Karlof et al. 2004): a link layer security architecture

Provide data confidentiality and node-to-node authentication 3 settings selected on a per-packet basis
Alice
Bob
no crypto integrity only (TinySec-Auth) Integrity + secrecy (TinySec-AE)
plaintext
encryption
ciphertext
decryption
plaintext
Algorithm used for encryption SkipJack in CBC-CTS mode

it allows cipher text to have the same length as the plain text even though plain text is not a multiple of block size
Limited computational complexity

require simple hash, rotation or scrambling operations
Several implementation of the SKC algorithms for WSN (RC5, Skipjack, DES, 3DES, AES, RC6) Implementation of architecture for network security
TinySec, MiniSec, SNEP (part of the SPINS protocol suite), ZigBee
Main drawbacks
reduced level of security (to ensure low energy consumption) single network-wide key it does not attempt to protect against replay attack implementations for Mica motes only
Major drawback
how to distribute keys?
MiniSec (Perrig et al. 2007): a secure network layer

Provide data confidentiality, authentication and replay protection
High level of security and low energy consumption Two operating modes
Comparison
High MiniSec SPINS ZigBee
Algorithm used for encryption SkipJack in OCB mode

Provides for authentication and secrecy with fewer block cipher calls than in TinySec
Security
MiniSec-U: unicast communication MiniSec-B: broadcast communication
TinySec Low Low High
Rewrote TinyOS network stack

GenericComm generic network stack AMStandard Active Message transmission
Implementation for Telos motes

300 bytes of RAM, 3KB of code memory
Energy Consumption
http://sparrow.ece.cmu.edu/group/projects/minisec/minisecipsn07.ppt
Symmetric key establishment & manage ment 1/2

How many keys should a node maintain?
Globally shared secret key
safeguard from external attackers not secure from internal attackers (the key is exposed if a node is compromised)
Symmetric key establishment & manage ment 2/2

Distributed approach
each is preloaded with some key material with which to establish shared keys with other nodes after deployment Deterministic schemes
LEAP (Zhu et al. 2003)
sensors are preloaded with an initial key from which further keys can be established 4 different keys are used depending on whom the sensor is communicating with (individual key, pair-wise key, group key, network key) Assumption: attackers cannot compromise a node during the network initialization phase {K1, R=2 Probabilistic schemes K3} Gligor et al. (2004), Hwang et al. (2004) K1 K3
Pair-wise keys between each pair of nodes

each node requires to have n-1 keys (n is the number of nodes) solution not scalable
Centralized key distribution

each node shares a key with the base station if two nodes must communicate securely they can acquire a shared key from the base station single point of failure
General idea
K1, K2, , Ks
each node randomly picks R keys from a key pool S Key use the common shared key to establish pool secure communication with its neighbors very sensitive to the choice of parameters (R,S)
{K1, K5}
{K3, K7}
40
Public Key Cryptography (PKC)

Bobs Public Key Bobs Private Key
Elliptic Curve Cryptography (ECC)

Based on the algebraic structure of elliptic curves over finite fields Short key, high level of security Several ECC schemes
ECDH (Elliptic Curve Diffie Hellman) ECDSA (Elliptic Curve Digital Signature Algorithm) ECIES (Elliptic Curve Integrated Encryption Scheme)
Alice
Bob
A typical ECDHbased key exchange

plaintext
encryption ciphertext decryption
plaintext
Strong degree of security

more resilient to node compromise than symmetric key technology
Based on the Elliptic Curve Discrete Logarithm Problem (ECDLP)
Choose random KA
Alic e
Curve G is publicly known TA = KA * G TB = KB * G
Bob
Choose random KB
Flexible and easier to manage Drawback

High computation and storage requirement compared to SKE (exponential operations with large prime numbers) however recent moves to investigate feasibility of using PKC on sensor platforms
Determining KX given KX * G is hard TinyECC (A. Liu & P. Ning 2008)

ECDH, ECDSA, ECIES Mica, MicaZ, Telos, Imote2 Several optimization techniques
Compute KA * TB Agree on KA * KB * G
Compute KB * TA
Authenticity of keys
Attackers can easily impersonate any node by claiming its public key and launch the man-in-the-middle attack
node C may impersonate node B node A and also impersonate A to B in this way C can act as invisible router and learn all messages between A and B to
A B
Broadcast Authentication
Ensuring that a broadcast message has been sent by the claimed sender Two-party communication
achieved through a symmetric mechanism based on the Message Authentication Code (MAC)
In broadcast setting this is insecure Tesla (Perrig et al. 2002)

any of the receivers knows the MAC key and could impersonate the sender authenticated broadcast by using symmetric primitives introduces asymmetry by delaying key disclosure drawbacks
complex schemes, loose time synchronization, information exchange between exchange nodes before authentication of broadcast messages can begin
Conventional solution
making use of a certificate signed by a trusted Certificate Authority (usually the base station) B can send its public key with corresponding certificate to node A such that A can verify the correctness of the certificate with the well-known public key of the CA
Asymmetric schemes are the natural way to provide broadcast authentication

No need of synchronization Digital Signature (i.e. ECDSA)
Bottleneck: signature verification (more than 10 sec)
Attacks
Physical layer
Jamming: adversary interferes radio signals emitted by sensors, or continuously generates a request-to-send signal
Countermeasure:
detect jamming and route messages around the jammed area
Attacks
Link layer
Collision: adversary transmits signals, which result in frame errors; colliding frames are discarded and retransmission requires energy
Countermeasure:
use error-correcting codes
Exhaustion: adversary may exploit the interactive nature of link protocols in interrogation attack, and sensor runs out of energy
Countermeasure:
limit interrogation rate
Tampering: enemy captures and replaces sensors

Countermeasure:
tamper-proof (expensive) sensors hide sensors develop tamper-resistant protocols
Acknowledgment spoofing:
Some routing protocols use link layer acknowledgments Adversary spoofs acknowledgments, changing targets estimate of link quality
41
Attacks on network/routing 1/2

Link layer encryption prevents majority of attacks: false routing information, Sybil attacks, acknowledgment spoofing, etc development of an appropriate key management architecture is of great importance!!!
Attacks on network/routing 2/2

Sinkhole attack
adversary attracts messages from neighbors by advertising for example a high route to the base station
Sybil attack
adversary creates multiple identities (mostly affects geographical routing protocols) Countermeasure:
adopt validation techniques shortest
False routing information

injecting false routing control packets into the network example: captured node attracts traffic by advertising path to sink, high battery power, etc
Countermeasure:
Adopt validation techniques
Wormholes
Adversary close to sink implements a sinkhole Another laptop class node advertises high route to the base station, through the malicious node
Countermeasure: tight clock synchronization http://comp.ist.utl.pt/pdis-srm/Acetatos/WSN-security.pdf
quality other
Selective forwarding
compromised node may refuse to forward packets or may forward selected packets
Countermeasures:
neighbors assume the compromised node failed and start using another route multipath routing
http://comp.ist.utl.pt/pdis-srm/Acetatos/WSN-security.pdf
Attack on transport layer

Hello floods
adversary broadcasts HELLO message to nodes and then advertises high-quality route to sink
Countermeasure:
adopt multi path routing, and bidirectional link verification
Programming
Architectures
A lot of research on developing communication and software architectures for sensor networks
Should be general and extensible Should support heterogeneity Should be designed with the constraints of sensor networks in mind
TENET
Masters control motes Applications run on masters, and masters task motes
Hierarchical Architectures TENET Software architectures defying norms set for traditional networks SP Architecture Software architectures designed using lessons from traditional networks An IPv6 Architecture
Motes process data,
and may return responses No multi-node fusion at the mote tier
42
SP Architecture
Propose that sensor networks have a narrow waist, like that Internet Application Layer Due to their unique constraints, routing Timing, Power protocols inSecurity networks are application Mgmt., sensor Routing Components specific etc. SP Layer Thus lower the waist to between the data-link Data-Link Layer layer and the network layer Hardware Components Propose Sensornet Protocol (SP), a best-effort single link broadcast layer as the narrow waist of sensor network systems
IPv6 Architecture
Claim that an IPv6 based network architecture would be well suited to sensor networks
Highly scalable General and extensible Amenable to compression (6LowPAN), and allows for more efficient implementations than IPv4
Propose and implement a complete IPv6 network architecture for sensor networks
Uses 6LowPAN compressed header format Incorporates many WSN essentials Allows for integration of sensor networks into the Internet
From J. Hui etal., SenSys 2008
Operating Systems
General-purpose operating systems too heavy-weight to run on sensor nodes Sensor network operating systems should
Be lightweight Enable some form of concurrency Provide mechanisms to access hardware sensors etc Provide services to enable applications e.g. routing, neighbor discovery
TinyOS
Most popular sensor network operating system Written in nesC, an extension of C designed for sensor nodes Main Features
High concurrency, interrupt driven Monolithic (no kernel) Small Footprint Component Based Contains components for Routing, Timers, etc. Static memory allocation Asynchronous functions called Tasks scheduled for execution by a Task Scheduler, allow for concurrency and split-phase execution
Event-driven operating systems

TinyOS, SOS
Multithreaded operating systems

Contiki, Mantis
SOS
A dynamic sensor network operating system written in C Main Features
Contains a core kernel which provides essential services Modules that can be inserted and removed at runtime Message based rather than event based Dynamic memory No memory protection, modules assumed to be cooperative
Contiki
Lightweight flexible sensor network operating system written in C Main Features
Consists of an event-based kernel Supports pre-emptive multi-threading on a per-process basis Allows for dynamic loading/unloading of modules Dynamic memory Has the concept of a service a dynamically linked process implementing functions used by other processes managed by a service layer
43
Programming Languages and Abstractions

Lots of work on designing programming languages and abstractions for sensor networks to simplify the task of programming them Programming Languages
nesC
nesC
Most popular sensor networking language used with the TinyOS operating system Extension of C Completely static
No dynamic memory or function pointers
Programming Abstractions
Protothreads, Abstract Regions
Component based design

Modules and their interfaces Components wired together using a wiring specification
Macro-programming Languages
Regiment, Flask, DSN, Pleiades
Event-based concurrency model

Split-phase function calls
Energy-aware languages and abstractions

Eon, Levels
Parameterized interfaces to allow multiple instances of same module Provides atomic keyword to annotate asynchronous code
Programming Abstractions
Protothreads - allow for writing even-driven programs in a thread like style
Provide a conditional blocking wait abstraction Protothreads are stackless
Share same stack, context switching done by stack rewinding
Regiment
High-level language for spatiotemporal macro-programming based on Functional Reactive Programming Network seen as a set of spatially distributed data-streams Primitives for performing aggregation over regions, manipulating individual streams, triggering new computation etc.
Abstract Regions Provide a communication abstraction for a physical neighborhood

Hide details of dissemination and aggregation within the regions Programming abstractions for neighbor discovery, data sharing, reduction etc.
Flask
domain-specific language embedded in Haskell Staging mechanism to separate node-level code from macro-code Macro-code in Haskell, node-level code in Red, subset of Haskell Seamlessly integrates nesC with Red
DSN
Declarative in nature (main constructs are predicates, tuples, facts and rules) @ used to specify the location of any tuple, e.g. @n Links to hardware (sensors, actuators) using built-in predicates Users can pose queries for the DSN runtime to output
Energy Aware Programming Languages and Abstractions

Eon
Energy-aware language designed for perpetual systems (that harvest environmental energy to keep running) Declarative coordination language allows composing nesC/C blocks together Paths through program may be annotating with energy states Runtime energy management uses annotations to pick paths of program to execute in order to maximise QoS under energy constraints
Pleiades
Procedural macro-programming language an extension of C Provides abstractions for nodes, global and node-local variables, sensors, timers etc. @ used to specify the location of any node-local variable Provides a concurrent loop abstraction cfor guarantees serializability of cfor using locking
Has inbuilt deadlock detection and recovery mechanisms
Levels
Programming abstraction for energy-aware applications Programmer defines multiple energy levels and a lifetime goal
Annotates blocks of code with possible energy levels
Optimal level-assignment for various code blocks decided at runtime in order to best satisfy lifetime goals
44
Sensor Data Integrity

Ensure sensed data is of good quality Good quality sensor measurements are essential.
Data Integrity
Utility to scientists, engineers, and domain experts. Ideally, comparable in quality to the data collected using traditional sensors.
Quality assurance is challenging:

Huge amount of sensor data. Need for automated techniques. Difficult to define good data for phenomena that are not well understood.
Data quality in the wild
Data faults
Data faults cause the affected sensor readings to deviate from the pattern exhibited by the true sensor readings.
For example, a visual or statistical anomaly.
Figures from Ni et al., Sensor Network Data Fault Types, ToSN, vol.5, #3, Aug09
Fault Taxonomy
Data-centric view
Defined with respect to the true/normal sensor readings. Significant deviation from normal is a fault. Anomalies/outliers.
Faults: Data-centric view

SHORT: single sample spikes.
CONSTANT (stuck at)
System-centric view
Anomalous sensor readings are due to faults in system components (root cause analysis).
Significant overlap between the two views.
NOISE: increase in variance

additive noise.
45
Faults: System-centric view

Calibration errors
Parameters can drift over time.
Fault Prevalence: Real-world datasets

Datasets NAMOS INTEL Lab Berkeley Great Duck Island SensorScope % of faulty samples 10-35% ~20% 3-60% Less than 1% Fault types NOISE, CONSTANT NOISE, SHORT, CONSTANT SHORT, NOISE SHORT
Hardware faults
Loose connection, sensor damage, low battery
Software faults
Errors in data logging
Impact of System faults

Loose connection known to cause SHORT faults. Low battery can result in NOISE faults.
Sharma et al. On the Prevalence of Sensor Faults in Real-World Deployments. SECON, 2007.
Fault detection: Data-centric view

Data-centric view motivates use of statistical techniques for data fault detection. Key idea:
1. 2.
Statistical techniques for fault detection

Techniques that have proven effective:
Declarative approaches: rules that precisely define what a fault is. Least-squares regression: exploit spatial correlation to estimate the correct value of a sensor reading. Time series analysis: exploit temporal correlations. Learn a model for true sensor reading using supervised/unsupervised learning. Error detection/correction during the data fusion step. e.g. computing avg., sum etc.
Define normal pattern based on sensor data. Flag significant deviations from the normal pattern as faulty.
How do you define the normal pattern?

Exploit spatio-temporal correlations across samples from different sensors. Leverage domain knowledge.
Key drawback:
Efficacy depends on the parameter settings.
Fault detection: System-centric view

Determining the correct calibration set-up
Controlled experiments in the lab. Online monitoring of and recovery from calibration errors.
The road ahead

Need to develop online fault detection methods. Fault detection must be built into the system from the start.
Hierarchical architecture for fault detection: local fault detection at a sensor node that is followed by fault detection at a master node that collects data from several sensors.
Monitoring
Collect periodic measurements of the supplied voltage. Monitor unusual or lack of activity at a sensor.
Extracting information from faulty samples.

Methods for correction faulty readings.
46
Now, we have everything we need

Lets build WSN applications!!
Env.Monitoring Env.Monitoring SHM SHM Tracking Tracking
Programming Programming Architecture Architecture Congestion Congestion Control Control Data Analysis Data Analysis & Integrity & Integrity Debugging & Debugging & Diagnosis Diagnosis
Applications Applications
Security Security
Image Sensing Image Sensing Medical Medical
Applications
Security Security
Transport Transport
Time Synch. Time Synch.
Localization Localization
Routing Routing
Dissemination Dissemination
Storage Storage
MAC MAC
Sleep Sleep Scheduling Scheduling
WSN Applications
Monitoring Environments
Great Duck Island, Redwood forest, James Reserve Volcano Underwater monitoring
Common Challenges
Long-lived, robust operation
Limited Energy Limited Memory Large number of nodes deployed over possibly large area Error/fault tolerance
Monitoring Structures (SHM)

GGB, VTB, Wisden
Ease of application development

and adaptation and re-tasking
Security / Target Tracking

Surveillance, Disaster management, ZebraNet
Unexpected nature of the real environment

Theory might not hold in reality
Industrial/Infrastructure Monitoring
Machine monitoring, Energy/Water monitoring
Application-specific Requirements
Data rate vs. Duty cycle
High data rate for high fidelity data
SHM (GGB, VTB), Volcano, Image-based monitoring (JR)
Taxonomy
Low latency Reliable delivery Long lifetime
Surveillance Medical Tracking Data Rate Volcano SHM Imaging
Environment Water/Power Underwater Machine
Low duty cycle for long life time

Environmental monitoring (GDI, Redwood, ESS)
Reliability Low latency Time-synchronized sensing Many more
47
Environmental Monitoring
GDI, Redwood, ESS (at JR), LUSTER
Low sampling rate Low duty cycle, long life time Large-scale multi-hop network
Structural Health Monitoring

GGB, VTB
High sampling rate Reliable data transport Time-synchronized sampling Large-scale multi-hop network
Image-based Environment Monitoring

Bird nest monitoring
High data rate Compression and Reliability Large-scale 2-tier network
Medical (Patient Monitoring)

MEDiSN, CodeBlue, AlarmNet
Low latency Reliability Privacy/Security Sensor Accuracy
Meteorological Sensing: the Sensing Gap

Sparse, high-power radar sensing gap: earth curvature effects prevent 72% of the troposphere below 1 km from being observed coarse resolution
10,000 ft 3.05 km 4 km 1 km 2 km
tornado
ea
gap
ac e
Horz. Scale: 1 = 50 km Vert. Scale: 1 -=- 2 km 0 40 80 120 RANGE (km) 160 200
rth su rf
240
There is insufficient knowledge about what is actually happening (or is likely to happen) at the Earths surface where people live. [NRC 1998]
3.05 km
Other Sensor Networks
snow wind
5.4 km
48
CASA: collaborative adaptive sensing of the atmosphere

CASA: dense network of low power radars: sense lower 3 km of earths atmosphere collaborating radars: improved sensing improved detection, prediction finer spatial resolution responsive to multiple end-user needs
CASA: dense network of inexpensive, short ra nge radars

instead This: of this.
10,000 ft 3.05 km
snow
3.05 km
wind tornado
ea rth su rf
ac
40
80
120 RANGE (km)
160
200
240
finer spatial resolution beam focus: more energy into sensed volume multiple looks: sense volume with most appropriate radars
Sample atmosphere when and where end-user needs are greatest
Oklahoma 4-Node Test Bed
Spring 2007 storm season:

4/10/07: first CASA data citation by NWS
FLUS74 KOUN 102343 FLUS74 KOUN 102343 AWUOUN AWUOUN AREA WEATHER UPDATE AREA WEATHER UPDATE NATIONAL WEATHER SERVICE NORMAN OK NATIONAL WEATHER SERVICE NORMAN OK 742 PM CDT TUE APR 10 2007 742 PM CDT TUE APR 10 2007 ..WARNING DECISION UPDATE ..WARNING DECISION UPDATE THIS WARNING DECISION UPDATE CONCERNS THIS WARNING DECISION UPDATE CONCERNS COMANCHE AND GRADY COUNTIES. COMANCHE AND GRADY COUNTIES.
5/8/07: circulations in testbed
8:15 pm
Cyril Chickasha Rush Springs
Norman OK (NOC)
Lawton
MESOCYCLONE NEAR STERLING CONTINUES MESOCYCLONE NEAR STERLING CONTINUES TO STRENGTHEN PER TWO RADAR VIEWS. TO STRENGTHEN PER TWO RADAR VIEWS. CASA NETWORK ALSO SHOWING CASA NETWORK ALSO SHOWING PRONOUNCED HOOK. STORM WILL PRONOUNCED HOOK. STORM WILL ENCOUNTER WARM FRONT...WITH POSSIBLE ENCOUNTER WARM FRONT...WITH POSSIBLE ENHANCED LOW LEVEL SHEAR JUST EAST OF ENHANCED LOW LEVEL SHEAR JUST EAST OF STERLING AND WEST OF RUSH SPRINGS. STERLING AND WEST OF RUSH SPRINGS. TORNADO WARNING IS POSSIBLE IF NOT TORNADO WARNING IS POSSIBLE IF NOT LIKELY TO BE ISSUED AS STORM REACHES LIKELY TO BE ISSUED AS STORM REACHES SOUTHWEST GRADY COUNTY. SOUTHWEST GRADY COUNTY. BURKE BURKE
7:21pm
KSWO TV
Note: not policy
April 10, 2007 Elevated Super Cell

CASA High Resolution Data NEXRAD Comparison
CASA IP1 view: May 8 event
KLWE at 1.0 deg elevation, 21km range (~200m AGL)
7:26pm 7:28pm
7:32pm
7:34pm
7:36pm
7:38pm
7:39pm
corresponding NEXRAD view
CASAs Adaptive Sector scanning at multiple elevations from 1 to 14 degrees, 40 sec. sector scan
Ground Truth Verification by Val Castors NEWS9
7:28pm
7:34pm
7:39pm
49
Architectural worldview
application-layer functionality, control, protocols
Architecture overview
storage
data
query interface
MC&C: Meteorological command and control

Meteorological Detection Algorithms
1 Mbps (moment) 100 Mbps (raw)
streaming storage
blackboard
prediction
A B C D E F G H I J K 1 G3 G3 G3 G3 G3 G3 G3 R1 R1 R1 R1 2 3 4 G3 G3 G3 G3 G3 G3 G3 G3 G3 G3 G3 G3 G3 G3 G3 G3 G3 G3 G3 G3 G3 R1 R2 R2 F1 F2, R1 F2,H2 H1,F1 H1 ,F1 T2,R1 H1 T2,H1 T2,R1 5 G3 G3 G3 G3 G3 G3 G3 R1 R1 R1 R1
Feature Repository
6 G3 G3 G3 G3 G3 G3 G3 G3 G3 G3 G3
7 G3 G3 G3 G3 G3 G3 G3 C2 C2 C2 G3
8 G3 G3 G3 G3 G3 G3 G3 G3 G3 G3 G3
9 G3 G3 G3 G3 G3 G3 G3 G3 G3 G3 G3
IP backplane
SNR data policy Meteorological Task Generation
End users: NWS, emergency response
30 sec. heartbeat
Resource planning, optimization
resource allocation
Meteorological Command and Control (MC&C)

Time sensitive: decouple ingest from command generation
Meteorological Command and Control

4 3.5 3 2.5 2 1.5 1
0.7
data ingest, storage

Radar 1
feature detection
second s
LB
. . .
LB grid constructor
0.5
0.6
Radar 2
Data Ingest Retrieval, Detection Algorithms s

Feature Repository
10
20
30
40
50
seconds
0.5 0.4 0.3 0.2 0.1 0
t-30
data ingest
streaming retrieval, detection
streaming retrieval, detection
itera tions
LB
. . .
t+30
radars
Repository/blackboard
A B C D E F G H I J K 1 2 G3 G3 G3 G3 G3 G3 G3 G3 G3 G3 G3 G3 G3 G3 R1 R1 R1 F 1 R1 H1 ,F1 R1 H1 3 4 G3 G3 G3 G3 G3 G3 G3 G3 G3 G3 G3 G3 G3 G3 R2 R2 F 2,R1 F 2,H2 H1 T ,F1 2,R1 T 2,H1 T 2,R1 5 G3 G3 G3 G3 G3 G3 G3 R1 R1 R1 R1 6 G3 G3 G3 G3 G3 G3 G3 G3 G3 G3 G3 7 G3 G3 G3 G3 G3 G3 G3 C2 C2 C2 G3 8 G3 G3 G3 G3 G3 G3 G3 G3 G3 G3 G3 9 G3 G3 G3 G3 G3 G3 G3 G3 G3 G3 G3 Feature Repository
repository/ blackboard
A B C D E F G H I J K
1 2 G3 G3 G3 G3 G3 G3 G3 G3 G3 G3 G3 G3 G3 G3 R1 R1 R1 F 1 R1 H1 ,F1 R1 H1
3 4 G3 G3 G3 G3 G3 G3 G3 G3 G3 G3 G3 G3 G3 G3 R2 R2 F 2,R1 F 2,H2 H1 T ,F1 2,R1 T 2,H1 T 2,R1
5 G3 G3 G3 G3 G3 G3 G3 R1 R1 R1 R1
6 G3 G3 G3 G3 G3 G3 G3 G3 G3 G3 G3
7 G3 G3 G3 G3 G3 G3 G3 C2 C2 C2 G3
8 G3 G3 G3 G3 G3 G3 G3 G3 G3 G3 G3
9 G3 G3 G3 G3 G3 G3 G3 G3 G3 G3 G3
20
40
60 iterations
80
100
120
140
300 250 runtime (msec) Optimization 200 150 100 50 0 1 5 9 13 17 21 25 29 33 37 41 45 49 53 57 61 65 69 73 77 81 85 89 93 97 heartbeat Tas k Generation
A B C D E F G H I J K
1 G3 G3 G3 G3 G3 G3 G3 R1 R1 R1 R1
2 3 4 G3 G3 G3 G3 G3 G3 G3 G3 G3 G3 G3 G3 G3 G3 G3 G3 G3 G3 G3 G3 G3 R1 R2 R2 F1 F2, R1 F2,H2 H1,F1 H1 ,F1 T2,R1 H1 T2,H1 T2,R1
5 G3 G3 G3 G3 G3 G3 G3 R1 R1 R1 R1
6 G3 G3 G3 G3 G3 G3 G3 G3 G3 G3 G3
7 G3 G3 G3 G3 G3 G3 G3 C2 C2 C2 G3
8 G3 G3 G3 G3 G3 G3 G3 G3 G3 G3 G3
9 G3 G3 G3 G3 G3 G3 G3 G3 G3 G3 G3
Meteorological Task Generation
task generation optimization
end-user preferences, policy optimization
task generation
feature repository
radar targeting requests
Michael Zink, David Westbrook, Sherief Abdallah, Bryan Horling, Vijay Lakamraju, Eric Lyons, Victoria Manfredi, Jim Kurose, Kurt Hondl, "Meteorological Command and Control: An End-to-end Architecture for a Hazardous Weather Detection Sensor Network," 2005 ACM Mobisys Workshop on End-end Sense-and-response Systems, June 200
Incorporating end-user utilities

storage
Optimizing radar scans:

incorporating end user considerations
Where to point?
R1 R2
data
query interface
MC&C: Meteorological command and control

Meteorological Detection Algorithms
Find configuration that optimizes utility at time step k:
1 Mbps (moment) 100 Mbps (raw)
streaming storage
J=
configurations ,C
max
tasks ,t
U (t , k )Q(t , C )
blackboard
A B C D E F G H I J K 1 G3 G3 G3 G3 G3 G3 G3 R1 R1 R1 R1 2 3 4 G3 G3 G3 G3 G3 G3 G3 G3 G3 G3 G3 G3 G3 G3 G3 G3 G3 G3 G3 G3 G3 R1 R2 R2 F1 F2, R1 F2,H2 H1,F1 H1 ,F1 T2,R1 H1 T2,H1 T2,R1 5 G3 G3 G3 G3 G3 G3 G3 R1 R1 R1 R1
Feature Repository
R1 configurations
6 G3 G3 G3 G3 G3 G3 G3 G3 G3 G3 G3 7 G3 G3 G3 G3 G3 G3 G3 C2 C2 C2 G3 8 G3 G3 G3 G3 G3 G3 G3 G3 G3 G3 G3 9 G3 G3 G3 G3 G3 G3 G3 G3 G3 G3 G3
R2 configurations
Utility how important is task t to the users at time k?

End users: NWS, emergency response
SNR data
policy
30 sec. heartbeat
Resource planning, optimization
Meteorological Task Generation
U (t , k ) =
groups , g
w U (t , k )
g g
resource allocation
Quality how good is scanning configuration C (distance, coverage, # radars) for task t?
50
Optimizing radar scans: architecture!

Find configuration that optimizes utility at time step k:
How to define how important: Ug(t,k)

user values for detected weather features
J=
separation of how important, U(t,k), from how good,Q(t,C) U(t,k,Q(t,C)) would have been possible but: complex to solve complex to specify and update U(t,k,Q(t,C)) stovepipe design
configurations ,C
max
tasks ,t
U (t , k )Q(t , C )

naturally: group-sensitive utility for each feature (tornado, wind shear, hail core) scanned and the survey says..
User Utility Rules (revised)

interval-based preferences: do X every Y time units utility considers both objects, time
Rules NWS N1 N2 EMs E1 E2 time reflectivity over AOI velocity over AOI 360 task size lowest lowest 1 1 Yes Yes 1 / min 1 / min time storm 360 task size lowest full volume 1 1 Yes Yes 1 / min 1 / 2.5 min Rule trigger Sector Selection Elevations # radars Contig. Sampling interval
User feedback: NWS: want mental movie scanning areas of interest at regular intervals need context: scan areas around features (storm cell) want to joystick system (want their own network)
E3
task size
lowest
2+
Yes
1/ 2.5 min

naturally: group-sensitive utility for each feature (tornado, wind shear, hail core) scanned and the survey says..
want to joystick system (want their own network)
Virtualization: enabling the end user

virtualization of computing, communication, and sensing resources each user:
sees standalone sensor network can modify, download, execute, experiment with own code implements user-specific service outside (architecturally above) infrastructure provider
User feedback: NWS: want mental movie scanning areas of interest at regular intervals need context: scan areas around features (storm cell) want to joystick system want to joystick system (want their own network) (want their own network)
51
Virtualization: making end users happy

CASA code CASA code
detection
Virtualization: enabling end user

CASA code CASA code
detection
instead of this.
storage
CASA code CASA code CASA code CASA code
CASA code
observed state policy utliity fcn end users
instead of this.
storage
CASA code CASA code CASA code CASA code
CASA code
observed state policy utliity fcn end users
CASA code
resource allocation
CASA code
resource allocation
.this system view
CASA code storage

CASA code CASA CASA code code
CASA code detection
CASA CASA code code observed state user code end users
CASA code
CASA code
logical user-view: dedicated system!
user CASA code code

storage
user CASA code
code CASA CASA code code code
CASA code code detection
user
user CASA CASA code code code

observed state user
user
user CASA code

code
user CASA code

code
CASA code
resource allocation
user CASA code code

resource allocation
Why virtualization?
users want programmability/resources at in-network nodes: computing over local data, storage good application: avoid active networking redux challenges: virtualizing sensing resources: sharing: sensed data from one user usable by another (unlike bandwidth, computing) admission control: mediating among different users with different priorities
partially satisfiable user requests? (negotiate?) time-vary allocation of resources? priorities among users (policy)?
Definition of sensing is changing..

2002 Traditional sensor networks - Specially designed hardware - Fully automatic and standalone systems - Thousands of small devices - Fixed, static devices 2008 Participatory sensing - Leveraging available devices - Humans in the loop - Heterogeneous devices - Total mobility BodyNets
Sensing the world with mobile devices (Nokia Research Center) http://research.nokia.com/files/insight/NTI_Sensing_-_Dec_2008.pdf
Emerging Directions
Participatory Sensing
Use sensors on cell phones in order to record environmental conditions, personal usage, and so forth Enables citizen sensing
People-c entric s ensing a pplicati on d omains
Body area networks

Network of physiological sensors to monitor individual health Useful for rehabilitation and training as well
Andrew Campbell, et al, The Rise of People-Centric Sensing, IEEE Internet Computing, July/August 2008
52
Imagin e 1 billi on s ensor enabled m obile ph on es scatt er ed acr oss th e plan et
Societal scale sensing
people are in the loop
This will lead t o
The global mobile sensor network
Sample Projects
Personal Environmental Impact measurement
UCLA
Research Challenges
Privacy, privacy, privacy Application development, role of cloud computing Mobile social networking
Recreational Networking
Dartmouth
Traffic management
UC Berkeley
Wildlife monitoring (owls)

MIT
Urban Documentation
USC
Body Sensor Networks

Bodynets
Wireless sensor technology for health monitoring applications. Nodes have many physiological sensors.
Challenges in Bodynets
Some commonality with sensornets Differences
Non-invasive design Smaller batteries, more stringent tradeoffs Packaging and placement details crucial
http://people.virginia.edu/~bhc2b/papers/HansonEtalComputer09.pdf
Application
Most works in medical health-care. There is an effort to combine with mobile device
53
Questions?
54

Sensor Networks

Transféré par

Informations du document

Description originale:

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Sensor Networks

Transféré par

Droits d'auteur :

Formats disponibles

A word of thanks to our sponsors*

Emerging broader definitions

Urban participatory sensing

Embedded (in-situ) network sensing

Remote networked sensing

Seismic Structure response

Hazardous weather detection

data ingest, analysis, actuation: realtime control, tasking of sensor

In-situ versus remote sensing

Wide range of sensor nets: embedded

Wide range of sensor nets

Wide range of sensor nets

in spite of differences, commonalities as well!

The Old View

Wireless Sensor Networks

Aggregation and Compression Collaborative Signal Processing

Operating Systems Processor Platforms Radios Sensors

The Old View of the Network

Where are we?

Lots of deployments Designed for one purpose, little code reuse

Where are we going?

What do we need to get there?

A General-Purpose, Multi-User, Reactive Observing System

Complex sensing modalities

The New View of the Network

The New View

Some deployments will have mobile elements in one or both tiers

Time Localization Synchronization

Security and Management

EnergyManagement RadioMediumAccess SensorInterfaces

Sensor Node Architecture

Communication Unit Radio

Connectivity Unit USB/Serial

OperatingSystem andApplication+ Storage

13416MHzfrequencyrange 256KBSRAM,32MBFLASH,32MBSDRAM 3xUART,I2C,2xSPI,SDIO,I2S,AC97,USBhostand slave,CameraI/F,GPIO Upto0.85Voperation <31mA (activepower@13MHz),<387A(deep sleepmode)

902MHzto928MHz FHSSoperation 10kbpseffectivedatarate TX:265mA,Rx:65mA.33.6Voperation 22dBmmaxtx power,106dBm rx sensitivity 9.6Kmrangewith2dBi antenna

Primary requirement is low power operation

Additional sensor boards connected to nodes using expansion slots/pins

Energy harvesting: variability

24 W Ray Marine radar

Energy harvesting: modeling variability

Energy harvesting: theorem

Then: Question: given (,1,2)-source. How big a battery

generalizes to variable rate consumption

TenetdeploymentatVincent ThomasBridge @USC

Compartments Electromagnetic shielding

Heliomote @ UCLA/MSR Shakebox @USC

Mote Universe MicaDot

Imote (2005) TelosB (2004)

Spec (2003) weC (1999)

250kbps2.4GHzIEEE802.15.4Radiowith integratedantenna 13416MHz256kSRAM,32MBRAM, 32MBFLASH 387A(sleep) 66mA(Active) ~80mLOSrange 36mmx48mm

Support and Popularity

Cell phones as sensor nodes

Gateway Node Examples

800MHzVIAEdenN256MBDDRRAM CompactFlashbasedHDD MiniPCI 802.11LAN,Ethernet,Serial,USB, Keyboard,monitor 6.7 x4.8 x2.2

RFID vs Sensor Network

eBox ~ 27,000 sq. ft

RFID vs Sensor Network

Smartphones as Sensor Nodes

Overview: radar remote sensor

IP1 Radar Node Tower-Top Subsystem

Gigabit Eth. Switch