Your Document Title Presenter name and topic

1
DYNAMIQUE
DYNamic Adaptation in Mobile Internetworked
QoS-Aware Uninhabited Environments Allalaghatta
Pavan, Lee Graba, Ionut Cardei, Ho Wei Bai,
Srivatsan Varadarajan Sabera Kazi, Tom Phinney
Honeywell Laboratories, Minneapolis, MN Robert
Goldberg, Robert Martin ITT Industries
Aerospace/Communications, Clifton, NJ ONR
Program Review August 1-3, Berkeley, CA
2
Outline

• The Challenge
• Problem Statement
• DYNAMIQUE Project Objectives
• Existing Work and Whats New in DYNAMIQUE
• DYNAMIQUE Military Relevance
• Benefits of Proposed Approach
• Technical Approach
• Demonstration Plan
• Evaluation Plan and Metrics
• Progress to date

3
The Challenge

• ONR Vision
• A multi-tiered dynamic ad hoc network containing
  various unattended flying platforms (UAVs) -
  Internet-in-the-Sky, collaborating to support
  time-critical multi-mission applications.
• The Challenge
• Provide access and sharing of limited resources
  to multiple applications in the ad hoc network.
• Adapt to meet the dynamic functional and
  performance requirements (QoS) of distributed
  mission critical applications in the ad hoc
  network -
• Dynamic changes in the physical network
• Dynamic changes in the availability of limited
  resources
• Dynamic changes in mission requirements
• Our Hypothesis
• An adaptive end-to-end QoS-aware middleware can
  meet this challenge.

4
Problem Statement

• Mission-critical applications compete for limited
  resources with non-critical applications risking
  mission failures!
• Guarantee high-level functional and performance
  requirements (Quality-of-Service)
• e.g. Surveyed area, End-to-end delay (deadline),
  Image quality (NIIRS rating), Image Rate
  (frames/sec), Image Size, and Number of target
  classes recognized.
• Problem
• Provide required resources to mission critical
  applications while maximizing
• execution quality of non-critical applications
• Translate high-level application requirements
  into task requirements
• Translate task requirements into CPU, network,
  sensor-net, database requirements
• Allow multiple applications (mission critical,
  essential and non-essential) to share the limited
  
• resources to maximize their QoS
• Enable adaptation based on dynamically changing
  and multi-dimensional
• resource requirements to continue to meet the
  applications QoS
• changes in the ad hoc network, the resource
  constraints, and, the mission requirements

5
Problem Statement Failure Modes and Constraints
Absence of QoS provisioning and a non-adaptive
system can lead to mission failures
Need an end-to-end multi-resource solution
X
Power constrained at a node
Node failure
X
Link failure/s
Interference (weather/jamming)
6
DYNAMIQUE Project Objectives

• Provide a mechanism for mission critical
  applications to access and share limited
  resources via
• QoS specification, translation, negotiation and
  admission control and allocation
• Provide mechanisms to adapt application QoS in
  response to dynamic changes
• changes in the ad hoc network, changes in
  resource availability and changes in mission
• Proposed Solution Develop The ARMMNet Adaptive
  Resource Management System
• - a middleware between applications and the
  underlying network-wide resources, featuring
• Inter-application (external) adaptation
• QoS Expansion and Contraction
• Intra-application (internal or feedback)
  application
• Monitoring and Detection of Delivered QoS
• Feedback Adaptation of Current Operational Point
• QoS Aware Adaptive Applications
• Operational parameters that can be changed on the
  fly

7
Project Objective The ARMMNet Middleware
QoS mgmtper app
Multidimensional QoS-aware algorithms (e.g video
compression, target detection, )
Adaptive Applications
app QoS mgmt
ARMMnet comm
comm QoS mgmt

Adaptive Transport Layer
OS QoS mgmt
Adaptive Network Layer
Adaptive QoS Aware Protocols
QoS mgmt per socket
Adaptive Data Link Layer
FEC other coding
bit-coding selection
Adaptive Radios/ Wireless Channel
spreading or turbo code selection
chip/baud generation correlation/detection

frequency selection
up/down-conversion
QoS mgmtper task/thread
Operating System
power beamforming
antenna gain selection
8
Relationship with Sensor-net Middleware
9
Existing Work and Whats New

• Shortcomings of existing technologies
• Accessing and sharing resources
• Only a subset of resources considered (network or
  CPU in isolation)
• Static and homogeneous environments
• Limited to particular application class or
  services
• Adapting to changes
• Limited adaptations Only Inter-application
  adaptation or mission mode changes in isolation
• Inadequately address feedback adaptation
  (monitoring, detection and correction)
• Wired networks only
• Whats new in ARMMNet?
• Accessing and sharing resources
• Heterogeneity, changing resource sets (dynamic ad
  hoc network)
• Integrated resource management (CPU, network,
  database together)
• Variety of application classes
• Adapting to changes
• Comprehensive QoS and adaptation model (inter-,
  intra- and feedback adaptations)
• Handle a variety of changes in the dynamic ad hoc
  network network, resources and missions
• Adaptation permeating at all levels (mission,
  application, tasks, middleware, network
  protocols,

10
DYNAMIQUE Military Relevance
Examples of limitations in current military
missions that ARMMNet will overcome

• Surveillance Mission (using ATR)
• ATR applications consume bandwidth (several Mbps)
• Currently cannot share bandwidth, use dedicated
  satellite links, off-line transmitted and stored
• Computationally intensive (gt30 Gflops per image)
  - cannot share compute resources
• Off-line stored and processed
• Supported on expensive dedicated h/w, s/w and
  satellite links
• Distributed execution and near-real-time data
  fusion not possible
• Delay sensitive (deadline lt 10s)
• Currently, no guarantees on deadline - off-line
  processed
• Run in non-adaptive environments, is not
  QoS-aware
• Netted Fires Mission
• All messages during fire mission are high
  priority - need low delay (QoS) guarantee
• Currently preplanned dedicated networks to
  achieve this
• Operationally better to complete existing mission
  than begin a new mission
• No current policy for stressed network
• Fire request acceptance and resource allocation
  currently human functions
• Currently Inter-unit requests via humans - need
  database resources

11
Benefits Evidence from wired networks
Lower execution ratio gt Higher probability of
failed missions
without
Adaptation by QoS shrinking vastly improves
execution success ratio. e.g 0.39 to 0.98 for
medium criticality apps. gt 151 increase in
mission success
Unbounded latency gt Failed surveillance mission
with
Feedback adaptation reigns in unbounded latency!
12
Technical Approach QoS Contract Example
13
Approach ARMMNet QoS Contract Negotiation
Adaptation
Goals - Guarantee critical tasks -
Maximize essential tasks - Maximize task
QoS for each class - Minimize resource
management overhead

• Basic strategy

Application request for a QoS contract or events
necessitating adaptation
e.g. lt100ms worst case time to admit
lt100ms worst case time to adapt lt
5overhead (10s in a 60-frame 4 minute run)
if no resources assigned assign and
allocate else adjust allocation
(1) Search for a feasible solution with
QoS and resource constraints (2) Mechanisms
for search and enactment
Results

• A (re)negotiated QoS contract
• QoS contracts of existing applications adjusted
• QoS of executing tasks adjusted within their
  contracts
• Certain non-critical tasks suspended or
  re-mapped
• Denial of a contract

30
14
Scenario QoS Contract Negotiation

• First FLIR ATR request
• Requested QoS
• (512x512, 1024x1024), (8 fps, 16 fps) gt max
  3Mbps
• Granted QoS
• (512x512, 768X768), (8 fps, 14 fps) gt max 1Mbps

15
Scenario QoS Contraction (Inter-Application
Adaptation) Example 2

• Second FLIR ATR request (same priority)
• Requested QoS
• (512x512, 1024x1024), (8 fps, 16 fps) gt max
  3Mbps
• Granted QoS
• (512x512, 768x768), (8 fps, 12fps) gt max 0.5
  Mbps
• Appl 1 undergoes QoS contraction
• (frame rate adjusted)

16
Scenario QoS Contraction (Inter-Application
Adaptation) Example 3

• Third FLIR ATR request (higher priority)
• Requested QoS
• (512x512, 1024x1024), (8 fps, 16 fps) gt max
  3Mbps
• Granted QoS
• (512x512, 768x768), (8 fps, 14fps) gt max 0.5
  Mbps
• Appl 1 and 2 undergo QoS contraction
• (frame rate adjusted to (8, 10))

0.5
0.25
0.25
17
Scenario QoS Expansion (Inter-Application
Adaptation) Example 3

• Third appl departs (higher priority)
• QoS of appl1 and appl2 expanded to
• (512x512, 768x768), (8 fps, 14 fps)
• gt max 0.5Mbps each
• appl1 and appl2 undergo QoS expansion
• rate increased for both appls

0.25
0.5
0.5
0.25
18
Scenario Network Layer Triggered Adaptation

• Noisy or broken link between UAVs causes appl1
  and appl2 to be rerouted in the network

X
1
0.5
1
19
Scenario Power Triggered Adaptation

• Low transmit power at intermediate UAV causes
  appl1 and appl2 to adapt
• QoS regions shrunk for both appl1 and appl2 to
• (256x256, 768x768), (8 fps, 10 fps)
• gt 0.25 Mbps max for both appls
• Rate adjusted for both appls

X
1
0.5
0.5
0.5
Power constrained at a node
20
Approach ARMMNet Service Architecture
Service Manager (SM) as a recursive building block
21
Joint Demonstration Plan with UCLA
Testbed

• Year I Testbed Setup (HL and UCLA)
• Year II Single ATR application with basic QoS
  and basic network triggered adaptation
• Year III Multiple ATR applications with inter-
  and intra-application and advanced network
  triggered adaptation, mission mode changes
• Year IV Complete ATR demos, basic Netted Fires
  applications and radio channel triggered
  adaptations
• Year V Fully integrated ATR and Netted Fires
  scenarios with all adaptation scenarios

22
Evaluation Plan and Metrics
Execution Success Ratio

• Joint simulations (HL/UCLA/ITT) using QualNet
  simulation tool
• Year I
• Setup, training and basic models of ARMMNet with
  QoS
• Year II
• Advanced models of ARMMNet with inter- and
  intra-application adaptation
• Basic network triggered adaptation
• Basic ATR model
• Year III
• Advanced inter- and intra-application and network
  triggered adaptation with multiple ATR apps
• Adaptive radio models
• Basic Netted Fires scenario
• Year IV
• Advanced Netted Fires scenario
• Radio channel triggered adaptation
• Year V
• Integrated ATR Netted Fires with all adaptations

Number of executed applications at criticality i
Number of requested applications at criticality i
QoS Adaptation Success Ratio
Number of completed QoS adaptation requests
Total number of QoS shrinking requests
Admission Probability
Number of QoS contracts satisfied
Total number of QoS contracts requested
ARMMNet Protocol Overhead Average Admission
(Adaptation) Time
S Admission (adaptation) times for N apps
N
23
Progress to date

• Systems requirements (75 complete)
• ATR and Netted Fires scenarios
• Adaptation scenarios for ATR (complete)
• QoS Parameters for ATR (complete)
• Functional requirements for Netted Fires
  (ongoing)
• ARMMNet Middleware
• System architecture
• Service Manager (SM) design
• Interfaces (ongoing)
• Components (ongoing)
• Software structure (ongoing)
• Inter-SM and Intra-SM protocols for resource
  management
• Basic admission control and adaptation protocol
  (ongoing)
• QualNet Simulations (ongoing), Joint simulation
  plan (completed)
• Adaptive QoS Protocols
• Interface definition for the network protocols
  (ongoing)
• Adaptive Radio - Assessment and Demonstration
• Identify COTS and ITT radios (ongoing)
• Define experimentation and demonstration plan
  (complete)