Applications of Wireless Sensor Networks

1
Applications of Wireless Sensor Networks
2
Outline

• Quick overview of applications in different
  real-world domains
• Two basic problems
• Monitoring sampling the environment
• Tracking know the trajectory of targets
• Three case studies
• Habitat monitoring
• Structural monitoring
• Target tracking

3
Warning

• Researchers are generally not good at
  applications
• We are a little bit far from real-world
  application scenarios
• We are too busy to invent/develop the technology,
  and have not cared too much about how to use it
• We as researchers tend to make things complex
• To show how smart we are
• You may know much better than me !

4
Examples of Applications of Sensor Nets in Reality

• Habitat monitoring
• Environmental observation and forecasting
  systems Columbia River Estuary
• Smart Dust
• Biomedical sensors
• Target tracking

5
Estuarine Environmental Observation and
Forecasting System

• Observation and forecasting system for the
  Columbia River Estuary

6
CORIE Approach

• Real-time observations
• Estuarine and offshore stations
• Numerical modeling
• Produce forecast, circulation
• Virtualization application
• Vessel survey, navigation
• fishing, etc

7
Smart Dust Mote

• Tiny light-communication

8
Military Applications of Smart Dust
9
Biomedical Sensors

• Sensors help to create vision

10
Classifications of Sensor Nets

• Sensor position
• Static (Habitat, CORIE, Biomedical)
• Mobile (Smart Dust, Biomedical)
• Goal-driven
• Monitoring Real-time/Not-real-time (Habitat,
  Smart Dust)
• Forecasting (CORIE)
• Function substitution (Biomedical)
• Communication medium
• Radio Frequency (Habitat, CORIE, Biomedical)
• Light (Smart Dust)

11
Application-specific Constraints

• Material Constraints
• Bio-Compatibility
• Inconspicuous
• Imitative to environment
• Detect-proof e.g. stealth flight
• Secure Data Communications
• Regulatory Requirements such as FDA

12
Limited Computation and Data Storage

• Sensor design
• Multi-objective sensors and single (a
  few)-objective sensors.
• Cooperation among sensors
• Data aggregation and interpretation

13
Low Power Consumption

• Low power functional components
• Power-manageable components
• Several functional state (low state-transition
  overhead)
• Deep-sleep, Sleep, On
• Provide different QoS with different power
  consumption.
• Power Management
• Power measurement
• Power budget allocation
• Control transitions between different power
  states.

14
Wireless Communication

• Communication mediums
• Radio Frequency Habitat monitoring, Biomedical
  sensors and CORIE estuarine observation
• Light (active and passive) Smart Dust
• Ad hoc versus infrastructure modes
• Topology
• Routing

15
What we have learned from these cases?

• The quality of applications depends on your
  imagination and real-world awareness
• The number of applications is growing bigger day
  by day
• The sky is the limit

16
Case Study 1 Habitat Monitoring

• What can we learn from such a simple application?
• Progressive refinement from application scenario
  to the detailed component technology

17
Motivation Application Scenario

• How much can they vary?
• What are the occupancy patterns during
  incubation?
• What environmental changes occurs inthe burrows
  and their surroundings duringthe breeding
  season?

• Questions
• What environmental factors make for a good nest?

18
Problem Formulation Translation

• Solution
• Deployment of a sensor network

• The impact of human presence can distort results
  by changing behavioral patterns and destroy
  sensitive populations
• Repeated disturbance will lead to abandonment of
  the colony

• Problems
• Seabird colonies are very sensitive to
  disturbances

19
Great Duck Island Project
20
Sensor Network Architecture
21
Mica Sensor Node

• Single channel, 916 Mhz radio for bi-directional
  radio _at_40kps
• 4MHz micro-controller
• 512KB flash RAM
• 2 AA batteries (2.5Ah), DC boost converter
  (maintain voltage)
• Sensors are pre-calibrated (1-3) and
  interchangeable

Left Mica II sensor node 2.0x1.5x0.5 cu.
In. Right weather board with temperature,
thermopile (passive IR), humidity, light,
acclerometer sensors, connected to Mica II node
22
Power Management

• Sensor Node Power
• Limited Resource (2 AA batteries)
• Estimated supply of 2200 mAh at 3 volts
• Each node has 8.128 mAh per day (9 months)
• Sleep current 30 to 50 uA (results in 6.9 mAh/day
  for tasks)
• Processor draws apx 5 mA gt can run at most 1.4
  hours/day
• Nodes near the gateway will do more forwarding

75 minutes
23
Communication

• Routing
• Routing directly from node to gateway not
  possible
• Approach proposed for scheduled communication
• Determine routing tree
• Each gate is assigned a level based on the tree
• Each level transmits to the next and returns to
  sleep
• Process continues until all level have completed
  transmission
• The entire network returns to sleep mode
• The process repeats itself at a specified point
  in the future

24
Network Re-tasking

• Initially collect absolute temperature readings
• After initial interpretation, could be realized
  that information of interest is contained in
  significant temperature changes
• Full reprogramming process is costly
• Transmission of 10 kbit of data
• Reprogramming application 2 minutes _at_ 10 mA
• Equals one complete days energy
• Virtual Machine based retasking
• Only small parts of the code needs to be changed

25
Sensed Data including the Nasty Portion
Raw thermopile data from GDI during 19-day period
from 7/18-8/5/2002. Show difference between
ambient temperature and the object in the
thermopiles field of view. It indicates that the
petrel left on 7/21, return on 7/23, and between
7/30 and 8/1
26
Health and Status Monitoring

• Monitor the motes health and the health of
  neighboring motes
• Duty cycle can be dynamically adjusted to alter
  lifetime
• Periodically include battery voltage level with
  sensor readings (03.3volts)
• Can be used to infer the validity of the motes
  sensor readings

27
What have we learned?

• A simple application scenario may yield enough
  systems insights
• Among different architectural options and
  component choices, which worked? Which did not?
• E.g., Single hop, multihop?
• What is the main impeding factor for systems
  design goals?
• E.g., energy? Accuracy?
• There are enough problems coming out of a real
  application scenario!
• E.g., re-tasking
• No need to fabricate new ones in your mind!

28
Case Study 2 Structural Monitoring Wisden
Structural health monitoring (SHM) Detection and
localization of damages in structures Structural
response Ambient vibration (earthquake, wind
etc) Forced vibration (large shaker) Current SHM
systems Sensors (accelerometers) placed at
different structure location Connected to the
centralized location Wires (cables) Single hop
wireless links Wired or single hop wireless data
acquisition system
29
Real-World Deployment Scenario
Seismic test structure Full scale model of an
actual hospital ceiling structure Four Seasons
building Damaged four-storey office building
subjected to forced-vibration
30
Sensor Network for Seismic Test Structure Scenario
10 node deployment Sampling at 50 Hz along three
axes Transmission rate at 0.5 packets/sec Impuls
e excitation using hydraulic actuators
31
Motivation

• Are wireless sensor networks an alternative?
• Why WSN?
• Scalable
• Finer spatial sampling
• Rapid deployment
• Wisden
• Wireless multi-hop data acquisition system

32
Challenges

• Reliable data delivery
• SHM intolerant to data losses
• High aggregate data rate
• Each node sampling at 100 Hz or above
• About 48Kb/sec (10 node,16-bit sample, 100Hz)
• Data synchronization
• Synchronizing samples from different sources at
  the base station
• Resource constraints
• Limited bandwidth and memory
• Energy efficiency
• Future work

33
Wisden Architecture
Challenges Architecture Component Description
Reliable data delivery Reliable Data Transport Hybrid hop-by-hop and end-to-end error recovery
High data rate Compression Silence suppression Wavelet based compression
Data Synchronization Data Synchronization Residence time calculation in the network
34
Reliable Data Transport

• Routing
• Nodes self-organize in a routing tree rooted at
  the base station
• Used Woo et al.s work on routing tree
  construction
• Reliability
• Hop-by-hop recovery
• How ?
• NACK based
• Piggybacking and overhearing
• Why hop by hop?
• High packet loss

Retransmission
NACK
Retransmission
Retransmission
NACK
NACK
35
Reliable Data Transport (cont.)

• End to End packet recovery
• How ?
• Initiated by the base station (PC)
• Same mechanism as hop-by-hop NACK
• Why ?
• Topology changes leads to loss of missing packet
  information
• Missing packet information may exceed the
  available memory
• Data Transmission rate
• Rate at which a node injects data
• Currently pre-configured for each node at R/N
• R nominal radio bandwidth
• N total number of nodes
• Adaptive rate allocation part of future work.

36
Compression

• Sampled data significant fraction of radio
  bandwidth
• Event based compression
• Detect Event
• Based on maximum difference in sample value over
  a variable window size
• Quiescent period
• Run length encoding
• Non-quiescent period
• No compression
• Saving proportional to duty-cycle of vibration
• Drawback
• High latency

Compression
No Compression
Compression
37
Compression For Low Latency

• Progressive storage and transmission
• Event detection
• Wavelet decomposition and local storage
• Compression
• Low resolution components are transmitted
• Raw data, if required available from local
  storage
• Current Status
• Evaluated on standalone implementation
• To be integrated into Wisden

Flash Storage
Wavelet Decomposition
To sink on demand
Quantization, Thresholding, Run length coding
Reliable Data Transport
Sink
Low resolution components
38
Data Synchronization

• Synchronize data samples at the base station
• Generation time of each sample in terms of base
  station clock
• Network wide clock synchronization not necessary
• Light-weight approach
• As each packet travels through the network
• Time spent at each node calculated using local
  clock and added to the field residence time
• Base station subtracts residence time from
  current time to get sample generation time.
• Time spent in the network defines the level of
  accuracy

TAT-(qA qB)
TCT-(qC qD)
39
Implementation
Hardware Mica2 motes Vibration card (MDA400CA
from Crossbow) High frequency sampling (up to
20KHz) 16 bit samples Programmable anti-aliasing
filter Software TinyOS Additional software 64-bit
clock component Modified vibration card firmware
40
Seismic Test Structure Setup
Setup 10 node deployment Sampling at 50 Hz along
three axes Transmission rate at 0.5
packets/sec Impulse excitation using hydraulic
actuators For validation A node sending data to
PC over serial port (Wired node) A co-located
node sending data to the PC over the wireless
multihop network (Wisden node)
41
Results Frequency Response
Power spectral density Wisden node
Power spectral density Wired node
Low frequency modes captured High frequency modes
lost Artifact of compression scheme we used
42
Results Packet Reception and Latency
Packet reception 99.87 (cumulative over all
nodes) 100 , if we had waited longer Latency 7
minutes to collect data for 1 minute of vibration
43
What we have learned from this case study?

• Application requirements motivate networking
  protocol design
• Data reliability --gt hop-by-hop end to end
• Time synchronization --gt base station is the
  reference
• In-network processing is needed
• Compression helps to reduce data communication
• 3. Again, no need to forge problems to solve at
  school or in your lab
• Look at applications in reality!

44
Case Study 3 Object Tracking

• Given a sensor network, use the sensors to
  determine the motion of one or more targets
• Canonical domain for DSNs - much of what we have
  seen so far is applicable
• data routing, query propagation, wireless
  protocols
• Typically requires more cooperation among
  entities than other examples we have seen
• Compare is there an elephant out there? vs.
  where has that particular elephant been?

45
Tracking Challenges

• Data dissemination and storage
• Resource allocation and control
• Operating under uncertainty
• Real-time constraints
• Data fusion (measurement interpretation)
• Multiple target disambiguation
• Track modeling, continuity and prediction
• Target identification and classification

46
Tracking Domains

• Appropriate strategy depends on the sensors
  capabilities, domain goals and environment
• Requires multiple measurements?
• Bounded communication?
• Target movement characteristics?
• No single solution for all problems
• For example
• Limited bandwidth encourages local processing
• Limited sensors requires cooperation

47
Why Not Centralized?

• Scale!
• Data processing combinatorics
• Resource bottleneck (communication, processing)
• Single point of failure
• Ignores benefits of locality

48
Why Not (fully) Distributed?

• (i.e. everyone tracks)
• Redundant information and computation
• Can increase uncertainty
• Lack of unified view
• High communication costs
• (exception overhearing Fitzpatrick 2003)

49
Organization-Based Tracking

• Use structure, roles to control data action
  flow
• Can be static, or dynamically evolved
• Brooks 2003 Spontaneous coalition formation
• Horling 2003 Partitions, mediated clustering
• Li 2002 Hierarchical information fusion
• Yadgar 2003 Hierarchical teams
• Wang 2003 Roles and group formation
• Zhao 2002
• Geographic groups

50
Distributed Target Tracking

• Single target
• Fixed, acoustic sensors
• Requires multiple measurements
• Limited ad-hoc wireless network
• Track and classify target
• (classification, which uses a supervised learning
  technique, is not discussed here)

51
Location-Centric Tracking

• Operation steps at each node
• Initialization disseminate sensor information
• Receive candidates describe approaching targets
• Local detections gather measurements
• Merge detections form track, compare candidates
• Determine confidence estimate uncertainty
• Estimate track predict future target location
• Transmit track notify relevant sensors

52
Location-Centric Tracking

• Closest point of approach (CPA) measurements
• Target detection causes cell formation
• Cells formed around the targets estimated
  location
• Intended to include relevant sensors
• Manager is selected
• Node with greatest signal strength
• Manager collects local CPAs
• Linear regression over CPA
• node locations

53
Location-Centric-Tracking

• Estimated location compared to prior tracks
• Projections from candidate tracks
• Cell created for track in new area
• Size is a function of target velocity
• Track information propagated to cell
• Tracking repeats

54
Location-Centric Advantages
Avoids combinatorial explosion of track
association Centralized n targets, n candidate
locations n2 Distributed 1 target, n candidate
locations n Reduces communication costs
(multi-hop ad hoc) Saves energy
55
Results
No Filtering Kalman Lateral Inhibition
RMS Comm 18.1 14,512 (?) 8.9 254,552 11.3 21,792
56
Organization-based Tracking

• Fixed doppler radars
• Requires multiple, coordinated measurements
• Multiple targets
• Shared 8-channel RF communication

57
Sensor Characteristics
Hardware Fixed location, orientation Three 120
radar heads Agent controller Doppler
radar Amplitude and frequency data One
(asynchronous) measurement at a time
58
Scaling Issues

• Information retrieval
• Sensor locations, related target information
• Task assignment
• Scan scheduling, tracking
• Conflict propagation
• Competition for sensor time
• How far must information travel?
• How to obtain data from many sources?
• How to cope with large quantities of data?

59
Organizational Control

• Use organization to address scaling issues
• Environment is partitioned
• Constrains information propagation
• Reduces information load
• Exploits locality
• Agents take on one or more roles
• Limits sources of information
• Facilitates data retrieval
• Other techniques also built into negotiation
  protocol and individual role behaviors

60
Organization Overview
61
Typical Node Layout

• Nodes are arranged or scattered, and have varied
  orientations.
• One agent is assigned to each node.

62
Partitioning of Nodes

• The environment is first partitioned into
  sectors.
• Sector managers are then assigned.

63
Competition for Sensor Agents

• Sector members send their capabilities to their
  managers.
• Each manager then generates and disseminates a
  scan schedule.

64
Track Manager Selection

• Nodes in the scan schedule perform scanning
  actions.
• Detections reported to manager, and a track
  manager selected.

65
Managing Conflicted Resources

• Track manager discovers and coordinates with
  tracking nodes.
• New tracking tasks may conflict with existing
  tasks at the node.

66
Data Fusion (Track Generation)

• Tracking data sent to an agent which performs the
  fusion.
• Results sent back to track manager for path
  prediction.

67
Communication Protocols
gt 20 message types currently in use Results,
sector management, track management, target
detection, negotiation, directory services,
reliable messaging, etc.
(results from a typical three minute, two target,
eight node scenario)
68
Protocol Usage Map
Protocols
DrA
DrQ
DrR
TB
RR
TD
PTC
RB
PC
DA
TBU
ES
69
Sector Size
This one parameter affects many things Sector
manager load Smaller sector smaller manager
directory Larger sector better sector
coverage Track manager actions Smaller sector
fewer update messages Larger sector fewer
directory queries Communication distance, agent
activity, RMS error, message type
counts Empirical evaluation of varying this
parameter
70
Experimental Setup
Radsim simulator 36 sensors 1-36 equal sized
sectors 4 mobile targets 10 runs per
configuration Hypothesis sector size of 6-10
agents is best
71
Communication Characteristics
Larger sectors with more agents leads to less
messaging overall Less tracking control Fewer
directory queries More sectors to query More
tracking data
72
Load Disparity
Large sectors increase SM comm. load More
messages to handle Greater disparity - SM is a
hotspot Greater disparity in activity
load Average action totals are constant
73
Domain Metrics
Communication distance increases with larger
sectors Track migration triggered by
boundaries but better RMS error More
measurements due to lower control overhead
74
Whats Best?
Find inflection point in graphs
intersection Empirical evidence supports sector
size from 5-10 sensors
This would vary, depending on sensor and
environmental characteristics
75
What we have learned from this case study?

• Scaling motivates in-network processing
• The large number of nodes is not a trouble maker,
  but a blessing --gt exploit it!
• Hierarchical structure is useful to address
  scaling
• Location-based design is a useful approach!
• There are a lot of tradeoffs in different
  performance metrics!
• Demonstrated via parameter tuning
• Select one based on your application scenario

76
Summary

• Applications are as good as your creativity
• I may not be an expert on it
• There are no magic solutions that work in all
  cases
• Application-dependent/specific solution is the
  way to go
• Tradeoff between different factors!
• Which factor is more important depends on your
  application requirements!
• Some care more about energy
• Some care more about data quality (no lost data)
• Some care more about latency