|
|
|
ubiQoS Architecture
The components of the ubiQoS middleware present a similar architecture, shown in Figure 2, designed by composing different modules that provide different functionality. The ubiQoS gateway is the most complete component including all basic modules. The other ubiQoS components have more limited duties and include only a subset of the gateway functions. In particular, ubiQoS proxies do not need LDAP and discovery servers; ubiQoS client/server stubs only provide functionality for gateway discovery and RTP flow receiving/sending.
Figure 2. The modular architecture of ubiQoS components.
The QoS Monitoring module observes
the state of resources and services that are local to the ubiQoS component.
The module extracts and works on monitoring information about VoD flows from
RTCP sender/receiver reports. It also achieves the visibility
of Java Virtual Machine (JVM) indicators, e.g., method invocation
and object/memory allocation for any Java thread, via the JVM
Profiler Interface, an experimental API of the Java 2 platform for the monitoring
of Java-based applications. In addition, this module monitors system indicators,
e.g., CPU load, file system occupation, network packet collision rate, by exploiting
the Java Native Interface
to integrate with platform-dependent monitoring mechanisms, e.g., the psapi.dll
on Windows NT and pstat on Unix.
Other details about our Java-based module for
QoS monitoring are available here.
The Admission Control module maintains
information of all current VoD flows. Any entry include a unique identifier
for the VoD flow, a unique identifier for the VoD content, a tuple of QoS requirements
associated with the flow, the identifiers of previous and next ubiQoS components
in the distribution path. Depending on information obtained from the monitoring
module and on the current state of already accepted flows, the module chooses
to accept or reject new VoD flow requests. The Accounting module
exploits the monitoring module to keep a log of the QoS level provided
to the different receivers. It is in charge of authenticating
users and associating them with the requested VoD flows and the
corresponding accounting information. For any couple
The QoS Manager module coordinates
the other local modules and decides the QoS level for the following ubiQoS
components in the VoD path. During the negotiation phase,
it combines QoS requirements from user/terminal profiles and reservation data
from the admission control module. On this basis, it decides to enforce a specific
point in the space of possible values for QoS parameters, e.g., frame rate,
size and resolution. Usually, an interval for QoS parameters is permitted; the
manager module chooses the QoS point to maintain by considering the resource
consumption policy of the local host. ubiQoS currently provides two
simple extreme policies. The thrifty one enforces QoS to minimize resource
consumption according to a specified function cost. The greedy one chooses
the QoS that reserves the maximum local resource usage. In the latter case,
new VoD flow requests dynamically modify the QoS point of accepted flows by
preempting previously committed resources. We are extending the set of policies
of the QoS manager module: in particular, we are considering differentiated
behavior depending on receiver priority. At provision time,
the manager module can modify the provided QoS level by moving in the
QoS space to maximize a cost function with weighted QoS parameters
(depending on user/terminal profiles). For instance, a device with limited
display capabilities can specify a frame rate weight larger than frame resolution
to indicate a preference in degradation of image quality instead of frequency
decrease.
