Wireless Mobile Platform OAEP

33 %
67 %
Information about Wireless Mobile Platform OAEP
Science-Technology

Published on June 15, 2007

Author: Abbott

Source: authorstream.com

Wireless Mobile Platform OAEPLessons, Progress, and Future Work:  Wireless Mobile Platform OAEP Lessons, Progress, and Future Work David Wagner UC Berkeley Platform Innovations:  Platform Innovations TinyOS 1.1 New release processes Integrating Midterm Demo Enhancements:  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 TinyOS 1.1 Release:  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 Beta Release Process:  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 Network Innovations:  Network Innovations A better MAC layer High-speed sampling Lib/Route Reliable bulk transport B-MAC:  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 High-frequency Sampling & Logging:  High-frequency Sampling andamp; Logging Supports up to ~ 16 KHz sampling on mica, mica2 motes Fast logging flash-based file system (512kB) Low jitter: andlt; 10μs at 6 KHz 2.5kHz, mote shaken 2.5kHz, mote dropped Matchbox flash filer 1 KHz RAM RT averaging Robust Ad-hoc Routing:  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) andgt;98% reliability on CC1000 Reliable Bulk Transport:  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) creation handshake, implicit tear-down Selective acknowledgements, retransmission Data transferred reliably from RAM 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 start buf alloc ok *** data ack vector Pushing Scale Throughout the Platform:  Pushing Scale Throughout the Platform Manufacture and deployment time Network Longevity Network Programming Simulation Testbeds and New Platforms Some Lessons from Midterm Demo:  Some Lessons from Midterm Demo Packaging matters Good: Minimize exposure to the elements, lift antenna away from ground Bug: Unexpected interaction between antenna andamp; 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 ultrasound Mica2 dot mag sense power battery reflector Collision absorption O-ring Seal Good thermal characteristics Midterm Lessons:  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 =andgt; 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) Long-term Deployments in Harsh Climate:  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 Typical Network Architecture:  Typical Network Architecture Transit Network Basestation Gateway Sensor Patch Patch Network Base-Remote Link Data Service Client Data Browsing and Processing Sensor Node Widely dispersed Dense patches 1 km in GDI Solar-powered mote with big antenna Power Management: Cooperative Interfaces:  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 permissible depth 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) Monitoring and Management of the Network:  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 Low-power Event Dissemination: Trickle:  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 =andgt; 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 Slide19:  Scalable Network Programming:  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 Network Reprogramming: Deluge:  Network Reprogramming: Deluge Data dissemination protocol for program data Program size (128K) andgt;andgt; 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. Network Reprogramming: Deluge:  Network Reprogramming: Deluge Sample TOSSIM data on 25 nodes in long rectangle Scalable, Scriptable TinyOS Simulation:  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 =andgt; each script agent is a closure Development Testbeds:  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 andamp; educational tools Towards a Level 2 Node:  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 Card Bottom View Telos: Exploring Next-Generation Possibilities:  Telos: Exploring Next-Generation Possibilities Single board philosophy Robustness, Ease of use, Lower Cost Integrated Humidity andamp; 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 andamp; 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) Other Innovations:  Other Innovations Ranging and Localization Ranging and Localization:  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 Shadowing:  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 =andgt; 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 MobiLoc: Mobility Enhanced Localization:  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 NEST Final Demo Plans:  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 Questions?:  Questions? DARPA Template Slides:  DARPA Template Slides Administrative:  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: Subcontractors and Collaborators:  Subcontractors and Collaborators Subcontractors … Collaborators … Project Name:  Problem and Challenge FY04 Schedule Impact … New Ideas … Additional Supporting Text… Problem and Challenge Description 1QFY03 Tasks/Milestones 2QFY03 Tasks/Milestones 3QFY03 Tasks/Milestones 4QFY03 Tasks/Milestones Project Diagram Here Project Name PI Name Affiliation Problem Description/Objective:  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 Project Status:  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 Goals and Success Criteria:  Goals and Success Criteria Give very concrete metrics that can be measured Specify explicit Go/No-Go decision points Project Plans:  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 Project Schedule and Milestones:  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 Technology Transition/Transfer:  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 Program Issues:  Program Issues Provide information on existing or anticipated problems with the project or the overall NEST program that you’d like to see addressed

#pages presentations

Add a comment

Related presentations

Related pages

Wireless Mobile Platform OAEP, SlideSearchEngine.com

Wireless Mobile Platform OAEP #pages Science-Technology presentation by Abbott
Read more

Wireless Mobile Platform OAEP Lessons, Progress, and ...

Wireless Mobile Platform OAEP Lessons, Progress, and Future Work - PowerPoint PPT Presentation
Read more

1 Wireless Mobile Platform OAEP Lessons, Progress, and ...

1 Wireless Mobile Platform OAEP Lessons, Progress, and Future Work David Wagner UC Berkeley. Published by Modified about 1 year ago
Read more

Wireless Mobile Platform OAEP Lessons, Progress, and ...

Wireless Mobile Platform OAEP Lessons, Progress, and Future Work. David Wagner UC Berkeley. Platform Innovations. TinyOS 1.1 New release processes.
Read more

1 Wireless Mobile Platform OAEP Lessons, Progress, and ...

Slide 1 1 Wireless Mobile Platform OAEP Lessons, Progress, and Future Work David Wagner UC Berkeley Slide 2 2 Platform Innovations TinyOS 1.1 New release ...
Read more

Ppt Automatic-mobile-recharger-station | Powerpoint ...

View and Download PowerPoint Presentations on AUTOMATIC MOBILE RECHARGER STATION PPT. ... Presentation Summary : Wireless Mobile Platform OAEP Lessons, ...
Read more

oAEP Alternatives and Similar Software - AlternativeTo.net

Popular Alternatives to oAEP for Windows, Mac, Linux, Android, Android Tablet and more. Explore 9 apps like oAEP, all suggested and ranked by the ...
Read more

oAEP Alternatives for Windows - AlternativeTo.net

Popular Alternatives to oAEP for Windows. Explore 6 Windows apps like oAEP, all suggested and ranked by the AlternativeTo user community.
Read more

1 Wireless OEP Secure Language-Based Adaptive Service ...

1 Wireless OEP Secure Language-Based Adaptive Service Platform (SLAP) for Large-Scale Embedded Sensor Networks David Culler, Eric Brewer, David Wagner,
Read more

PPT – Improving Wireless Data Transmission Speed and ...

Improving Wireless Data Transmission Speed and Reliability to Mobile Computing Platforms - PowerPoint PPT Presentation
Read more