CS294-1 Deeply Embedded Networks Emerging Standards and Course Perspective

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

2. Number Crunching Data Storage Mainframe Minicomputer productivity interactive Workstation PC Laptop PDA New Class of Computing log (people per computer) streaming information to/from physical world year

3. 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 CENS.ucla.edu

4. 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

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

6. A Systems View • Desire for decomposition • Modularity, Optimization, Predictability • Interactions Across Layers / Components • Constraints • Information availability • Control • Performance Characteristics

7. 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 • Cluster Formation

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

9. 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 ???

10. 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

11. Events and Buffering • Retain buffer swap • Start/End ptr across layers to allow encapsulation

12. S S S S M M M M 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?

13. 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

14. 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

15. Energy Usage • Radio off => rediscover • 10-30 sec to discover Mica Worst case

16. 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

17. 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

18. 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

19. 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

20. 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

21. 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.

22. 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

23. 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

24. 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?

25. Thanks • Projects Friday Dec 5, 2 pm, 6th floor Soda