Thực hiện chất lượng dịch vụ trong các mạng IP (P2)

2
Service Quality
Requirements
In this chapter, means of assessing and specifying service quality
requirements are described. To lay the foundation for discussion,
the following questions need to be answered:
• What is a service?
• What kind of services are there?
• What does it mean to provide quality support for a particular
service type?
• Which form of representation of service quality requirements is
the best one?
Background for answering the first question will be sought by
first studying a few typical Internet services, and then proceeding
to define suitable concepts for service definition. The second and
third questions will be answered by studying the factors affecting
service quality, as well as the means of measuring service qual-
ity. Finally, the means of specifying service quality requirements
are reviewed.
First, it is in order to discuss the relation of service quality sup-
port to the commonly used term “Quality of Service” (QoS). QoS
is an overarching term, which different schools of thought relate to
Implementing Service Quality in IP Networks Vilho R
¨
ais
¨
anen
 2003 John Wiley & Sons, Ltd ISBN: 0-470-84793-X
10 SERVICE QUALITY REQUIREMENTS
different parts of end-to-end service quality, including user expe-
rience and service quality support mechanisms.

International Telecommunication Union’s Telecommunications
branch’s (ITU-T’s) related definitions [G.1000] are as follows:
• Quality is the totality of characteristics of an entity that bear on
its ability to satisfy stated and implied needs.
• Quality of service is the collective effect of service performances,
which determine the degree of satisfaction of a user of service.
Different viewing angles on Quality of Service are listed as fol-
lowing:
• QoS requirements of user or customer are a statement of the level
of quality required by the applications of customers/users of a
service, which may be expressed non-technically.
• QoS offered or planned by provider is a statement of the level
of quality expected to be offered to the customer by the ser-
vice provider.
• QoS delivered or achieved by provider is a statement of the level of
the actual quality achieved and delivered to customer.
• QoS perceived by user or customer is a statement expressing the
level of quality that customers believe they have experienced.
The term “QoS” is deliberately avoided in this book, except when
it has a specific, well-established usage such as “IP QoS mecha-
nism X” or “QoS framework of standard body Y”. The author’s
use of the terms relevant for this discussion is as follows:
• End-to-end service quality: end result of everything that affects the
end user’s experience of service. The factors affecting this will
be discussed in more detail below, but an overview is provided
in Figure 2.1. End-to-end quality is not purely subjective, albeit
affected by psychological factors related to the particular use
of service [BSD00]. Depending on the context, this may mean
either service quality planned by the provider, or service quality
experienced by the end user. In this book, the viewpoint of

inherent service quality requirements falls into this category.
• Service quality support mechanisms: means of supporting service
quality along the route assumed by the service instance. This
includes, broadly speaking, service quality signalling schemes
SERVICE QUALITY REQUIREMENTS 11
End user Service providerNetworkTerminal
Figure 2.1 Factors of end-to-end service quality include cognitive and psy-
chological factors (end user), implementation of service support in terminal,
implementation of service quality support in network, and implementation
of service by the service provider
such as Resource Reservation Protocol (RSVP) and service qual-
ity support mechanisms such as Differentiated Services (Diff-
Serv). As a result of using service quality support mechanisms,
one obtains QoS delivered by the provider on the service level
[G.1000], which can also be characterized by network perfor-
mance level on network level [I.350].
End-to-end service quality can be thought of being composed
of service quality support domains (see below). The breakdown
of end-to-end service quality into constituent parts is used, for
example, in ITU-T’s recommendation telephony planning model,
“E-model” [G.107, G.108] and the European Telecommunication
Standardization Institute’s (ETSI’s) IP telephony project QoS model
[TIPHON-1]. Such a division is often referred to by the term “QoS
budgets”.
This book attempts to be neutral with respect to Internet access
technologies. The attitude towards technologies can be character-
ized as “forward-looking” in the sense that the service quality
support potential of different technologies is in some cases evalu-
ated beyond currently used deployments. Due to the affiliation of
the author, issues specific to wireless issues are considered where

the author has assessed them to bring added value to the reader.
IP-based Radio Access Network (RAN) is used as a case study for
the concepts developed in this book since the author has partici-
pated in the work in this area.
12 SERVICE QUALITY REQUIREMENTS
2.1 SERVICES ON THE INTERNET
To develop a conceptual definition of services, let us next take
a look at what kind of services are known to be in use on
the Internet.
Examples of well-known services on the wireline Internet at the
moment include:
• sending and receiving E-mail;
• accessing news content with a browser;
• e-banking;
• e-trading;
• whiteboard applications;
• chatting.
E-mail is “the original service” of the Internet (a short summary of
Internet history can be found, for example, in [Kap99]). Developed
from a simple means of conveying text messages, modern e-mail
clients can deliver attachments and support multiple content types.
Most of the services in the above list typically make use of Hyper-
text Transfer Protocol (HTTP). Whiteboard and chat applications, on
the other hand, can be implemented as point-to-point applications
between communication endpoints (computers).
In their original form, the HTTP-type examples listed above
were classical examples of the client–server type interaction on the
wireline Internet. For example, when I start up my PC, launch a
web browser and click the British Broadcasting Corporation (BBC)
link on my Netscape browser, a HTTP request is sent to the server

whose IP address results from the Domain Name Server (DNS) res-
olution of “news.bbc.co.uk”. As a response to the request by the
client (Netscape browser), a web server of BBC sends the news
homepage back to my browser in Hypertext Mark-up Language
(HTML) format.
A single HTML page may include components from multiple
servers, which is often the case with commercial HTML pages
with embedded advertisement content. In addition to text and
figures, the content provided by an HTTP server can also contain
streamed audio or video such as news footage and downloadable
files, for example, Moving Pictures Expert Group (MPEG) audio
layer coding 3 (MP3) files. An HTTP page can be interactive with
menus, type-in fields, and buttons invoking further reply/request
interactions, while still conforming to the client–server paradigm.
2.1 SERVICES ON THE INTERNET 13
Common Gateway Interface (CGI) scripts can be invoked dur-
ing HTML page access in the HTTP server, making it possible
to implement actions such as database searches and on-request
HTML page creation based on results. Downloading of Java

applets into the browser allows for local processing in the client.
A variant of the client–server paradigm spontaneously came
into being after the free on-line MP3 repository Napster was
charged of infringing copyright of the publishers and of the
music artists. Distributed versions of the service were developed,
consisting of a central server containing pointers to the location of
the actual music files on other Internet hosts. From the point of
view of interactions, the distributed scheme is still of client–server
type, the only substantial difference being distributed storage of
the content and related redirections.

A trend in the making is that of allowing
greater freedom to select the time and place
of accessing the Internet content. We are not
referring to 200-metre modem cable here, but
to wireless access. Many airports and hotels
already provide 802.11 standard WLAN access to the Internet – all
that customer needs is an 802.11 Network Interface Card (NIC) in
the PC. WLAN speeds provided by the 802.11 family of standard
operating at 2.4 GHz frequency band extend at the moment up
to 11 Mbit/s. Similarly, high-end mobile phones have evolved
into wireless terminals supporting browsing (with Wireless Access
Protocol, WAP) and e-mail delivery. For cellular access, protocols
have been developed with better support for Internet content,
including General Packet Radio Service (GPRS) and Universal
Mobile Terrestrial System (UMTS). Again, the basic scheme for
browsing the Internet is of client/server type for WLAN access,
GPRS, and UMTS.
Because of increased support for user mobility, services dedi-
cated to reaching the mobile user are becoming increasingly impor-
tant. An example of this type, the client–server paradigm can be
used for implementing instant messaging service, differing from e-
mail by the requirement of rapid delivery of message. One of the
first such services was the SMS of GSM, recently extended to MMS
supporting also pictorial content. Same kind of services have been
developed also for the general purpose Internet. Extending this
idea beyond pairwise person-to-person messaging leads to mul-
tiparty communication such as online chatting (web chat). It is
14 SERVICE QUALITY REQUIREMENTS
useful to note that often also the person-to-person services make
use of a server in the network, which takes care of distribution of

the actual messages.
A new class of services, different from the traditional
client–server paradigm and related to mobile users, is emerging,
called push-type services. To provide an example of this, a research
engineer reading his e-mails in the airport using 802.11 WLAN
access could receive on his display an unsolicited advertisement
for a perfume far too expensive for his income level on offer
at the nearby tax-free store. Push-type services require a way of
identifying the target mobile host. Push-type services are possible
also in GSM networks.
An equally novel type of service, made possible by the Internet,
is point-to-point real-time communication over the Internet. Voice
over IP (VoIP) clients for PCs can be downloaded from the Inter-
net that contain audio and/or video coding/decoding function
as well as protocols for sending audio/video samples in packet-
switched networks. This makes it possible for two such clients to
contact each other directly, if they know each other’s DNS names
or IP addresses. This kind of solution is not very scalable, how-
ever, since the end user is left with the task of maintaining a
“telephone directory” of callees. A Call Processing Server (CPS)
such as a Session Initiation Protocol (SIP) proxy is typically used
for interfacing to terminal availability information. Also, the Inter-
net of today does not automatically provide good enough quality
for a VoIP call without signalled quality support. Thus, a practi-
cal solution typically involves a directory server as well as some
means of providing service quality support for the connection.
These examples only scratch the surface of possible Internet ser-
vices. The ones described above are among the most well-known
ones. As is evident from the examples, the Internet is a good plat-
form for creating new kinds of innovative services, provided that

the inherent quality requirements of services can be satisfied.
The ITU-T provides a long list of Internet service types in
[G.1010]. In [Y.1541], the following summary classification for
Internet services is given in Table 2.1:
The following types of Internet communications have been
identified so far:
• Delivery of real-time content such as audio or video. This includes
both conferencing and streamed content.
• Delivery of data-type content such as e-mail.
2.1 SERVICES ON THE INTERNET 15
Table 2.1 Draft IP QoS classes  International Telecommunication Union
QoS Class Applications
0 Real-time, jitter-sensitive, high interaction (VoIP, VTC)
1 Real-time, jitter-sensitive, interactive (VoIP, VTC)
2 Transaction data, highly interactive (signalling)
3 Transaction data, interactive
4 Low loss only (short transactions, bulk data, video streaming)
5 Traditional applications of default IP networks
Source: From [Y.1541].
• Interactive client–server applications. This category includes
browsing and messaging involving a network server. There may
be multiple degrees of urgency within this category, ranging
from web browsing to real-time remote control of machinery.
• Server-initiated services. This category includes “unsolicited”
services such as receiving of advertisements. Although the
actual content may fall within data-type or real-time type
content discussed above, this is a separate category for the
reason of not being requested by the terminal.
Let us next take a closer look at the diverse types of content can be
delivered over the Internet. A crude summary of some of the most

common types is given in Table 2.2, and more elaborate discussion
will follow later in this chapter. The diverse nature of the types
of services sets certain requirements of the service quality support
on the Internet. Definition of the conceptual framework, as well
as a description of the mechanisms needed, form the fact matter
of this book and are shown in Table 2.2. The mobility aspects of
Table 2.2 Summary of some of the most common Internet service content
types
Internet service Request/reply? Content delivery
time
Continuous
content?
E-mail No Not critical No
HTTP page Yes Interactivity required No
Streamed content Yes Medium Yes
Instant messaging/
web chat
Yes Interactivity required No
Music file download Yes Not critical No
Push-type advertisement No Not applicable No
Multimedia call No Short Yes
16 SERVICE QUALITY REQUIREMENTS
service quality support are not a central topic in this book, but
will be referred to where appropriate.
2.2 DEFINITION OF A SERVICE
On the Internet, the definition of service in general is a difficult
issue [RFC3052]. The open standards environment characteristic of
the Internet makes it possible to devise services with much greater
freedom than in the Intelligence Networks (IN) environment. The
SIP framework of the Internet Engineering Task Force (IETF), for

example, provides for building blocks for reachability and identity
services, and – together with the Session Description Protocol
(SDP) – makes it possible to signal application requirements
between two ends of the communication. A practical consequence
of the preceding facts is that the idea of standardizing services is
no longer valid [RFC3052]. Thus, we shall adopt a broad view here
based on classification of services.
There is a long body of experience of implementing services
within the telecommunications industry. The basic reason for this
is that in the communications model of telephony the services
assurance is provided by the network, whereas terminals (tele-
phones) are relatively simple. Subsequently, precise service defi-
nitions are required to provide service quality end-to-end also in
the presence of multiple commercial operators. In addition, espe-
cially the service implementation of mobile telephony requires a
sophisticated service quality requirement definition. For this rea-
son, telecommunication services are used as a framework and
point of comparison in the following.
The original telecommunications service, voice telephony, has
been complemented with services such as call forwarding, voice
mailboxes, and A subscriber (caller) number display for the B sub-
scriber (callee). The paradigm for supporting this in the POTS
environment is called Intelligent Networks (IN), making possi-
ble the creation of new services in the world of circuit-switched
telephony.
The TeleManagement Forum defines service from a telecommu-
nications point of view as follows [SMH01]:
Service – a telecommunication service is a set of independent
functions that are an integral part of one or more business
processes. This functional set consists of the hardware and

2.2 DEFINITION OF A SERVICE 17
software components as well as the underlying communica-
tions medium.
The above definition is a fairly high-level one. Another approach
is adopted by the 3rd generation partnership project (3GPP), view-
ing services from a technical support perspective. The 3GPP QoS
framework provides the following set of definitions related to ser-
vices [22.105]:
Bearer service: A type of telecommunication service that
provides the capability of transmission of signals between
access points.
Service Capabilities: Bearers defined by parameters, and/or
mechanisms needed to realize services. These are within
networks and under network control.
Service Capability Feature: Function offered by service
capabilities that are accessible via the standardized
application interface.
Services: Services are made up of different service capability
features.
For the present purposes, it is sufficient to know that the con-
cept of “bearer” is an abstraction for service quality support class
provided by the network.
Comparing the two definitions above, services can be viewed
as being a part of business processes from above (by “the suits”
in Internet terminology), and being made possible with service
quality support mechanisms from below (by the engineers).
In telecommunications, the management of services has been
an important issue. According to [ECN02], standardization of ser-
vice management framework in telecommunications industry has
not been successful in the sense that all aspects of service man-

agement conform to a standard. On the other hand, standards
have been created for relevant interfaces for the purpose of inter-
operator service management. In this book, the viewpoint is not
that of standardized services, but of management and other pro-
tocol interfaces that can be used for constructing services. When
the interfaces are based on open standards and the concepts used
in specifying service support across business parties are involved,
the lack of standardized services can be turned into an advantage
for all parties involved: the customer, the network provider, and
the service provider.
18 SERVICE QUALITY REQUIREMENTS
2.2.1 End user service versus provider-level
services
A useful conceptual division for bringing structure into the discus-
sion about services is that between end user services and provider-
level services. End user service means the service as experienced by
an end user (single instance of a service), whereas provider-level
service definition is typically concerned with an aggregated view
of individual sessions.
An example of studying services at end user level is a study
to what extent of user experience of e-commerce is satisfactory.
As will be discussed in Section 2.3, this requires the definition
of suitable metrics, and a controlled means of performing the
measurement.
Continuing the e-commerce example, the provider-level service
would view e-commerce sessions en masse, on an aggregated level.
The e-commerce service provider would probably look at the
overall average number of transactions per hour, broken down
according to time of day, taking an example. Another example, an
Internet Service Provider (ISP) providing connectivity for home

customers is likely to be able to look at history data of average
load in different parts of the network, including Digital Subscriber
Line Access Module (DSLAM) and the link towards a Point of
Presence (PoP) in backbone network. A connectivity provider
for service operators would likely look at the loading level on
leased lines towards service providers and towards the backbone
network.
Now let us assume that Mary Ann, the owner of a corner shop
grocery buying her fruits in Internet auctions, wants to get an
Internet connection to take care of her bidding and other financial
matters of her business using Asymmetric Digital Subscriber Line
(ADSL) access to the Internet. What is she to do? Mary Ann will
have an agreement with her ISP saying, for example, that her
access line maximum throughput is 1024 kbit/s downlink and
256 kbit/s uplink. Having experienced problems with congestion
before, Mary Ann may not be satisfied with the theoretical access
line maximum throughput only, but require guarantees about
average throughput available between the Internet (PoP) and
DSLAM also during peak hours, for example. Capacity-wise, this
throughput requirement would be a component of an end user
service level agreement (SLA) between the ISP and Mary Ann. The
2.2 DEFINITION OF A SERVICE 19
SLA brings with it the question of how the fulfilment of the
agreement can be verified by the customer.
It is possible that the bank Mary Ann is a customer of is using a
service provider, let’s say an Internet fruit auction site, which does
not belong to the domain of the ISP the bank is using for Inter-
net access. The presence or absence of direct peering agreement
between these two can affect the end user service quality experi-
enced by Mary Ann. If Mary Ann were to expand her business

(and presumably increase traffic as well), she might inquire about
the inter-provider service level agreement in deciding which ISP to
use, especially if more than one critical service were at a stake.
Please note that at this stage the agreement between Mary Ann
and the service provider becomes less of one between end user
and an ISP and more like a peering agreement. It is also possible
that the fruit auctioning site does not connect directly to the ISP
domain, but that there’s a separate long-haul backbone operator
involved. In this case, all inter-operator SLAs potentially affect the
service quality.
So far, the example has concentrated on throughput. The next step
in enhancing service quality is being able to ask for and receive guar-
antees for different kinds of services. In addition to auctioning and
e-commerce transactions, the ever energetic and technically savvy
Mary Ann has decided to switch her telephone traffic from POTS to
VoIP. She decides that this means that VoIP calls must receive prior-
ity delivery, e-commerce and auctioning transactions must receive
high quality treatment, and e-mail and other web browsing use the
remaining capacity of the agreement between the ISP and Mary
Ann’s enterprise. In order to be able to promise this, the ISP requires
Mary Ann to characterize the flows for each transaction types. As
we shall see in the next chapter, operator needs this information to
implement service quality cost-efficiently.
Collecting the essential content of the above little fable, the fol-
lowing phases related to service quality can be identified:
1. Inherent service quality requirements need to be understood.
For example, a VoIP call has strict limits on allowable delay
but can tolerate some packet loss. TCP-based services such as
browsing will adapt to available bandwidth, but throughput
of individual sessions is enhanced by minimizing variations in

Round-Trip Time (RTT) and available bandwidth.
2. The volume of each service needs to be estimated. What is the
peak-hour usage of each service and when does it occur?
20 SERVICE QUALITY REQUIREMENTS
3. Acceptable end user service level for each service type must
be definable. For services such as VoIP, there is not much free-
dom in selecting service quality except for choice of coding
scheme. For browsing, on the other hand, the average through-
put of non-critical sessions can possibly be throttled down dur-
ingpeakhours.
4. Service flow characteristics need to be defined. How large is
the volume of traffic for each service type resulting from the
previous steps?
5. A SLA is made between end user and connectivity provider.
6. Operator and service provider use appropriate mechanisms for
fulfilling the promised service level (provider-level SLA). The
operator may send reports of the measured SLA level, and the
service provider makes his/her own measurements to double-
check the situation.
7. The end user may wish to have means of verifying the confor-
mance of service to SLA.
The emphasis in this section is on defining characterizations of
service quality characterizations, that is, end user SLA-related
issues. The inter-provider SLA issues are discussed in Chapter 6.
Some means of SLA verification by the end user are referred to in
Chapters 4 and 7.
2.2.2 About service instances and service events
Considering a single service type such as a HTTP browsing, the
aggregate service – provision of HTML content – is used via ser-
vice instances, or user browsing sessions to the server. A single

service instance, on the other hand, can often be considered to con-
sist of a number of service events. For example, the service instance
comprising of browsing the BBC website would consist of service
events that are HTTP query/reply pairs. For client–server type
interaction, the service event roughly corresponds to the appli-
cation transaction in [SMJ00]. Generalizing, for the purposes of
the present book, service event is a distinct, measurable part of
a service instance that can be clearly defined. See Table 2.3 for
examples of service event types.
For the client–server case, the definition of a service event is
relatively clear. In the case of telephony, on the other hand, such
2.2 DEFINITION OF A SERVICE 21
Table 2.3 Some Internet services and service event types
Service Service event type Note
News summary WWW
home page
HTTP request + HTTP
reply
Two-way service
event (client-server-
client).
IP telephony Call set-up signalling
message
Uses TCP (for
example), may
have service quality
requirements.
Transmission of voice
sample from sender
to receiver

One-way service
event.
HTTP interface to client’s
bank account
Authentication Request/reply.
Multiple encrypted
HTTP requests using
forms
A variable number of
two-way service
events.
a definition is not equally easy. The service event could equally
justifiably be defined to be any of the following alternatives:
• end-to-end delivery of a voice sample;
• end-to-end delivery of a talkspurt (a sequence of voice samples
bounded by absence of voice signal);
• end-to-end delivery of entire voice content of a telephone call.
Luckily, no overarching definition for service event is necessary
for this book. A service event is a definition to uniquely describe
service requirements, and can be used flexibly according to need.
It is important to separate the parts of service instance having dif-
ferent characteristics and service quality requirements. In the case
of a VoIP call with application sharing, for example, the following
distinct service event types can be enumerated:
• connection set-up signalling (e.g., H.323 or SIP);
• transmission of VoIP media stream (e.g., G.723.1 or Adaptive
Multi-Rate codec, AMR) or a part thereof;
• transmission of application data (most likely TCP).
Each of these service event types has specific quality requirements,
some coming from standards, and some from less official design

targets. Some examples of service events are provided in Table 2.3.
22 SERVICE QUALITY REQUIREMENTS
2.2.3 Reference model for this section
For the purposes of the present section, a simple reference model
is described here. More advanced reference models are discussed
in Chapter 5, after appropriate network QoS mechanisms have
been described.
To start with, let us first list the different types of services on
the Internet there are. As illustrated by examples in Section 2.1,
the most familiar one is the client–server type service based
on requests and replies (see Figure 2.2). However, services
exist where the endpoint is another user. Examples of this
connectivity/service type paradigm include messaging, presence
and telephony/conferencing services. The latter paradigm is used
as a high-level reference model for this book, as it includes the
single-endpoint client/server model as a special case.
SLAs can be used between the service provider and connectivity
provider, between connectivity providers, and between connectiv-
ity provider and end user. When a connectivity provider supports
Service
provider
Access
provider
Client
Server
Service
provider
Client
Client
Connectivity

provider
Server
End
user
SLA
End
user
SLA
End
user
SLA
Inter-provider SLA
Inter-provider SLA
Figure 2.2 Client–server (upper figure) and connectivity/service (lower
figure) paradigms illustrated
2.3 SERVICE QUALITY ESTIMATION 23
Aggregate service
Service
instance
Service
instance
Service
instance
Service
event
Service
event
Service
event
Service

event
Type A Type CType B
...
Figure 2.3 The relation of concepts ‘‘aggregate service’’, ‘‘service
instance’’, ‘‘service event’’ and ‘‘service quality requirement type’’ as
used in this book
service quality, the SLAs between different parties must be able
to express service quality requirements.
Service, as seen by an end user, consists of an instantiation
of the service, in turn comprised of one or more service events.
A single service instance can contain multiple classes of service
events, a major aspect of classification being related to the need
for particular service quality requirement type. This is illustrated
in Figure 2.3. As will be discussed later, the network typically
handles services in terms of service quality classes.
Service Level Agreements and related technologies will be dis-
cussed in more detail in Chapter 6.
2.3 SERVICE QUALITY ESTIMATION
The desirability of a customer having the means to verify service
quality was referred to before. In addition to verification aspects,
24 SERVICE QUALITY REQUIREMENTS
a meaningful definition of service quality in a SLA must be based
on an understanding of how service quality is measured. Thus,
let us next consider how service quality can be estimated. Vari-
ous individual aspects pertaining to serving the customer can be
measured. For the Internet, measurements of objective character-
istics such as delays and packet loss percentages have been made
since wide-scale deployment of the Internet [Bol93, Pax97]. This is
a very important topic for this book, and examples of measurable
quantities are discussed in Section 2.3 below. Standardized means

of making the measurements and utilizing the information will be
discussed in Chapters 4 and 7.
The numerical measures of individual characteristics are not
enough for formulating a framework for service quality assess-
ment. The corner shop grocer – very justifiably – doesn’t neces-
sarily want to how many milliseconds it takes for the sentence
“bag of carrots” to traverse from Edinburgh to Glasgow or how
many audio samples were lost during the telephone call. Mary
Ann – the grocer – wants the order to be placed and understood
correctly by Pierre, the wholesale retailer. What needs to be mea-
sured is the effect of objectively definable and measurable events
of perception process. Especially for the purposes of end user com-
munication of service quality characteristics, they often need to be
presented to the end user in a “palatable” form.
One approach is to express service quality in terms of per-
service concepts. Due to the potentially large number of services,
this leads to an unnecessary diversification of terminology. The
approach in this book is to attempt to formulate a set of service
quality-related characteristics that span the range of different ser-
vices, while attempting to be concrete enough to be understood by
non-technical people. Services can then be conceptually be made
to correspond to a subset of each characteristic. Before delving into
discussion about these characteristics, we shall study the means of
assessing service quality for individual services for the purposes
of technical concreteness.
2.3.1 Measures of end user experienced service
quality
Table 2.4 lists some factors affecting the end user experience
for telephony, and a corresponding generalization for Internet
services. For telephony, a mathematical model called the E-model

2.3 SERVICE QUALITY ESTIMATION 25
Table 2.4 Factors affecting service quality for telephony and Internet
services in general
Telephony Internet services
Psychological factors – importance of
communication
Psychological factors – importance
of communication
Availability of service Availability of service
Call set-up time Service invocation time
Constancy of service quality Constancy of service quality
Surroundings/background noise Surroundings
Terminal audio setup:
microphone/loudspeaker/headset
User interface for service client
Audio coding scheme Protocol representation of service
instance
TCP/IP protocol stack implementation TCP/IP protocol stack
implementation
Operating system – scheduling Operating system – scheduling
Service quality support on the Internet Service quality support on the
Internet
[G.107] has been developed by ITU-T for the purposes of
end-to-end planning. The model takes into account mostly
technical factors along the telephone connection between the
“A subscriber” and “B subscriber”, to use the telephony jargon.
Similarly, the factors contributing to user experience in IP
telephony have been divided into ones originating from the
terminals (hosts), and the transport network in between [TIPHON-
2]. The measurement of end user service quality experience,

however, is not fully captured with mathematical modelling only.
These issues will be discussed in more detail below.
In the case of telephony, the need for measuring end user ser-
vice quality experience was recognized early on. The effect of
a lost voice sample is perceived very differently depending on
which kind of phoneme it coincides, with what kind of audio
coding scheme is used, and how large a share of the audio sam-
ples are lost. The Mean Opinion Score (MOS) [P.800] is a scheme
for performing controlled evaluation of subjective voice quality