Project Deliverable

CELTIC IPNQSIS D5.3.1

IPNQSIS - IP NETWORK MONITORING FOR QOS INTELLIGENT

SUPPORT

DELIVERABLE D 5.3.1 COMPONENT DESIGN FOR QOE-DRIVEN

CONTROL

Author full name

Martn Varela

Author affiliation

VTT

Author email address

martin.varela@vtt.fi

Contributors
Antonio Cuadra Snchez, IND; Eric Allilaire, VGC; Jukka-Pekka
Laulajainen, VTT; Eugenio Rogles, ALU

Identifier:

Deliverable D5.3.1

Class:

Report

Version:

V1.0

Version Date:

2011-10-03

Distribution:

Public

Responsible Partner:

VTT

D5.3.1 Component Design for QoE-Driven Control

Confidential

1 (15)

Project Deliverable

CELTIC IPNQSIS D5.3.1

DOCUMENT HISTORY
Version

Date

Comments

V01

2011-04-27

Initial
ToC,
distribution

V0.2

2011-08-05

CEM Arquitecture (IND)

Draft

V0.3

2011-09-15

S3 and various fixes

and comments

Draft

V0.4

2011-09-30

Removed old S3, added

missing parts

Draft

V0.5

2011-09-30

Add Conclusions
chapter (ALU)

Draft

V1.0

2011-10-03

Finalized the document

Final

V1.1

2012-03-28

Extended Executive
Summary

Final

D5.3.1 Component Design for QoE-Driven Control

Status
work

Draft

Confidential

2 (15)

Project Deliverable

CELTIC IPNQSIS D5.3.1

EXECUTIVE SUMMARY
The present document provides a high-level overview of the design of QoE-based network control
components. The goal of this document is not to provide detail specifications for the components, nor is it
to provide algorithmic descriptions of how they should behave. Instead, we propose a set of interfaces (in
terms of operations and types required) for the different QoE-driven control components. Furthermore, we
do so in a language-agnostic way, leaving options open for later implementation.

This deliverable provides an overview of the IPNQSIS CEMS architecture, and describes how the QoEbased network control components fit into it. In particular, we describe the CEMS elements that are
related to QoE-based network control, and how they relate with the rest of the system. These aspects are
described in Section 2 of this document.

The aim of these components is to improve the behaviour of the network using QoE as an optimization
target. That is, given the current state of the network, and models for its performance and the QoE of the
relevant applications, along with policies and other constraints, the control components will derive and
implement the necessary changes in the network configuration, or prompt a human operator to do so. By
so doing, the network resources can be utilized to their full potential, while providing certain (soft)
guarantees about the quality experienced by the users. An overview of the different QoE-based control
mechanisms and their relation with other components (such as monitoring / performance indicators) is
given in Section 3. Said section also covers the relations between the control components and policies
(such as traffic prioritization, traffic shaping, etc.), performance models (for example models for predicting
QoS and correlating it to QoE).

A formal description of the QoE-based control interfaces is also provided in Section 3, given in terms of
the concepts introduced above.

The documents concludes with Section 4.

D5.3.1 Component Design for QoE-Driven Control

Confidential

3 (15)

Project Deliverable

CELTIC IPNQSIS D5.3.1

TABLE OF CONTENT
DOCUMENT HISTORY ................................................................................................................................ 2
EXECUTIVE SUMMARY .............................................................................................................................. 3
GLOSSARY .................................................................................................................................................. 4
1

INTRODUCTION AND SCOPE ............................................................................................................. 5

CUSTOMER EXPERIENCE MANAGEMENT ARCHITECTURE.......................................................... 6

2.1
2.2
2.3

MANAGEMENT DATA........................................................................................................................... 7
CONTROL MANAGER .......................................................................................................................... 8
INTERVENTION MANAGER ................................................................................................................... 8

QOE-DRIVEN NETWORK CONTROL .................................................................................................. 9

3.1 GENERAL ARCHITECTURE FOR CONTROL COMPONENTS........................................................................ 9
3.1.1 Performance Indicators ........................................................................................................... 10
3.1.2 Policies .................................................................................................................................... 10
3.1.3 Performance Models ............................................................................................................... 10
3.1.4 Decisions ................................................................................................................................. 11
3.1.5 Defining a Generic CM ............................................................................................................ 11
3.2 QOE-DRIVEN CONTROL COMPONENTS .............................................................................................. 11
3.2.1 Dynamic Network Provisioning ............................................................................................... 11
3.2.2 Traffic shaping ......................................................................................................................... 12
3.2.3 Traffic Differentiation ............................................................................................................... 12
3.2.4 Access Control ........................................................................................................................ 12
3.2.5 Access network selection ........................................................................................................ 12
3.3 SIGNALLING ISSUES ......................................................................................................................... 13

CONCLUSIONS ................................................................................................................................... 14

REFERENCES ..................................................................................................................................... 15

APPENDIX: NOTATION ...................................................................................................................... 15

GLOSSARY

QoE Quality of Experience; in the case of media services, the perceptual quality experienced by the
users of the service.
QoS Quality of Service; indicators of network performance.

D5.3.1 Component Design for QoE-Driven Control

Confidential

4 (15)

Project Deliverable

CELTIC IPNQSIS D5.3.1

INTRODUCTION AND SCOPE

The present document provides a set of high-level guidelines for the design of QoE-driven network
control components.
The goal is not to provide detailed algorithms for QoE-driven control, but to establish a high-level design
for the components, by considering which inputs they need to take into account, and what kinds of
outputs (in terms of corrective actions or alerts) are to be expected of them..
Several possible control mechanisms are covered, along with their requirements and expected
performance gains. High-level descriptions of how the components might work are given as each
mechanism is introduced, in order to help the reader understand what the expected performance gains
will be.
The rest of the document is split in three sections, as follows. Section 2 covers the overall Customer
Experience Management architecture, and describes where the control components fit in it. Section three
introduces the different components and their high-level design in terms of the types of information they
require and the types of actions they produce. Section 4 concludes the document.

D5.3.1 Component Design for QoE-Driven Control

Confidential

5 (15)

Project Deliverable

CELTIC IPNQSIS D5.3.1

CUSTOMER EXPERIENCE MANAGEMENT ARCHITECTURE

QOE-driven control functionalities are integrated into the Customer Experience Management Architecture
described in D2.2 document DEFINITION OF REQUIREMENTS OF THE MANAGEMENT SYSTEMS
TO KEEP UP WITH QOE EXPECTATIONS BASED ON QOS AND TRAFFIC MONITORING.

In particular there is a Control level that handles the QoE delivered to the customers and its feededback
from the monitored level in order to act proactively into the network to improve customer satisfaction. All
the activities related to this task belong to QoS/QoE Management System as shown on Fig 2-1.

Figure 2-1. Control Level into IPNQSIS Architecture.

The purpose of this architecture is to allow controlling the traffic users are generating in the managed
networks. Service Providers use a series of limited resources shared by all users equally. This implies
that under certain circumstances the quality offered and the quality experienced can be diminished, and it
is not possible to take effective corrective actions.
To address these issues, we propose a solution that may act on the network to adequately manage the
available resources according to certain information (user profiles, contracted services and QoE
information) and a series of pre-defined policies.
This architecture includes an information model that introduces the following entities:

Management Data: Provides information to determine, in real time, the state of the network, and it
is the data source that feeds the control component. In particular, any assumptions about QoE
metrics, network QoS metrics, application-level data, etc. that might be needed for the
components to work as expected are classified as Management Data.

D5.3.1 Component Design for QoE-Driven Control

Confidential

6 (15)

Project Deliverable

CELTIC IPNQSIS D5.3.1

Control Manager (CM). Receives real-time management data, the users in the network and the
services requested, to determine what the state the network is, and thereby apply the necessary
mechanisms to guide their behaviour, if necessary. These criteria are transferred to an
intervention manager, which depends on the attributes listed, and applies corrections, as needed,
on the network. The CM also must have user and service models, and be able to establish
certain policies for action on the intervention system.

Intervention Manager (IM). It consists of a device or network node itself, which incorporates a
number of functions to act on the network. Its operation is based on the management of certain
network resources and control policies as dictated by the Service Manager. Therefore the IM IS
implements the actual control mechanisms in the network (i.e. bandwidth). This functionality will
control the network resources among conditions, according to some specific policies. Different
modes of action can be implemented depending on the intended purpose, such as controlling the
performance of a specific type of traffic, or controlling the mass traffic volume regardless of its
nature.

The following figure shows the QoS/QoE Management System Architecture.

Figure 2-2. CEMS at Control Level.

2.1

Management Data

The management data is fed from the Monitoring Level and comprises all the information needed by the
Control Manager in order to make the relevant decisions and, if needed, act upon the network through the
Intervention Manager.
This information can be contained in detailed records (in particular, in XDR format), including the most
relevant information, such as:

Network identifiers (IPs,MACs)

User identifiers
Available Quality information (KPI, KQI, QoE metrics, etc.)
Supporting Information (Network requirements, traffic classification, events, etc,)

D5.3.1 Component Design for QoE-Driven Control

Confidential

7 (15)

Project Deliverable

CELTIC IPNQSIS D5.3.1

In order to establish the management data, an initial XDR can be defined for this purpose:

2.2

Generic: valid for all IP based services (until transport layer)

Configuration data: enriched from customers databases and BSS
Signaling plane: fields from control & signaling protocols
Transport plane: fields from multimedia flow
QoS attributes
QoE attributes

Control Manager

The Control Manager is the core of the QoS/QoE Management System and receives real-time information
from the monitoring system, such as QoS/QoE metrics, users and the services requested, to determine
what state the network is in, and thereby implement the necessary mechanisms to make the necessary
adjustments, if any.
These control decisions are transferred to an Intervention Manager,, which actually applies corrective
actions on the network. It is also advisable to have user, network and service models in order to be able
to establish certain policies for action on the intervention system. In particular, this is useful to make (at
least locally) optimal decisions based on the available data, and the quality and performance estimations
provided by the models.
To address the performance of the network, it is necessary to know the characteristics and requirements
of the traffic on which it is intended to act, such as sensitivity to packet losses, delay, response time and
jitter..
In this way, these types of traffic are considered as relevant:

2.3

Loss- and delay-sensitive traffic such as real-time applications and interactive traffic.
The types of traffic that tend to use instant or gradually larger amounts of bandwidth, such as
FTP traffic.
The traffic whose performance may be affected by the variation of the delays, as is the case of
video on-demand services in real time, or voice over IP services.
Traffic amenable to rate control, or able to automatically adapt at the application layer in the
presence of network impairments.

Intervention Manager

Intervention Managers are network elemenrs that incorporate certain functions for acting upon the
network. An IMs operation is based on the management of certain network resources and control policies
as dictated by the Service Manager.
For instance, acting on the network based on the management of the links bandwidth will control the
allocation of that resource among competing traffic flows, according to some specific policies and the
decisions made by the CM.
There are different modes of action depending on the intended purpose, such as controlling the
performance of a given type of traffic, or aimed at controlling the volume of traffic regardless of its nature.

D5.3.1 Component Design for QoE-Driven Control

Confidential

8 (15)

Project Deliverable

CELTIC IPNQSIS D5.3.1

QOE-DRIVEN NETWORK CONTROL

In this section we provide a framework for implementing QoE-driven, enriched versions of the control
mechanisms described in Section 3. This is done by considering QoE information (both as inputs and as
performance targets), as well as network QoS information, policies, current traffic composition and other
Management Data.

3.1

General architecture for control components

At a conceptual level, the QoE-driven network control mechanisms proposed within IPNQSIS all share a
common pattern. Performance indicators (such as QoE estimations, QoS measurements, etc.) and
control policies are fed into the Control Manager. The CM then uses that data, along with models for
network performance and application-level QoE, to make decisions on:

Whether corrective actions are needed

What actions are needed, if any
Where and how those actions need to be implemented

The decision-making can be very simple or very complex, depending on the network and applications
considered, the available QoE and performance models, and the controls mechanisms available. At a
high-level, however, the input data will be fed through a set of rules, out of which will emerge a decision
on the needed corrective actions. Once the decision is made, it can then be implemented through the
relevant Intervention Manager(s).

Figure 3-1 Generic Functioning of a QoE-Driven Control Component

Figure 4-1 describes the conceptual design of QoE-driven control components. Actual components will be
specializations of this design, and each instance will depend on the available metrics, models and control
mechanisms. For example, if considering a network with DiffServ support and IPTV as the application
under consideration, a specific QoE-driven control component could be instantiated with a suitable model
for IPTV QoE, network QoS measurements, a DiffServ-aware set of policies, and DiffServ-capable
performance models. The IM in question could be a router capable of performing appropriate DiffServ
marking on the relevant packets, as needed.
This generic approach to QoE-driven control can be easily abstracted by defining polymorphic types for
the inputs and outputs involved, and then defining suitable instances for the concrete desired control
mechanisms.
This allows for simple specification of the behaviour of the different control mechanisms implemented,
and is easily extensible if new mechanisms are to be added.

D5.3.1 Component Design for QoE-Driven Control

Confidential

9 (15)

Project Deliverable

CELTIC IPNQSIS D5.3.1

In what follows, suitable types are defined for performance indicators, policies, performance models and
control actions, and then used to define the general form for Control Managers. See the Appendix for a
short, informal description of the notation used below.
3.1.1

Performance Indicators

Performance indicators provide a quantitative view of the current performance, and can be considered at
the network or application layers. Common examples of these indicators are:

Packet loss rate and loss distribution

One-way (or round-trip) delays and jitter
Available bandwidth
Actual transmission rates
Perceptual quality estimations (e.g. as provided by PSQA or the E-model)

Other, less commonly used performance indicators can be also considered, for example:

Connection establishment time

Address allocation time
Average response times for certain services (such as DNS)

The type for performance indicators can then be defined as:

PerformanceI = QoEI | QoSI | OtherI | [PerformanceI]

While not necessary at this point, each of the PerformanceI constructors needs to be further refined for
actual instantiation, for example, QoS indicators would cover loss rates, delays and jitters, throughputs,
goodputs, etc. In the case of QoE, indicators would cover MOS, MOS estimations, PSNR, MSE, etc.

3.1.2

Policies

Policies provide guidance and bounds for the decision-making process. Oftentimes, the control decisions
will be based on tiered pricing schemes, with either (or both) application- and subscriber-based
differentiation, and thus they cannot be solely based on the technical performance aspects. Different
pricing schemes for services often have Service Level Agreements (SLAs) attached to them, which may
also impose restrictions on the type and granularity of the control performed on the network.

As a starting point, the following definition is used for the Policy type:
Policy = ApplicationP | SubscriberP | SLAP | [Policy]

Unlike performance indicators, which can be mostly thought of as simple numeric values, policies require
more complex definitions. This document will not provide these definitions, and they will be, throughout
the project, adopted on an ad-hoc basis as required by the implementation. While a formal specification
for policies is outside the scope of IPNQSIS, and will not be provided, it can be taken as a given, and
policies can be considered as a set of constraints on the possible operations and performance levels
attainable via the proposed control mechanisms.

3.1.3

Performance Models

The goal of performing QoE-driven control is to improve the quality perceived by the users of a given
service, under the constraints posed by the network itself, the application requirement, and the policies
implemented by the network provider. This is, at heart, an optimization problem, where the QoE needs to
be maximized under the constraints mentioned above, or where QoE needs to be kept at acceptable level
while optimizing other parameters (costs, resource utilization, etc.). It is necessary, therefore, to have
suitable models on which to perform the optimization. Understanding how a given control action may
impact the network QoS requires adequate models for network performance. In turn, understanding how
the modified QoS will impact the QoE requires suitable models for QoE. Models for user behaviour (both
individual and aggregate) are also useful to estimate network requirements.

A first definition of the type for performance models could then be:
PerformanceM = QoSM | QoEM | [PerformanceM]

D5.3.1 Component Design for QoE-Driven Control

Confidential

10 (15)

Project Deliverable

CELTIC IPNQSIS D5.3.1

Performance models can be used when combining different control components, as a way to feed the
expected outcome of one component into a second one, and so on. Given a performance model, it is in
general possible to obtain estimations of performance under that model. For example, the following
estimators could be defined:
estimateQoE :: PerformanceI QoEM QoEI
estimateQoS :: PerformanceI QoSM QoSI

which allow, together with the impact assessment indicators described in the next section, to compose
two or more control components in order to achieve the desired results.

3.1.4

Decisions

As described previously, the CM is provided with information about the current performance, the policies
in place, and models for the network performance and/or the users perception of quality, and then it
makes decisions on which corrective actions, if any, are to be applied on the network. A control decision
will generally consist of a single action to be carried out, but it is conceivable that several actions could be
combined into a single decision. Thus, types for the actions that are possible to perform will be defined,
and decisions will be lists (likely empty lists or singletons, in most simple cases) of these actions.
Action = ProvisionA | ShapingA | MarkingA | AccessControlA | HandoverA | AlertA
Decision = [Action]

Decisions can be evaluated (from a performance perspective), by either implementing them and
measuring the result, or by estimating their impact on a performance model. This can be done via:
measureImpactD :: Decision PerformanceI
estimateImpactD :: Decision PerformanceM PerformanceI

3.1.5

Defining a Generic CM

Having defined what the inputs and outputs of the CM are, it is now possible to state that the CM
establishes a relation:
CM :: PerformanceI Policy PerformanceM Decision

In the following section, specific instances of this generic GM will be defined, for different type of control
mechanisms.

3.2

QoE-Driven control Components

This section describes the design of control components that implement different control strategies. It
should be noted, however, that these are in general not used in their own, but combined with one
another.
3.2.1

Dynamic Network Provisioning

Dynamic network provisioning allows the operator to re-distribute or augment the network resources
available to a certain user, group of users, or services. In the simplest case, the control action could be an
alert to the network operator that more resources are needed in a certain network segment, in order to
support certain services. The actual intervention could then be done manually. In other cases, where
physical capacity is available but restricted by policies, the intervention could be done automatically, by
implementing new policies and assigning more or less resources to certain user groups or services.
Generally, provisioning CM instances will establish a relation:
CMP :: PerformanceI Policy PerformanceM DecisionP

Where
D5.3.1 Component Design for QoE-Driven Control

Confidential

11 (15)

Project Deliverable

CELTIC IPNQSIS D5.3.1

DecisionP = [ProvisionA]

3.2.2

Traffic shaping

Traffic shaping enforces policies for traffic management, ensuring that certain traffic classes (e.g. for a
given service, or for a given group of users) is treated in a way that guarantees 1 certain performance
targets for the relevant classes. Put another way, shaping will treat traffic in lower priority classes in such
a way that the performance targets for the higher-priority classes can be achieved. Shaping is often used
in conjunction with DiffServ and/or queue management mechanisms, and it can be used as a way to
implement certain types of provisioning. An example of shaping application would be to distribute the
available bandwidth in a network in such a way that, say, VoIP traffic is guaranteed a certain percentage
of the links capacity at any given time, with queuing delays below a certain threshold, while the rest of the
links capacity is used for other classes of traffic.
Shaping then can be, in common cases, generally typed as:
CMS :: PerformanceI Policy PerformanceM DecisionS

With
DecisionS = [ShapingA]

3.2.3

Traffic Differentiation

Service differentiation is a well-known way of improving the quality of certain applications, in particular
those that have, like video and voice, constraints in terms of acceptable delays and losses. In the context
of IPNQSIS, DiffServ is a clear candidate to be used as the traffic differentiation mechanism for control
purposes, although other possibilities can also be considered (e.g. 802.11p or the 3GPP QoS classes for
mobile traffic). A DiffServ-based control component will then be able to modify packet-marking policies.
For traffic differentiation there is then:
CMD :: PerformanceI Policy PerformanceM DecisionD

Where
DecisionD = [MarkingA]

3.2.4

Access Control

Access control provides another mechanism to control the QoS/QoE in a network, by allowing new
streams into the network only if there is enough capacity to handle them. This can be combined with
different traffic or subscriber classifications in order to obtain a very flexible system. Priorities for access
can be established based on the application type (e.g. conversational class applications can high higher
priority than streaming class applications, which in turn will have higher priority than bulk-transfers, etc.)
and on the subscription type, for when tiered pricing schemes are used. Generally, we can state that:
CMA :: PerformanceI Policy PerformanceM DecisionA

Where
DecisionA = [AccessControlA]

3.2.5

Access network selection

The final mechanism which we will consider is the selection of a different access interface on the terminal
side. This is particularly useful in the context of mobile devices with multiple network interfaces, and even
more so in the case where the devices have multi-homing capabilities. Typically, in such a context there
will be a protocol such as Mobile IP or Host Identity Protocol, that will handle the mobility aspects. The
decision to switch to a different network can be, in this case, taken by either the terminal or the network.
The latter case is interesting for example for off-loading traffic from a mobile network into WiFi hotspots.
In a form analogous to the other mechanisms, we have:

Or at least strives to achieve.

D5.3.1 Component Design for QoE-Driven Control

Confidential

12 (15)

Project Deliverable

CELTIC IPNQSIS D5.3.1

CMH :: PerformanceI Policy PerformanceM DecisionH

Where
DecisionH = [HandoverA]

3.3

Signalling Issues

In order to carry out the necessary corrective actions, it will be necessary for the CM to communicate with
the relevant network equipment and / or with human operators. To this end, suitable signalling
mechanisms need to be established. While making those mechanisms explicit at this stage would likely
be limiting to the development of prototypes, we suggest that existing, established protocols be used
whenever possible. Among these, the following are particularly of note:

SNMP(v3) [RFC3411]
MIH [IEEE802.21]

D5.3.1 Component Design for QoE-Driven Control

Confidential

13 (15)

Project Deliverable

CELTIC IPNQSIS D5.3.1

CONCLUSIONS

As already introduced in the document, the Control Level is key in the CEMS architecture to properly
handle the QOE delivered to customers by means of proactive intervention in a managed network,
according monitored and pre-processed QoS/QoE performance data and defined policies for intervention
in case QoE is perceived as diminished.
Monitorization of QoS/QoE performance data will be providing reliable information of the performance
quality experienced by the service, together with the QoS performance provided by the network; these
inputs will be used to make decisions on dynamic adaptations to network conditions or intervention on the
QoS of the network when applicable.
The Service Optimization that may drive to a dynamic adaptation to network conditions is studied in Task
3.2 and it is used as input to the Control Manager of the Control Level.
Self-Learning algorithms that use network measurements to adapt dimensioning rules based on traffic
characterization are studied in Task 4.3 and used as input to the Control Manager of the Control Level.

D5.3.1 Component Design for QoE-Driven Control

Confidential

14 (15)

Project Deliverable

REFERENCES

CELTIC IPNQSIS D5.3.1

[IEEE802.21] IEEE 802.21 Media Independent Handover Services - http://www.ieee802.org/21/

[RFC3411] IETF Network Working Group An Architecture for Describing Simple Network
Management Protocol (SNMP) Management Frameworks - http://tools.ietf.org/html/rfc3411

APPENDIX: NOTATION

The notation introduced in Section 3 to describe the functionality of the control components and the CM
aims at providing a concise way for describing the inputs and outputs of said components, as well as that
of related actions (such as performance estimations based on the current status of the network and a
given network model). Both the notation for the type definitions and actions are loosely modelled on
Haskells algebraic data type definition syntax, and function type signatures, respectively. The idea
behind this is to enable, later on, easy implementation of control components with clearly defined
interfaces.
The following short explanations explain the meaning of the different constructs.
A = B | C | D

Means that the type of objects A encompasses that of B, C or D. That is to say, an object of type A is
either one of type B, type C, or type D.
[A]

represents a list of elements of type A.

R :: A B

Denotes a relation R from elements in A into elements in B, while

R :: A B C

denotes a relation R from elements in the Cartesian product of A and B into elements in C.

D5.3.1 Component Design for QoE-Driven Control

Confidential

15 (15)