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. acoustic ultrasound mag dot 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. 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 B-MAC

8. 16 KHz sensor 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 RAMRT averaging Matchbox flash filer 1 KHz 2.5kHz, mote dropped 2.5kHz, mote shaken

9. RFM End-to-end Success vs. Distance 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

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 *** ack vector data ok start

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 • 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 O-ring Seal ultrasound Mica2 dot mag sense power Good thermal characteristics battery Collision absorption

13. 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 Midterm Lessons • 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. Internet Typical Network Architecture Widely dispersed Dense patches Patch Network Sensor Node Sensor Patch Gateway 1 km in GDI Solar-powered mote with big antenna Transit Network Client Data Browsing and Processing Basestation Base-Remote Link Data Service

16. Application: query processing detection, reporting Sensor Drivers & Filters Comm Stack Timer Sensor 3 Sensor 2 Radio Clock Sensor1 Power Management 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. • 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

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. 1. Advertise 2. Request 3. Transmit 4. Repair Version: 2 Pages: (0,1,2) Version: 2 Pg: 0, Pkt: 15 Page: 0 Pg: 0, Pkt: 3 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.

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 => 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... Bottom View Top View w/ Daughter Card

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 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 • 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. PI Name Affiliation Project Name Problem and Challenge New Ideas • … Problem and Challenge Description Project Diagram Here Additional Supporting Text… Impact • … FY04 Schedule • 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 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