The Moving Picture Experts Group

Resource and Quality Management

Part number: 
Activity status: 


  MPEG Multimedia Middleware (M3W) Resource Management


MPEG doc#: N8690
Date: October 2006
Authors: Johan Muskens & Jean Gelissen (Philips)


1.      Introduction

MPEG, a working group in ISO/IEC, has produced many important international standards (for example: MPEG-1, MPEG-2, MPEG-4, MPEG-7, and MPEG-21). MPEG feels that it is now important to standardize an Application Programming Interface (API) for Multimedia Middleware (M3W) that is based on a defined set of requirements [1]. This API provides a uniform view to a multimedia middleware platform that can be realized by a number of different vendors.

The M3W specification supports software systems that can be upgraded and extended during their lifetime (possibly at runtime). This means we have a context in which software can be developed by multiple different parties and the software configuration can be modified in the period that a device is already owned and used by a consumer. Software from multiple parties and runtime upgrading / extension are major threats with respect to robustness and reliability of the software.

In order to provide robustness with respect to resource usage ISO/IEC 23004 Part 4 – Resource Management specifies an optional framework for resource management. The goal is to optimize and guarantee the Quality of Service that is delivered to the end-user in a situation where resources are constrained (due to the need for cost effective development of a product).

2.      Resource Management Framework

The resource management framework specified in M3W is based guaranteed resource budgets and uses a contract model. This contract model consists of two parts:

¾       Resource: The resource management framework must guarantee a certain resource budget to the individual functional parts. This resource budget should enable the functional part to provide a certain level of quality.

¾       Quality: The functional part that must provide a certain level of quality (for the user).

The main idea is that (some) services and applications are quality aware, meaning that they know how much resources they need to provide a certain level of quality. The number of quality levels can vary between application / service. The resource management framework is able to create and guarantee a number of resource budgets satisfying the needs of an application / service for a specific quality level. The budgets (and therefore quality levels) are negotiated based on the priorities of the user, thus making sure that the user will get the maximum quality of service that can be guaranteed.

The resource management framework consists of a number of roles depicted in the next figure. The main responsibilities of the individual roles will be described in the following subsections.

2.1        Quality Manager (QM)

Its main goal is to manage system global quality. It assigns resources to Applications and Service Instances. The interaction between the QM and the Applications or Service Instances is based on the mentioned contract model. The QM follows a protocol for negotiating this contract. Additional interaction should be performed for re-negotiating, due to the Application needing more resources, not fulfilling the required quality, etc.

2.2        Quality Chief (QC)

The quality chief is part of the application or service. It is the counterpart of the QM. It is in charge of interacting with the QM and driving the execution of the Application, according to the agreed quality level. The complexity of the quality chief varies. Its basic functions are negotiating with the QM, setting the resulting quality levels, and handling overruns and other potential requests from the QM. Advanced functions include Application monitoring, adaptation, management of the Application’s resources, etc. The QC can take advantage of domain semantic information for carrying out these operations, which should imply that they are performed more efficiently.

2.3        Resource Manager (RM)

The resource manager is in charge of performing the platform and device independent actions for managing resources. In particular, the main responsibilities of this role are:

  • Setting the budgets assigned to each of the threads (or clusters of threads)
  • Account for resource usage
  • Enforce budgets
  • Keep statistical information
  • Provide information on available resources to Applications

It closely interacts with the resource chiefs (discussed in the following sub-clause) for doing these activities.

In the negotiation phase, it uses the admission test to check whether there is sufficient capacity for satisfying a tentative assignment. The admission test can be done for each resource individually or in an integrated way. The second option is the most convenient, as it can consider dependences on the resource usage. This is the reason why this responsibility has not been deferred to the resource chiefs.

2.4        Resource chief (RC)

The resource chief has specific knowledge of a particular resource. It is in charge of supporting the Resource Manager to account and enforce the budgets of this resource. Its main responsibilities are to:

  • Isolate platform dependent issues,
  • Manage its corresponding resource(s),
  • Interact with the Resource Manager for accounting and enforcing purposes.

3.      Summary

The Application Programming Interface (API) for Multimedia Middleware specified by M3W provides a uniform view to the Multimedia Middleware in a device. A realization of such a middleware can be provided by a number of different vendors. The M3W specification contains a specification of a resource management framework. This resource management framework provides robustness with respect to resource usage in a situation where:

  • Resources are constraint
  • There is software from multiple different vendors
  • System configuration is changed in the period that a device is owned and used by a consumer

The resource management framework works best in a situation where applications and services are quality aware (know how much resources they need in order to provide a certain level op quality), but is also able to deal with a situation where (not all of) the services and applications are quality aware.

4.      References

[1]   The Multimedia Middleware (M3W) requirements are in the annex to the Multimedia Middleware (M3W) Requirements Document Version 2.0 (ISO/IEC JTC1/SC29/WG11 N6981). A Call for Proposals derived from these requirements was issued at the 70th MPEG Meeting in Palma, Mallorca

[2]   ISO/IEC 23004, Information Technology — Multimedia Middleware, The M3W standard.