CS294-1 Deeply Embedded Networks
Emerging Standards and Course
Perspective
David Culler
University of California, Berkeley
12/2/03

Mainframe
Minicomputer
Workstation
PC
Laptop
PDA year
12/2/03
Number Crunching
Data Storage productivity interactive streaming information to/from physical world

Example uses
• Env. Monitoring, Conservation biology, ...
– Precision agriculture, land conservation, ...
– built environment comfort & efficiency ...
– alarms, security, surveillance, treaty verification ...
• Civil Engineering: structures response
– condition-based maintenance
– disaster management
– urban terrain mapping & monitoring
• Interactive Environments
– context aware computing, non-verbal communication
– handicap assistance
» home/elder care
» asset tracking
• Integrated robotics
12/2/03
CENS.ucla.edu

Typical Characteristics
• # nodes >> # people
• sensor/actuator data stream
• unattended
• inaccessible
• prolonged deployment
• energy constrained
• operate in aggregate
• in-network processing is necessary
• what they do changes over time
=> must be self-organized, self-maintaining and programmed in situ to operate at very low duty cycle
12/2/03

The System Challenge
Monitoring & Managing Spaces and Things applications data mgmt service network system architecture
MEMS sensing
Comm.
Proc
Store technology uRobots actuate
Power
12/2/03
Miniature, low-power connections to the physical world

A Systems View
• Desire for decomposition
– Modularity, Optimization, Predictability
• Interactions Across Layers / Components
– Constraints
– Information availability
– Control
– Performance Characteristics
12/2/03

Where Have We Been?
• Application-Driven Network Architecture
• Emergence of Wireless Sensor/Effector Nodes
• Operating Systems for DENs
• Low-power MAC, discovery, topology formation
• Tools for analysis
• Broadcast / Data dissemination
• Design Lessons (Lew Girod, Dave Hughes)
• Aggregation and in-network processing (Sam)
• Multihop Routing for Data Collection (Alec)
• Time Synchronization
• Ad Hoc Routing
12/2/03
• Cluster Formation

Where We’ve been (cont)
• Directed Diffusion
• Localization
• Collaborative Signal Processing (Feng Zhao)
• Tracking
• Multi-resolution Storage
• Distributed Control
• Coverage
• Security
• Privacy
• Emerging Standards
12/2/03

Impact of radio design?
• Bluetooth ?
• IEEE 802.15.4 ?
• Bluetooth and Sensor Networks: A Reality Check
– Designed as cable replacement
– Connection oriented, frequency hopping
– Narrow interface
– TDM - master/slave(7) piconet
– ScatterNet ???
12/2/03

Fresh Look at BlueTooth
• Fixed MAC
• Similar event-driven
• Discovery and connection mgmt below HCI
– Master: inquiry
– Slave: inquiry scan
• Pre-established connection above
• Build self-assembly out of connection ???
• Timing and pwr mgmt invisible to appln
– App adapts to radio, not reverse
• Very small stack
– 10% of Bluetooth
– 3 KB for UART HCI
–
MAC in HW
12/2/03

Events and Buffering
• Retain buffer swap
• Start/End ptr across layers to allow encapsulation
12/2/03

Multihop Topology Formation
• Two radios per node
– Master (connects to children)
– Slave (connects to parent)
• Grow Tree as very slow flood
– Turn on slave and look for master
– If success, turn on M and allow children
• Backtrack on fail
– Try alternating parent
– 3 connect-fail on node with 7 children
» Disconnect child
» On disconnect, disconnect all children
– Convergence???
– Maintenance over time?
• How well connected can network be?
S
M
M
S
M
S
M
S
12/2/03

In-Network Processing
• Query Graph subset of radio graph
• Devices can negotiate “sniff mode”
– App has no control over timing
• App adapts to TDM
– Pipelines query processing across epochs
– Cannot go into deep sleep
• No rate adaptation to contention
• No snooping
12/2/03

Throughput & Power
• Small fraction of peak
• 5x ChipCon & RFM
• Similar uJ/bit
• High Power
– 30 mW radio on
– 39 mW inquirable
– 89 mW waiting for conn
– 136 mW maintain conn
– 200 mW @ 6 KB/s
• Sniff save 5 mW
12/2/03

Energy Usage
• Radio off => rediscover
• 10-30 sec to discover
12/2/03
Mica
Worst case

Closing Observations
• Scatter nets still not supported
• Certification
• Applns denied relevant information
• Connection maintenance expensive
• Sniff not much value
• Perhaps this all changes with “single chip” version
– MCU shared with application
12/2/03

What about 802.15.4?
• Sensor nets at least a secondary goal
– Game controllers primary
• Direct Sequence Spread Spectrum
– instead of freq. Hop (O-QPSK)
• Phy & MAC separate from network (Zigbee)
• Simple, controllable MAC
• Attention to low duty-cycle devices
• 0-104 byte packets
12/2/03

Lessons about Methodology
• Emerging area, so not just X improvement over established basis
• Reaching beyond current technology
• Define method of evaluation along with new idea
• Still, some classic pitfalls to avoid
12/2/03

1. Compare to a Weak Strawman
• My fancy routing protocol is 40% better than all nodes flooding (when there is only one or two “communications” going on at a time).
• My fancy scheduling algorithm uses half the energy of naively burning full time (when there may be simple ways of reducing energy cost of most prevalent state).
• This piece of steel is a million times stronger than that wet noodle .
• Weak strawthings are for negative results
– This piece of lasagna is ONLY 40 stronger than that wet noodle
– If it is all you’ve got, estimate optimal so you can see the spread
12/2/03

12/2/03
2. Change many parameters at once and claim the one that you have been talking about accounts for the improvement
• My adaptive clustering protocol (which happens to also compress n values to 1 at each hop) is 40% better than tree-based routing (of all the data).
• Patterson refers to this as the Computer Science Method

3. Design for a different load point and compare where yours is intended
• My new protocol (designed for short messages) is 40% better then theirs (designed for long messages) on short messages.
• My scheduling algorithm (designed for high contention) is
40% better than theirs (designed for moderate contention) on …
• Also good to never show simple options that perform almost as well as your really complex thing, because that just confuses the reader.
12/2/03

4. Do very narrow empirical assessment and extrapolate through simulation, neglecting the impact of more general setting
• Measure range error for particular pair of nodes in direct alignment and use for many pairs of nodes in arbitrary orientation
12/2/03

Small Technology, Broad Agenda
• Social factors
– security, privacy, information sharing
• Applications
– long lived, self-maintaining, dense instrumentation of previously unobservable phenomena
– interacting with a computational environment
•
Programming the Ensemble
– describe global behavior, synthesis local rules that have correct, predictable global behavior
•
Distributed services
– localization, time synchronization, resilient aggregation
• Networking
– self-organizing multihop, resilient, energy efficient routing
– despite limited storage and tremendous noise
• Operating system
– extensive resource-constrained concurrency, modularity
– framework for defining boundaries
• Architecture
– rich interfaces and simple primitives allowing cross-layer optimization
• Components
– low-power processor, ADC, radio, communication, encryption, sensors, batteries
12/2/03

Larger Questions
• What is the energy required to maintain a distributed data structure (e.g, routing tree, connectivity graph) to a certain level of precision?
• What are sufficient conditions on local rules to assure globally predictable behavior?
• What are the scalability limits and how are they influenced by hierarchy, connectivity, storage?
12/2/03

Thanks
• Projects Friday Dec 5, 2 pm, 6th floor Soda
12/2/03