1

Wireless Mobile Platform OAEP

Lessons, Progress, and Future Work

David WagnerUC Berkeley

2

Platform Innovations

TinyOS 1.1New 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

dot

mag ultrasound

acoustic

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 layerHigh-speed sampling

Lib/RouteReliable 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

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

2.5kHz, mote shaken 2.5kHz, mote dropped

Matchbox flash filer

sensor 16 KHz 1 KHzRAMRT averaging

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)• >98% reliability on CC1000

RFM End-to-end Success vs. Distance

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

Throughput vs Loss Rate (Window =16)

0

50

100

150

200

250

300

0 5 10 15 20 25Loss Rate

Thr

ough

put (

Byt

e/s)

Throughput

# of packets sent / 10

example throttled to 10 pkts/secexample throttled to 10 pkts/sec

start

buf alloc

ok

***

data ack vector

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

• 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

Exposed components

ultrasoundMica2 dot

mag sensepower

battery

reflector

Collision absorption

O-ring Seal

Good thermal characteristics

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–Don’t 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 => 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

Transit Network

Basestation

Gateway

Sensor Patch

Patch Network

Base-Remote Link

Data Service

Internet

Client Data Browsingand Processing

Sensor Node

Widely dispersed

Dense patches

1 km in GDI

Solar-powered mote with big antenna

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)

Application: query processing

detection, reporting

Radio

Comm

Stack

Clock

Timer

Sensor 3Sensor 2

Sensor

Drivers &

Filters

Sensor1

Power Management

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.

• Fault handling–Error logging and/or reporting

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 => more listening, less transmitting

• Simple, “polite gossip” algorithm• “Every once in a while, broadcast what “version” you

have, unless you’ve 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

Time

Time To Reprogram, Tau, 10 Foot Spacing (seconds)

18-20

16-18

14-16

12-14

10-12

8-10

6-8

4-6

2-4

0-2

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) >> 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.

Version: 2Pages: (0,1,2) Page: 0

Version: 2Pg: 0, Pkt: 15 Pg: 0, Pkt: 3

1. Advertise 2. Request 3. Transmit 4. Repair

22

Network Reprogramming: Deluge

• Sample TOSSIM data on 25 nodes in long rectangle

0

200

400

600

800

1000

1200

En

erg

y U

se

d (

uA

h)

0 2 4 8 12 16

Spacing Between Nodes

Breakdown of Energy Used (Full Speed Send)

EEPROM Writes EEPROM Reads Messages Received

Messages Sent Radio Listening

C

Effect of Packet Send Period on Time to Completion (p < .01)

0

100

200

300

400

500

600

0 2 4 8 12 16

Spacing Between Nodes

Tim

e t

o C

om

ple

tio

n (

s)

Full speed 64ms 128ms 256ms

Effect of Sender Selection Methods on Time to Completion

0

100

200

300

400

500

0 2 4 8 12 16

Spacing between Nodes

Tim

e E

lap

se

d (

s)

Most recent adv Closest to src

Farthest from src Closest to reqer

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 => 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 don’t 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 CardBottom 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 => 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

time

RF

Acoustic

distance

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– Packaging and deployment

• Consider solar-rechargable motes

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

Problem and Challenge

FY04 ScheduleImpact…

New Ideas …

Additional Supporting Text…

Problem and Challenge Description

1QFY03• Tasks/Milestones

2QFY03• Tasks/Milestones

3QFY03• Tasks/Milestones

4QFY03• Tasks/Milestones

ProjectDiagram

Here

ProjectDiagram

Here

Q1 Q2 Q3 Q4

Project NamePI NameAffiliation

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 them—this 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 you’d like to see addressed