Dr. Vijay Raghavan Defense Advanced Research Projects Agency Information Exploitation Office

  • View
    25

  • Download
    2

Embed Size (px)

DESCRIPTION

Network Embedded Systems Technology (NEST). Workshop on Extreme Scaling Arlington, VA. Dr. Vijay Raghavan Defense Advanced Research Projects Agency Information Exploitation Office. November 12, 2003. Meeting Purpose. - PowerPoint PPT Presentation

Text of Dr. Vijay Raghavan Defense Advanced Research Projects Agency Information Exploitation Office

  • The attacks are primarily in the eastern 100 miles, which is coincidentally the section which is operated by a US subsidiary of Occidental Petroleium. Each outage day represents about $1.5M in lost revenue, so there is a huge financial incentive to solve this problem.

    The red dots represent pipeline punctures, and the green represent pipeline dents, so every attack is not successful in terms of stopping flow.

    This inset chart shows the altitude..the pipeline travels over some very mountainous areas, b ut a large fraction of the distance is in triple canopy jungle.

    *UNCLASSIFED FOR OFFICIAL USE ONLY

    300 kmborderIRAQSYRIAAL QAIMIRAQ / SYRIA Border October 2003

    *UNCLASSIFED FOR OFFICIAL USE ONLY

    Kansas Pipeline Canonical 10,000 Node Problem25 kmdirt road500m500mSensor node with 50m rangeExfiltration node (PDA)Both sides1% of Total LaydownSchedule3 month6 month9 month12 month100030006000Full systemdemonstrationSpecs Dismounts armed and unarmed Vehicles 2 second latency < $150/node Pfa < 1 alarm/day Pd = 0.95 at walking speed

    *UNCLASSIFED FOR OFFICIAL USE ONLY

    The Big Three Problems - MITRESensor RangeRequire a magnetometerThe sensor range needs to be ~1.3x the node spacing.In this case ~65 m.Magnetometer ranges of 65 m are beyond the state of the art.Earths magnetic noise exceeds the signal by ~10x.Over-the-Air LoadingThis is a complex service:Reliable multicast (i.e., with local retry).May need group service.Very strong motivation towards incremental loading.Some application may need to run while others load.Implies dynamic linking.Requires OS-style security

    *UNCLASSIFED FOR OFFICIAL USE ONLY

    The Big Three Problems - MITRESentry Service (power)The required on subset of the network will be too large.Alternative drives up required sensor range.Extending system life by raising node density is inferior to just using bigger battery

    Need temporal sampling.Need power savings of ~100x. Need the almost always off communication model.Maybe comm. deadline and comm. scheduling.

    *UNCLASSIFED FOR OFFICIAL USE ONLY

    Feedback from 9-22-03 Conference CallTimeline is too aggressiveJune 04100December 041000June 0510,0002. Sensor mix: a. Magnetics unlikely to detect weapons at ranges > 1mb. PIR unlikely to be a cure-all c. Consider McKuen radars3. Comms range seen as problematic

    4. Need 4 X more PDAs Pfa / lifetime / latency very aggressive

    *UNCLASSIFED FOR OFFICIAL USE ONLY

    Feedback from 9-22-03 Conference Call (cont.)Need for rock-solid over air loading capability needed to demonstrate scalability and this is not currently in hand.Architecture work needed.Power is a huge problem for a demonstrationAlways on needed to achieve PfaDebugging and software loads are battery intensiveLifetimes are currently far too short7.Solid packaging needed (one touch only) Need a separate contractor to actually camp in desertand deploy sensors9. Next tier PDA work needed , as well as highest tier (GUI)

    *UNCLASSIFED FOR OFFICIAL USE ONLY

    Feedback from 9-22-03 Conference Call (cont.)Dynamic tagging seen as an alternate approach that demonstrates scalability without problems in static sensor laydown11. Rush to production seen as a costly mistake. A disciplined,Step-by-step process with formalized acceptance criteria at eachStage was recommended to avoid a failure.

    *UNCLASSIFED FOR OFFICIAL USE ONLY

    Systems that Scale Well1. Self-contained sensors2. Self-contained static sensor clusters3. Sensor clusters with handoff interactions

    *UNCLASSIFED FOR OFFICIAL USE ONLY

    Systems that Scale Well (cont.)4. Sensor clusters with dynamic assignments5. Robust systems that adjust to sensor dropouts, etc.6. Systems which maintain only local state

    *UNCLASSIFED FOR OFFICIAL USE ONLY

    Systems That Do Not Scale Well1. Any system with a non-zero Pfa per sensor node 2. Any non-robust system that requires multiple touches per sensor3. Any system with performance that can be degraded by a malfunctioning, poorly placed, or imperfect node.4. Any system that creates a disproportionate response to stimuli 5. Any system that does not plug into umbrella information systems

    *UNCLASSIFED FOR OFFICIAL USE ONLY

    Conclusion For most applications sensor nets are inherently scalable, but their implementations are often not

    The path to practical scalable systems lies through careful extensible architecture work and bulletproof hardware/software design

    It may be possible to demonstrate (but not fully test) a scalable system with fewer than 10,000 nodes

    *UNCLASSIFED FOR OFFICIAL USE ONLY

    Lessons from the UCB Wireless OEP Demo and Issues in Scaling Sensor WebsCory Sharp, Robert Szewczyk, Massimo Franceschetti, Prabal Dutta, David Culler, Shankar Sastry

    NEST Extreme Scaling Workshop,Washington, DC11/12/2003

    *UNCLASSIFED FOR OFFICIAL USE ONLY

    Lessons from UCB DemoScaling Issues we set out to tackleThings that proved very valuableThings that proved problematicThings we wished we hadMonitoring and Restart from the BeginningScalable Network ReprogrammingFoundations of ScaleRecommendations

    *UNCLASSIFED FOR OFFICIAL USE ONLY

    Scaling Issues We Designed For

    *UNCLASSIFED FOR OFFICIAL USE ONLY

    Key Pragmatic IssuesSolve the specific problem within time and $ budgetReliablyTime, Time, Time, Time

    Time to design, prototype and test what you think is a working hardware & software solutionNot at scaleTime to manufacture a large number of nodesOnly get one shot (be conservative)Time to test-fix-test-integrate-test-fix- Dont see scaling issues until late in the process~1000 person-hours in last two weeksTime to assemble, reassemble, Human scaling limits

    *UNCLASSIFED FOR OFFICIAL USE ONLY

    HardwareDriven by specific application planNot generic experimental like MicaUsage factorsoutside, robots running over it, in-sun, possibly wet, Specific sensing modalitiesBoard designs, Geometric orientation, Mechanical Design is central (co-design)Appn => package => boards

    Foresee the needs of dev, debug, deployment processField UI, resetAssembly, re-assembly, recharging process

    Minimize exposureLift radio off the ground

    *UNCLASSIFED FOR OFFICIAL USE ONLY

    PEG Mechanical DesignExposed componentsWatertight compartmentultrasoundMica2 dotmag sensepowerbatteryreflectorCollision absorptionO-ring SealGood thermal characteristics

    *UNCLASSIFED FOR OFFICIAL USE ONLY

    SoftwareNEST service architecture as a beginningGreater number => simpler functionComplete modularity of each subsystemNode positioningSensing and reportMobile-to-mobile routingPursuer hear and navigateNot just source concept, but full interfaces to allow testing in the field of each without the others to blameDelay Binding Wherever PossibleComplete parameterizationThresholds, update rates, ranges, Management servicesAssume irregular, lossy connectivity

    *UNCLASSIFED FOR OFFICIAL USE ONLY

    Algorithmic Simplicity by DecompositionLowest-tier nodes only performed entity detectionLocal processing, threshold detection, announceSimple Leader ElectionSimple aggregation for position estimationLittle calibrationSimple mobile-mobile reliable routingSolid tree rooted at landmarkComplexity consolidated in higher tierDisambiguationTrajectory EstimationNavigationNoise-adaptive control loopMinimalism paysNice to have solid theory to support doing very simple things

    *UNCLASSIFED FOR OFFICIAL USE ONLY

    Steps that proved invaluable

    *UNCLASSIFED FOR OFFICIAL USE ONLY

    Management ServicesIdentPing, Version, Compile timeCommand line scriptingCheck all report inCheck config valuesConfigSet/Get each potential parameterAutomated behaviors on updateSave/Restore to FlashHuman overrideResetSleep / Wakeup

    *UNCLASSIFED FOR OFFICIAL USE ONLY

    Simple and SolidOnce a node is assembled, if it responds to Ping, it should workReliability of quick test was keyComplete testing of each major component at near-scale in isolationClean stimulus, observable responseCombining was trivialPowerful receiver to see what was going on in much of network

    *UNCLASSIFED FOR OFFICIAL USE ONLY

    Multiple Fall BacksLocalization: fix the position based on network addressTransform of addressExplicit SetRangingRoutingSingle hop to base802.11 back channel to pursuerEvader-pursuer back channelLandmark routingExcellent signal-strength based slow tree buildSensingUsed most of them in testingKept them in the codeReduced stress along the way

    *UNCLASSIFED FOR OFFICIAL USE ONLY

    Things that Proved Problematic

    *UNCLASSIFED FOR OFFICIAL USE ONLY

    HardwareBiggest Risk FactorGetting boards done and software working in timeBudget allowed only one production shotScale was limited by slowest production stepAntenna Internal coiled antenna was dismal => external whipProved to be time consuming and problematic in assemblyweak mount point (10% loss)Recharging required disassembly (see above)Power conditioning introduced noise issues & leakageUnforeseen interactionsRadio + magnetometerUsed the wrong kind of wire (duh!)No self-guided assemblyModularity, while has many values, has a significant costToo hard to see LEDsno physical resetMultiple antennas on pioneers interferedDifferential GPS black magic TIME, TIME, TIMEYou dont know what is wrong till late in the development

    *UNCLASSIFED FOR OFFICIAL USE ONLY

    SoftwareNetwork programming fell apart for large app on many nodesDictated the development cycleConfig was life saverGot solid single hop just after it was neededCurrent design has deep shortcomings (below)Software Knowledge bottleneckNice abstractions that too few people knew how to useUnderestimated the amount of glue code between the tiersWished we hadBetter Regression suitesLogged EverythingMuch better op