david culler, eric brewer, david wagner, shankar sastry univ. of california, berkeley
DESCRIPTION
EmBedded. Systems. Wireless. Wireless OEP Secure Language-Based Adaptive Service Platform (SLAP) for Large-Scale Embedded Sensor Networks. David Culler, Eric Brewer, David Wagner, Shankar Sastry Univ. of California, Berkeley. Administrative. - PowerPoint PPT PresentationTRANSCRIPT
1
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
Sys
tems
Wir
eles
s
EmBedded
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: [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
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 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
5
Secure Language-Based Adaptive Service Platform for Large-scale Embedded Sensor Networks
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
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
Schedule
June 01Start
June 02 Sept 02Sept 04
End
Sept 03
OEP110x100 kits
OEP2
OEP1defn
OEP1eval
OEP2proto
FSMon OEP1
OEP2
analysis
chal. app defnlog &traceadv.sim macro.
langdesign
OEP2
platform
designOEP3
platform
design
langbasedoptimize& viz
finalprog.env
chal app &
evaluation
Wireless OEP
David Culler, Eric Brewer, David Wagner
Shankar SastryUC Berkeley
F33615-01-C-1895
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
midterm
demo
transitionplanning
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
Imp cycles/blk ms/blk
RC5 C only ~5750 + 1.70 ms
RC5 SPINS: C/asm ~2775 avg 0.75 ms
SkipJack
TinySec: C ~2500 0.70 ms
RC5 TinySec: C/asm ~1775 avg 0.50 ms
• 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
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
Basestation
Gateway
Sensor Patch
Patch Network
Base-Remote Link
Data Service
Internet
Client Data Browsingand Processing
Sensor Node
Transit Network
13
Sample ResultsNode lifetime & UtilityNode lifetime & Utility
Effective communication phaseEffective communication phase
Packet Loss correlationPacket Loss correlation
14
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))
clear transitional silent
15
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
APP
AMPHOTOTEMP
CRC
BYTE
ADC RFM
APP
AMPHOTOTEMP
CRC
BYTE
ADC RFM
APP
AMPHOTOTEMP
CRC
BYTE
ADC RFM
APP
AMPHOTOTEMP
CRC
BYTE
ADC RFM
RFM M
odel
Component Graphs
Event Queue
ADC Event
CLOCKTOSSIMImplementations
ADC Model
ADC Model
SpatialModel
SpatialModel
CommunicationServices
SerialForwarder
TOSSIM
Communication
Ev
en
t Bu
s
GUI Plug-ins
EventsDrawingCommands
16
Mini-app Framework
• 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
Scheduler
Localization
HoodTuples
Routing
TimeSyncMag
Sensor
Estimation
Presentation this afternoonPresentation this afternoon
17
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-packetsinterpreted
• Char. stability of navigation control alg.
Mica Mote
MotorServo Board
Kyosho Mini-Z RC Car
ATmega8 Microcontroller
51-Pin I/O Expansion Connector
Analog I/OUART, I2C, SPICommunication
Digital I/O
Accelerometer Battery Voltage
Motor1
Motor2
navigation
Clock Robot
MotorPacketMotorTop
MotorPacket
MZ
Motor1 MZServo
ADC
Self location/heading
Desired location
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
Mote-on-a-chip• 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
AVR Core
Address Translation
Unit
SPI Programming
Unit
UART
Timer ModulesRF Serialization
Digital I/O
ADC Controller
Address Match Unit
RAM Block
Address Match Unit
RAM Block
Address Match Unit
RAM Block
Address Match Unit
RAM Block
Address Match Unit
RAM Block
Instruction Bus
Memory Bus
RF Timing
Channel Monitoring
RF Clocking
X
?
?
?
?
RF Control Reg
RF Freq LOock
Encryption
reg
win
reg
win
20
2
51.44)(
...359.0
2
2
rdxxgCNP
r
cc
c
CNP
Squishing and squashingShifting and squeezing
for the standard connection model (disc)
Connectivity Phase Trans. w/ random connection model
0.3 0.4
Connectionprobability
||x1-x2||
))(()( 2121 xxpgpxxgs
)( 21 xxg
2
)())((x
xgxgENC
))(())(( xgsENCxgENC )(xgss
MASSIMO FRANCESCHETTIMASSIMO 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
June 01Start
June 02 June 03 June 04
OEP110x100 kits
OEP2 OEP3
OEP1defn
OEP1eval
FSM nesCon OEP1
chal. app defnlog &traceadv.sim
macro. langdesign
OEP2
platform
design
OEP3
platform
design
finalprog.env
chal app &
evaluation
langbasedoptimize& viz
midterm demo
tinyos 1.1
transition
planning
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