1 / 66

Opportunistic Resource Utilization Networks (Oppnets) for UAV Ad-Hoc Networking

Opportunistic Resource Utilization Networks (Oppnets) for UAV Ad-Hoc Networking. Phase I Final Review Infoscitex Corporation 25 Feb 2011. Agenda. Project Team Technical Overview Task Summary and Discussion Future Work Conclusions Infoscitex Background. Project Team.

blanca
Download Presentation

Opportunistic Resource Utilization Networks (Oppnets) for UAV Ad-Hoc Networking

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Opportunistic Resource Utilization Networks (Oppnets) for UAV Ad-Hoc Networking Phase I Final Review Infoscitex Corporation 25 Feb 2011

  2. Agenda • Project Team • Technical Overview • Task Summary and Discussion • Future Work • Conclusions • Infoscitex Background

  3. Project Team • Infoscitex Corporation • Principal Investigator: Andrew DeCarlo Email: adecarlo@infoscitex.com / Phone: (781) 890-1338 x289 • Project Manager: Dr. Sherman Tyler Email: styler@infoscitex.com / Phone: (781) 890-1338 x263 • Subcontractors • Western Michigan University: Dr. Leszek Lilien • Purdue University: Dr. Bharat Bhargava

  4. Agenda • Project Team • Technical Overview • Task Summary and Discussion • Future Work • Conclusions • Infoscitex Background

  5. Problem to be Solved • Resource virtualization maximizes distributed application performance • Resources allocated and adapted on-the-fly • Allows a broad range of distributed computing, networking, and sensing applications • Content- and context-based data management • Service-Oriented Architecture (SOA) • Virtual Private Networks (VPNs) • Coordinated network security • Barriers to resource virtualization in mobile ad-hoc networks (MANETs) • MANETs are less structured than traditional networks • Special challenges result from this lack of structure: • Frequent link breakage • Inconsistent data rate • Incompatibility of resources • Temporary unavailability of needed resources and communication links

  6. Opportunistic Resource Utilization Networks (Oppnets) for UAV Ad-Hoc Networking: Novel MANET consisting of an initial seed network that temporarily recruits resources. Oppnets: Allow the construction of highly adaptive, flexible, and maintainable application networks Utilize and enhance applications, even including inflexible, stovepiped, legacy applications Adapt and optimize the use of resources on-the-fly Enable and facilitate distributed applications Virtualize resources across platforms, allow scalability, and promote dynamic growth Oppnets are: Opportunistic resource/capability utilization networks Opportunistic growth networks Specialized Ad-Hoc Networks/Systems (SAHNS) Oppnets are not: “Generic” ad-hoc networks Mesh networks Grid computing systems P2P networks Opportunistic connectivity networks Oppnets exploit diverse capabilities such as radio spectrum, connectivity, computing power, sensing, actuation, and image recognition The Infoscitex Solution (Oppnets)

  7. Fighter Satellites X-47B UCAS Seed Oppnet Radar Processing LCSs Carrier Merchant Ships Target USVs Underwater Acoustic Array The Oppnet Concept Oppnets recruit and coordinate the capabilities of diverse networks, sensors, and computational resources in a way that optimizes resource utilization and also ensures improved QoS despite intermittent link connectivity. Oppnet links non-Oppnet UCAS links to Carrier

  8. Technical Objectives • Identifying Key Use Cases: • Identify one or two basic use cases for proof of concept, including any: • Mobility models • Helper networks • Necessary resources • Develop tactical Oppnets based on use cases • Developing Tactical Oppnet Capabilities: • Implement resource virtualization, network optimization, and network expansion capabilities within scope of use cases • Emphasize security, modularity, scalability, SOA support, and QoS improvement • Tailor Oppnets for X-47B UCAS and other platforms • Testing and Demonstrating Oppnets: • Simulate Oppnets’ performance in software • Fine-tune the general Oppnet implementation for selected use cases • Hardware testbed simulation • Proof-of-concept demonstration

  9. Agenda • Project Team • Technical Overview • Task Summary and Discussion • Future Work • Conclusions • Infoscitex Background

  10. Phase I Milestone Schedule 9/22/2014 10

  11. Task 1: Identify Key Use Cases • Use Case Features: • Carrier Strike Group (CSG) consisting of carriers, Littoral Combat Ships (LCSs), and other air/surface vehicles • X-47B UCAS on carrier acts as a seed Oppnet • Seed recruits capabilities including: • Sensing • Data links • Computation • Actuation • Resource/capability virtualization methods include: • Service directory lookup • Lookup from helper networks’ service directories • True discovery

  12. Oppnet Use Case Example Fighter Satellites X-47B UCAS Seed Oppnet Radar Processing LCSs Carrier Merchant Ships Target USVs Underwater Acoustic Array 9/22/2014 12

  13. Task 1: Identify Key Use Cases Helpers 4-7 used to compute statistics in simulation results: The seed Oppnet needs to integrate a radar plot, and requests assistance from LCS1 (Helper 4). Helper 4 is unable to do the integration itself, so it recruits the satellite link (Helper 5) to search for available services. Helper 5 connects to several different radar processing capabilities (across two hops total) that comprise Helper 6. The integrated radar plot returned by Helper 6 comes up empty, so the seed Oppnet truly discovers an F/A-18E fighter flying overhead. The F/A-18E becomes Helper 7, and identifies and localizes the target, allowing the seed Oppnet to send pursuit vehicles after the target. Helpers 4-7 are key to the use case Involve scalability, multiple hops, and resource/capability virtualization (Helper 6) Use all three discovery types (service directory lookup, discovery through helper’s service directory, true discovery) Improve the UCAS’ speed and accuracy in identifying and apprehending a fast-moving surface target 9/22/2014 13

  14. Use Case Breakdown 18 20 44 Radar Plot Integrator Helper 4 UCAS Seed Oppnet 41 21 22 28 33 37 17 43 45 51 19 42 23 24 46 47 27 48 25 50 52 30 32 36b 38 40 F/A-18E Super Hornet, Helper 7 31 26 Radar Plot Analyzer Helper 6 39 AEHF Satellites Helper 5 36a 49 34 29 35 9/22/2014 14

  15. Task 2: Develop Tactical Oppnet Capabilities Oppnet Capabilities Resource/capability virtualization, network optimization, network expansion Capabilities are implemented with an emphasis on: Security Modularity Scalability SOA support QoS improvement Previously demonstrated in CBRN first-responder applications 9/22/2014 15

  16. Lookup Subsequence 1) look up directory and identify reservist helper 2) order to join 3) joins and is integrated into Oppnet [Note: We assume for now that all ordered helpers are able to join.] 4) order helper to provide (activity) report OR: orderforwarding a task/message to helper H and for H's (activity) report 5) helper does its job 6) helper sends result report 7) receivereport from helper OR: receive andforward report 8) release helper (i.e., sends the releasemsg to the helper). Discovery Subsequence 0) failed look up for reservist helper 1) attemptdiscovery: scan & discovery (are discovered non-reservists Oppnet-enabled or not?) 2) ask to join 3) agree to join or not; if agreed, joins and is integrated into Oppnet 4) ask helper for (activity) report OR: ask for forwarding a task/message to helper H and for H's (activity) report 5) helper does its job 6) helper sends result report 7) receivereport from helper OR: receive and forward report 8) release helper Task 2: Develop Tactical Oppnet Capabilities 9/22/2014 16

  17. Oppnet considerations: Must not disrupt critical operations Must perform risk evaluation Must assure privacy and security Sequence of Oppnet Operations 9/22/2014 17

  18. Oppnet Expansion Process 9/22/2014 18

  19. Seed Nodes Name Functions SEED_scan Scan communication spectrum to detect devices that could become candidate helpers SEED_discover Discover candidate helpers with a specific communication mechanism SEED_listen Receive and save messages in buffer SEED_validate Verify the received command SEED_isMember Checks if a device is already an Oppnet node (Oppnet member) SEED_evalAdmit Evaluate a device and admit it into Oppnet if the device meets criteria for admittance SEED_sendTask Send a task to other Oppnet device SEED_delegateTask Delegate a task that requires a permission from the delegating entity SEED_release Release a helper when no longer needed SEED_processMsg Process a message from buffer SEED_report Report information to control center/coordinator Partial List of Oppnet Virtual Machine Primitives CC Nodes 9/22/2014 19

  20. Partial List of Primitives for Helper Nodes 9/22/2014 20

  21. Partial List of Primitives for Helper Nodes (cont.) 9/22/2014 21

  22. Partial List of Helpers for Lightweight Nodes 9/22/2014 22

  23. Task 2: Develop Tactical Oppnet Capabilities Oppnets as an extension of SOA SOA limited to lookup via predefined service directories in infrastructure Oppnets also provide true discovery QoS in Oppnets Common QoS requirements include: Availability Accessibility Integrity Performance Reliability Seed Oppnet itself might not possess all capabilities necessary to meet QoS requirements Pre-registered Reservists will provide the needed capabilities Other (discovered) helpers may improve QoS further Oppnets must invoke and utilize all capabilities in network to meet user-defined QoS requirements (e.g., time-sensitivity) Semantic Web capabilities QoS requirements may also assist in helper discovery and selection 9/22/2014 23

  24. Task 3: Test and Demonstrate Oppnets • Software Simulation • Fine-tuning Oppnet implementation • Providing information for customizing the implementation per each use case • Demonstrating feasibility

  25. Task 3: Test and Demonstrate Oppnets Ac. Array Ac. Array UCAS Speedboat F/A-18E UCAS Speedboat GOAL: Test the UCAS’ speed and accuracy in apprehending a fast-moving speedboat without (left) and with (right) Oppnets helpers 9/22/2014 25

  26. Simulation Input Parameters [1] Values < 1 will be considered in future simulation runs. 9/22/2014 26

  27. Simulation Random Variables [1] By simulation assumption, the yval of the point at which the F/A-18E enters AOR is 0. [2] Before starting to look for F/A-18E as a helper, UCAS asked for help 4 other helpers. Time to ask these 4 helpers and to find out that another helper is needed is the sum of individual times needed for each of these 4 helpers. Each individual time includes time for UCAS to locate and integrate the helper plus time to send the UCAS’ help request message to the helper plus time needed by the helper to process the help request and reply UCAS, and time for the helper’s reply message to reach UCAS. Time for forwarding messages among these helpers must also be added. 9/22/2014 27

  28. Results: Varying Delay in Integrating Helper for Speedboat Detection (Delays and Success Ratios) 9/22/2014 28

  29. Varying Delay in Integrating Helpervs. Delay in Speedboat Detection Integration Delay Integration Delay 9/22/2014 29

  30. Varying Delay in Integrating Helpervs. Success Ratios without and with Helper Integration Delay 9/22/2014 30

  31. Results: Varying Helper Density for Speedboat Detection (Delays and Success Ratios) 9/22/2014 31

  32. Varying Helper Density vs. SuccessRatios without and with Helper (Delay Range 1) 9/22/2014 32

  33. Varying Helper Density vs. SuccessRatios without and with Helper (Delay Ranges 2 and 5) 9/22/2014 33

  34. Varying Helper Density vs. Helper Integration Delay and Speedboat Detection Time (Delay Ranges 1 and 5) 9/22/2014 34

  35. Single-Fighter Denial of Help (Delays and Success Ratios) 9/22/2014 35

  36. Single-Fighter Denial of Help (Delays and Success Ratios) 9/22/2014 36

  37. Multi-Fighter Denial of Help (Delays and Success Ratios) 9/22/2014 37

  38. Multi-Fighter Denial of Help (Delay Range 1) 9/22/2014 38

  39. Multi-Fighter Denial of Help (Delay Range 2) 9/22/2014 39

  40. Multi-Fighter Denial of Help (Delay Range 5) 9/22/2014 40

  41. Conclusions • 10-helper use case broken down into 61-interaction simulation • Service directory lookup, helper directory lookup, and true discovery have all been simulated. • The effects of all relevant primitives have been simulated and verified with respect to the use case. • True discovery proves to be a very beneficial asset because: • Truly-discovered helpers can detect the speedboat in <4 sec after integration, compared with nearly 34 sec for directory-lookup helpers. • Success rate is at least two times higher with a truly-discovered helper than without one • Quickly approaches 100% for higher-helper-density lower-integration-delay scenarios. 9/22/2014 41

  42. Agenda Project Team Infoscitex Background Technical Overview Task Summary and Discussion Future Work Conclusions 9/22/2014 42

  43. Future Work • Considered Future Extensions: • Denial of help: Demonstrate the effects of a helper being unable to help. • Less-invasive help mode: Allow helpers (including truly-discovered helpers) to operate without requiring host/human intervention. • Introduce effects of detection probability: Vary the detection probability to address different surface conditions. • Introduce sensor array coverage areas: Simulate marginal and certain detection by acoustic sensor arrays. • Change initial speedboat position. • Vary speedboat movement patterns: Change from straight-line motion to random changes in velocity (e.g., evasive actions). • Use more random variables for helper integration: Assign random variables to quantify communication/processing among the helpers. • Consider longer helper integration delays. • Vary AOR size: Currently 100 mi by 100 mi. • Emphasize Radar Plot Integration:We currently assume radar plot integration in Helper 6 always fails. Consider variable plot integration success/failure. 9/22/2014 43

  44. Future Work Considered Future Extensions (continued): Effects of scalability on radar plot integration: Vary number and variety of resources/capabilities that comprise Helper 6, and show how this affects radar plot integration speed and success rate. Effects of service availability on radar plot integration: Vary whether or not resources/capabilities within Helper 6 are available. Merging Protocol Stacks: Show how merging protocol stacks within Helper 6 affects radar plot integration speed and success rate. Quality of Service: Measure the quality of service (available bandwidth, bottleneck bandwidth, one-way delay, packet loss ratio, etc.) in the communications links Model strength of assigned task:Assign strong tasks that require interruption of current tasks. Other extensions TBD 9/22/2014 44

  45. Phase II Task Plan • Task 1: Collect User and Operational Requirements • Detailed analyses of mobility constraints (e.g., maximum speed, cruising speeds, aircraft service ceiling), sensor parameters (e.g., range, field of view, sweep rate), etc. of identified helpers and SNAP entities • Study of resources and capabilities desired by the SNAP end users • Task 2: Implement Control/Seed Oppnet Virtual Machine (OVM) Primitives • Implement control and seed OVM primitives in the Oppnets testbed • Verify and validate primitives’ performance based on scalability, range of available services/capabilities/resources, and speed/computational efficiency in carrying out a mission • Task 3: Implement Helper OVM Primitives • Downselect to a controlled, well-defined set of helpers • Implement helper OVM primitives in the Oppnets testbed • Verify and validate primitives’ performance based on scalability, range of available services/capabilities/resources, and speed/computational efficiency in carrying out a missio • Task 4: Implement Lite OVM Primitives • Downselect to a controlled, well-defined set of lightweight nodes (lites) • Implement lite OVM primitives in the Oppnets testbed • Verify and validate primitives’ performance based on scalability, range of available services/capabilities/resources, and speed/computational efficiency in carrying out a mission 9/22/2014 45

  46. Phase II Task Plan (cont.) • Task 5: Module Assembly and Debug • Integrate the control, seed, helper, and lite OVM primitives as a system within the Oppnets testbed • Verify compatibility between modules • Develop any additional functionality and architecture requirements necessary for simulating the primitives together on the Oppnets testbed • Task 6: Simulation, Test, and Evaluation • Simulate the control, seed, helper, and lite OVM primitives as a system within the Oppnets testbed • Identify risks associated with further development • Develop a risk mitigation plan and list of design considerations • Task 7: Further Research, Development, Test, and Evaluation (RDT&E) • Implement design improvements identified in Task 6 • Perform additional system-level and module-level simulations as needed • Identify risks associated with large-scale systems integration • Task 8: Systems Integration • Develop risk mitigation plan for large-scale systems integration • Begin integration of Oppnets with SNAP • Investigate other large-scale systems that can benefit from Oppnets in the short term 9/22/2014 46

  47. Phase II Milestone Schedule 9/22/2014 47

  48. Agenda • Project Team • Technical Overview • Task Summary and Discussion • Conclusions • Infoscitex Background

  49. Agenda Project Team Technical Overview Task Summary and Discussion Future Work Conclusions Infoscitex Background 9/22/2014 49

  50. Who We Are 9/22/2014 • Engineering, Research and Development • Develop advanced technologies • Provide technical services • Founded in 2000 • Small Business 50

More Related