Endeavouring to Build Networks of Tiny Devices

1
Endeavouring to Build Networksof Tiny Devices

• David Culler
• Computer Science Division
• U.C. Berkeley
• www.cs.berkeley.edu/culler

2
Background

• Q1 design principles for Extremely Diverse
  system architectures?
• immense services (Millennium, Ninja)
• tiny devices
• appln as graph of state machines
• concurrency intensive, variation in load,
  robustness
• reactive
• tiny devices became eyes and ears of
  ubiquitous computing
• become source of control as well

3
Emerging Microscopic Devices

• CMOS trend is not just Moores law
• Micro Electical Mechanical Systems (MEMS)
• rich array of sensors are becoming cheap and tiny

• Imagine, all sorts of chips that are connected
  to the physical world and to cyberspace!

4
Current One-Inch Networked Sensor

• 1 x 1.5 motherboard
• ATMEL 4Mhz, 8bit MCU, 512 bytes RAM, 8K pgm flash
• 900Mhz Radio (RF Monolithics) 10-100 ft. range
• ATMEL network pgming assist
• Radio Signal strength control and sensing
• I2C EPROM (logging)
• Base-station ready
• stackable expansion connector
• all ports, i2c, pwr, clock
• Several sensor boards
• basic protoboard
• tiny weather station (temp,light,hum,press)
• vibrations (2d acc, temp, LIGHT)
• accelerometers
• magnetometers

5
TinyOS Approach

• Stylized programming model with extensive static
  information
• Program graph of TOS components
• TOS component command/event interface
  behavior
• Rich expression of concurrency
• Events propagate across many components
• Tasks provide internal concurrency
• Regimented storage management
• Very simple implementation
• Broad range of alternative execution mechanisms
• For More see http//tinyos.millennium.berkeley.edu
  

6
Tiny OS Concurrency Framework

• Scheduler Graph of Components
• constrained two-level scheduling model threads
  events
• Component
• Commands,
• Event Handlers
• Frame (storage)
• Tasks (concurrency)
• Constrained Storage Model
• frame per component, shared stack, no heap
• Very lean multithreading
• Efficient Layering

Events
Commands
send_msg(addr, type, data)
power(mode)
init
Messaging Component
Internal State
internal thread
TX_packet(buf)
Power(mode)
TX_packet_done (success)
init
RX_packet_done (buffer)
7
Application Component Graph
Route map
router
sensor appln
application
Active Messages
Radio Packet
Serial Packet
packet
Temp
photo
SW
HW
UART
Radio byte
ADC
byte
Example ad hoc, multi-hop routing of photo
sensor readings
clocks
RFM
bit
8
DARPA-esq demo

• UAV drops nodes along road,
• hot-water pipe insulation for package
• Nodes self configure into linear network
• Calibrate magnetometers
• Each detects passing vehicle
• Share filtered sensor data with 5 neighbors
• Each calculates estimated direction velocity
• Share results
• As plane passes by,
• joins network
• upload as much of missing dataset as possible
  from each node when in range
• 7.5 KB of code!

9
Cory Energy Monitoring/Mgmt System

• 50 nodes on 4th floor
• 5 level ad hoc net
• 30 sec sampling
• 250K samples to database over 6 weeks

10
Energy Monitoring Network Arch
sensor net
control net
802-11
telegraph
PC
PC
modbus
scada term
UCB power monitor net
Browser
11
Directions

• Systems technology long-term management
• integrate new MAC and rate control (Alec Woo)
• in situ network programming (Rob Szewczyk)
• node query scheme (Sam Madden)
• implicit discovery (Phil Levi)
• signal strength adaptation
• telegraph
• Power management
• Battery monitoring and adaptation
• current and voltage sensors
• non-intrusive load monitoring
• integrate with broader sensor net
• alert response

12
Emerging de facto tiny system

• Feb. bootcamp
• 40 people
• UCB, UCLA, USC, Cornell, Rutgers, Wash.,
• LANL, Bosch, Accenture, Intel, crossbow
• Several groups actively developing around tinyOS
  on rene node
• Concurrency framework has held up well.
• Next generation(s) selected as DARPA networked
  embedded system tech (NEST) open platform
• Smaller building blocks for ubicomp

13
NEST Program Structure evolution
Composition Open Platform
initial low-power wireless Open Platform 100
tiny devices for alg. dev.
year
3
2
1
0
14
HW Platforms

• Current SmartDust MacroMOTE gt Renes gt
• Phase 1 6 months gt algorithm studies
• Mote, MEMS sensors, TinyOS
• more microcontroller
• atmega163 gt 2x storage
• atmega103 gt 128K flash, 4k ram
• TIMSP430 gt 60k flash, 2k ram, HW , ...
• many subtle factors
• RFM with ASH 100 kb/s
• too early for bluetooth
• 100 nodes for lt 20K
• Phase 2 30 months gt composition of algs
• ARM-power, Bluetooth physical
• integrated system
• OS??

15
SW Platform

• Tiny event-driven component OS
• allows NEST abstractions to emerge and each level
• Language-based robustness and optimization
• eg., critical path and jitter analysis
• inter-component transformations
• narrow interface with simple IDL
• Tiny networking
• power-aware appln-specific ad hoc routing, MAC,
  transmission control
• in network aggregation
• in situ programming
• Algorithm building blocks
• Local multicast
• event-driven reception
• intelligent pruning of retransmission
• non-blocking execution

16
Programming Environment Tools

• Provide support for event-driven programming,
  composition, debugging visualization in the
  small (node) and large (collection)
• Emulation gt simulation gt real devices
• identical APIs, range of visibility, and reality
• Debugging and visualization tools
• geared toward many interacting nodes
  event-centric development
• Application-Specific Virtual Machines
• analogous to query-plan vs query-processing
  engine
• FSM-based programming abstractions
• Macrocomputing

17
FSM-based Software Approach

• Fundamentally, we are not computing, we are
  moving data intelligently
• threads are a computing abstraction, FSMs are a
  protocol abstraction
• use FSMs as the base then add some computing
• natural high concurrency
• natural handling of events, exceptions, and the
  environment
• tools for understanding stability (e.g markov
  models, game theory, control theory)
• composition is separate from creation
• late bind the callee in a separate step called
  "composition"

18
Macrocomputing

• Program a large, unstructured collection in
  aggregate
• Single program, multiple data
• but errors and probabilistic behavior
• unstructured collection
• global variables that reflect collections
• need to handle error propagation
• scatter/gather for collections?
• online query processing?
• multi-WEbS abstractions

19
Security

• Individual nodes may be compromised, but hard to
  get large fraction of nodes.
• Attacks introduce another form of unreliability
  in the data.
• Lightweight encryption/decryption,
  authentication.
• Novel protocols to support aggregate operations,
  eg., broadcast, w/o shared root key
• Resilient aggregation

20
Resilient Aggregators

• operate in the face of faulty nodes, intermittent
  communication, and security attacks
• ex max is not resilient, nine-tile is.
• develop algebra of resilient aggregators
• Random sampling as implementation
• foundation for security model
• easy to attack a node
• hard to attack large fraction of the nodes

21
Simulation

• Large-scale NEST simulator
• very large number of small nodes
• integrated with event-driven OS design for
  efficiency
• checkpointing
• Adversarial simulation mode
• Detecting composition bugs and scaling bugs
• Target failure search for bugs
• test race conditions automatically
• pick orders that consume resources
• more efficient than random-walk testing
• simulator is an adversary
• guided search
• Hybrid simulator/testbed

22
Test-bed Kits

• in situ programming/upgrade and debugging
• synchronized logging (trace extraction)
• passive monitoring
• data collection

23
Challenge Applications
active markers
obstacles

• sequence of applications
• interactive spaces
• flock of model cars
• Multi-agent pursuit-evasion
• also environmental monitoring
• stunt ranch whole canopy ecophysiology with UCLA

UAVs
evader
24
Closed-loop at many levels

• Within a node
• behavior adapts to available energy, physical
  measurements, network condition
• Across the network
• discovery and routing, transmission rate and
  schedule
• adopting roles,
• Within the middleware components
• synchronization, scheduling
• On the vehicle
• direction, stability, probabalistic map building
• Among the vehicles
• competitive, hidden markov decision processes

25
New building blocks for Ubicomp
26
New Collaboration

• Intel Berkeley LabletExtreme Interconnected
  Systems (XIS) lab