Using QuO Quality of Service Components in the UAV Application

1
Using QuO Quality of Service Components in the
UAV Application
Craig Rodrigues
BBN Technologies

• TAO CCM Meeting
• August 20, 2002

2
The Quality Objects (QuO) Framework Supports
Development of Distributed Applications with QoS

• Specifying and enforcing stringent QoS
  requirements for DRE applications is very
  difficult with existing middleware.
• BBN QuO works on top of DOC middleware to
  allow developers to develop QoS-enabled DRE
  applications, such as the UAV
• Presentation breakdown
• Architecture of QuO
• Applying QuO to UAV application to enforce QoS
  requirements
• Issues for integrating QuO in a Component Model
  framework

3
What QuO Middleware Provides the QoS Developer

• Separation of concerns between software
  functional properties and QoS needs
• Consistent interfaces for QoS measurement and
  resource management control
• Standard middleware interfaces between
  application and QoS-provider layers
• Facilities for application level-adaptation
• Off-the-shelf mechanisms and behaviors for QoS
  management

4
QuO Adds Specification, Measurement, and
Adaptation into the Distributed Object Model
Application Developer
CORBA DOC MODEL
Mechanism Developer
Application Developer
CLIENT
CLIENT
operation()
OBJ REF
out args return value
Delegate
Delegate
QuO Developer
SysCond
SysCond
SysCond
QUO/CORBA DOC MODEL
SysCond
IDL SKELETON
MECHANISM/PROPERTY MANAGER
IDL STUBS
OBJECT ADAPTER
Mechanism Developer
5
QuO Provides In-Band and Out-of-Band Measurement

• In-band measurement handled by instrumentation
• A structure is transparently passed along with
  the method call/return
• Information can be inserted, read, and processed
  to record and evaluate method call statistics
  (e.g., the time spent in marshalling)
• Out-of-band measurement provided by system
  condition objects

6
The QuO Toolkit Supports Building Adaptive
Applications or Adding Adaptation to Existing Apps

• QuO aspect languages
• Contract description language and adaptive
  behavior description language
• Code generators that weave QuO code into Java and
  C applications
• System Condition Objects
• Provide interfaces to resources, managers, and
  mechanisms
• QuO Runtime Kernel
• Contract evaluator
• Factory object which instantiates contract and
  system condition objects
• Instrumentation library
• QuO gateway
• Insertion of special purpose transport layers and
  adaptation below the ORB

CORBA IDL
Contract Description Language (CDL)
Delegates
Contracts
QuO Runtime
Code Generators
Adaptation Specification Language (ASL)
7
QuO Provides In-Band and Out-of-Band Adaptation
and Control

• In-band adaptation provided by the delegate and
  gateway
• A delegate decides what to do with a method call
  or return based upon the state of its contract
• Gateway enables control and adaptation at the
  transport layer
• Out-of-band adaptation triggered by transitions
  in contract regions
• Caused by changes in the system observed by
  system condition objects

8
Systemic Behaviors are Packaged into Reusable
Bundles Called Qoskets

• The Qosket encapsulates a set of contracts (CDL),
  system condition objects (IDL), and QoS adaptive
  behavior (ASL)
• The Qosket exposes interfaces to access QuO
  controls and information (specified in IDL)
• The Qosket separates the functional adaptive
  behavior (business logic) from the QoS adaptive
  behavior and the middleware controls from the QoS
  mechanisms

9
Writing a Qosket, Instantiating and Wrapping It,
and Specializing It to a Functional Interface
10
Applying QuO to the Current UAV OEP Application
11
The UAV Concept of Operations

• Sensors on the UAVs gather video, radar, and
  other information and transmit them to control
  stations
• Operators at stations send commands to the UAVs
  to pilot them, control their sensors, and to
  locate and prosecute targets

• Multiple UAV sources requires management of
  resources for delivery of sensor information
  control commands
• Differing missions require tradeoffs of data
  content and form
• Fidelity of sensor information must be sufficient
  for manual or automatic recognition of target
• End-to-end delivery, processing, and use of
  sensor information must be frequent and fast
  enough to support prosecution of time-critical
  (possibly mobile) targets

12
High Level View of UAV OEP Architecture
Control Station Host 5
UAV Host 1
Host 4
Video Source Process
Displays
Video Distributor Process 1
Filter
Throughput Contracts
Wired
Filter Contract
Bandwidth Management
UAV Host 2
Control Station Host 6
Video Distributor Process 2
Video Source Process
Displays
Filter
Throughput Contracts
CORBA A/V Streaming Service
Filter Contract
Bandwidth Management
Wireless Ethernet


UAV Host 3
Control Station Host 7
Video Distributor Process 3
Video Source Process
Display
Scale/ Compress
ATR
Bandwidth Management
ATR Contract
Quality Contract
13
QUO_ROOT/UAV/uav/qoskets contains Currently
Available Reusable Behavioral Qoskets

• async_sender - dispatches frames to receivers
  using separate threads, set
  thread priorities for use with RT-CORBA
• atr - responds to ATR alerts by modifying image
  quality of video sources
• diffserv - determines Diffserv codepoint to set
  for an A/V stream (similar to rsvp
  qosket)
• distributor - monitors received frame rate and
  signals preferred frame rate
  (MPEG)
• filter - determines which frames to drop (MPEG)
• fragment - fragmentation and reassembly of
  frames for transmission over
  network (RSVP)
• fragment_ppm - fragmentation and reassembly of
  PPM frames for transmission
  over network
• frame_proc - introduces external processing of
  frames, for use with testing
  RT-CORBA
• header - creates, parses, and optionally removes
  RTP header information for MPEG
  frames
• rsvp - determines RSVP reservation policy for an
  A/V Service stream

14
Conceptual View of UAV OEP Illustrating Qoskets
and Network Resource Management
Instrumentation
Instrumentation
RSVP qosket
Sender
Distributor
Diffserv qosket
Header qosket
Filter qosket
Header qosket
Distributor QuO kernel
Receiver
Dvdview
Header qosket
Instrumentation
15
Target Recognition Triggers Coordinated Adaption
Between Multiple Video Feeds
Receiver (PPM)
Distributor (PPM)
ATR QuoKernel
Send alert
Send frame
Change quality from (1) to (2)
Infopipes
DVDview (PPM)
(1) Low grade, ¼ size image filter, (2) High
grade, remove filter
(1) High grade, 10 fps, (2) Low grade, 2fps
Filter qosket
Receiver (MPEG)
Distributor (MPEG)
DVDview (MPEG)
Sender (MPEG)
Video file
16
Examples of Specific Qoskets in UAV Application
17
A Qosket That Measures Throughput and Reserves
Bandwidth
Video Distributor
send_frame()
BWReserveQosket

StreamEndpointDelegate
Normal
Filter?
reserve_ bandwidth()
Degraded
Timestamp
Unusable
Sequence no.
reservation status
request reservation
throughput
send_frame()
A/V Streaming Service
Video Display
AQoSA
RSVP
18
RSVP Fragmentation Problem Solved by Use of QuO
Qoskets
Distributor
Receiver
Reassemble Frame Delegate
Frame Filter Delegate
Fragment Frame Delegate

• MPEG in UDP packets were being fragmented by IP.
• Routers did not know that fragmented IP packets
  were part of a RSVP reservation of UDP packets.
• Solution QuO delegates for fragmentation/reassem
  bly, so UDP packets are not fragmented at IP
  level.

19
Alert/Reponse Qosket Specifies Application
Adaptation after Recognizing a Target
process( in Frame f)
Video Display Proxy (receiver)
CORBA
RMI
Target coordinates
send_coordinate( in Coordinate c)
QuO Contract (atr_quokernel)
CORBA

• ATR identifies coordinates of target, sends
  notification to QuO contract which in turn
  affects video image quality

20
Enhanced Resource Management CapabilityDiffserv
Integration with RTCORBA
21
Enhanced RTCORBA with Diffserv Capability
Preserving End-to-End Priorities

• Existing priority in RTCORBA used for OS-level
  task scheduling across distributed nodes
• Our enhancement to RTCORBA uses this priority to
  set Diffserv field in IP packets associated with
  a specific CORBA call
• Network treats packets differently based on value
  of Diffserv field can be used as another
  mechanism for end-to-end QoS

EF
Router
22
How should we apply Diffserv to UAV?

• Give different types of CORBA calls different
  network priorities
• Give command messages higher priority than data
  messages
• Give different clients different network
  priorities depending on the relative importance
  of the clients

• Utilize scheduling tools like RapidRMA to combine
  network priorities and OS-scheduling priorities
  for end-to-end QoS

23
Where Do We Go From Here?

• How do we map QoS management features of QuO to
  features in existing CCM middleware?
• delegates can be Portable Interceptors
• How should we take Qoskets and turn them into
  CORBA Components?
• How can we make reusable components for resource
  management, ie. network (RSVP, Diffserv), CPU,
  etc.?
• How do we make better use of design tools (ie.
  GME)to create Qoskets, and implement them in a
  DRE application?

24
Issues for Integrating QuO with a Component Model
Framework
Craig Rodrigues
BBN Technologies

• TAO CCM Meeting
• August 20, 2002

25
Reminder of Basic QuO Architecture
Application Developer
CORBA DOC MODEL
Mechanism Developer
Application Developer
CLIENT
CLIENT
operation()
OBJ REF
out args return value
Delegate
Delegate
QuO Developer
SysCond
SysCond
SysCond
QUO/CORBA DOC MODEL
SysCond
IDL SKELETON
MECHANISM/PROPERTY MANAGER
IDL STUBS
OBJECT ADAPTER
Mechanism Developer
26
Basic Elements of QoS Management Must be
Integrated into Component Model to offer Basic
QoS Services
QuO Delegate
QuO Delegate
Component
QuO Contract
QuO Contract
Sys cond
Sys cond
Sys cond
external
external

• QuO delegates can manage interactions between
  services
• QuO contracts summarize QoS regions of external
  context
• QuO sysconds can get system properties of
  infrastructure and other components

27
Basic Features that a Component Model Should
Offer to QuO

• Component model must allow QuO components to
  expose well-defined interfaces so that components
  can
• be plugged dynamically into some sort of context
  or container
• be given lifecycle commands (load, unload, stop,
  start)
• expose some kinds of QoS properties (reflection)

28
Important Places where QoS Can Be Inserted in a
Component-based DRE Application

• interaction between components (in-band)
• interaction between components and environment
  (out-of-band)
• interaction between components and containers
  (cross-cutting)

29
Component Model Must Allow In-Band QoS Management

• In-band adaptation provided for inter-component
  communication
• Component proxy decides what to do with a method
  call or return based upon the state of its
  contract
• Used to provide control and adaptation

30
Component Model Must Allow Out-of-Band QoS
Management

• Out-of-band adaptation provided for communication
  between components and environment
• Caused by changes in the system observed by
  system condition objects
• Causes transitions in contract regions

31
Component Model Should Allow QoS Management to
Cross-Cut Components
QoS Management State and Services
QoS Management State and Services
Service Broker

• QoS is a cross-cutting concern that can affect
  the interaction between multiple components
• CCM must allow for complex component interactions
  that will result from implementing cross-cutting
  QoS management
• URI is using a similar approach with Qoskets and
  a Trader Service-like interface to assign CORBA
  priorities to components in a system

32
How do we support Qosket Interfaces in the CORBA
Component Model?

• The Qosket encapsulates a set of contracts (CDL),
  system condition objects (IDL), and QoS adaptive
  behavior (ASL)
• The Qosket exposes interfaces to access QuO
  controls and information (specified in IDL)
• The Qosket separates the functional adaptive
  behavior (business logic) from the QoS adaptive
  behavior and the middleware controls from the QoS
  mechanisms
• Qoskets are cross-cutting, their interfaces will
  not map directly to CCM interfaces

33
Conclusions

• Integrating QoS management into the CORBA
  Component Model will be important for developing
  component-based DRE applications
• QuO offers a middleware framework for QoS-enabled
  applications. QuO functionality needs to be
  integrated with CCM features.
• Component model use cases for QoS were mentioned.
• QuO integration with BBN Cougaar,
  http//www.cougaar.org, an existing Javabeans
  derived Component Model, might provide lessons
  for future QuO integration with CCM
• Advanced programming techniques like AOP and
  reflection used
• QoS and adaptive code has been separated from
  components and containers into Cougaars
  component model infrastructure using an
  abstraction called binders