Networks
ICS Sensor 203A Crista Lopes
Outline
RFID systems Sensor networks
Testbeds and protocols Architectures and Network Programming Operating Systems and In-network Processing
RFID
Applications
Supply-chain global tracking Localized tracking Routing in conveyer belts Security
Bar Codes vs. RFID
tag, backed by data processing system tag, backed by massive data processing system no line-of-sight reprogrammable non-zero cost
(target price: 10 cents)
line-of-sight immutable info zero cost ()
more dynamic tracking
System architectures
[Wireless] Sensor Networks
Applications
Industrial control and monitoring
lighting, a/c, machinery
Environmental monitoring
fire, pollution, wild life, agriculture, etc.
Health monitoring Traffic monitoring and control Building structures monitoring Asset tracking and supply chain mngmt Security and military sensing
Testbeds & Protocols
SensorNet Architectures For Indoor Location Detection
David Starobinski Ioannis Paschalidis Ari Trachtenberg Boston University
NSF NOSS Meeting Colorado School of Mines 10/18/2004
Indoor Location Detection: An Enabling Technology
Smart homes and offices Tracking personnel and equipment (e.g., in hospitals) Assisting visibly impaired population Disaster recovery
Indoor Location Detection: Technical Challenges
Most approaches use signal landscape mapping Problem: signal landscape highly varying in both time and space:
Multi-path fading Long-term dependencies (e.g., doors opening and closing)
Research Thrusts
1. Robustness
Provide resiliency to sensor failures and signal changes Theory of information and identification codes
2. Optimization
Determine optimal sensors placement and activation Theory of detection, large deviation, and non-linear programming
Testbed - Implementation
Outreach Activities: BU SensorNet Consortium
Liaison between academia and industry Foster collaboration and technology transfer Train and educate students
Web Information
Laboratory of Networking and Information Systems: http://nislab.bu.edu/ Center for Information and Systems Engineering: http://www.bu.edu/systems/
Communication Patterns for Collaborative Reasoning in Sensor Networks
Leonidas Guibas Sebastian Thrun Computer Science Stanford University
Co-optimization of Networking with Application-Specific Processing
Sensor Net Applications Network Stack
Communication Structure
Communication patterns in a sensor network are shaped by
the structure of the physical phenomena being monitored the task to be accomplished the nature of errors and uncertainty in the measurements the state of the sensor nodes themselves (energy reserves, etc.)
Communication Patterns For Generic Tasks
A. Going from limited local information to global understanding
Qualitative understanding of sensor layouts, signal landscapes, etc.
Algebraic Topology, Data Analysis and Mining, Shape Spaces Henri Poincare
B. Distributed lightweight probabilistic reasoning
Integration of evidence from multiple sources maintenance of multiple hypotheses
Bayesian Estimation, Decision Theory, Probabilistic Learning Thomas Bayes
A1. Understanding the Sensor Field Layout a landmark
An understanding of the topology of the field layout can be essential for many tasks in the network, from routing to information discovery and the proper integration of evidence. This topological information may be derivable from local connectivity data among the nodes and not require expensive geometric operations, such as node localization. Such lightweight global analysis techniques can be both very efficient and very robust. The combinatorial Delaunay complex
The geodesic Voronoi diagram
A2. Understanding Signal Landscapes
We may want to qualitatively understand sampled signal landscapes, to gain a deeper understanding of the phenomena being monitored, be they forest fires or moving vehicles. The qualitative features of the landscape determine how we might go about planning escape routes from the fire or forming sensor collaboration groups to track the vehicles. Since noise will be invariably present in the data, we must develop methods that can focus on the essential features of the landscape and not be sidetracked by irrelevant distractions.
A3. Creating a Society of Nodes
To perform its tasks, a sensor network needs to organize itself in various ways. Certain nodes may have to assume specialized functions and become clustereheads or gateways. Nodes need to form `districts and `towns, providing higher-level named abstractions for applications to use information highways have to be built and brokerage services established to link information providers and information seekers.
A double ruling derived via a Morse function distance to boundary
General Approach
1. Use lightweight information, such as direct node connectivity, to extract the overall structure of the sensor field 2. Enable `geometric operations and predicates, such as geographic routing, even though no explicit geometry is known 3. Organize nodes according to their sensed data into collaboration groups 4. Provide ways for information providers and seekers to meet 5. Build natural information highways
Advantages of Topological Methods
Can naturally extract global knowledge from local information Many topological algorithms can easily be implemented in a distributed fashion Topological persistence and other techniques can provide information filters for suppressing noise features
B1. Integration of Evidence
Energy conservation argues for innetwork information aggregation The aggregation of probabilistic information is tricky. In order to avoid overcounting the same evidence multiple times, information about where information originates and how it is routed must be maintained Current loopy belief propagation methods are too expensive for direct implementation on sensor networks
B2. Distributed Identity Management
The identities of tracked vehicles can become confused when they pass near each other That confusion may persist even after they separate and the identity ambiguity must be maintained in the network Sensor data later on may disambiguate one of the vehicles The network must also disambiguate the other ... ?
?
Mixing
Action at a distance?
Sensor confirms tank
General Approach
1. User poses query, plus a cost-forinformation ratio 2. System propagates query through sensor net (decentralized message propagation) 3. Sensor nodes respond with data 4. Internal nodes integrate uncertain information with Bayesian techniques 5. Result communicated back to user
Advantages of Bayesian Reasoning
Can resolve `inconsistent information Can provide a measure of uncertainty Can reason with partial/incomplete information Can be entirely decentralized (e.g., loopy belief propagation)
Advantages of Decision Theory
Enables user to specify importance of information Provides natural `pruning technique
for avoiding flooding a network with lowpriority queries for terminating probabilistic inference prematurely
Project Summary
Qualitative understanding of signal landscapes and sensor layouts Lightweight distributed probabilistic reasoning A test-bed implementation within a university building
The End
Another kind of sensor network exhibiting distributed reasoning based on local interactions ...
Funneling Impulses in Sensor Networks
PIs: P. Jelenkovic, N. Maxemchuk, V. Misra, D. Rubenstein RA: P. Cheung Columbia University
Differences
1) 2) 3) 4) Sensor Network Impulse of arrivals Many sources to few sinks (funnel) Compression in Network Hostile Environment Conventional 1) Uncorrelated arrivals 2) Many sources to many sinks 3) .Preserves Data
Projects
Impulse in a funnel: PCF rather than DCF Scheduling Funnel: Density of sensors to extend network lifetime Compression: Generic and Application Specific Hostile environment: Persistence of data waiting to be forwarded Multipath routing
Approach
Develop Mathematical Model of Sensor Networks Test the models by simulation Use data from real applications in the simulations
Experimental Applications
1. Predict the spread of a fire With FDNY using NIST Model 2. Early warning for shock waves from an earthquake (few seconds ) With Lamont-Doherty Earth Observatory 3. Spread of biological contaminants or poison gas With Mechanical Engineering Dept.
Compression Model
1. 2. 1. 2. Physical Event is a 4-D Bandwidth limited signal 2 types of frames - like MPEG Full information Differential information 2 phases per frame Push: Low sequency components - generic Pull: Additional Components from specific locations - Application specific
Compression Technique
1. Interpolate Non-uniform samples to obtain uniform samples 2. Form and Forward low sequency components in a frame 3. Request additional components in specific locations Difference between picture compression and fire readings
Temperature Thresholds in a Frame
Sensor Networks for Undersea Seismic Experimentation (SNUSE)
PI: John Heidemann Co-PIs: Wei Ye, Jack Wills Information Sciences Institute University of Southern California
Why Undersea Sensor Networks?
Vision: to reveal previously unobservable phenomena (Pottie) Goal: to expand senor-net technology to undersea applications Numerous potential applications
Oilfields: seismic imaging of reservoir Environmental: pollution monitoring Biology: fish or micro-organism tracking Geology: undersea earthquake study Military: undersea surveillance
Our Focus Application
Seismic imaging for undersea oilfields
Collaborate with USCs ChevronTexaco Center for Interactive Smart Oilfield Technologies (CiSoft)
Current technology
High cost Perform rarely, about once every 1-3 years
Photo courtesy Institute of Petroleum
Our Approach: Undersea Sensor Nets
Dense sensor networks are largely changing terrestrial sensing today Bring the concept to undersea environment
Enable low-cost, frequent operation Radio Platform Radio Buoys Exploit dense sensors, close observation Buoys
Acoustic
Acoustic
Current Undersea Networking
Sparse networks, small number of nodes, longrange acoustic communication
Navy Spawar (Rice): Seaweb network ~20 nodes Woods hole & MIT (Stojanovic) Northeastern Univ. (Proakis) Navy Postgraduate School (Xie)
Cable networks: high speed, high cost
Neptune Network (Several Universities led by Univ. of Washington)
3000km fiber-optic/power cables; $250 million in 5 years
Instead we focus on low-cost, wireless and dense networks
Our Research: Acoustic Communication
Water significantly absorbs radio waves Existing work on acoustic comm.
Focus on reliability and bandwidth utilization (push to higher bit rates) COTS acoustic modems are long range (190km), power hungry and costly
Our focus is to develop short-range (50500m), low power (similar to Mica2 radio), low-rate (10kbps), and low cost acoustic comm. hardware
Our Research: Networking Protocols
Large and varying propagation delay breaks/degrades many existing protocols
Sound is over 5 magnitude slower than radio Time sync, localization, MAC protocols
Will investigate time-sync and localization algorithms that takes the propagation delay into account Will investigate efficient MAC protocols suitable for large latency
Long-Term Energy Management Application only runs once a month
Nodes sleep for a month to conserve energy Will investigate new energy management schemes for long sleep time
Inspired by work at Intel Portland
Delay tolerant data transport
Large sensor data and low-bandwidth acoustic comm. Will investigate suitable DTN techniques
Delay tolerant networking research group (dtnrg.org)
Summary
Project goal: expanding sensor-network technology to undersea applications Research directions
Hardware for low-power, short-range acoustic communications Networking protocols and algorithms suitable for long propagation delay Long term energy management
Project website http://www.isi.edu/ilense/snuse
Exploring the Design Space of Sensor Networks Using Route-aware MAC Protocols
Injong Rhee and Bob Fornaro
Department of Computer Science North Carolina State University
Motivation and Goal
NewMACschemes ExistingSensorMAC Protocols
Expanding design space
Under extremely low energy budget
Testbed: Wildlife tracking
Endangered animals in NC (Red wolves, black bears, etc.) Current telemetry techniques are not adequate. Sensor networks can improve monitoring of these animals Our teams have been working with wildlife biologists and NC zoology association on this project.
Design choices :
Existing approaches
SMAC: Tradeoff (couplingof Throughputand Responsetime)
TDMA: Goodservice Mediumenergy
802.11 Good service Highenergy
Our approach: Route-aware MAC (RASMAC)
SINK
On-demand routing paradigm (Directed diffusion, SPIN, etc) Route-awareness: the MAC layer of a node knows whether it is on a currently active routing path or not.
If not on such a path, it switches off its radio. Reduce idle listening
16 14 12 10 8 6 4 2 0
Power consumption of node subsystems
Power (mW)
Route-aware MAC (RASMAC)
If off, how does it know of a new active path?
Software: Periodic synchronization Hardware: passive radio-powered trigger Decoupling of throughput and response time.
Periodic synchronization
Response time
Wake-up time duration (or frequency) while on active paths
Throughput
Performance results:
Route-aware MACs
RATDMA: Extremelylow Energybudget RASMAC: Lowenergy budget Existing MAC
c
Architecture and Programming
Creating an Architecture for Wireless Sensor Networks in a nutshell
David Culler, Scott Shenker, Ion Stoica
Electrical Engineering and Computer Sciences University of California, Berkeley NETS/NOSS Infosession
Sensor Network Networking Today
Appln Transport Routing Scheduling Topology Link Phy EnviroTrack TinyDB Regions FTSP Dir.Diffusion SPIN TTDD Deluge Trickle Drip MMRP TORA Ascent Arrive MintRoute CGSR AODVDSR GPSR ARA GSR GRAD DBF DSDV TBRPF Resynch SPAN GAF FPS ReORg PC Yao SMAC WooMac PAMAS BMAC TMAC WiseMAC Pico Hood Bluetooth RadioMetrix RFM CC1000 eyes
802.15.4
nordic
The Internet Architecture
End-to-end flows
application transport
Pt-to-pt dominantly Many applications sharing the network
network
IP link
physical
Over best effort packet delivery service Opaque, universal routing service Agnostic to physical link and application characteristics Radical simplification of a really hard problem
Efficiency cost Quality cost
What role a sensor net architecture?
Env. Monitoring Structures Detection/Alarm Tracking Active Environments Distr. Control
Wide range of long-lived applications Diverse, constrained, evolving resources
Low duty cycle Small tables Loss, noise & change
Embedded in & adapting to phy. env. In-network processing, not E2E Highly application specific WSN needs a narrow waist Few applications over many nodes
Emerging view of sensor networking
Applications Compose what they need
Tracking Application Sensing Application
Multiple Network Layer Protocols
Pt-Pt Routing 1-1
Neighborhood Sharing 1-k / k-1
Aggregatio n N --- 1
Data Collection N-1
Robust Dissemination 1-N
Rich Common Link Interface (SP)
Multiple Link and Physical Layers
BlueTooth
CC1000
???
IEEE 802.15.4
infneon
***
Six Aspects of a Sensor Network Arch. Design Principles
Guidelines and constraints, what functionality, what state To what are we agnostic
Functional Architecture
Logical building blocks/protocols, interfaces, interconnections, interdependencies
Programming Architecture
API/ISA what logical data types and operations are expressible
Protocol Architecture
Distributed algorithms to provide each component service, defn. of the information exchanged between instances Most existing work is of this form
System Support Architecture
Capabilities of the node to support the network arch.
Physical Architecture
Set of nodes, interconnects, communication fabrics upon which network is constructed
Areas of Work
Physical Architecture
Multitier, non-homogeneous (patches, transit, internet) SNA should not require unconstrained nodes Should utilize unconstrained nodes to reduce burden on constrained ones Mobility within physically embedded context
Programming Architecture
SNA will define consistent interfaces that encompass seven communication abstractions underlying range of programming models 1. Dissemination 2. Collection 3. Aggregation 4. Localized Neighborhood 5. Point-to-point 6. Data-centric storage 7. Attribute-based routing
Functional Architecture Protocol Architecture System Support Architecture Design Principles
Physical Architecture Programming Architecture Functional Architecture
Areas of Work (2)
Thin-waist as expressive interface to best-effort 1-hop broadcast - SP implement over a range of links, utilize by a range of network protocols Higher level optimization within control & info exposed by SP
Protocol Architecture address-free protocols over SP, focusing on general, yet efficient
techniques for defining forwarding predicate and reusable mech. For duplicate detection, suppression, and transmission scheduling Name based: simple set of primitives at SP layer that allow network layer services to dictate and use naming Discovery, schemes
formation, maintenance, forwarding Application-independent portions support sharing of partner networks
In-network storage: provide soft-state abstraction as building-block
for variety of address-free and name-based network protocols active in-network storage: identify minimalist actions that are flexible enough to higher levels to express meaningful predicates and queries
System Support Architecture Design Principles
Physical Architecture Programming Architecture Functional Architecture Protocol Architecture
Areas of Work (3)
Key cross-layer issues: discovery, time coordination, power management, network management security Focus on cooperative interfaces
System Support Architecture
SNA independent of particular OS, but implemented on one
extend TinyOS to better support SNA processing
Encapsulation, Buffer management, Robustness, Scheduling
Design Principles
Initial set guide the SP approach Refined through the process
Push-and-pull
Goal: Open, Interactive Community Process
Actively pull in components developed by the community Actively push out the framework Interactive dialog on both
Community Workshops early and often
First one ~march 04
Initial framework for feedback on direction Establish key collaboration participants in sub-areas
Annual follow-ons
Winnowing process for interfaces, components
Experience, feedback, planning, prioritize, next steps
Network stack(s) openly available to entire program at all times
On testbeds as they emerge
Series of course materials
Intend to be shared and circulated
Lightweight and Flexible Sensor Network Management
Kang G. Shin and Daniel L. Kiskis Real-time Computing Laboratory EECS Department The University of Michigan
Our Key Motivations
Self-organization in sensor networks
Essential for large-scale, unattended deployment Required for evolving over time It is pervasive
Across scales Across services
Better software engineering needed
Build or buy/borrow Large number of home-grown components Composing and configuring a system is difficult
Incompatibility Hidden architectural assumptions Redundancy
Resource constraints
Approach
Take management-centric view of selforganization
Common management functions
Start/stop service Query and modify parameters Signal events Invoke functions
Common management information
Objects Attributes Parameter and event types
Derive management models
Approach, contd
Develop network service management infrastructure
Encapsulate common management functionality Standardize management information Management protocols
Evolve and evaluate through core services
Routing Hierarchical cluster management Network bootstrapping
AgletBus Architecture
Implementation and Evaluation
Sensor network testbed
Mica and Mica2 Motes TinyOS and NesC iMotes and Stargates Parallel monitoring for debugging and evaluation
Simulation
TOSSIM NS-2
Expected Results
Management models for sensor networks Network management infrastructure
Management software components
Lightweight, robust, and flexible Shared code base for inter-node communication
Common interfaces
Benefits
Consistent, standardized management functions Reduced code footprint Improved software reliability
End
Real-Time Computing Laboratory http://kabru.eecs.umich.edu/
Sensor Coordination using Active Dataspaces
Steven Cheung NSF NOSS Informational Meeting October 18, 2004
Why sensor network programming hard?
Deploying new or additional sensors Limited CPU power and memory Scalability Locality Sensor nodes
Applications Intermittent end-to-end connectivity Hibernation Attacks
Data aggregation
Need: High-level programming abstraction
Applications Focus of this project Optimizing CPU & memory use Aggregation Security Scalability Locality
Naming Deploying new or additional sensors Intermittent end-to-end connectivity Hibernation
Sensor nodes
Our Approach: Active dataspace (ADS)
ADS is an active data repository that provides associative operations for data access Inspired by the tuple space model [Gelernter 85], developed for parallel computing Every data tuple (or record) contains a list of fields Basic TS operations:
in is used to remove tuples from TS rd to read tuples out to create data tuples eval to create active tuples
Features of ADS
Data-centric model Time-uncoupling: Data consumers and producers do not need to be active at the same time Identity-uncoupling: Endpoints do not need to know each others identities Stable network paths between endpoints need not exist Virtual tuples support data generation on demand Tuple set operator and cardinality constraint to facilitate in-network aggregation Search constraint for specifying the scope and preferences for tuple selection to exploit locality
Expected results
High-level programming model and language to ease sensor network programming for a wide range of application domains Architecture and techniques to implement a resource-efficient, adaptive, and trustworthy ADS system Evaluation studies using a prototype ADS implementation
High-Level, Efficient Sensor Network Programming
NOSS Informational Meeting October 18, 2004
Eddie Kohler UCLA
Cross-Service Concerns
Two sampling modalities, two sampling periods
Light ( ) and temperature ( )
time
Result: interference and inefficiency
Reduce sleep time, data aggregation Small changes to periods can reduce costs
Sampling periods a cross-service concern
Each component must be aware of the others Does this prevent efficient application-level component libraries?
Programming Languages for Sensors
Use a programming language to solve this programming problem Goal: Smart sensor network service libraries System designers build parameterized libraries
Examples: temperature sensing, sensor value smoothing, routing tree formation, link quality estimation, query processing, More flexible application components than conventional nesC
Scientists plug libraries together to build applications
The libraries weave themselves into an efficient program
Sensor Network Application Construction Kit
Language
Transitive path connections let independent services create a shared message path: MsgSrc ..> TreeDispatch ..> Network Partially constrained parameters address cross-service issues: TimerM(period >= 20)
Compiler
Expands a SNACK program and weaves together the results Shares components as much as possible
Component and service library
Components work effectively with the SNACK language Parameters, path connections, dynamic memory, packet format, Services can build real applications
SNACK Expansion (1)
Application Specification
Tree Dispatch Light Sampler Tree Dispatch Temp Sampler
Sample light and temperature, send both up a routing tree
LightSampler -> [collect::Put16] TreeDispatch; TempSampler -> [collect::Put16] TreeDispatch;
Pretty simple!
SNACK Expansion (2)
Partial Expansion: Dispatch
Tree Dispatch Service Msg Sink Msg Src Null Forward Tree Service Dispatch Network Light Sampler Time Src Light Sense Time Sink Tree Dispatch Service Temperature Sampler Time Src Msg Sink Msg Src Dispatch Network Temp Sense Time Sink
Null Forward Tree Service
The components came from a user-defined service library
Easy to understand and change
Compiler expands the services one step
SNACK Expansion (3)
Further Expansion: Tree and Link Estimator
Tree Dispatch Service Msg Sink Msg Src Null Forward Dispatch Network Tree Service Msg Sink Msg Src Tree Link Estimator Network Link Estimator Msg Sink Msg Src Link Estimator Network Light Sampler Time Src Light Sense Time Sink Tree Dispatch Service Temperature Sampler Time Src Msg Sink Msg Src Dispatch Network Tree Service Msg Sink Msg Src Tree Link Estimator Network Link Estimator Msg Sink Msg Src Link Estimator Network Temp Sense Time Sink
Null Forward
then all the way
SNACK Expansion (4)
Post Compilation: Merged Services
Msg Sink Msg Src Null Forward 1 Null Forward 2 Dispatch 1 Dispatch 2 Tree Link Estimator Network Time Src Temp Sense Light Sense Time Sink
then contracts to a minimal, efficient program!
Conclusion
SNACK an important step in mote programming practice
Readable Reusable libraries Efficient, too
Next steps
More real applications (ESS) Non-mote platforms Heterogenous deployments Multi-program systems
Operating Systems and In-network Processing
Ultra Low-Power, SelfConfiguring, Wireless Sensor Networks
Steve Wicker School of Electrical and Computer Engineering Cornell University
Our Network Model: Numerous, Cheap, and Small
Large numbers of small, low power sensors distributed (randomly) across coverage area Exploit redundancy Adaptive link and networking technologies Distributed processing, reporting tools
Berkeley Dust Mote
Wadsworth/Cornell Biosensor
Research Team: 2004 NSF Nets_NOSS
Software Tools Goal: Development of platform technologies for low-power sensor networks. Cross-Disciplinary team
ECE - Wicker, Tong, Manohar CS - Birman, Sirer
MagnetOS Self-Configuration
Approach:
Tie operating system and lowpower processor technologies to self-configuring network theme Develop extensive testbed for testing and demonstrating technologies
MAC Low-Power Processor
Platform Technologies: SNAP Asynchronous Processor (Manohar, ECE)
Clockless logic
Spurious signal transitions (wasted power) eliminated Hardware only active if it is used for the computation
Processor Atmel StrongARM MiniMIPS Amulet3i 80C51 (P) Lutonium SNAP
Bus 8 32 32 32 8 8 16
Year 200? 200? 1998 2000 1998 2003 2003
E/op 1-4 nJ 1.9 nJ 2.3 nJ* 1.6 nJ* 1 nJ** 43 pJ 24 pJ
Ops/sec 4 MIPS 130 MIPS 22 MIPS 80 MIPS 4 MIPS 4 MIPS 28 MIPS
MIPS: highperformance
24pJ/ins and 28 MIPS @ 0.6V
Cornell Testbed Configuration
Network Self-Configuration Through Game Theory
Motivations: efficiency and scalability Efficiency - ability of market-based distributed control mechanisms to move complex networks toward optimal operating points. Scalability - distributed decision-making inherent in market settings.
Interaction and decisions are local, obviating the need for a global perspective (both memory and computationallyintensive).
Critical Tools: Equilibrium concepts, utility-based decision making, and bargaining.
Prisoners Dilemma
Two partners in a legal firm are caught...