CS 554 Introduction to Real-Time and Embedded Systems

Overview of Sensor Networks

Professor Kyoung Don Kang

Lecture 16October 24, 2006

Overview

• What is a sensor network?– Sensing– Micro-sensors– Constraints, Problems, and Design Goals

• Overview of Research Issues and Challenges

• I have borrowed liberally from other presentations

Sensing

Sensing

Remote In-situ

Networked Other…

Hardware

• Processor + Wireless Communication + Sensors (and Actuators)

• Mass production of miniature hardware

MICA2 Motes

Typical Node Hardware

Low PowerEmbeddedProcessor

Radio Transceiver

Memory

SensorsBattery

Limited Lifetime

8-bit, 10 MHzSlow Computations

1Kbps - 1Mbps, 3-100 Meters,

Lossy Transmissions

128KB-1MBLimited Storage

Expensive --Requires Supervision

A more detailed view

Enablers – Micro-Sensors

• Small (coin->matchbox->PDA range)• Limited resources

– Battery operated– Embedded processor (8-bit to PDA-class

processor)– Memory: Kbytes—Mbytes range– Radio: (Kbps – Mbps; often small range)– Storage (none to a few Mbits)

General Characteristics• Large-scale fine-grained heterogeneous sensing

– 100s to 1000s of nodes providing high resolution– Spaced a few feet to 10s of meters apart

• Collaborative– Each sensor has a limited view

• Spatially• In terms of sensed data type

• Distributed– Communication is expensive– Localized decisions and data fusion necessary

Wireless, Distributed Sensing

• Why Distributed Sensing?– Closer to phenomena– Improved opportunity for

LOS– 1/r4

• Why Wireless?– Ad hoc deployment– Remote locations

• Why Collaborative?– Battery operated– Communication much

more expensive than compute (will this always be true?)

– In network processing to reduce data size closer to source

Applications

Applications

• Many applications need real-time sensing (and control)!

• Interface between Physical and Digital Worlds – A great many applications

• Military– Target tracking/Reconnaissance– Weather prediction for operational planning– Battlefield monitoring

• Industry: industrial monitoring, fault-detection…• Civilian: traffic, homeland security, medical…• Scientific: eco-monitoring, seismic sensors, plume

tracking…

Applications

Habitat Monitoring: Great Duck Island

Habitat Monitoring: Redwood Trees

Sourece: David Culler’s Mobihoc 2005 Keynote

Structural Monitoring: Golden Gate Bridge

Medical Care: CodeBlue at Harvard

Cargo Tracking

Caveat…

• Not all sensor networks are this way

• Unclear whether really deeply embedded custom devices are the way to go (vs. something like a PDA)– Costly to design– Difficult to program and control– Cannot leverage the economy of scale advantage of

COTS related technology such as PDAs and flash memories

• Other scales possible: e.g., have a sensor network made of wired devices without so much of the power issues

Basic Terminology and Concepts

• Phenomenon: the physical entity being monitored

• Observer (aka sink, or base station): a collection point to which the sensor data is disseminated– Usually a relatively resource rich node– Sensors observer data relay sometimes called

reachback

• Sensor network provides discrete sampling of the phenomena in space and time

• Observer asks questions in terms of the phenomena – does not care about the infrastructure of the sensor network

Typical Scenario

DeployWake/Diagnosis

Self-Organize Disseminate

But others possible

• Sensors mobile or not?

• Phenomena discrete or continuous?

• Monitoring in real-time or for replay analysis?

• Dynamic queries vs. long term queries

Sensor Nets vs. Ad Hoc Nets• Greater number of nodes• Densely deployed• More failure-prone• Mobility?• Many-to-one, not point-to-point• Sensor node limitations: power,

computational capabilities, memory• Data driven: possibly no global

identification for sensor nodes

Challenges in Networked Sensing

• Energy is a design constraint for battery operated sensors– Network lifetime is a performance metric– Communication a major cost (1000:1 ratio to

computation)• Application objectives vs. available resources

– Control redundancy– Load balance– Aggregate data– Local situational awareness

Challenges (cont’d)• Data centric operation

– Challenges traditional network design and QoS

• Self-configuration

• Resilience to node failure and attacks

• Multidisciplinary• Effective network design requires application

understanding

• Physical world messier than what we’re used to

Protocol Stack

Alternative, more data-centric model

Protocol Stack: Physical Layer

• Frequency selection• Carrier frequency generation• Signal detection• Modulation

Responsible for:

Protocol Stack: Physical Layer

• Hardware cost– How do we get down to $1/node?

• Radio– Ultrawideband?

•Very low powered, short pulse radio spread over several GHz

•40Mbps ~ 600Mbps

Issues:

Protocol Stack: Physical Layer

• Radio (Cont.)– Zigbee/IEEE 802.15.4

•2.4GHz radio band (= 802.11.b & Bluetooth)

•250Kbps•Up to 30 meters

– Pico radio•100Kbps•Limit power consumption to 100 uW

– Other? (infrared, passive elements …)

Protocol Stack: Data Link Layer

• The multiplexing of data streams• Data frame detection• Medium access • Error control• Encryption

Responsible for:

Data Link Layer: Medium Access Control

• Goals:– Creation of the network infrastructure– Fair and efficient sharing of communication resources

between sensor nodes• Existing solutions?

– Cellular - single hop network is impractical for sensor networks

– Ad hoc MACs (e.g., 802.11 or Bluetooth): Power conservation still not emphasized

– Scale– Data centric operation– Security is not considered!

• WEP for 802.11 is broken• Do we care about link layer security?

Data Link Layer: Medium Access Control

• Basic strategy: turn off radio transmitter when idle

• This can be ineffective due to startup costs• Dynamic power management schemes may

provide an answer• Error handling• Existing MAC protocls: S-MAC, B-MAC, Z-MAC,…

Power Savings:

Protocol Stack: Network Layer

• Power efficiency• Data-centric nodes• Data aggregation when

desired/possible• Attribute-based addressing and

location awareness

Design principles:

Minimum Energy Routing

• Maximum PA route• Minimum energy

route• Minimum hop

(MH) route• Maximum

minimum PA node route

Directed Diffusion

• Route based on attributes and interests

Protocol Stack: Network Layer

• Data-centric routing– Directed Diffusion– Data Aggregation

• Flooding• Gossiping/non-uniform dissemination• Sensor protocols for information via negotiation

(SPIN)• Sequential assignment routing (SAR)• Low-Energy Adaptive Clustering Hierarchy (LEACH)

Schemes:

Protocol Stack: Transport Layer

• End-to-end Reliability– Multi-hop retransmission– Congestion

• End-to-end security– Like SSL: authentication, encryption,

data integrity– Good? What about data aggregation?

Protocol Stack: Application Layer

• Sensor network management • Database queries

Other Issues

• Operating system – TinyOS– MANTIS OS– Smart Card OS

• Localization, Synchronization and Calibration• Aggregation/Data Fusion• Security

– Encryption– Authentication– Data Integrity– Availability – DOS attacks– Also, Non-repudiation and Authorization

Time and Space Problems

• Timing synchronization • Node Localization• Sensor Coverage

Time Synchronization• Time sync is critical at many layers in sensor

nets– Aggregation, localization, power control,

distributed DSP

Ref: based on slides by J. Elson

Sources of time synchronization error

• Send time– Kernel processing– Context switches– Transfer from host to NIC

• Access time– Specific to MAC protocol

• E.g. in Ethernet, sender must wait for clear channel

• Propagation time– Dominant factor in WANs

• Router-induced delays– Very small in LANs

• Receive time

• Common denominator: non-determinism

Conventional Approaches• GPS at every node (around 10ns accuracy)

– But• doesn’t work everywhere• cost, size, and energy issues

• NTP– some “primary time servers” are synchronized via GPS, atomic

clock etc.– pre-defined server hierarchy (stratums)– nodes synchronize with one of a pre-specified list of time servers– Problems:

• potentially long and varying paths to time-servers • delay and jitter due to MAC and store-and-forward relaying• discovery of time servers

– Perfectly acceptable for most cases• E.g. Internet (coarse grain synchronization)• Inefficient when fine-grain sync is required

– e.g. sensor net applications: localization, beamforming, TDMA etc

Limitations of What Exists

• Existing work is a critical building blockBUT…

• Energy– e.g., we can’t always be listening or using CPU!

• Wide range of requirements within a single app; no method optimal on all axes

• Cost and form factor: can disposable motes have GPS receivers, expensive oscillators? Completely changes the economics…

• Needs to be fully decentralized, infrastructure-free

Ref: based on slides by J. Elson

Localization

• Each node finding its position – why? – Data meaningless without context– Localization of targets and events– Geographical forwarding/addressing

• Why not just GPS at every node?– Large size and expensive– High power consumption– Works only outdoors with LOS to satellites– Overkill – often only relative position is

needed– Works only on earth :-)

What is Location?• Absolute position on geoid

– e.g. GPS• Location relative to fixed beacons

– e.g. LORAN• Location relative to a starting point

– e.g. inertial platforms• Most applications:

– location relative to other people or objects, whether moving or stationary, or the location within a building or an area

• Range and resolution of the position location needs to be proportionate to the scale of the objects being located

Localization Techniques

• Measure proximity to “landmarks”– e.g. near a basestation in a room– example systems:

• Olivetti’s Active Badge for indoor localization– infrared basestations in every room– localizes to a room as room walls act as barriers

• Most commercial RF ID Tag systems– strategically located tag readers

– improved localization if near more than one landmark• Estrin’s system for outdoor sensor networks

– grid of outdoor beaconing nodes with know position– position = centroid of nodes that can be heard

» # of periodic beacon packets received in a time interval exceeds a threshold

– a problem: not really location sensing• it really is proximity sensing• accuracy of location is a function of the density of

landmarks– Location accuracy = O(distance between landmarks)

Techniques for Location Sensing

• Measure direction of landmarks– Simple geometric relationships can be used to

determine the location by finding the intersections of the lines-of-position

– e.g. Radiolocation based on angle of arrival (AoA) measurements of beacon nodes (e.g. basestations)

• can be done using directive antennas or antenna arrays

• need at least two measurements

BS

BS

BS

MS

1

2

3

Techniques for Location Sensing • Measure distance to landmarks, or Ranging

– e.g. Radiolocation using signal-strength or time-of-flight• also done with optical and acoustic signals

– Distance via received signal strength• mathematical model that describes the path loss attenuation

with distance– each measurement gives a circle on which the MS must lie

• use pre-measured signal strength contours around fixed basestation (beacon) nodes

– can combat shadowing– location obtained by overlaying contours for each BS

– Distance via Time-of-arrival (ToA)• distance measured by the propagation time

– distance = time * c• each measurement gives a circle on which the MS must lie• active vs. passive

– active: receiver sends a signal that is bounced back so that the receiver know the round-trip time

– passive: receiver and transmitter are separate» time of signal transmission needs to be known

– N+1 BSs give N+1 distance measurements to locate in N dimensions

Radiolocation via ToA and RSSI

x1

x2

x3

d1

d3

d2

MS

BS

BS

BS

Many other issues

• What about errors? Collisions? No LOS?

• If sensors are mobile; when should we localize?

• Multi-hop localization?

Data Management Problems

• Observer interested in phenomena with certain tolerance accuracy, fidelity, freshness, delay

• Sensors sample the phenomena• Sensor Data Management

– Determining spatio-temporal sampling schedule

• Difficult to determine locally

– Data aggregation and fusion• Interaction with routing

– Network/Resource limitations• Congestion management• Load balancing• QoS/Realtime scheduling

phenomena

sensors

observer

Spatio-Temporal Sampling

• How often should a given sensor report?– Collected data should meet application goals at

reasonable load to the network– Data/event driven

• Locally difficult to determine appropriate sampling/reporting rate– Collaboration needed to improve local estimate

• How to express interests and translate into actions (sensor abstractions)

Data Aggregation and Fusion

• Related data from multiple sensors aggregated/fused– Reduces data size and overall load– Provides more comprehensive estimate of data

importance to manage sensors better

• Provide support for effective data fusion– Routing and MAC support– Sampling schedules should be coordinated– Tradeoff between data quality and resource

demand should be exposed to the application

Key design issues

• Extended lifetime• Responsiveness• Robustness• Synergy• Scalability• Heterogeneity• Self-configuration• Self-optimization and adaptation• Systematic design• Privacy and security

Questions?