Side_1_360

The mappings between QC, AC and NPL defini-
tion are described in more detail in the following.

Each pair (QC, AC) in the matrix is called a
Quality Class Specification (QCS), and its value
corresponds to a Network Performance Level
(NPL). As briefly mentioned above, an NPL is a
(feasible/small) set of NPPs (e.g. delay, jitter and
loss), each with an objective, i.e. value1)and a
guarantee per parameter that its value will stay
inside the range. By doing so, it is enabled to
relate different quality classes with different
application categories. In other words, the objec-
tives of an NPL are the target for the network in
order to provide the desired QC when an appli-
cation (belonging to an AC) is instantiated. Each
NPL can be seen as a data ‘flow’ within the net-
work and must be treated/managed accordingly.

Regarding ACs, three options have been chosen:
interactive real-time, non interactive real-time
and non real-time. Regarding NPLs, relevant
NPPs chosen are delay, jitterand loss. Regard-
ing their values, upper bounds on the values of
those parameters and related guarantees (e.g. %
of time the parameter value is below the thresh-
old) are specified.

As input to the experiments (as described in next
chapters), a QUASI-model with two QCs (i.e.
Premiumand Basic) and three ACs relative to
applications characterised by significantly differ-
ent performance requirements (i.e. non real-time,
non interactive real-time, interactive real-time)
was used. Combining two QCs with three ACs
results in at most six possible data flows to be
treated differently in the network in order to pre-
serve the performance requirements of the rela-
tive services/applications (Table 2). The Pre-
mium class of each AC would be treated better
than the Basic class. All the remaining traffic not
belonging to these two subscribed quality classes
or exceeding the agreed traffic profile or the
total bandwidth available, is treated as Best
Effort (no NPL values are given for BE).

In order to implement this kind of model, there

should be methods for the operator to monitor

the achieved NPL and control the network so

that guaranteed NPL is reached.

One of the first things to be fixed was selection

of the NPL parameters. The project started by

investigating similar architectures. They mostly

use end-to-end delay of IP packets, IP packet

loss ratio, jitter – which may mean variation of

delay between consecutive IP-packets or some-

thing else, and throughput in some sense. There

are definitions for similar parameters in the

ITU-T Recommendation I.380 and IETF’s IPPM

(RFC2330). Why the QUASI-model definitions

are not adopted from either of these is partially

caused by the QUASI-model as the parameters

should be between MRPs and partially since

these standards also define the way to measure

them, indicating test traffic based measurements.

There was some concern whether measuring low

loss ratios with test traffic would be a good solu-

tion and whether test traffic could accurately de-

scribe delay and jitter of user traffic. The reason

why jitter was defined as standard deviation in a

small time interval and not from the difference

between two consecutive packets was that, if the

measurement is on user traffic, the packets may

belong to different users and we did not want to

measure per flow. These considerations led to

the following definitions for the NPL-parameters:

Delay:Delay is the average delay over the time

interval of 16 minutes of one-way transfer

AC 1 AC 2 ... ACn

QC 1 NPL 11 NPL 12 ... NPL1n

QC 2 NPL 21 NPL 22 ... NPL2n

... ... ... ... ...

QCm NPLm1 NPLm2 ... NPLmn

Table 1 The general QUASI-

model

1)Note that the value may be expressed as a range.

Application Categories

AC1 AC2 AC3

Quality Premium NPL 11 NPL 12 NPL 13

Classes Basic NPL 21 NPL 22 NPL 23

Best Effort –––

Table 2 The practical QUASI-

model