David Culler, Eric Brewer, David Wagner, Shankar Sastry Univ. of California, Berkeley

1. EmBedded Systems Wireless Wireless OEPSecure Language-Based Adaptive Service Platform (SLAP) for Large-Scale Embedded Sensor Networks David Culler, Eric Brewer, David Wagner, Shankar Sastry Univ. of California, Berkeley

2. Administrative • Project Title: Secure Language-Based Adaptive Service Platform (SLAP) for Large-Scale Embedded Sensor Networks • PM: Vijay Raghavan • PI: David Culler, Eric Brewer, David Wagner, Shankar Sastry • PI phone # : 510-643-7572 • PI email: culler@cs.berkeley.edu • Institution: University of California, Berkeley • Contract #: F33615-01-C-1895 • AO number: • Award start date: 6/1/01 • Award end date: 10/31/04 • Agent name & organization: Juan Carbonell, AFRL/Rome

3. Subcontractors and Collaborators • Crossbow • manufactures & tests node and sensor boards • offers for sale beyond initial contract run • UCLA • development of networking algorithms, coordination services, testbed development • Intel Research • application studies, base-station support, ubicomp usage, language design • potential next generation design and manufacturing collaboration • Kestrel, UCI, Vanderbilt, Notre Dame, MIT, USC, U Wash., UIUC, UVA, Ohio State, Bosch, Rutgers, Dartmouth, GATECH, Xerox

4. Problem Description, Project Overview • Develop NEST platform research to dramaticallyaccelerate the development of algorithms, services, and their composition into applications • theory to practice at a very early stage, without each group developing extensive infrastructure • Critical barriers are scale, concurrency, complexity, and uncertainty. • Permit demonstration of fine-grain distributed control • Define series of challenge applications to drive the program components • Metric of success • rate of development of new algorithmic components & novel factors revealed through hands-on empirical use • degree of reuse of platform components • scale of integration across program • effectiveness of fine-grain dist. control on challenge P.E.G. • scale of use of NEST components in challenge app

5. Secure Language-Based Adaptive Service Platform for Large-scale Embedded Sensor Networks • Recent Progress • • Completed TinyOS 1.0 release • full nesC impl. + idl + Msg i/f generator • advance NW stack with link-level ack • ChipCon radio stack + crossbow mica-CC • TinySEC encryption and security • reliability-based, prob. routing • Scalable TOSSIM with nw model and GUI • Harsh longterm env. mon. deployment • Constraint-based localization calibration • TinyDB & nesl macroprogramming • 2nd spin mote-on-chip • stability anal. of MoteBot control • operational mid-term appln framework Wireless OEP David Culler, Eric Brewer, David Wagner Shankar Sastry UC Berkeley F33615-01-C-1895 Schedule lang based optimize & viz Impact • Enable creation of embedded distributed syst. of unprecedented scale and role • Enable new classes of applications integrated with physical world • Accelerate prototyping and evaluation of new coord. & synthesis algorithms • Drive NW sensor challenge applications log & trace adv. sim transition planning chal. app defn final prog. env FSM on OEP1 macro. lang design OEP1 defn OEP1 eval New Ideas • Small, flexible, low-cost, low-power, wireless embedded sensor devices with Tiny event-driven, robust, open OS • FSM high-concurrency prog. env. • Macroprogramming unstructured aggregates • Resilient aggregation & Adversarial Simulation June 02 Sept 02 Sept 03 Sept 04 End June 01 Start OEP2 proto OEP2 platform design OEP2 OEP2 analysis OEP1 10x100 kits OEP3 platform design chal app & evaluation midterm demo

6. Project Status • Robustified Platform - TinyOS1.0 • nesC language, whole pgm analysis, idl, refined all components, link-level acks, routing, documentation,network programming, race detection • Long term, outdoor deployment + many smaller • MidTerm tracker framework operational • TinySEC security supported (soon default) • Guided Crossbow on chipcon mica/dot • provided chipcon network stack, dot port • other companies mfr. mica variants (Intel CF, dig. sun) • TOSSIM prob. connectivity, whole applns, GUI • Preliminary macroprogramming approaches • New MotBots, motor board, control and analysis • Testing 1st mote-chip, fab’d 2nd • Challenge minitask, security minitask, transition planning

7. Platform HW Development • Mica => Crossbow dot, mica2 • chipcon radio, supported in UCB release • Other companies producing variants • intel, digital sun, Bosch, dust inc. • Prototyped new weatherboard with all digital sensors • New motor-control board for CotsBots

8. TinyOS 1.0 • Release finalized in Oct 02. • Based on nesC language and tools • Revised and tested every components • beta cycle & feedback with other groups • Documentation and tutorials • New NW stack with link-level acks • retransmission dictated by higher levels • Automatic msg class generator • Major rewrite of TOSSIM • Substantially reduced start-up and development time

9. NesC • Clean linguistic support for TinyOS concepts • components, cmds, events, tasks, storage • framework to move forward • Integrated (and improved) IDL • interfaces distinct from component defn • bi-directional bundles of methods • parameterized (incl. interposition in par. i/f) • whole program analysis and optimization • 25% code-size reduction: dead (9%), inlining (16%) • nesC-DOC documentation tool • Substantially reduced startup and dev. time • MIG automatically generates host java class for each type of TOS_MSG • zero bug’s identified in compiler since release

10. NesC developments • Automatic Race and Deadlock detection • Key idea: detect sharing, enforce atomicity • Two kinds of contexts: intrpt & task • Tested on full TinyOS tree + applications • 186 modules (121 modules, 65 configurations) • 20-69 modules/app, 35 average • 17 tasks, 75 events on average (per app) • Found 156 races: • 103 real:fixed by atomic + post • 53 false: state-based guards, buffer swap, causal • Abstract Components • multiple instances of components • multi-client components

11. TinySec • Link layer security for TinyOS applications • Previous solutions are insecure or too resource-intensive • 802.11 WEP, GSM, Bluetooth, IPSEC • Transparent (e.g. simple key management, key file, built into stack) • Access control, Confidentiality, Message integrity • Architectural features • Single globally shared cryptographic key • Cryptography based on a block cipher • New TinyOS radio stack that integrates security mechanisms • Extensible (e.g. easy to add new HW/SW implementations of block ciphers and modes of operation) • Implementation • TinySecM: bridges radio stack and crypto • +5 bytes to msg • + mac&iv • - CRC&group

12. Internet Patch Network Sensor Node Sensor Patch Gateway Transit Network Client Data Browsing and Processing Basestation Base-Remote Link Data Service Environment Monitoring Experience • live & historical readings http://www.greatduckisland.net • 43 nodes, 7/13-11/18 • above and below ground • light, temperature, relative humidity, and occupancy data, at 1 minute resolution • >1 million measurements • Best nodes ~90,000 • 3 major maintenance events • node design and packaging in harsh environment • -20 – 100 degrees, rain, wind • power mgmt and interplay with sensors

13. Sample Results Node lifetime & Utility Effective communication phase Packet Loss correlation

14. clear transitional silent Reliability-Based Routing • Building up MHop routing based on prob. connectivity model • characterize link behavior • develop link estimators • EWMA of windowed ave => 10% w/i 100 msgs • statistical nbhd table • distributed estimated reliability-based topology formation • cycle detection/breaking • Simulation and empirical char. of alternatives • beacon and shortest-hop perform poorly • path-loss estimate, threshold shortest-path good • fewest aggregate transmissionsmost attractive • Minimize (1/(pfi * pri))

15. Event Queue Communication Services Component Graphs RFM Model APP APP ADC Event APP APP TEMP PHOTO AM TEMP PHOTO AM TEMP PHOTO AM TEMP PHOTO AM CRC CRC CRC CRC BYTE BYTE BYTE ADC BYTE RFM ADC RFM ADC RFM ADC CLOCK RFM TOSSIM Implementations ADC Model Spatial Model TOSSim • Builds directly from TinyOS code • Scales 1,000s of nodes • Captures network behavior at bit level • static, dynamic topology • prob. link mode • debugging • Whole applns interact with simulation same way as real network • Vizualization environment GUI Plug-ins Event Bus Communication Events SerialForwarder Drawing Commands TOSSIM

16. Mini-app Framework Presentation this afternoon • Series of telecons => arch • Preliminary arch document • Re-designed demo as composition of services • Service info sharing w/i node & between nodes (i.e., comm) => reflected tuples • Init. version operational Estimation Scheduler Localization Mag Sensor Time Sync Routing Hood Tuples

17. 51-Pin I/O Expansion Connector Digital I/O Analog I/O UART, I2C, SPI Communication Motor1 ATmega8 Microcontroller Self location/heading navigation Motor2 Desired location Accelerometer Battery Voltage Clock Robot Motor Packet MotorTop MZ Motor Packet Motor1 MZServo ADC CotsBots Platform • Dual-tinyOS system • UART packet link • Motor Servo Board • Atmel ATmega8L • 1-8MHz,,8KB Prog.1KB RAM • 2 Discrete H-Bridge Circuits • Speed and Direction Control • up to 4A, 30V load • Power Monitoring • Accelerometer • Motor-packets interpreted • Char. stability of navigation control alg. MotorServo Board Mica Mote Kyosho Mini-Z RC Car

18. MacroProgramming • Goal • Write high-level programs for groups of motes • Deal with failure and uncertainty, varying numbers of motes • Abstract issues of time, location, neighbors • Provide implicit communication and data sharing • Enable low power and bandwidth efficiency • TinyDB – declarative SQL-like • streaming queries, filters, aggregation, triggers • released with TinyOS • soon: materialized queries & actions • Unstructured Dataparallel • preliminary nesl emulation

19. reg win RF Control Reg Encryption RF Freq LOock Mote-on-a-chip Address Match Unit Address Match Unit Address Match Unit RAM Block Address Match Unit AVR Core Address TranslationUnit RAM Block Address Match Unit Instruction Bus RAM Block RAM Block RAM Block X • proved synthesis path & architecture • NW hardware accel. • Start symbol detection • Timing extraction • DMA • partial energy analysis • ~ 150 uA/Mhz @ 1.5V • ~1 uA standby • 2nd version • transmitter • 1 mA, .5 mW TX power • stream-based encryption • register windows • RF control • RF freq. lock Memory Bus SPI Programming Unit Timer Modules RF Serialization UART RF Timing ? Digital I/O RF Clocking ? ADC Controller Channel Monitoring ? ?

20. l=0.3 l=0.4 CNP Squishing and squashing Shifting and squeezing Connectivity Phase Trans. w/ random connection model for the standard connection model (disc) Connection probability ||x1-x2|| MASSIMO FRANCESCHETTI

21. Other progress • Multihop adaptive slotted-ring routing protocol for deep energy conservation. • Self-calibrated localization • Watch-dogs • Network Programming • Actuated sound environment

22. Goals and Success Criteria • Enable rapid advance of theory and practice of networked, embedded devices and distributed algorithms upon them. • adoption of the platform: ~100 groups nationwide • emergence of new algorithms for important problems in this space • demonstrations of working components • Create a framework in which to integrated the best-of-breed middleware and components of fine-grained distributed control. • working demonstration of challenge appln.

23. Project Plans of 6 Mos • Develop and execute mid-term demo • coordinate and integrate middleware components • TinyOS 1.1 • automated race detection, abstract components, TinySec, component classification, HAL • Improved Network Services • time synch, coordinates, delivery, discovery • integration with contributed middleware • Stronger security: key mgmt and distribution, replay protection • Tunable confidentiality guarantees • Better performance • Refinement of challenge app based on transition plan requirements • Design of OEP2 for challenge appln

24. Project Schedule and Milestones transition planning lang based optimize & viz chal. app defn log & trace adv. sim final prog. env FSM nesC on OEP1 macro. lang design OEP1 defn June 02 June 03 June 04 June 01 Start tinyos 1.1 OEP2 platform design OEP1 eval OEP2 OEP3 OEP1 10x100 kits OEP3 platform design chal app & evaluation midterm demo

25. Technology Transition/Transfer • All HW and SW open and web-accessible • several groups building new boards & components • tinyos.sourceforge.net • Crossbow manufacturing and marketing MICAs • chipcon dot shipping, mica2 in process • engaged in other DARPA efforts • Intel Research collaborating on architecture language, and applications • potential avenue for Silicon Radio and MEMS efforts • major habitat monitoring effort • Several start-ups & product development • Dust Inc, DigitalSun, SensiCast, Bosch,

26. Program Issues • Shifting into a new phase of integrating middleware • Refinement of challenge application essential to guiding definition of OEP2 • expected to be strongly influenced by transition plans • NSF and other fed. agencies are waking up to sensor networks in a big way • opportunities for collaboration • rapidly growing commercial interest • creating vendors to supply DOD technology • ACM SenSys Conference: november 2003 • due April 1