Wireless OEP Secure Language-Based Adaptive Service Platform (SLAP) for Large-Scale Embedded Sensor Networks Systems Wireless EmBedded David Culler, Eric Brewer, David Wagner, Shankar Sastry Univ.
Download ReportTranscript Wireless OEP Secure Language-Based Adaptive Service Platform (SLAP) for Large-Scale Embedded Sensor Networks Systems Wireless EmBedded David Culler, Eric Brewer, David Wagner, Shankar Sastry Univ.
Wireless OEP Secure Language-Based Adaptive Service Platform (SLAP) for Large-Scale Embedded Sensor Networks Systems Wireless EmBedded 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: [email protected] • 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 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 Recent Progress Wireless OEP David Culler, Eric Brewer, David Wagner Shankar Sastry UC Berkeley F33615-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 • 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 Schedule lang chal. app defn OEP1 defn FSM OEP1 on OEP1 eval June 02 log & trace adv. sim transition based planning optimize & viz macro. lang design Sept 02 final prog. env Sept 03 Sept 04 End June 01 Start OEP1 OEP2 OEP2 proto platform OEP2 design analysis 10x100 kits OEP2 OEP3 chal app & midterm platform evaluation demo design 5 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 6 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 7 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 8 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 9 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 10 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 Imp – +5 bytes to msg • + mac&iv • - CRC&group RC5 C only RC5 SPINS: C/asm Skip Jack TinySec: C RC5 TinySec: 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 – • • Best nodes ~90,000 3 major maintenance events Sensor Patch Gateway Transit Network node design and packaging in harsh environment – • Patch Network Sensor Node -20 – 100 degrees, rain, wind power mgmt and interplay with sensors 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 Event Queue • Builds directly from TinyOS code • Scales 1,000s of nodes • Captures network behavior at bit level – static, dynamic topology – prob. link mode ADC Event Communication Services APP APP APP APP TEMP PHOTO AM TEMP PHOTO AM TEMP PHOTO AM TEMP PHOTO AM CRC CRC CRC CRCBYTE BYTE BYTE ADC BYTERFM ADC RFM ADC RFM 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 Communication SerialForwarder 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 CotsBots Platform • Dual-tinyOS system 51-Pin I/O Expansion Connector UART, I2C, SPI Digital I/O Analog I/O Communication – UART packet link • Motor Servo Board Motor1 ATmega8 Microcontroller Motor2 – Atmel ATmega8L – 1-8MHz,,8KB Prog.1KB RAM – 2 Discrete H-Bridge Circuits Accelerometer • Speed and Direction Control • up to 4A, 30V load – Power Monitoring – Accelerometer Self location/heading navigation Battery Voltage MotorServo Board Mica Mote Desired location Clock • Motor-packets MotorTop interpreted MZ Motor1 MZServo • Char. stability of ADC navigation control alg. Robot Motor Packet Kyosho Mini-Z RC Car Motor Packet 17 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 18 Mote-on-a-chip • proved synthesis path & architecture • NW hardware accel. reg win AVR Core – Start symbol detection – Timing extraction – DMA – ~ 150 uA/Mhz @ 1.5V – ~1 uA standby – transmitter • 1 mA, .5 mW TX power – – – – stream-based encryption register windows RF control RF freq. lock Memory Bus Timer Modules • partial energy analysis • 2nd version Instruction Bus ? ADC Controller Encryption Address Translation Unit RF Serialization UART Digital I/O Address Match Unit Address Match Unit Address Match Unit Address Match Unit Address Match Unit X RAM Block RAM Block RAM Block 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) 0.3 0.359... c 2 r CNP c g ( x)dx c 4r 2 4.51 2 0.4 CNP Connection probability ENC ( g ( x )) g ( x) x 2 ENC( g ( x)) ENC( gs( x)) gss(x) g ( x1 x2 ) gs( x1 x2 ) p g ( p ( x1 x2 )) ||x1-x2|| Squishing and squashing Shifting and squeezing 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 • 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 23 Project Schedule and Milestones transition chal. app defn planning FSM nesC on OEP1 OEP1 defn June 02 June 01 Start OEP1 eval log & trace adv. sim macro. lang design June 03 tinyos OEP2 1.1 platform design OEP2 OEP1 10x100 kits midterm demo lang based optimize & viz final prog. env June 04 OEP3 OEP3 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, 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, 25 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 26