Wireless Mobile Platform OAEP Lessons, Progress, and Future Work

1
Wireless Mobile Platform OAEPLessons,
Progress, and Future Work

• David Wagner
• UC Berkeley

2
Platform Innovations

• TinyOS 1.1
• New release processes

3
Integrating Midterm Demo Enhancements

• TinyOS improvements
• Better radio stack (Chipcon CC1000)
• Mica2Dot support
• Sensorboard support
• Hardware designs published
• Magnetometer board with reset
• Ultrasound board with dedicated TinyOS processor
• Dual-voltage Power board w/ rechargeable battery
• Acoustic board with greater amplitude and
  dedicated TinyOS processor

4
TinyOS 1.1 Release

• nesC 1.1 data race detection, atomicity
• TinyOS
• mica2 and Mica-Dot support (chipcon radio)
• power management, battery monitoring
• TinySec
• ad-hoc routing (lib/Route)
• Matchbox filesystem, for flash chip
• Development environment
• network reprogramming (Xnp)
• TinyViz (visualisation for tossim)
• on-mote debugging (gdb over JTAG)
• Distribution re-structured
• RPMs for Linux and Cygwin
• HW platform support re-organized
• contrib directory
• minor release process created

5
Beta Release Process

• New process get your new ideas in TinyOS, faster
• open a new beta project - comes with SOW and
  time limit
• develop - often multiple participants
• merge becomes part of default CVS tree
• appears in next monthly minor release
• Monthly release process distribute new code
  faster
• 1st of the month create CVS branch
• run regression tests (new...) on branch
• fix discovered problems
• create release from branch (approx. 1 week after
  branch), announce to world
• merge fixes back to main trunk
• merge major changes from beta directory into
  TinyOS CVS (gives 1 month for widespread testing
  before release)
• Example UCLA/UCB collaboration on B-MAC

6
Network Innovations

• A better MAC layer
• High-speed sampling
• Lib/Route
• Reliable bulk transport

7
B-MAC

• New Features
• Automatic Gain Control (AGC)
• Noise floor estimation
• Filtering for Clear Channel Assessment (CCA)
• Low-power listening
• Link-layer ACKs
• Improvements
• Raise max bandwidth from 42 to 53 packets/sec
• Double effective data throughput
• 85 channel utilization
• Time synchronization interfaces for UCLA/VU
• Configurable Backoff

• Included in TinyOS 1.1.2 (December 03 Release)
• Example of a beta-process success

8
High-frequency Sampling Logging
Matchbox flash filer
RAMRT averaging
1 KHz

• Supports up to 16 KHz sampling on mica, mica2
  motes
• Fast logging flash-based file system (512kB)
• Low jitter lt 10µs at 6 KHz

2.5kHz, mote dropped
2.5kHz, mote shaken
9
Robust Ad-hoc Routing

• Convergence of lib/Route multihop routing
  interface
• Several different implementations (RFM and CC)
• Applications select implementation in config
  (e.g. TASK, Surge)
• Link quality Management
• Neighborhood Management
• Adaptive Cost-based Route Selection
• Thresholded shortest-path
• Minimum path-loss
• Minimum retransmission
• Link-level Retransmission
• Send Queueing
• Extensive Study (sensys)
• gt98 reliability on CC1000

10
Reliable Bulk Transport

• Goal reliable, unicast transfer of large data
  sets
• Principles
• Matched to physical hierarchy
• Data set/flash, segment/SRAM,
• Packet/radio
• Explicit session (segment) creationhandshake,
  implicit tear-down
• Selective acknowledgements,retransmission
• Data transferred reliably fromRAM to RAM
• Speed controlled by timer,to avoid channel
  saturation
• Results
• Reliable, even for 20 loss rates
• Throughput degrades gracefully

example throttled to 10 pkts/sec
buf alloc

data
ack vector
start
ok
11
Pushing Scale Throughout the Platform

• Manufacture and deployment time
• Network Longevity
• Network Programming
• Simulation
• Testbeds and New Platforms

12
Some Lessons from Midterm Demo
reflector
Exposed components
O-ring Seal
ultrasound
Mica2 dot
mag sense
power
Good thermal characteristics
battery
Collision absorption

• Packaging matters
• Good Minimize exposure to the elements, lift
  antenna away from ground
• Bug Unexpected interaction between antenna
  magnetometer
• Design for operation
• If you have to touch every node, you lose
• Bugs no reset button, recharging requires
  reassembly, LEDs are invisible
• Antenna insertion and pin alignment were major
  time consumers

13
Midterm Lessons

• Time is critical
• Design, prototype, test hardware and software
• Manufacturing a large number of nodes
• Test, integrate, and fix cycle when working at
  scale
• Assembly and disassembly of nodes
• Develop glue between tiers in the network
• Issues for large deployments
• Power consumption and recharge
• Maintenance
• Need robust hardware and packaging
• Must expect individual nodes to be hands-free
• Reprogramming
• Dont use modular hardware
• Only causes more faults for no benefits
• Support services are invaluable
• Ident ping, version, compile time
• Command-line scripting
• Remote configuration
• Reset / sleep

• Development methodology
• More nodes gt simpler code
• Completely modular subsystems allow testing and
  debugging in isolation
• Node position
• Sensing and report
• Mobile-to-mobile routing
• Pursuer navigation
• Extensive parameterization reduces the need for
  reprogramming
• Thresholds, update rates, ranges, etc
• Assume lossy links
• Simplicity pays
• Robustness trumps features
• Multiple fall-backs per service
• Allow testing and debugging of service in
  isolation at scale
• Mitigates risk
• Localization fixed, remote set, ranging
• Routing single hop, 802.11 back channel,
  landmark multihop
• Global access during debugging
• Big antenna

• Wish we had done
• Better regression suites
• Logged everything (the science of the demo)

14
Long-term Deployments in Harsh Climate

• Deployed two monitoring networks on Great Duck
  Island
• Node design based on NEST midterm package
• PIR for detection microclimate
• Large, non-uniform geographic area
• Unintrusive, survive heat, rain, storms
• Shallow network deployed mid-June
• 49 nodes 23 weather station motes, 26 burrow
  motes
• Reading every 5 minutes
• Network diameter 70 meters
• Asymmetric, bi-directional communication with low
  power listening send data packets with short
  preambles, receive packets with long preambles
• Expected life time 4 months
• Deeper network in July/August
• 92 nodes 44 weather motes, 48 burrow motes
• Network diameter 1/5 mile
• Low power listening tradeoff channel capacity
  for average power consumption (hit 10 uA sleep,
  12 mA active)
• Reading sent to base station every 20 minutes,
  route updates every 20 minutes.
• Expected lifetime 2.5 months
• 2/3 of nodes join within 10 minutes, remainder
  within 6 hours.
• Still running after hurricane

15
Typical Network Architecture
Widely dispersed Dense patches
Patch Network
Sensor Patch
Sensor Node
Gateway
1 km in GDI Solar-powered mote with big antenna
Transit Network
Basestation
Client Data Browsing and Processing
Base-Remote Link
Data Service
16
Power Management Cooperative Interfaces

• Power management extends std control
• 1000-fold range of power draw
• Components informed of intention to go to sleep
• Take internal actions
• Propagate control
• Scoreboard determined permissibledepth of sleep
  state
• Scheduler drops to sleep on idle
• Key interrupts drive wake-up
• Watchdog is built in similar fashion
• Low level grenade timer
• Various levels of health monitoring to keep it
  from going off
• Implemented and incorporated into TinyOS Appln
  Sensor Kit (TASK)

17
Monitoring and Management of the Network

• Determine what went wrong and take action
• Extremely simple and reliable
• Ensure liveness, preserve access to network
  nodes, help with fault diagnosis
• Networking monitoring
• Enforce minimum and maximum transmission rates
• Verify minimum reception rate
• Node health monitoring
• Beyond battery voltage sensor data monitoring
• Failure of a sensor an indicator of node health
• Detectable failures impacting lifetime GDI
  humidity and clock skew experience
• Program integrity checks
• Stack overflow
• Watchdog / deadman timer
• Require attention from different parts of the
  system, reset if abandoned
• Address many different time scales
• Test low-level system components timers, and
  task queue to ensure basic system liveness
• First use min reception rate
• Partial system shutdown
• Flash/EEPROM writing under low voltage
  conditions, broken sensors, etc.

18
Low-power Event Dissemination Trickle

• Problem Propagate news of rare events,
  efficiently
• eg. Reprogramming, configuration change, new
  capsules
• energy dominated by checking to see if have most
  current version
• trade-off between rate of notification can cost
  of maintenance
• must adapt to deployment density
• Denser gt more listening, less transmitting
• Simple, polite gossip algorithm
• Every once in a while, broadcast what version
  you have, unless youve heard some other nodes
  broadcast the same thing.
• Behavior (simulation and deployment)
• Scalability thousands of nodes, huge variations
  in density
• Maintenance a few sends per hour
• Propagation less than a minute
• msg flux per unit area constant, despite
  variation in node density

19
(No Transcript)
20
Scalable Network Programming

• Out of core, epidemic algorithm
• Program (flash) divided into sequence of pages
• Version has sequence hash per page pages
• Page (segment) size determined by RAM, Flash xfer
  buffer, and size of directory
• Nodes hold version page diffs disseminate
  either
• Basic primitive reliable page multicast
• Fragment and transmit packets per page, vector
  ack, selective fix up per receiver, snoop,
  consistency checking
• Receive / ack process must be limited to RAM
  (flash in XNP)
• Dissemination algorithms
• Fast push, pipeline series of pages in space
• Epidemic maintenance
• Eliminate the wrong image problem
• New version propagate page diffs
• Potentially, multiple levels of pages to organize
  code and metadata
• System image version number vector of page
  hashes
• Organize image to reduce pages that change
• Linearization of functions, holes
• Blue sky ideas
• default TinyOS network reprogramming kernel as
  the system restore checkpoint

21
Network Reprogramming Deluge

• Data dissemination protocol for program data
• Program size (128K) gtgt RAM (4K)
• Data represented as a set of fixed-size pages
• Basic Protocol

• Optimizations Considered
• Transmit data rates, pipelining of pages, forward
  error-correction, sender selection, sender
  suppression
• Currently
• Implemented in nesC, working in TOSSIM.
• Page-based bootloader working on nodes
• Energy consumption, time-to-completion acceptable
• Pipelining of pages a big win, transmitting at
  maximum data rate minimizes time-to-completion
  and energy wasted due to idle-listening.
• Forward error correction is beneficial in sparse
  nets
• All other optimizations show no significant
  difference and increase complexity
• Testing on larger real-world networks.

22
Network Reprogramming Deluge

• Sample TOSSIM data on 25 nodes in long rectangle

23
Scalable, Scriptable TinyOS Simulation

• TOSSIM simulate TOS implementation at controlled
  level of detail
• bit-level network 100 nodes in real time
• packet-level network thousands of nodes
• TinyViz
• provides convenient means of looking at what is
  going on inside your distributed applications
• extensible plug-ins
• T-Script
• allows scripting of everything going on around
  the simulation
• reproducible dynamism
• regression testing, parameter studies, mobility,
  fault injection, environmental model
  (sensors/actuators), logging, debugging
• scripts are written in Java-based Python
• integrated with full tool chain
• event-driven gt each script agent is a closure

24
Development Testbeds

• Often need deployed collection of test motes with
  powerful back-channel
• instrumentation, debugging, fast reprogramming
• intermediate point in simulation / emulation /
  deployment spectrum
• real network, controlled environment, large
  instrumentation and control bandwidth
• Developed ethernet approach (with Intel) and
  provided to CrossBow
• atmel programmer on mote end
• lantronics 10BT ethernet-serial device
• uses power over ethernet
• Tool suite for programming, logging, data
  collection
• Ethernet based programming/monitoring platform
• eMote (NOT a mote)
• Production version of EPRB
• 802.3af Power over Ethernet capable
• Enables large scale testbeds educational
  tools

25
Towards a Level 2 Node

• IPAQ, Intrynsic, etc dont have the connectivity
  options
• often hard hard to maintain linux distribution
  (esp. iPAQ)
• STARGATE All-purpose embedded computing
• 400 MHz Xscale / Linux
• Ethernet, Bluetooth, USB, Serial, PCMCIA/CF (x2),
  JTAG, BerkeleyMOTE interface
• Onboard Li-ION controller
• Users
• Intel Open-Source Robotics
• Sensor Nets
• Compact base station platform
• UCB,UCLA, U of Utah, Harvard, more...

Top View w/ Daughter Card
Bottom View
26
Telos Exploring Next-Generation Possibilities

• Single board philosophy
• Robustness, Ease of use, Lower Cost
• Integrated Humidity Temperature sensor
• First platform to use a 802.15.4 radio
• CC2420 radio, 2.4 GHz, 250 kbps (12x mica2)
• 3x RX power consumption of CC1000, 1/3 turn on
  time
• Same TX power as CC1000
• Motorola HCS08 processor
• Lower power consumption, 1.8V operation,faster
  wakeup time
• 40 MHz CPU clock, 4K RAM
• Package
• Integrated onboard antenna, 3dBi gain
• Removed 51-pin connector
• Everything USB Ethernet based
• 2/3 A or 2 AA batteries
• Weatherproof packaging
• Support in upcoming TinyOS 1.1.3 Release
• Available February from Moteiv (moteiv.com)

27
Other Innovations

• Ranging and Localization

28
Ranging and Localization

• Systematic study based on mid-term ultrasound
  board
• many nodes with uniform collection of pairs at
  many distances
• ranging data collection in many environments
• carpet, grass, dirt, pavement
• Goal identify why range-error extrapolated to
  localization performance is so optimistic
• so much better on paper than in practice
• Careful development of measurement technique and
  filters
• Yields 10 cm (90 confidence) over 5 m
• Key is that likelihood of valid range estimate
  decreases with range and with number of nodes
• Yielded surprising result on collision behavior

29
Shadowing

• All modern RF/Acoustic time-of-flight systems
  encase the acoustic pulse in the radio pkt
• Use RF MAC to mediate acoustic
• Associate correct chirp with correct pkt
• Assumes collision gt loss
• so does most of the wireless protocols
• Assumption is often false with FSK
• slightly stronger packet earlier packet
• received despite collision
• Modified receiver processing
• scan for start symbol within packet
• recover stronger-late packet
• Recover data from most collisions!
• significant change in network behavior

distance
Acoustic
RF
time
30
MobiLoc Mobility Enhanced Localization

• Use range/angle to target, as measured by
  default sensors, to better localize nodes
• reduce (eliminate?) anchor nodes
• how much processing involved?
• Elegant simple approximation
• when a target crosses the line through two nodes
  consider the sum and difference of their range
  measurement
• min sum (when between) separation distance
• max diff when outside

31
NEST Final Demo Plans

• Redefine Pursuit-Evasion Game Scenario
• Road in the middle of the field is an evader
  safe-zone
• Pursuit occurs when evaders leave road
• Exposes and leverages NEST research
• Line in the sand
• Waking up Big Brother
• Sentry service
• Enhancements over NEST Midterm Demo
• Up to 5 robots 3 pursuers, 2 evaders
• Multi-object tracking, Coordinated pursuit
• Larger field, more motes
• Estimate energy consumption versus evader
  activity
• Early challenges
• Select and freeze sensing modes
• Tied to decisions Extreme Scaling Demo
• Design nodes and network explicitly for
  multi-object detection
• Additional challenges and enhancements
• Secure links
• More distinct separation of composable services

32
Questions?
33
DARPA Template Slides
34
Administrative

• Project Title
• Program Manager Vijay Raghavan
• PI Name(s)
• PI Phone Number(s)
• PI E-Mail Address(es)
• Company/Institution
• Contract Number
• AO Number
• Award Start Date
• Award End Date
• Agent Name/Organization

35
Subcontractors and Collaborators

• Subcontractors
• Collaborators

36
Project Name
PI Name Affiliation
Problem and Challenge

• New Ideas

Problem and Challenge Description
Project Diagram Here
Additional Supporting Text
FY04 Schedule

• Impact

• 1QFY03
• Tasks/Milestones
• 2QFY03
• Tasks/Milestones
• 3QFY03
• Tasks/Milestones
• 4QFY03
• Tasks/Milestones

37
Problem Description/Objective

• What specific technical problem(s) are you trying
  solve?
• How does your project contribute to the goals and
  current status of the NEST program?
• Identify specific success criteria for your
  project
• You may be informal at this point, but thinking
  along these lines will be useful in figuring out
  program metrics, something that will be done
  during the course of the PI meeting
• If you have many different results you can talk
  about, it would be nice to enumerate all of them
  in one chart but talk in detail about just one of
  themthis way, the audience gets an appreciation
  of your work without having to do absorb a lot in
  a short amount of time

38
Project Status

• Identify current technical approach to reaching
  your project's goals
• Describe changes in technical approach since last
  NEST PI Meeting
• Describe progress made since last NEST PI Meeting
• Identify deliverables and publications
• Identify specific milestones accomplished
• Identify and update status to delayed milestones

39
Goals and Success Criteria

• Give very concrete metrics that can be measured
• Specify explicit Go/No-Go decision points

40
Project Plans

• Describe your project's plans for FY04, including
  detailed plans for the next six months
• Identify specific performance goals
• Identify how your progress will be measured and
  success determined
• Try to use very concrete metrics
• If at all possible, indicate how success can be
  measured on the OEP

41
Project Schedule and Milestones

• Show the key 3-5 tasks in the project and the
  schedule for achieving these tasks
• Be very specific on contracted milestones and
  demonstration events
• Annotate timeline using Government Fiscal
  Years/Quarters only
• Start timeline at award and end timeline at award
  end
• Show completed milestones and schedule
  advances/slippages
• Describe project milestones that occur in next
  six months

42
Technology Transition/Transfer

• Provide information on any technology transition
  activities your team has identified
• Provide details on the technology transition
  opportunities, the relevant DoD organizations,
  and the applicable areas of the program and your
  project

43
Program Issues

• Provide information on existing or anticipated
  problems with the project or the overall NEST
  program that youd like to see addressed