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: 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 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