Wireless OEP Secure Language-Based Adaptive Service Platform SLAP

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

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 #: F 33615 -01 -C-1895 • AO number: • Award start date: 6/1/01 • Award end date: 10/31/04 • Agent name & organization: Juan Carbonell, AFRL/Rome 2

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 3

Problem Description, Project Overview • Develop NEST platform research to dramatically accelerate 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 4

Secure Language-Based Adaptive Service Platform for Large-scale Embedded Sensor Networks Wireless OEP David Culler, Eric Brewer, David Wagner Shankar Sastry UC Berkeley F 33615 -01 -C-1895 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 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 Recent Progress • Completed Tiny. OS 1. 0 release • • • full nes. C impl. + idl + Msg i/f generator advance NW stack with link-level ack Chip. Con radio stack + crossbow mica-CC Tiny. SEC encryption and security reliability-based, prob. routing Scalable TOSSIM with nw model and GUI Harsh longterm env. mon. deployment Constraint-based localization calibration Tiny. DB & nesl macroprogramming 2 nd spin mote-on-chip stability anal. of Mote. Bot control operational mid-term appln framework Schedule chal. app defn FSM OEP 1 on OEP 1 eval OEP 1 defn June 02 log & trace adv. sim lang transition based planning optimize & viz macro. lang design Sept 02 final prog. env Sept 03 June 01 Start OEP 1 OEP 2 proto platform OEP 2 design analysis 10 x 100 kits Sept 04 End OEP 2 OEP 3 chal app & midterm platform evaluation demo design 5

Project Status • Robustified Platform - Tiny. OS 1. 0 – nes. C language, whole pgm analysis, idl, refined all components, link-level acks, routing, documentation, network programming, race detection • • Long term, outdoor deployment + many smaller Mid. Term tracker framework operational Tiny. SEC 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 Mot. Bots, motor board, control and analysis Testing 1 st mote-chip, fab’d 2 nd Challenge minitask, security minitask, transition planning 6

Platform HW Development • Mica => Crossbow dot, mica 2 – 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 Cots. Bots 7

Tiny. OS 1. 0 • Release finalized in Oct 02. • Based on nes. C 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 8

Nes. C • Clean linguistic support for Tiny. OS 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%) • nes. C-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 9

Nes. C developments • Automatic Race and Deadlock detection – Key idea: detect sharing, enforce atomicity – Two kinds of contexts: intrpt & task – Tested on full Tiny. OS 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 10

Tiny. Sec • Link layer security for Tiny. OS 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 Tiny. OS radio stack that integrates security mechanisms Extensible (e. g. easy to add new HW/SW implementations of block ciphers and modes of operation) • Implementation – Tiny. Sec. M: bridges radio stack and crypto Imp – +5 bytes to msg • + mac&iv • - CRC&group RC 5 C only RC 5 SPINS: C/asm Skip Jack Tiny. Sec: C RC 5 Tiny. Sec: C/asm cycles/blk ms/blk ~5750 + 1. 70 ms ~2775 avg 0. 75 ms ~2500 0. 70 ms ~1775 avg 0. 50 ms 11

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 Patch Network Sensor Node – 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 Sensor Patch Gateway Transit Network Client Data Browsing and Processing Basestation Base-Remote Link Internet Data Service 12

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

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 clear transitional – cycle detection/breaking • Simulation and empirical char. of alternatives silent – beacon and shortest-hop perform poorly – path-loss estimate, threshold shortest-path good – fewest aggregate transmissionsmost attractive • Minimize (1/(pfi * pri)) 14

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

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

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

Macro. Programming • 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 • Tiny. DB – declarative SQL-like – streaming queries, filters, aggregation, triggers – released with Tiny. OS – soon: materialized queries & actions • Unstructured Dataparallel – preliminary nesl emulation 18

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

Connectivity Phase Trans. w/ random connection model for the standard connection model (disc) l=0. 3 l=0. 4 CNP Connection probability Squishing and squashing Shifting and squeezing ||x 1 -x 2|| MASSIMO FRANCESCHETTI 20

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

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

Project Plans of 6 Mos • Develop and execute mid-term demo – coordinate and integrate middleware components • Tiny. OS 1. 1 – automated race detection, abstract components, Tiny. Sec, 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 OEP 2 for challenge appln 23

Project Schedule and Milestones transition chal. app defn FSM nes. C on OEP 1 defn June 02 June 01 Start planning OEP 1 eval log & trace adv. sim macro. lang design June 03 tinyos OEP 2 1. 1 platform design OEP 2 OEP 1 10 x 100 kits midterm demo lang based optimize & viz final prog. env June 04 OEP 3 platform design chal app & evaluation 24

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, mica 2 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, Digital. Sun, Sensi. Cast, Bosch, 25

Program Issues • Shifting into a new phase of integrating middleware • Refinement of challenge application essential to guiding definition of OEP 2 • 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 Sen. Sys Conference: november 2003 • due April 1 26