SLA Management Handbook: Concepts and Principles

SLA Management Handbook
Volume 2
Concepts and Principles
Release 2.5
GB 917-2
Member Evaluation, Version 2.5 July 2005
TeleManagement Forum 2005
i
SLA Management Handbook - Vol 2
Notice
The TeleManagement Forum (“TM Forum”) has

made every effort to ensure that the contents of this
document are accurate. However, no liability is
accepted for any errors or omissions or for
consequences of any use made of this document.
This document is a draft working document of TM
Forum and is provided to its members solely for
formal comments and evaluation. It is not a Forum
Approved Document and is solely circulated for the
purposes of assisting TM Forum in the preparation
of a final document in furtherance of the aims and
mission of TM Forum. Any use of this document by
the recipient is at its own risk. Under no
circumstances will TM Forum be liable for direct or
indirect damages or any costs or losses resulting
from the use of this document by the recipient.
Members of TM Forum are granted limited
copyright waiver to distribute this document within
their companies. They may not make paper or
electronic copies for distribution outside their
companies. The only purpose of the provision of
this draft document to members is for making
formal comments thereon to TM Forum.
This document may involve a claim of patent rights
by one or more TM Forum members, pursuant to
the agreement on Intellectual Property Rights
between TM Forum and its members, and by non-
members of TM Forum.
Direct inquiries to the TM Forum office:
240 Headquarters Plaza

East Tower – 10th Floor
Morristown, NJ 07960 USA
Tel No. +1 973 944 5100
Fax No. +1 973 944 5110
TM Forum Web Page: www.tmforum.org
GB917-2 Version 2.5 TeleManagement Forum 2005 Page ii

Executive Summary
The Service Level Agreement (SLA) Management Handbook series consists of

four volumes. These are Volume 1, Executive Overview, Volume 2, Concepts and
Principles, Volume 3, Applications and Examples and Volume 4, Enterprise and
Applications. The series has a common conceptual base with each volume
concentrating on specific topics. The volumes may be read in any order although it
is suggested that Volumes 2 and 4 be read before Volume 3. It is expected that
the readers of Volume 1 are interested in an overview of the SLA Management
process that is sufficient to enable them to provide management guidance to their
organizations. For reader convenience, the Executive Summaries for Volumes 1,
2, and 4 are in the Annexes to this document.
The objective of the SLA Management Handbook series is to assist two parties in
developing a Service Level Agreement (SLA) by providing a practical view of the
fundamental issues. The parties may be an “end” Customer, i.e., an Enterprise,
and a Service Provider (SP) or two Service Providers. In the latter case one
Service Provider acts as a Customer buying services from the other Service
Provider. For example, one provider may supply network operations services to
the provider that supplies leased line services to its customers. These relationships
are described as the Customer-SP interface and the SP-SP interface.
The perspective of the SLA Management Handbook series is that the end
Customer, i.e., an Enterprise, develops its telecommunication service
requirements based on its Business Applications. These requirements are
presented to a Service Provider and the two parties begin negotiating the specific
set of SLA parameters and parameter values that best serves both parties. For
the SP, the agreed-upon SLA requirements flow down through its organization and
become the basis for its internal management and control of its Quality of Service
(QoS) processes. For the Enterprise Customers, the SLA requirements serve as a
foundation or a component of its internal network services or business services.
This volume of the Handbook contains three tools that provide the foundation for
clarifying management roles, processes, responsibilities and expectations. These
are the Key Quality Indicator Methodology, the Life Cycle of the Service and the
SLA Parameter Framework.
Service Providers have historically reported the performance of their networks

against a set of Key Performance Indicators (KPIs). These KPIs are inherently
network focused and provide little direct indication of the end to end service
delivery that the network supports. Nevertheless KPIs are an important
measurement for network operations and will continue to be so for the foreseeable
future.
GB917-2 Version 2.5 TeleManagement Forum 2005 Page iii

The move towards service focused management leads to a requirement for a new
'breed' of indicators that are focused on service quality rather than network
performance. These new indicators or Key Quality Indicators (KQIs) provide a
measurement of a specific aspect of the performance of the product, product
components e.g. services, or service elements and draw their data from a number
of sources including the KPIs
A service and its associated SLA are divided into six Life Cycle Stages to clarify
the roles of the Customer and the SP. The six Life Cycle Stages are as follows:
product/service development, negotiation and sales, implementation, execution,
assessment and decommissioning. Each life cycle stage addresses specific
operations processes in the enhanced Telecom Operations Map (eTOM) [GB
912]. The SLA Life Cycle provides a complete process description by delineating
interactions between well-defined stages.
Many performance parameters exist that have similar names yet have drastically
different definitions. The SLA Parameter Framework is a useful tool for
categorizing parameters. The framework organizes SLA parameters into six
categories based upon service and delivery technology and upon measures of
individual instance and average performance. The specification of specific values
for service performance parameters is part of a specific contract negotiation and is
beyond the scope of the Handbook.
The SLA Management Handbook series incorporate earlier work that appears in
the Performance Reporting Concepts and Definitions Document [TMF 701], in the
Service Provider to Customer Performance Reporting Business Agreement [NMF
503] and in Service Quality Management Business Agreement [TMF506].
GB917-2 Version 2.5 TeleManagement Forum 2005 Page iv

Table of Contents
Notice ............................................................................................................................................... ii
Executive Summary...................................................................................................................... iii
Table of Contents........................................................................................................................... v
List of Figures................................................................................................................................ xi
List Of Tables............................................................................................................................... xiv
1 Introduction ................................................................................................................................. 1
The Drivers For Service Level Agreements ............................................................................ 1
Approach To SLA Specifications............................................................................................. 2
SLA Business Relationships.................................................................................................... 3
Scope........................................................................................................................................ 4
Handbook Benefits................................................................................................................... 7
1.1.1 Service Providers .................................................................................................... 7
1.1.2 Customers ............................................................................................................... 7
1.1.3 Equipment And Software Vendors ......................................................................... 8
Notes For Readers................................................................................................................... 8
Overview................................................................................................................................... 8
2 Business Considerations ........................................................................................................ 12
Introduction............................................................................................................................. 12
The Business Context............................................................................................................ 12
2.1.1 SLAs In The Evolving Marketplace ...................................................................... 14
The Business Model............................................................................................................... 14
2.1.2 The Basic Model ................................................................................................... 14
2.1.3 The Relationship Model ........................................................................................ 15
2.1.4 End To End Service .............................................................................................. 16
Business Benefits................................................................................................................... 17
2.1.5 Customer Benefits................................................................................................. 17
2.1.6 Service Provider Benefits...................................................................................... 19
2.1.7 Supplier Benefits ................................................................................................... 19
Service Performance Parameter Selection........................................................................... 20
GB917-2 Version 2.5 TeleManagement Forum 2005 Page v

Service Measurement Considerations...................................................................................20

2.1.8 Performance Parameters And Metrics..................................................................21
2.1.9 Performance Measurement Methodology ............................................................21
Anticipating Change................................................................................................................22
3 Telecommunications Services ................................................................................................23
Service Characterization.........................................................................................................23
The Enterprise View ...............................................................................................................24
Service Elements....................................................................................................................24
Service Containment And Management Domains ................................................................26
Customer Contact Point Reference Model ............................................................................26
Service Access Points ............................................................................................................27
3.1.1 Definition ................................................................................................................27
3.1.2 SAP Examples.......................................................................................................28
3.1.3 Multiple SAP Services ...........................................................................................29
3.1.4 Single SAP Services..............................................................................................29
3.1.5 Regulatory Issues ..................................................................................................30
Performance Perspectives .....................................................................................................30
3.1.6 Service Performance Factor Definitions ...............................................................31
3.1.7 Network Performance Factors ..............................................................................32
3.1.8 Events And Performance Parameters ..................................................................32
3.1.9 Network Performance - Service Performance Distinctions..................................33
3.1.10 The Role Of Traffic Engineering............................................................................34
Performance Indicator Hierarchy ...........................................................................................36
3.1.11 KQI Definition And Usage .....................................................................................38
Quality Of Service ...................................................................................................................39
3.1.12 User Perception .....................................................................................................40
3.1.13 Customer Satisfaction ...........................................................................................41
3.1.14 Views Of QoS ........................................................................................................42
3.1.15 Service Performance Specification Model............................................................45
3.1.16 Assessing Performance ........................................................................................46
Service Availability ..................................................................................................................47
3.1.17 Customer Perspective ...........................................................................................47
3.1.18 Service And Network Performance Perspective ..................................................48
3.1.19 Computing Basic Service Availability....................................................................49
GB917-2 Version 2.5 TeleManagement Forum 2005 Page vi

3.1.20 Service Degradation Factor (SDF) ....................................................................... 50

3.1.21 SAP Weighting ...................................................................................................... 51
3.1.22 SAP Attributes And Parameters ........................................................................... 52
3.1.23 Service Availability Information Sources .............................................................. 55
3.1.24 Service Availability And Layered Protocols.......................................................... 55
3.1.25 Service Availability Levels..................................................................................... 56
Emergency Priority Service.................................................................................................... 57
3.1.26 The Service Definition........................................................................................... 57
3.1.27 ETS Performance ................................................................................................. 59
Selected Service Considerations........................................................................................... 60
3.1.28 Time To Restore Service ...................................................................................... 60
3.1.29 Time To Provide Service ...................................................................................... 61
3.1.30 Service Delay ........................................................................................................ 63
3.1.31 Service Access...................................................................................................... 64
3.1.32 Throughput ............................................................................................................ 65
3.1.33 Errors ..................................................................................................................... 65
4 SLA Content And Management .............................................................................................. 66
Content Recommendations ................................................................................................... 66
4.1.1 The Fulfillment Process ........................................................................................ 67
4.1.2 The Assurance Process........................................................................................ 68
4.1.3 Customer Interface Management......................................................................... 69
4.1.4 General Recommendations.................................................................................. 69
Relating Offers, Products, Services And SLAs ..................................................................... 70
4.1.5 Role Of SLAs Within Service Products ................................................................ 73
4.1.6 Defining Service Commitments ............................................................................ 75
4.1.7 SLA To Service Mapping...................................................................................... 76
4.1.8 Service Example ................................................................................................... 77
Multiple Domain SLAs............................................................................................................ 77
5 SLA Management Tools........................................................................................................... 80
The Service Life Cycle ........................................................................................................... 80
5.1.1 The Product/Service Development Phase........................................................... 81
5.1.2 The Negotiation And Sales Phase ....................................................................... 82
5.1.3 The Implementation Phase................................................................................... 83
5.1.4 The Execution Phase............................................................................................ 83
GB917-2 Version 2.5 TeleManagement Forum 2005 Page vii

5.1.5 The Assessment Phase ........................................................................................83

5.1.6 The Decommissioning Phase ...............................................................................84
Use Cases And Scenarios .....................................................................................................84
KQI Development Methodology .............................................................................................85
5.1.7 Service Scenarios..................................................................................................85
5.1.8 Analyse Timeline....................................................................................................86
5.1.9 Identify Service Topology ......................................................................................87
5.1.10 Develop Transaction Matrix...................................................................................87
5.1.11 Develop KQIs.........................................................................................................88
5.1.12 Identify Measurements ..........................................................................................89
The SLA Parameter Framework ............................................................................................90
5.1.13 Network Bearer Services And Application Services.............................................90
5.1.14 Parameter Categories ...........................................................................................90
5.1.15 Service Views ........................................................................................................91
5.1.16 The Service Parameter Table Examples..............................................................92
5.1.17 Service/Technology Independent Parameters .....................................................93
5.1.18 Technology-Specific Parameters ..........................................................................94
5.1.19 Service Specific Parameters .................................................................................95
5.1.20 Service Degradation ..............................................................................................96
5.1.21 Management Of Service And Network Performance...........................................96
SLA Data Management ..........................................................................................................97
5.1.22 Role Of In-Service Monitoring ...............................................................................99
6 SLA Performance Reporting..................................................................................................100
Measurement And Reporting Intervals ................................................................................100
6.1.1 Measurement Considerations .............................................................................100
6.1.2 Events And Reporting..........................................................................................101
Performance Reporting ........................................................................................................102
6.1.3 Role Of The Performance Reporting Process....................................................103
6.1.4 Process Functions Addressed ............................................................................103
The Reporting Functional Interfaces ....................................................................................103
Reporting Scenarios .............................................................................................................104
6.1.5 Reporting With Acknowledgement......................................................................104
6.1.6 Reporting Via Drop-Off ........................................................................................105
6.1.7 Reporting On Demand ........................................................................................106
GB917-2 Version 2.5 TeleManagement Forum 2005 Page viii

6.1.8 Changing The Reporting Mode .......................................................................... 107

State Model .......................................................................................................................... 107
6.1.9 Events And State Transitions ............................................................................. 108
Reporting Intervals ............................................................................................................... 109
6.1.10 Measurement Interval ......................................................................................... 109
6.1.11 Data Collection Interval....................................................................................... 110
6.1.12 Aggregate Interval............................................................................................... 110
6.1.13 Example............................................................................................................... 110
Types Of Reports ................................................................................................................. 110
Common Report Formats .................................................................................................... 111
Performance Report Content............................................................................................... 112
6.1.14 Service-Independent Measurements ................................................................. 112
Traffic Data Report Content................................................................................................. 112
7 Relationship To TMF Initiatives ............................................................................................ 113
NGOSS................................................................................................................................. 113
eTOM.................................................................................................................................... 113
SID 115
References .................................................................................................................................. 117
Acronyms .................................................................................................................................... 120
Annex A - Terms and Definitions............................................................................................. 128
Annex B - Executive Summary For Volume 1........................................................................ 138
Annex C - Executive Summary For Volume 3........................................................................ 142
Annex D - Executive Summary For Volume 4........................................................................ 144
Annex E – Performance Specification References ............................................................... 146
E.1.1 Conditions............................................................................................................ 146
E.1.2 Essential Findings ............................................................................................... 146
Annex F – Report Information Sources .................................................................................. 154
Annex G - Perceived And Delivered Performance ................................................................ 157
Annex H - SLA Lifecycle Use Cases........................................................................................ 161
Annex I – Example Of KQI Methodology ................................................................................ 181
Annex J – Key Quality Indictor Format ................................................................................... 190
Annex K – eTOM Mapping ........................................................................................................ 194
Administrative Appendix........................................................................................................... 199
About this document ............................................................................................................ 199
GB917-2 Version 2.5 TeleManagement Forum 2005 Page ix

Document Life Cycle.............................................................................................................199

Document History .................................................................................................................200
Version History .................................................................................................................200
Release History ................................................................................................................200
Document History .................................................................................................................201
How To Obtain Copies .........................................................................................................201
How To Comment On This Document.................................................................................201
Acknowledgments.................................................................................................................202
About TeleManagement Forum ...........................................................................................204
GB917-2 Version 2.5 TeleManagement Forum 2005 Page x

List of Figures
Figure 1-1: Service Delivery Relationships ......................................................................4
Figure 1-2: The SLA Management Handbook Documents ............................................4
Figure 2-1: SLA At The Customer-Service Provider Interface.................................... 15
Figure 2-2: Service Provider Centric eTOM Business Relationship Model.............. 16
Figure 2-3 End-To-End Service Challenge ................................................................... 17
Figure 2-4 Customer Viewpoint Of Service.................................................................. 18
Figure 3-1: Service Functions And Service Resources .............................................. 23
Figure 3-2: Networks Services - Business Services And Applications ................... 24
Figure 3-3: Layered Service Architecture...................................................................... 25
Figure 3-4: Customer Contact Point Reference Model................................................ 27
Figure 3-5: Simplified ATM/SDH/PDH Network............................................................. 28
Figure 3-6: A Service Access Point Example ............................................................... 29
Figure 3-7: Network Performance – Service Performance Relationship ................. 31
Figure 3-8: Traffic Engineering Tasks Per E.490.1....................................................... 35
Figure 3-9 Key Indicator Hierarchy................................................................................ 37
Figure 3-10 KQI Identification......................................................................................... 38
Figure 3-11: Four Views Of Quality Of Service ............................................................. 42
Figure 3-12 Inter-Relationships Between Various Viewpoints Of QoS .................... 43
Figure 3-13: Service Specification Model...................................................................... 46
Figure 3-14: Factors Contributing To Quality Of Service............................................ 46
Figure 3-15: Relationship Of Service Availability To Service Performance ............. 48
Figure 3-16: Time To Restore Service (TTRS) Illustration........................................... 61
GB917-2 Version 2.5 TeleManagement Forum 2005 Page xi

Figure 3-17: Service Ordering Process Sequence Diagram........................................62
Figure 3-18: Time To Provide Service Tolerance..........................................................63
Figure 4-1: eTOM Level 0 View Of Level 1 Process Groupings ..................................66
Figure 4-2 SLA Universe..................................................................................................70
Figure 4-3 End-To-End SLA Management ....................................................................71
Figure 4-4 Product Components ....................................................................................72
Figure 4-5: Bundle Composition .....................................................................................73
Figure 4-6: Service Contract Relationships...................................................................74
Figure 4-7: Components Of An SLA Template..............................................................75
Figure 4-8: SAP Relationship And Activity Diagrams ..................................................76
Figure 4-9: Service Composition Example ....................................................................77
Figure 4-10: Service Delivery Across Multiple Service Domains ...............................78
Figure 4-11: Multiple Domain SLA Relationships - Case 1..........................................78
Figure 4-12: Multiple Domain SLA Relationships - Case 2..........................................79
Figure 5-1: Service And Associated SLA Life Cycle ....................................................81
Figure 5-2 KQI Methodology ...........................................................................................85
Figure 5-3 Customer Experience Timeline....................................................................86
Figure 5-4 Developing The Transaction Matrix ............................................................88
Figure 5-5 Developing KQIs From The Matrix ..............................................................88
Figure 5-6: Service Parameter Category Framework ..................................................91
Figure 5-7: Service Functions-Parameter Categories Relationship..........................91
Figure 5-8 Typical Service Parameters..........................................................................92
Figure 5-9: IP Service With DSL Access ........................................................................92
Figure 5-10: ATM Cell Delivery Service ..........................................................................93
Figure 5-11: Availability Performance Measures ..........................................................95
Figure 5-12: SLA Related Data.........................................................................................98
GB917-2 Version 2.5 TeleManagement Forum 2005 Page xii

Figure 5-13: SLA Performance Data Collection............................................................ 98
Figure 5-14: Performance Levels For Related Services.............................................. 99
Figure 6-1: Time Line For Reporting Network And Service Incidents..................... 101
Figure 6-2: eTOM Customer Relationship Management Processes ....................... 102
Figure 6-3: Performance Reporting Interface ............................................................. 104
Figure 6-4: Reporting With Acknowledgement .......................................................... 105
Figure 6-5: Reporting Via Drop-Off............................................................................... 106
Figure 6-6: Reporting With Acknowledgement And Optional Logging .................. 106
Figure 6-7: On-line Performance Reporting Control.................................................. 107
Figure 6-8: Performance Reporting Process State Model ........................................ 108
Figure 7-1 NGOSS Framework..................................................................................... 113
Figure 7-2 Simplified eTOM Process Flow ................................................................. 114
Figure 7-3 Key Service Measurement Entities........................................................... 116
GB917-2 Version 2.5 TeleManagement Forum 2005 Page xiii

List Of Tables
Table 3-1: Service And NP Specification Characteristics............................................33
Table 3-2 Mapping Of Service Unavailability Causes...................................................48
Table 3-3: Example OF Service Degradation Factors ..................................................50
Table 3-4: Billing, Performance And Availability Relationships .................................50
Table 3-5: SAP Attributes And Parameters....................................................................52
Table 3-6: ETS Functional Requirements ......................................................................58
Table 3-7: ETS Performance Mapping............................................................................59
Table 6-1: Significant Times For Performance Reporting .........................................101
Table 6-2: Performance Reporting Events And States ..............................................108
GB917-2 Version 2.5 TeleManagement Forum 2005 Page xiv

1 Introduction
The Drivers For Service Level Agreements
The interest in Service Level Agreements (SLA) has significantly increased due to
the changes taking place in the telecommunications industry. The liberalization of
the telecommunications market has been an important event leading to change
and competition. SLAs represent one of the responses to this newly competitive
environment where a variety of providers enter the marketplace and compete for
Customers. New entrants that are striving to gain market share and to establish
themselves as viable suppliers can use SLAs to provide one means of attracting
Customers. By committing to provide specified levels of service with compensation
or administrative responses if such commitments are not met, a new Service
Provider (SP) can begin to establish its credibility. Likewise, incumbent SPs are
increasingly offering SLAs in response.
The rapid evolution of telecommunications-based applications is accelerating the

rate of introduction of new services that use emerging networking technologies.
SLAs, because they provide a commitment to specified performance levels, can
help encourage Customers to use these new services and technologies. The
critical dependency between a constantly expanding set of essential business
activities and the availability of communication networks and information services
means that greater numbers of Customers are demanding increasingly stringent
communications and information service levels to insure business continuity.
Several emerging market needs place a new emphasis on specifying service

performance in an SLA. These include the requirement to support emergency
response personnel, the opening up of the telecom service market to competition,
and the deployment of services based on network technologies such as ATM and
IP. Additionally, the number of ebusinesses requiring very high levels of service
availability from their external networks and services, such as servers, databases,
etc., continues to rapidly grow.
The cell/packet-based technologies raise new performance specification issues

not present in services based on traditional circuit switched networks and leased
lines. These new performance specifications are related to defining, monitoring
and collecting performance data, and to transforming that data into useful service
performance reports.
Many enterprise Information Technology (IT) departments are being evaluated on

the service levels they provide to other business units within their company.
GB917-2 Version 2.5 TeleManagement Forum 2005 Page 1

Consequently, these IT managers take steps to insure that their infrastructure and
staff can meet these internal SLAs. The IT staff will typically use the SLA
commitments from their SPs when planning the growth and evolution of their own
systems. SLAs are also advantageous for smaller organizations that do not have
an IT department and networking specialists. In these cases, SLAs can provide the
needed performance assurance.
Competition in the liberalized telecommunications markets and the requirements of

Customers for more complex services are leading to a greater emphasis on the
provision of efficient Customer service. SLAs and performance management can
contribute to determining how Customer care is perceived. Customer perception is
important, and good Customer relations including the ability and the capability to
meet commitments are at least as important as price. This is especially true for
Customers whose business success is dependent on telecommunications
services. SLAs can therefore aid SPs in attracting Customers and maintaining
Customer loyalty. All of these factors contribute to meeting Customer Relationship
Management (CRM) goals and initiatives.
All SPs are seeking new ways to distinguish the quality of their services from those
of their competitors. The use of SLAs provides an excellent mechanism to achieve
this goal. However, SPs frequently encounter difficulties in preparing and
managing SLAs. For example, since SLAs have developed in an ad hoc way,
there may not be a set of mutually understood SLA terms to use when creating a
Customer-specific agreement. In addition, many of the commonly used
performance parameters focus on network and network element performance,
whereas a Customer is concerned with assessing service performance levels. All
of these factors require that network-related performance measures be mapped
into service level metrics that are relevant to the service being provided and that
best reflect the Customer’s service expectations.
When multiple SPs are involved in providing a service to an end Customer, the
value chains become more complex. SLAs need to account for this value chain so
that the end Customer can be given the required level of service by it’s SP.
Consequently, all SPs supporting a service require a common understanding of
the service performance requirements and must follow a consistent approach to
SLA management in order to support the commitments to the end Customer.
Approach To SLA Specifications
The methodology and tools defined in this document have been developed to
support a customer centric approach. One key element is that not all of the factors
required to measure the customer’s experience can be derived from the network
component data.. Indeed the perception that customers have of a service is not
solely based on traditional quantitative measures related to network performance,
but may include more qualitative factors, for example; billing accuracy and the
perceived timeliness of problem resolution. This expanded view of customer
satisfaction provides a foundation for service modeling that can account for metrics

in all service components. Typically, a bottom up modeling approach does not

always satisfy this requirement.
The methodology and tools herein can be used to manage service quality
throughout the Customer Experience Lifecycle. This means managing service
quality beyond the in-use phase of the lifecycle to include point of sales,
provisioning, in-use phase and service cessation aspects. It should also be noted
that the in-use phase includes service components such as customer services and
billing.
The customer centric approach described herein recogonizes the need for
extending service quality management beyond individual services to the product
layer of the business. The basis for this is that products the customer buys are
typically composed of one or more services and it is this collection of services that
are the subjects of SLAs.
This document accounts for the fact that in real business situations there exists the
need for end-to-end service management especially when part of the service
delivery chain is outside of the customer facing service providers own business.
This is a situation that is becoming more prevalent in the industry with the
expansion of data services that rely on external content providers.
SLA Business Relationships
A Service Level Agreement (SLA) is an element of a formal, negotiated contract

between two parties, viz., a Service Provider (SP) and a Customer. It documents
the common understanding of all aspects of the service and the roles and
responsibilities of both parties from service ordering to service termination. SLAs
can include many aspects of a service, such as performance objectives, customer
care procedures, billing arrangements, service provisioning requirements, etc.
Although an SLA can address such items, the specification of the service level
commitments is the primary purpose of an SLA. Consequently, the concepts and
principles in this volume of the Handbook focus on the management of SLAs and
on a framework for identifying quality and performance factors and for specifying
an appropriate Level of Service (LoS) and appropriate Quality of Service (QoS) in
an SLA.
In the previous paragraph, references are made to a SP and a Customer. The SP

is the party providing the service and the Customer is the party ordering and using
the service. Both SP and Customer may be in a value chain of service delivery as
shown in a simplified form in Figure 1-1. In this case, a Customer in one SLA is the
SP in another SLA in the chain, and the SP in one SLA is the Customer in another
SLA. However, for any specific SLA, there will be one Customer and one SP.
Consequently, these general roles will be used in this document.

Figure 1-1: Service Delivery Relationships
Scope
Volume 2 of the SLA Handbook series addresses SLA Principles. It is part of the
TeleManagement Forum’s (TMF) four volume series on SLA Management. Figure
1-2 describes the relationship among the four volumes. Annexes B through D
contain the Executive Summaries from the other three volumes. The SLA
Handbook series was cooperatively developed by the TMF and the Open Group.
ICSP Context GB 917 Volume 1 Enterprise Context

eTOM, NGOSS Executive Overview e.g., ITIL
Expands On
Supports Supports
GB 917 Volume 4
GB 917 Volume 2 Enterprise View Through
Concepts And Principles SLA Negotiations
Application Of Based On
GB 917 Application GB 917 Volume 4

GB 917 Volume 3
Note Series Service Definitions,
Service And Technology
Reporting, And
GB 917-A VoIP Examples
Scenarios
ICSP = Information And Communications Service Provider
Figure 1-2: The SLA Management Handbook Documents

This volume defines Service Level Agreements (SLA), the circumstances under
which they are used, and their relationship to other service and business
constructs. It contains a model for telecommunications services that is useful for
SLA development. The important concepts of Service Availability (SA) and
Emergency Telecommunications Service (ETS) are specified in terms of this
service model. The service reporting process is addressed in detail. Finally, this
volume contains assistance in structuring the complex process of SLA
management by providing three tools, viz., the Key Quality Indication (KQI)
methodology, the six-stage Service Life Cycle and the SLA Parameter Framework.
These tools are the key technical contributions of Volume 2.

against a set of Key Performance Indicators (KPIs). These KPIs are inherently
network focused and provide little direct indication of the end to end service
delivery that the network supports. Nevertheless KPIs are an important
future.
'breed' of indicators that are focused on service quality rather than network
performance. These new indicators or Key Quality Indicators (KQIs) provide a
measurement of a specific aspect of the performance of the product, product
components e.g. services, or service elements and draw their data from a number
of sources including the KPIs
The development of an SLA must consider the complete life cycle of a service. Six
life cycle stages are identified in this volume. They are product/service
development, negotiation and sales, implementation, execution, assessment and
decommissioning. When the Customer-Provider interactions address each of
these stages, the resulting agreements will be better aligned and the relationship
enhanced. The term Customer refers to the business that consumes a service. A
Customer may also be another SP. An end user is considered to be an individual
within the Customer organization1.
Many performance parameters exist that have similar names yet have drastically
different definitions. The SLA Parameter Framework is a useful tool for
categorizing parameters. The framework organizes SLA parameters into six
categories based upon service and delivery technology and upon measures of
individual instance and average performance. The specification of specific values
for service performance parameters is part of a specific contract negotiation and is
beyond the scope of the Handbook.
This volume of the Handbook addresses SLA Management from the perspective
of the Customer - SP interface by focusing on service level and service quality
issues. It does not prescribe SLA management from a network operations or
service implementation perspective. An SLA between a Customer and a SP can
1
The main focus of this Handbook is on business and government Customers as opposed to SPs as customers of other
SPs.

refer to one or more services that the Customer is ordering from the SP. It is not
necessarily restricted to one service or even one type of service.
Agreement on terms and definitions for service performance parameters and their
measurement and reporting is a key aspect for constructing and managing SLAs.
Annex A of this document contains definitions for the key terms used in SLA
specifications.
Apart from functionality and price, service quality is an increasingly important factor
for Customers in the competitive telecommunication market. Some would say that
service performance is now the prime factor in selecting telecom services,
particularly for business Customers. This Handbook primarily addresses service
performance related SLA parameters. There are numerous business parameters
contained in a contract that are not covered by this Handbook. For example, while
a rebate process is described in terms of the parameters that may drive it,
parameters for payment and terms are not included herein.
Underlying management systems and detailed business processes tend to be

proprietary and will not be covered. The Customer and SP(s) often choose to
develop their own internal processes for market competitiveness. Therefore, the
Handbook provides the information necessary to develop and manage both
parties’ internal systems in a more efficient manner. The Handbook is consistent
with the enhanced Telecom Operations Map (eTOM). See Chapter 5 for examples
of SLA management in an eTOM environment.
This Handbook is designed to be a reference for SPs as they develop new

services and to assist in Customer discussions. It will inform and educate about
the intricacies of SLAs. It will also provide a structure for creating specifications that
enable both parties to agree on SLA parameters and parameter values and on the
mechanisms used to monitor and report the delivered level of service.
The Handbook is not intended to provide a collection of tables to be filled out

without knowledge of the underlying requirements, capabilities or limitations of the
technology or service(s).
Volume 2 of the Handbook focuses the Customer Relationship Management

(CRM) processes defined in the enhanced Telecom Operations Map (eTOM). This
includes negotiating the SLA during the Sales process, setting the SLA parameters
during the Order Handling process, relating Customer trouble reports to the SLA
during the Problem Handling process and providing rebates and/or other
administrative actions due to SLA violations as part of the Invoicing & Collections
and/or Customer QoS Management process. Some aspects of the eTOM lower
layer processes are considered. Future versions of the Handbook may address
these in more depth.

Handbook Benefits
The SLA Handbook provides valuable information to three classes of readers, viz.,
Service Providers, Service Customers, and Telecommunications and Data
Equipment and Software Providers. Specific benefits to these readers are
discussed in the following sections.
1.1.1 Service Providers
Service Provider is a general term including Information And Communications

Service Providers (ICSP), Network Operators (NO), Internet Service Providers
(ISP), Application Service Providers (ASP), etc.
This Handbook will assist SPs in developing new services with associated SLA
parameters, aligning SLA parameters to meet Customer requirements and an
SP’s internal processes, assigning internal processes according to SLAs, and
responding to SLA requirements from other SPs.
It helps an SP introduce operational changes, improve internal measurements and

reporting, enrich Customer relations and differentiate itself from its competitors.
This Handbook will assist Service Providers to quantify Service Levels (and
therefore the SLA) of any new service in terms of Key Performance Indicators
(KPIs) and Key Quality Indicators (KQIs). Additionally, by defining the level of
service that the SLA provides, the SP is provided with the means to develop a
mechanism for managing the customer’s expectation.
1.1.2 Customers
This Handbook will assist Customers in negotiating an SLA contract that satisfies
their application requirements and in understanding the possibilities, limitations and
expectations related to performance and cost of a service. The SLA parameter
framework documents the needs of individual customers.
The Handbook provides the technical framework within which projects on

“Customer Service” including SLA/QoS Management can function. The SLA
technical framework provides Customers with the means to develop a working
understanding of practical SLA parameters.
The customer will benefit from an SLA that reflects the service as he / she sees it
and not in terms of a technical network.
As Services begin to be quantified and measured in a standardized format,

customers can compare like for like between the SP’s products and the better SP
will realize a benefit in terms of key business drivers.

1.1.3 Equipment And Software Vendors
The Handbook helps Vendors, SPs and Customers create uniform cost-effective
SLA Management solutions. Such solutions consist of products and services
needed to satisfy requirements. Equipment and software vendors will gain insights
into their client’s needs through Volume 3 examples of services to be managed
and the performance parameters to be measured, reported and processed. and
through the SLA Application Notes document series.
The handbook will help vendors of OSS management solutions to understand the
value of a uniform method of determining KPIs and KQIs.
Notes For Readers
The following conventions are used in this volume of the Handbook.
This volume restricts the term enterprise to business entities that do not provide
Information and Communications services to the public.
Consistent with the usage in Volume 4, an end-to-end service is considered to be

one that exists between application layer entities. These entities may reside in
enterprise owned/managed equipment or in service provider equipment. An edge-
to-edge service is one that spans a Service Provider’s network.
Many of the figures in this volume use the Unified Modeling Language (UML)
notation. As this usage is limited to simple cases, familiarity with UML is not a
prerequisite for reading this volume. However, UML knowledgeable readers may
gain a deeper understanding of the information contained in the figures.
Parameter refers to the name of a quantifiable or concrete property of a service.

Parameter value is used when referring to a specific quantity or property, i.e.,
values may be numerical or alphanumeric quantities. In general, this volume uses
parameter and metric interchangeably.
Overview
The following paragraphs briefly describe the objectives and content of the
remaining Chapters of Volume 2 of the Handbook.
Chapter 2 Business Considerations
Business drivers for SLA management are identified and business benefits for
both Customers and SPs are described in this chapter.

Chapter 3 Telecommunications Services
This chapter introduces a conceptual service model that is used to identify service
components and to specify the role of such components within a SP’s service
offering to Customers. It provides examples of separating service offerings into
elementary building blocks, i.e., elementary services and service access points.
The examples also illustrate the relationships between these building blocks.
The chapter also summarizes the various network and service performance
concepts used in the industry. It then partitions service performance measures into
Level Of Service (LoS) and Quality Of Service (QoS) parameters and relates these
two concepts.
This Chapter also introduces Key Performance Indicators (KPIs) and Key Quality
Indicators (KQIs). KPIs are inherently network-based and provided little direct
indication of the end to end service performance. The service focus leads to a
requirement for new indicators that capture service quality rather than network
performance. These indicators are the KQIs. The KQIs provide a measure of
specific aspect of a service and are based on a number of sources including the
KPIs.
Two important services considerations, Service Availability and Emergency

Telecommunications Service, are discussed and are placed into the service
performance context used in the Handbook.
Chapter 4 SLA Content And Management
This chapter contains recommendations for the content, management, and

support of SLAs and their associated performance parameters. It also describes
various SLA structures and provides object models that describe the relationships
between SLAs and other service constructs.
Chapter 5 SLA Management Tools
The six-stage Service Life Cycle and the SLA Parameter Framework are
introduced and explained in this chapter. These two tools provide assistance in
structuring the complex process of SLA specification, negotiation, and
management.
When developing an SLA, consideration must be given to the complete service life
cycle as the various life cycle stages may affect SLA requirements. For example,
different combinations of processes are required to support the six phases of the
SLA life cycle. Different SLA parameters and values may apply during
product/service development, negotiation and sales, implementation, execution,
assessment, and decommissioning. The relevant use cases supporting SLA
management are described and related to the enhanced Telecom Operations Map
(eTOM) processes.
The SLA Parameter Framework is used to organize the large number of SLA
parameters that are in use in the industry. Specifically, the framework defines six

SLA parameters categories. These categories provide direction for developing the
SLA specification. The Framework is the basis for a structured process for SLA
negotiation that can reduce the time required to reach a mutually satisfactory
contract.
The framework places parameters into one of three categories, i.e., a parameter
may be technology specific, service specific or technology and service
independent. Some services may contain both technology-specific and service-
specific parameters; some may contain only one or the other. Many services
contain technology and service-independent parameters.
A commonly overlooked aspect of SLA parameters is the distinction between the

“aggregated” requirements that apply on average to the total user community and
the requirements that apply to a single user of the service. The Framework
addresses this issue.
Certain SLA parameters may be of more interest to the SP than the Customer and
vice versa. This framework provides an organized approach to jointly defining
pertinent SLA parameters and ultimately their values.
Chapter 6 SLA Performance Reporting
This chapter addresses those aspects of performance reporting that track

commitments contained in an SLA. It addresses customer reporting interfaces, and
the types, content, and frequency of reporting. It also contains requirements and
recommendations for reports and for the reporting interfaces.
Chapter 7 Relationship To TMF Initiatives
This chapter briefly discusses the relationships between the work on SLA
Management the TMF’s New Generation Operations Systems and Software
(NGOSS), enhanced Telecoms Operation Map (eTOM), and Shared Information and
Data (SID) initiatives.
Annex A
Agreement on terms and definitions for service performance parameters, and their
measurement and reporting, is required for constructing and managing SLAs.
Apart from functionality and price, service quality is an increasingly important factor
for Customers in the competitive telecommunication market. This Annex describes
SLA and QoS parameters, their classification and use.
Annexes B - D
These annexes contain the Executive Summaries from the other three volumes in
the SLA Management Handbook.
Annex E

This appendix provides an overview of work being undertaken on SLA and QoS
issues by various standards bodies and other organizations.
Annex F
This appendix reviews the data sources available to Service Providers that may be
used for performance reporting.
Annex G
This appendix contains a discussion of the issues surrounding perceived verses

delivered performance.
Annex H
This appendix contains SLA lifecycle use cases.
Annex I
Thiis annex provides examples of applying the KPI/KQI methodology.
Annex J
This annex lists the from to be used for KQIs.
Annex K
This annex provides a detail breakdown of the derivation and application of service
based measurements based on the eTOM framework.

2 Business Considerations
Introduction
Service performance encompasses both technical performance factors as well as

the more subjective Customer satisfaction. A SP, by offering various performance
levels for a given service, has the capability to balance the level of performance
offered against price and Customer expectation. The use of service performance
agreements provides SPs with the opportunity to delight their Customers, to build
stronger long-term relationships and brand image, and to maintain and grow
market share. The growing complexity of global services brings together a myriad
of services, suppliers and technologies, all with potentially different service
requirements. SPs are trying to integrate these services into Next Generation
Networks (NGN) that support these requirements, while striking a delicate balance
between cost and return on investment.
Government and Corporate Customers are seeking SLAs that offer more
extensive verification and analysis of the performance they receive from their
various telecommunications services. In addition to requirements such as service
accessibility and availability during periods of network congestion, the ability to
monitor services on an increasingly granular level is imperative. For example, to
efficiently manage their information and communications costs, these Customers
need information on service access rates during emergency conditions, the
number of successfully delivered packets in a given time period, the amount of
time a user was connected to a server, notification of what traffic type is using the
most bandwidth, what percentage of the traffic is going to a specific sub-network or
server, etc.
The Business Context
Traditional industry initiatives to measure service performance were focused on

monitoring the underlying bearer network performance and defining technology
based network measurements. This can lead to a misrepresentation of customer
perception of the end-to-end service.
These issues were identified by previous work of the TMF Service Quality
Management (SQM) Project Team and others such as ETSI in [ETR 003].

In their deliverable TMF506, Service Quality Management Business Agreement,

the TMF SQM project team observed, that
It is recognized by this analysis and others such as ETSI ETR 003 that the
computation of service quality is based on network-related parameters and
non-network-related parameters, for example, help desk answer time.
While is it well understood that network-related parameters are based on
performance usage and trends from Network Data Management, it is not
yet known how to furnish the non network- related parameters (criteria).
It concludes that additional network parameters together with new parameters for
service measurements need to be identified to capture a more accurate picture of
the customer's perception.
The business motivation for developing this set of end-to-end service

measurements stems from the following key drivers:
1) Selected customer retention: Retaining high value customers by delivering
an improved and quantifiable QoS.
2) Regulatory mandate:
• Oftel: “Carrier Pre-selection - Industry End to End Process
Description”, states that “Management information will need to be
captured to measure performance levels and achievement of
service levels.”
• Oftel press release Ref.: 77/01 Date: 15 November 2001
“Oftel has today set out the service levels that BT must offer to
other operators wanting to un-bundle BT local loops, following
consultation with the industry.
This is the first time that the telecoms regulator has formally
intervened to set service level standards, and is designed to
ensure that BT meets the needs of operators that want to provide
high speed services over unbundled loops.”
• Australian Communications Authority (ACA) – Telecommunications
(Customer Service Guarantee) Standard 1997, details the service
level requirements between a “carriage service provider” and a
customer.
Although in some areas of the world de-regulation is the preferred way forward is
reasonable to assume that in the main, regulatory requirements for service level
management will become more widespread.
3) Contractual commitments: Revenue affecting propositions that link QoS
and service levels to monetary penalties will have to be accurately policed.

4) Managing supply chain relationships. As the mobile business value chain

becomes more complex with the introduction of new market players, such
as virtual network operators and value added service providers, there is an
increasing need for network operators and service providers to manage
both retail and wholesale relationships, to guarantee quality levels across
and between networks.
2.1.1 SLAs In The Evolving Marketplace
As previously noted, a Service Level Agreement (SLA) is a formal agreement

between two parties established through a negotiation process. It is a commitment
that exists between the Service Provider and the Customer. It is designed to create
a common understanding about services, priorities, responsibilities, etc.
SLAs can cover many aspects of the relationship between the Customer and the
Service Provider such as service performance, billing, provisioning etc. Service
performance reports normally use the SLA as the specification for the data to be
provided to the Customer. Service parameters that are not explicitly included in the
SLA may be provided via the SP’s standard reports.
As the telecommunications service marketplace becomes more competitive, and

Customers become increasingly discerning and selective, Service Providers are
realizing the need to differentiate their products through value added services.
Additionally, industry deregulation is transforming a traditionally monopolistic
marketplace into an extremely competitive one.
SLAs, also known as Service Level Guarantees (SLGs), are an excellent tool for
establishing a Customer and Service Provider business relationship. A well-crafted
SLA sets expectations for all elements of the service to which it refers and provides
a basis for managing these expectations. It helps the Service Provider assess the
value of operational changes and of improved internal measurement and reporting
procedures. It also provides trending data, promotes improved Customer relations
and provides a vehicle for a SP to differentiate itself from its competitors.
The Business Model
2.1.2 The Basic Model
Figure 2-1 illustrates the fundamental SP – Customer relationship. This

relationship is important as Customers and SPs jointly negotiate an SLA covering
the services being provided. By this process they develop a greater understanding
of each party’s views, requirements and responsibilities. See Chapter 4 for
additional information on SLA content and roles.

Figure 2-1: SLA At The Customer-Service Provider Interface
2.1.3 The Relationship Model
The SLA Handbook makes use of the TM Forum’s enhanced Telecom Operations
Map (eTOM) [GB 912] business relationship model. The SLA management
aspects of this model are briefly reviewed in the following paragraphs.
The eTOM business relationship model captures the business relationships

between the various roles in a management value chain and illustrates the
principal points of contact between the roles.
Figure 2-2 presents an example of the roles and relationships involved in a value
network that is providing service products to the customer. Note that the figure
shows only those relationships that are relevant to the value network. It is very
likely, for example, that the Customer also has a relationship with Hardware,
Software, Solution, Vendors, etc. Since such a relationship is not part of the value
network, it is out of scope for the eTOM Business Relationship Context Model.
However, for those involved in supplying a service product to a Customer, the
relationships to the Hardware, Software, Solution, etc., Suppliers is relevant since
these relationships are involved in supplying a product to a Customer.
Figure 2-2 depicts the value network from the perspective of the customer-facing
service provider at the core of the value network. It explicitly includes the service
provider’s use of the eTOM Business Process Framework. Other parties may or
may not use the eTOM Business Process Framework. Note that the Handbook is
primarily focused on the SLA between the highlighted Service Provider (SP) and
the Government – Business Service Customer.
Figure 2-2 reflects the type of context that occurs in government and commercial
business environments where service relationships evolve constantly and where
these relationships need to be flexibly and rapidly reconfigured. The roles are
intended to represent the kind of parties that might be present in such an
environment. The model is generic and adaptable to many different contexts
without attempting to reflect all possible lower level details.

Figure 2-2: Service Provider Centric eTOM Business Relationship Model
2.1.4 End To End Service
In any value chain comprising a number of trading partners the main challenge is
to establish an effective end to end set of processes that deliver to the end user
and customer a seamless service that is indistinguishable from the same service
provided by a single supplier.
The introduction of a service management solution implies a substantial

investment for a service provider, both in capital and operational expenditure.
However, there is large effect on the value generation in a service provider, by

positively impacting overall operation cost, by exploiting existing assets and by
influencing revenue generation.
Figure 2-3 illsutrates the end to end service challenge.

Provider Customer
Third Party Service
Provider
CRM
Provider
S/PRM Third Party Service
Provider
Provider Customer
CRM
Customer Service Provider
S/PRM
CRM
S/PRM
Provider Customer
Third Party Service
Provider
Customer-Provider Relationship CRM
Interactions
S/PRM
CRM: Customer Relationship Management
S/PRM: Supplier/Partner Relationship Management
Figure 2-3 End-To-End Service Challenge
Business Benefits
2.1.5 Customer Benefits
The customer has a holistic view of the product based on a wide range of
interactions with the service provider. The combined perception of these
interactions across the whole product life cycle determines the customer's
perception of total service quality.
The customer view is illustrated in Figure 2-4.

Service Provider
Request for
proposal
Make order Org. units

Customer Notify
completion
Use service Processes

Request
assistance
Make trouble
report
Systems
Send
bill
Pay
bill Networks
Cancel
service
All interactions at the interface between

the customer and the service provider contribute to
a holistic view of service quality
Figure 2-4 Customer Viewpoint Of Service
A consistent approach to SLAs and SLA management will provide the following
benefits to service Customers. It:
1) Helps Customers develop the baseline, establish the requirements,
customize an SLA contract, validate the ongoing performance compliance
to end-to-end service level objectives, and review and refine the SLA as
business needs evolve.
2) Helps Customers establish parameters, measurement methods, reports
and exception handling procedures.
3) Helps Customers define high-level common terms and definitions for end-
to-end service performance in the form of network technology independent
performance parameters and reports. These include items such as mean
time to provision, mean time to identify, repair and resolve malfunction,
service availability, end-to-end throughput, delays and errors.
4) Helps Customers evaluate the relationship between the technology-
specific service and network parameters and the technology/service-
independent parameters of the SLA. This includes considering how, within
each of the multiple SP administrative domains, these parameters capture
or approximate the performance perceived by the Customer.
5) Helps Customers validate the performance of the service as defined in the
SLA by receiving scheduled and on-exception reports. This includes a
SP’s responses to performance inquiries. These reports include
notifications of SLA violations, of any developing capacity problems, and of
changes in usage patterns. The reports enable the Customer to compare
the delivered performance as defined in the SLA to its perception of the
service’s performance.

6) Helps Customers evaluate a SP's methods for detecting degraded service

performance and for alerting the Customer and responding to performance
events affecting the Customer's service.
7) Helps Customers verify the implementation of penalty provisions,
administrative actions, and any cancellation fees for a failure to maintain
and deliver the service defined in the SLA.
8) Helps Customers define the end-to-end requirements for multimedia
telecommunication services, especially those carried over IP-based
networks.
9) Helps Customers compare services and service quality levels offered by
different SPs.
2.1.6 Service Provider Benefits
benefits to Service Providers. It:
1) Helps introduce operational changes, improve internal measurements and
reporting, enrich Customer relations and differentiate the SP from its
competitors.
2) Helps create more knowledgeable Customers who can better express their
needs to the SP, reducing the time devoted to the negotiating process.
3) Helps create a common language and understanding with the Customer
on characterizing network and operational parameters.
4) Helps create SP internal recognition of the Customer’s perception of
network errors and service interruptions.
5) Helps prioritize service improvement opportunities.
6) Helps create common performance goals across multiple technology
domains.
7) Helps standardize performance-gathering practices across multiple internal
domains.
2.1.7 Supplier Benefits
benefits to hardware and software suppliers. It:
1) Helps suppliers understand Customer and SP requirements for SLAs.
2) Helps equipment suppliers agree on the mapping of technology-specific
parameters and measurement methods into service-specific parameters
and measurement methods.
3) Helps software suppliers agree on common interface definitions for SLA
management.

Service Performance Parameter Selection
An SLA should contain a number of objective, measurable service parameters

together with the parameter values that the Service Provider commits to deliver to
its Customer. The actual, i.e., the measured, values of these parameters may be
reported to the customer to provide a record of the delivered service.
Typically, SLAs describe performance in terms of2:

1) System/service accessibility, retainability, and integrity,
2) Time to identify the cause of a Customer-reported malfunction,
3) Time to repair a Customer-reported malfunction,
4) Provisioning-related time,
5) Quality of Service (QoS) targets.
Service Measurement Considerations
An SLA should contain values for the Level of Service and the Quality of Service
parameters that the Service Provider commits to deliver. The parameters defined
in the SLA should be measurable. The methodology or process used for
quantifying a specific performance parameter should be clearly described. The
delivered performance should be periodically, e.g., annually, reviewed with the
Customer. Based on these reviews, the Customer, if specified in the SLA, may
have the right to terminate the service contract, receive compensation for missed
commitments, require the SP to initiate administrative corrective actions related to
the delivered service, or pay an incentive for exceeding committed performance.
A Customer is generally not interested in a summary of the individual Network

Element performance parameter values. Whenever several SPs jointly support a
service, the aggregation of the individual Network Element or network section
performance reports is often not practical. Therefore more direct measures of the
end-to-end service as perceived by the user, when possible, provide the best basis
for performance reports.
There are many mature documents and tools that address Performance Reporting
for individual network elements and transport technology connections. However,
the Handbook series is the first open document to address end-to-end service
performance issues.
2
See Chapter 3 for a detailed discussion of service parameters.

2.1.8 Performance Parameters And Metrics
When a parameter is carefully specified, it is often called a metric. A metric is

defined in terms of well known technical concepts and quantities. Within the
Handbook series, the terms performance parameter and performance metric have
the same meaning and are used interchangeably. The choice of which term to use
is based on the common practice in the specific area being discussed.
It is important that Customers and Service Providers both work together to define
the common service performance metrics that can be measured and collected by
the network providers and made available to the Customers. A major problem is
that a single Service Provider often cannot control end-to-end performance
because multiple providers are involved in supplying the service. In order to verify
or monitor the delivered performance, it is important to identify measurable
network-based parameters and to implement an effective measurement scheme
that is capable of assessing SLA compliance.
The following criteria should be considered when defining network service

performance metrics for an SLA. A performance metric specified in the SLA
should:
1) Provide concrete repeatable measurements in well-defined quantities
without subjective interpretation,
2) Be useful to users and service providers in understanding the performance
they experience or provide,
3) Not exhibit a bias for services supported by one network technology as
opposed to another technology,
4) Be measurable via a process acceptable to service providers, their
customers and, in some cases, outside testing agencies while avoiding
inducing artificial performance goals,
5) Be useful as a specification in contractual documents to help Customers
with high performance requirements purchase the Level of Service they
need,
6) Be useful for publication in data sheets,
7) Be capable of measuring one provider independent of all others,
8) Be owned "by the community", not encumbered by any particular company
or individual,
9) Support diversity in the marketplace,
10) Support a diagnostic mode that can be used to sectionalize or identify the
degradation contributions in a long multi-hop, multi-provider path.
2.1.9 Performance Measurement Methodology
A measurement methodology or approach is the process for quantifying the

performance metric. When a service performance metric is specified, a
measurement procedure must be clear and fully documented. The methodology

for a service performance metric should have the property that it is repeatable; i.e.
if the methodology is used multiple times under identical conditions, it should result
in consistent measurements (though not necessarily the same values since a
metric may vary with respect to time). For a given set of performance metrics, a
number of distinct measurement methodologies may exist. Typical schemes
include direct measurement of a performance metric using injected test traffic,
calculation of a metric from lower-level measurements, and estimation of a
constituent metric from a set of more aggregated measurements. The
measurement methodologies should strive to minimize and quantify measurement
uncertainties and errors.
Anticipating Change
Since it is highly likely that a Customer’s service requirements will change during
the period of the service contract, some method for managing change should be
specified in the contract. An SLA provision should be made for liaison and dispute
resolution and for opportunities to resolve the service performance short-falls using
formal notification processes, responses, and verification. The service contract
should contain penalty clauses or administrative remedial actions to be taken for a
failure to meet the SLA performance commitments as well as a provision for
cancellation fees or compensation or incentive payments for exceeding
performance targets. The expected performance levels and SP-Customer
responsibilities must be clearly defined to avoid misunderstandings. However, a
service contract and its associated SLA should not be so thorough in specifying
the performance parameters that it unnecessarily complicates the contracting
process. It is very important that the Service Provider has the capability to detect
any degradation in service performance, alert the Customer, and respond to
performance events affecting the Customer.

3 Telecommunications Services
Service Characterization
A telecommunications service is a set of independent functions that are an integral

part of one or more business processes. These functions are supported by
hardware and software resources including the underlying communications
transmission media. The Customer sees all of the functions as an amalgamated
unit. A telecommunications service can include anything from a single leased line –
private line (LL-PL) service, to complex applications like a permanent virtual circuit
(PVC) based Frame Relay implementation delivered over an ISDN access
network with an ATM backbone using an SDH/SONET transport network. The
emerging Next Generation Networks (NGN) are expected to greatly increase the
number and types of services offered to Service Customers.
Figure 3-1: Service Functions And Service Resources
Figure 3-1 illustrates the relationship between service functions and service
resources. Service functions are composed of three distinct types of elemental
functions, viz., Primary Functions, Enabling Functions, and Operations,
Administration, and Maintenance (OAM) Functions. As shown in Figure 3-1,

service resources enable service functions. The three fundamental types of service
resources are hardware/software resources, staff resources, and intellectual
property/licenses resources.
The Enterprise View
Figure 3-2 illustrates the Enterprise view of the relationships among Enterprise
Business Applications, Enterprise Business Services and Network Services. The
Enterprise View is described in detail in Volume 4 of the Handbook. Volume 4 also
contains additional information on deriving Network Service performance
requirements from Business Application requirements.
Figure 3-2: Networks Services - Business Services And Applications
The Enterprise’s external network services are obtained from Information and
Communications Service Providers (ICSP). The Enterprise may also outsource
various Business Services and Business Applications. See Volume 4 for details.
Service Elements
The concept of layered transport network functional architecture is well

established. This concept is used in ITU-T Recommendations I.326, G.803, G.805,
and G.872. Similarly, a layered service architecture can be used as a basis for

defining “services” and service performance parameters such as Service

Availability3. For example, a specified Service Availability SA level may be offered
by a Service Provider for a Service Access Point (SAP) Group4. Figure 3-3
illustrates this multi-layered service concept.
Figure 3-3: Layered Service Architecture
In the layered service model illustrated in Figure 3-3, a Customer purchases a

service from Service Provider 1, via a service contract that identifies the service
access point(s) (SAP) and specifies the performance levels to be delivered at the
SAPs. In order to provide this service, Service Provider 1 brings together a number
of Service Elements (SEs). This process is analogous to the construction of a
telecommunications network from Network Elements (NEs) and transmission lines.
Thus, a “service” can be realized by a collection of co-operating SEs that provides
the overall service.
Each SE may be realized from network or service resources at the disposal of the
Customer facing Service Provider (Service Provider 1 in Figure 3-3), or may be
provided using services obtained by Service Provider 1 from other Service
Providers (e.g. Service Provider 2 in Figure 3-3). In order to support the service
commitments given to the Customer in the SLA, corresponding commitments are
required from the Service Providers contributing SEs used to construct the service.
3
See Section 0 for a discussion of Service Availability.
4
See Section 0 for a discussion of SAPs and SAP Groups.

The “integrating” Service Provider (Service Provider 1) must then ensure that the
negotiated SE commitments are sufficient to support the commitments made to
the Customer for the overall service. This will require that the overall commitment
can be computed from the individual SE commitments, e.g., in the simplest case,
the commitments are of the same kind. It also requires that the values of the
service parameters assigned to the SEs are adequate to ensure that the SLA
commitments to the Customer are in fact achievable.
Service Containment And Management Domains
As discussed in the previous section, the means of constructing an overall service

can be based on the concept of a layered service architecture. This leads to the
concept of service containment and management domains. One or more parts of
the network supporting a service may be under the administrative jurisdiction of a
Service Provider that does not directly provide the service to the end-Customer.
Similarly, the service itself may be comprised of a number of SEs, each of which is
also composed of a number of SEs, i.e., service composition is recursive in nature.
Indeed, in some cases, a Service Provider that does not have any physical
network access to the Customer may contract with a local Service Provider who
does, in order to provide the service to the Customer.
An integrated approach to service management requires that information related to

the delivered service performance be transferred between Service Providers. For
SPs with a Telecommunications Management Network (TMN), this is
accomplished via an “X-interface” between the Service Providers’ Operations
Support Systems (OSS). At the time of publication of this document, information on
delivered service performance is mainly exchanged manually via telephone and/or
facsimile.
It is expected that automated interface between OSSs will become common as

new services that are critical to business success continue to emerge. This trend
will be accelerated for ebusiness environments. A variety of standards already
exist for such automated interfaces and further standards are being developed.
For additional information on automated OSS interfaces see ITU-T
Recommendations M.3010 and M.3013.
Customer Contact Point Reference Model
The content of this section is based on the ITU-T Recommendation M.1535,

Principles For Maintenance Information To Be Exchanged At Customer Contact
Point (MICC).
As shown in Figure 3-4, a Customer contact point is a conceptual point at which a

Service Provider can interact with any Customer on issues related to the provided

telecommunication services. It serves as a reference model for exchanging service

performance and management information between the Customer and the Service
Provider’s staffs. The Customer/Service Provider interface can be realized through
either a human-to-human interface or an automated OSS to OSS interface.
Figure 3-4: Customer Contact Point Reference Model
The Customer may use the interface for the control and management of its
communication services. Since many Customers conduct business in a multiple
service, multiple Service Provider environment, Customers require their Service
Providers to supply service information at the Customer contact point in a
common, understandable manner.
Service Providers may use the interface to share information on service

performance and maintenance-related issues that will be supplied to Customers.
The Customer’s ever increasing demand for high quality cannot be overlooked.
Service Providers are responding to market forces to meet Customer expectations
by using a combination of technological capabilities and operating resources.
Service Access Points
3.1.1 Definition
A service is “delivered” to a Customer at Service Access Points (SAP). SAPs are

the conceptual points at which a service is provided by a "service provider" entity
to a "service user" entity. The Service Provider’s responsibility therefore includes a

service and its associated service elements that are provided at the specified
SAPs.
The SAP is the concept used to distinguish the boundary between the Customer
domain and the Service Provider domain.
The Service Provider delivers a contracted service to the SAP(s). Each service is
associated with at least one SAP. A SAP may only be associated with one service.
An integral part of defining and managing a service is the specification of the

SAPs. In addition to service performance levels, SAP specifications frequently
include market and physical network-related requirements. These latter items are
mainly related to regulatory and equipment ownership issues rather than to the
physical network configuration itself.
3.1.2 SAP Examples
The basic physical components that support Enterprise telecommunications

services are Customer Premises Equipment (CPE), a network access node and
an access network. The simplest form of this type of service is the Plain Old
Telephone Service (POTS). This service is typically provided via a telephone set
connected to a Serving Exchange (Central Office) over a copper access line.
A more sophisticated service example is shown in Figure 3-5. In this example a

range of services are provided over an ATM transport network via a network ATM
access switch, and a Customer ATM access switch.
Figure 3-5: Simplified ATM/SDH/PDH Network
The actual location of the SAP can depend on the ownership of the CPE. In the
case of a fully “managed service,” the CPE is owned and maintained by the
Service Provider. Here the SAP is on the Customer side of the CPE. For a leased
line service, the CPE may be owned and maintained by the Customer or by a third

party. In this situation, the SAP is effectively on the network side of the CPE. A
third case, such as interface between two networks is also possible. In this
instance the SAP, sometimes called a Network Access Point (NAP) or a Point Of
Presence (POP), is between two Service Providers where one party is effectively a
Service Provider for the other.
Figure 3-6 illustrates another service implementation. Note that in this example the
Service Provider’s responsibility may, where permitted by law, include all or parts
of the CPE, the access lines and the Provider’s backbone network/service
platform.
Figure 3-6: A Service Access Point Example
3.1.3 Multiple SAP Services
When the service-related interactions or traffic between Customer locations cross

the boundary of a Service Provider’s domain at two or more points (SAPs), the
service is classified as a multiple SAP service. LAN interconnection using Frame
Relay as a transport service is an example of a multiple SAP service.
3.1.4 Single SAP Services
When the service-related interactions or traffic between a Customer and Service

Provider cross the boundary of the Service Provider’s domain at only one logical
point, the service is classified as a single SAP service. The remote end point of a
single SAP service is a service element supplied by the Service Provider, rather
than another SAP belonging to the Customer or to a third party. The following
types of services are examples of single SAP services.
1) Accessing and retrieving the performance data and reports from the
Service Provider’s Web server via a SAP.
2) Receiving service performance management reports from the Service
Provider at the Customer’s SAP.

3) Exchanging trouble reports between the Customer and the Service

Provider at the Customer’s SAP.
4) Exchanging invoices, ordering requests, and billing information between
the Customer and the Service Provider’s facility involving a single SAP.
3.1.5 Regulatory Issues
The ownership of the CPE is often a regulatory issue. In some countries, the
Service Provider is not permitted to own and operate electronic equipment on the
Customer premises. In other countries, where the Service Provider is a legal
monopoly, the CPE may be provided, owned and operated by the Service
Provider.
This regulatory environment is changing with network and service liberalization

taking place across the world. Service competition is becoming the norm bringing
with it new service delivery arrangements. Thus performance at a SAP may be
defined in terms of Customer service parameters related to the actual service, or it
may be defined purely in terms of network path (network bearer service)
performance parameters supporting a service or range of services.
Performance Perspectives
The six service performance factors illustrated in Figure 3-7 are the main
contributors to the overall service performance perceived by a telecommunication
service user. These factors are high level concepts that are in turn characterized
by many parameters. See ITU-T Recommendations E.800 and E.801 for additional
discussion of these performance factors and their parameters.

Figure 3-7: Network Performance – Service Performance Relationship
3.1.6 Service Performance Factor Definitions
The service performance factors are defined in the following paragraphs. See
Section 0 for a discussion of the relationship between performance factors and
Quality of Service (QoS).
Service Support Performance is the ability of an organization to provide a service

and assist in its utilization. An example of service support performance is the ability
to provide assistance in commissioning a basic service, or a supplementary
service such as the call waiting service or directory enquiries service. Typical
measures include mean service provisioning time, billing error probability, incorrect
charging or accounting probability, undercharging probability, overcharging
probability and billing integrity (probability).
Service Operability Performance is the ability of a service to be successfully and

easily operated by a user. Typical measures include service user mistake
probability, dialing mistake probability, service user abandonment probability and
call abandonment probability.
Service Accessibility Performance is the ability of a service to be obtained, within

specified tolerances and other given conditions, when requested by the user.
Typical measures include service access probability, mean service access delay,
network accessibility, connection accessibility, mean access delay, p-fractile
access delay, accessibility of a connection to be established, unacceptable
transmission probability, no tone probability and misrouting probability.

Service Retainability Performance is the ability of a service, once obtained, to

continue to be provided under given conditions for a requested duration. Typical
measures include service retainability, connection retainability, retainability of an
established connection, premature release probability, release failure probability
and probability of successful service completion.
Service Integrity Performance is the degree to which a service is provided without

excessive impairments, once obtained. Typical measures include interruption of
service, time between interruptions, interruption duration, mean time between
interruptions and mean interruption duration.
Service Security Performance is the protection provided against unauthorized

monitoring, fraudulent use, malicious impairment, misuse, human mistake and
natural disaster.
3.1.7 Network Performance Factors
As illustrated in Figure 3-7, Network Performance (NP) is composed of Planning,

Provisioning, and Administrative Performance, Trafficability Performance (Grade
Of Service), Network Item Dependability Performance and Transmission
Performance. Various combinations of these factors provide the needed service
performance support. These performance factors are defined next.
Planning, Provisioning, and Administrative Performance is the degree to which

these activities enable the network to respond to current and emerging
requirements.
Trafficability Performance (Grade Of Service) is the degree to which the capacity

of network components meet offered network traffic under specified conditions.
Network Item Dependability Performance is the collective term used to describe
the availability performance and its influencing factors, reliability performance,
maintainability performance and maintenance support performance.
Transmission Performance is the faithfulness of reproduction of a signal offered to

a telecommunications system, under given conditions, when this system is in an
in-service state.
3.1.8 Events And Performance Parameters
The distinction between the Customer’s service requirements defined in an SLA

and the Network Performance factors was noted in the preceding sections. This
section discusses the important differences between performance events and
performance parameters.
Performance events are effectively instantaneous phenomena that occur within the
network supporting a service or within the service’s general environment that affect
the properties of the delivered service. Examples of events are Errored Seconds
(ESs), Severely Errored Seconds (SESs), Severely Errored Periods (SEPs), lost or

misdirected cells and packets, loss of signal, loss of network synchronization,

lightning strikes, earthquakes, etc.
Network performance parameters are usually defined in terms of the number

and/or intensity of event occurrences during a specified time interval. The values of
these parameters can be computed from event information and reported to the
service Customer. Typically, the performance parameter functions generate mean
values, fractiles, probability estimates, event rates, and event intensities. Specific
examples are the Errored Second Ratio (ESR), percentage Availability,
Throughput, Utilization, Severely Errored Period Intensity (SEPI), Mean Time
Between Outages or Failure (MTBO or MTBF), Outage Intensity (OI), Mean Time
to Provide Service (MTPS), Mean Time to Restore Service (MTRS), time to first
yield5, average call response time, etc.
3.1.9 Network Performance - Service Performance Distinctions
Network Performance (NP) is a conceptual framework that enables network

characteristics to be defined, measured, and controlled so that a network operator
can achieve its service objectives. The various components of NP and its
relationship to service performance were shown in Figure 3-7.
An SP creates a network with NP levels that are sufficient to enable the SP to

meet its business objectives while satisfying Customer requirements. Usually, this
involves a compromise between the cost and capabilities of a network and the
levels of performance that the network can support.
An essential difference between service parameters and NP parameters is that

service performance parameters are user-oriented while NP parameters are
network provider and technology-oriented. Thus service parameters focus on user-
perceivable effects (not their causes) and NP parameters focus on the efficacy of
the network in providing services to the Customer. The result is that service
parameters are relevant at/between Service Access Points (SAPs), usually on an
end-to-end basis, while NP parameters are relevant between the edges of network
components. These different view points are summarized in Table 3-1.
Table 3-1: Service And NP Specification Characteristics
5
Time to first yield is defined as the time interval between initiating service and the first reportable service-impacting
event.

Service Specifications Network Performance Specifications

User-oriented Provider-oriented
Service attribute Connection element attribute
Focus on user-observable effects Focus on planning, design and development,
operations and maintenance of network
Between/at Service Access Points End-to-end or network connection element
capabilities
It is important to recognize the differences in NP and service performance events

and parameters. In a layered network architecture, many of the events and
parameters in the network layers are NP phenomena that may or may not affect
customer service. This depends on the type of service and the application using
this service, specifically whether the latter employs software or hardware capable
of adjusting to or accommodating the effect of network events. For example, error
correction and retransmission applied at the upper OSI layers of a data
communication service may compensate for error events and poor performance at
the physical or the data link layers. In other cases, an application may be
vulnerable to “short break” events, even though these events do not result in
server layer unavailability. In these cases the client application may have to be
restarted. Short break events or intervals with high error rates can result in long
periods of service disruption if the higher protocol layers are impacted.
3.1.10 The Role Of Traffic Engineering
Figure 3-8 is based on the description given in ITU-T Recommendation E.490.1 of

the set of tasks that comprise traffic engineering. Note that in set of tasks labeled
Grade of Service, the definition of QoS used is that given in E.8006.
6
See Section 3.8 for the E.800 definition of QoS.

Figure 3-8: Traffic Engineering Tasks Per E.490.1
Grade of Service (GoS) is defined in ITU-T Recommendation E.600 as a set of

traffic engineering variables used to provide a measure of adequacy of a group of
resources under specified conditions.
As shown in Figure 3-8 the values of the GoS parameters are allocated to network
components in the Grade of Service Tasks. These values are then used in the
Traffic Control and Dimensioning Tasks to determine the required capacity of the
various network components / network elements. Typical GoS parameters include
parameters such as calling rate, call set-up delay, answer-signal delay, and
internal and external blocking.
Note that a network may be capable of providing different performance levels to

different services but it may also be the case that a network provides the same
treatment to all or to several services. In the latter case, the most stringent
requirement for each performance parameter must be provided for all of the
services. An important consequence of the inherent network capabilities is that
end-to-end performance objectives are derived not only from performance
requirements, but also from the Network Operator’s planning and traffic
engineering strategy.

Two classes of GoS objectives are commonly used. The first class contains the
accessibility objectives, i.e., the call and connection objectives, In this case GoS
objectives are governed mainly by the End-to-end Connection Blocking Probability
(ECBP). The second class contains the retainability and integrity objectives, i.e.,
the information transfer objectives. For ATM, these are the maximum queuing
delay (defined as a remote quantile of the cell delay distribution) and the mean
queuing delay, both based on Cell Transfer Delay (CTD) and the Cell Delay
Variation (CDV), and the Cell Loss Ratio (CLR).
It is perhaps worth noting that the performance delivered by cell/packet-based

networks will depend even more on traffic engineering methods and effectiveness
than it did for circuit-switched networks.
Performance Indicator Hierarchy

against a set of business focused Key Performance Indicators (KPIs). These KPIs
were inherently network-based and provided little direct indication of the end to end
service delivery that the network supports. Nevertheless KPIs are an important
future.
'breed' of indicators that capture service quality rather than network performance.
These new indicators or Key Quality Indicators (KQIs) provide a measurement of a
specific aspect of the performance of the product, product components e.g.
services, or service elements and draw their data from a number of sources
including the KPIs.
Two main types of KQI need to be considered. At the highest level, a KQI or
group of KQIs are required to monitor the quality of the product offered to the end-
user. These KQIs will often form part of the contractual SLA between the provider
and the customer. Product KQIs will derive some of their data from the lower level
Service KQIs, with the latter focused on monitoring the performance of individual
product components. In its simplest form a KQI may have one single KPI as its
data source. More commonly a Service KQI will aggregate multiple KPIs to
calculate the service element quality and Product KQIs will aggregate multiple
Service KQIs. Figure 3-9 Key Indicator Hierarchy
illustrates the key indicator hierarchy

Customer SLAs
Product Additional
KQIs Data
Customer Focus
Internal & Supplier/Partner SLAs Product Components
Service Additional
KQIs Data
Network Focus
Service Elements
Additional
KPIs Data
Service Resources
(Grouped by Type)
Performance
Related Data
Service Resource
Instances e.g.
Network Element
Figure 3-9 Key Indicator Hierarchy
A primary function of the KQI is the calculation of Service Level Agreement

compliance. In typical circumstances multiple KQIs will feed the SLA management
processes, with Service KQIs supporting multiple internal or Supplier / Partner
SLAs and Product KQIs supporting multiple Customer (external) SLAs.
As a service element may depend upon a number of network resources, it follows

that a Service KQI may call upon multiple KPIs in the aggregation process.
The nature of services that may be included in products offered by Service

Providers is likely to result in variants of a 'base' service. It is important therefore
that a KQI may also utilise other KQIs as part of its aggregation algorithm.
At all levels additional ‘contextual’ information is required to complete the

aggregation process, for example, the weighting factors applied to each KQI
parameter.
To summarise, starting from the network elements, the network performance data
is aggregated to provide KPIs that are an indication of service resource
performance. The KPIs are then used to produce the Service KQIs that are the
key indicators of the service element performance. Service KQIs are then used as
the primary input for management of internal or supplier / partner SLAs that
calculate actual service delivery quality against design targets or in the case of
supplier / partner, contractual agreements. Service KQIs provide the main source
of data for the Product KQIs that are required to manage product quality and
support the contractual SLAs with the customer.

Figure 3-9 illustrates the mapping of the key indicators onto the service
decomposition described in the TM Forum SLA Handbook.
Based on the preceding description of a KQI, a definition of the parameters which

make up a KQI can be developed. This is included in Annex J, Key Quality
Indicator Format.
3.1.11 KQI Definition And Usage
This section describes how the indicators in the measurement hierarchy are
derived and how they are used to manage the various SLAs that the operator
needs to manage.
Figure 3-10 shows, at a high level, the steps that are necessary to identify the
correct quality indicators to support the products and services. It also illustrates
how they relate to the Customer, Product, Supplier / Partner and Internal SLAs.
The diagram uses solid arrows to show the definition of the key indicators and SLA
templates and uses dashed arrows to show the flow of the resultant generated
indicators.
Individual
Internal
Customer
SLAs
SLA
Service
SLA
Templates
Supplier /
Partner
Product SLAs
Internal
SLA
Product
Product Service
SLA KPI Measurable
KQI KQI
Templates
Product Commercial Product Service Network

Service(s)
Design Product Components Resource Element
Figure 3-10 KQI Identification
The structure of an SLA Template is defined in the Section 0.
The process start with the ‘birth’ of the product concept and flows through the
design of the commercial product, the decomposition of that product into the
individual services and down to the service resources themselves. At each stage
of the total process, the key quality indicators necessary to manage quality at that
level and the template for the appropriate SLA are defined in a hierarchical
manner. The methodology ensures that ultimately all of the measurements
necessary for the management of the various SLAs are defined at the service
resource level.

By defining these measurements and templates in a top down approach, the

methodology also ensures that the usage of that data is captured at each level.
Hence the mapping of the measurements to SLAs is captured in the design phase
and ultimately relate back to the designed quality criteria of the product.
Quality Of Service
Quality of Service (QoS) at first appears to be a clear, unambiguous concept.

However, even a brief review of the literature reveals that QoS is an extremely
overloaded term with no generally agreed meaning. As QoS is central to this
document, this section will briefly discuss the various ways in which the term QoS
has been applied and conclude with the QoS definition adopted by this Handbook.
Service Quality can refer to
The “individual” level - the quality experience by an individual customer,
The “aggregated” level - the aggregation of the quality experienced by all

customers.
For an individual customer, it is possible to distinguish between expected quality,

for example, based on customer’s past experience and other related information,
contracted quality, the quality level identified in the customer SLA (Service Level
Agreement)., and actual experienced quality. The experienced quality comprises
factors that are network performance related (network oriented) and non-network
performance related (non-network oriented)
Factors that are independent from network performance include, for example, the
time to provide a service, and the response times and competence of the customer
service-centre to the network performance.
Network dependent factors for mobile service may include Core Network
performance, Radio Access performance, Call Detail Records, Transmission
system performance data, Value Added Systems performance data, Network
Probes e.g. signaling data, Drive Survey information, Planned Works information,
Service Fault Reports, Customer Reports.
Perceived quality is the value judgment actually made by a customer based on a

combination of expectations and experience.
ITU-T Recommendation E.800 defines QoS as the collective effect of service

performance which determines the degree of satisfaction of a user of the service.
E.800 also notes that the term QoS does not express or imply a degree of
excellence in a comparative sense, nor is it used in a quantitative sense for
technical evaluations.

In order to see the limitations of the E.800 definition, the next two sections discuss
user perception and customer satisfaction.
3.1.12 User Perception
QoS perceived by the user/customer is a statement expressing the level of quality

as quantified by them. The QoS perceived is expressed, usually in terms of
degrees of satisfaction and not in technical terms. Technical terms may be
expressed where the user/customer is able to understand and use these.
QoS perceived is currently assessed by customer surveys and from

user's/customer's own comments on the service
At the heart of a Service Provider’s success is rapid response to the service needs
of the customer. As the market develops the key objectives are ‘more for less’ --
faster service introduction, improved quality of service at a lower cost.
The factors that influence this perception will include at least the following:
1) Pre-sale material; the initial expectation of the service on which the initial
decision to purchase or participate was made
2) Billing accuracy
3) Security of data and transactions; m-commerce and privacy considerations
4) Price sensitivity; perceived value
5) Network quality; this is increasingly seen as 'a given', but requires
significant engineering to achieve.
6) Experience of the customer supplier relationship; all stages of the
customer lifecycle through provisioning, problem handling, and where
players in the supply chain may be 3rd parties with complex inter-
relationships.
There are several conceptual difficulties in assessing user perception of service
performance. Measurements made by a SP of network level performance may not
capture the user perception of the performance of a service. Additionally, with user
perception there is the question of whether a user’s perception of QoS is relative or
absolute. For example, is the user’s perception of a data service over a WAN the
same as for a data service over a LAN, of a voice service over an IP-based
network the same as over a PSTN, or of a video service over a
telecommunications network the same as for broadcast TV?
For voice services, characterizing user perception may involve specifying and
measuring performance both objectively using measuring devices, and
subjectively using test subjects. Objective measurement often involves In-service
Non-intrusive Measuring Devices (INMDs) that measure call clarity, noise and
echo. Analysis and interpretation of the results obtained is also specified.
Subjective methods often use standardized signal generators and human listeners
from whom Mean Opinion Scores (MOS) are derived.

However, to date the main service parameters used in SLAs for voice services are
the accessibility of the service, i.e., hours of operation and the availability of dial
tone during this period and the accuracy of billing. There have been no guarantees
as such on call completion rates or noise levels, echo, delay, and distortion.
However, networks have traditionally been engineered to deliver acceptable
performance under a broad range of offered traffic and network states. By keeping
toll circuit delay below 100 milliseconds, using echo cancellers, and maintaining
low error rates on digital connections, voice telephony performance is normally not
an issue. Another network metric frequently used is the measure of Customer
Affecting Incidents in terms of Blocking Defects Per Million Attempts.
For data services, new users often do not understand error conditions, and
perfection is expected. Higher level protocols have made LANs appear “flawless,”
and modern physical layer network transport makes this almost true. Experienced
users want WANs to behave like LANs. User expectations on response times to
query/request type messages escalate as technology improves.
Other real-time services such as video (MPEG and broadcast TV), sound program
and CD music are much more demanding than voice services. For IP-based
networks, a given level of IP transport performance results in a level of user-
perceived audio/video performance that depends in part on the effectiveness of
the methods used to overcome transport problems. Bit errors on a packet-based
network generally are either corrected at a lower functional layer, or result in
packet loss. Packet loss requires the receiving application to compensate for lost
packets in a fashion that conceals errors to the maximum possible extent. For data
and control, retransmission at the transport layer is used. For audio and video,
retransmission approaches have not been used.
In an IP-based network, traffic engineering and management will be even more

closely related to service performance than in a traditional circuit-switched network.
For example, the number of firewalls or router nodes traversed in delivering IP-
based services should be considered as well as the traffic handling capacity of
these devices.
The devices attached to the network and people such as Customer Care
representatives involved in delivering the service have a big impact on user
perceptions. Increasingly, high levels of performance at acceptable cost will be the
differentiating factor between SPs in a competitive service provision environment.
3.1.13 Customer Satisfaction
With respect to estimating customer satisfaction, the well known “Pareto 80/20”
rule often applies, i.e., 80% of the problems can be identified from 20% of the
measures. For example, 80% of Customer complaints might refer to a small
number of parameters such as unexpectedly long delays for new installations,
excessive service repair and restoration times, poor support information and
service, high congestion in the busy hour, etc. One challenge is to identify
“Customer-sensitive measures” and particularly the values that satisfy the
Customer, which may vary from one target group (market segment) to another.

The usual method of measuring Customer satisfaction is using a survey, the value
of which is naturally subject to the type of questions asked, and the quality of the
data obtained from them. A full survey covers many aspects of the
telecommunication business such as Pre-sales, Post-sales, Development,
QoS/NP, Fraud and Security, etc. In constructing and managing SLAs, some
means of measuring Customer satisfaction should be implemented. Cultural
issues and human factors need to be taken into account. The Customer
satisfaction/perception with/of a given service or selected parameters can be
assessed, for example, by the Mean Opinion Score (MOS) rating method in terms
of bad 1, poor 2, fair 3, good 4, and excellent 5.
Further information on measuring Customer satisfaction is available in the ITU-T

Handbook on Quality of Service and Network Performance [ITU-Hbk].
3.1.14 Views Of QoS
Figure 3-11 is a class diagram that shows the four principal uses of QoS concepts.
The following sections will discuss these areas and provide the background and
justification for the definition of QoS used in the Handbook.
Quality of Service
(QoS)
Type Of
Traff ic Engineering QoS Desired By QoS Offered By QoS

QoS Specif ications Serv ice Customers Serv ice Providers Achieved/Delivered
Figure 3-11: Four Views Of Quality Of Service
Figure 3-12 illustrates the inter relationships between the various viewpoints of
QoS.

User/Customer Service Provider Network Provider
Network
Network related
Performance
criteria
Objectives
QoS QoS
Requirements Offered
Non-Network related
criteria
Network
QoS QoS
Performance
Perceived Achieved
Measurements
Shows activity & flow
Shows feedback
Figure 3-12 Inter-Relationships Between Various Viewpoints Of QoS
3.1.14.1 Traffic Engineering Applications

As noted in Section 3.1.10, QoS concepts are used in the Traffic Engineering
process. Here the QoS requirements are the basis for determining the numerical
value of traffic engineering parameters that provide a measure of the adequacy of
the physical network under specified operating conditions. These parameter
values are inputs to the network design and operations design processes. See
ITU-T Recommendations E.490.1 and Section 3.1.10 for additional information on
the traffic engineering process.
The QoS requirements used for Traffic Engineering applications are high level
specifications that represent composite satisfaction levels for a broad set of
services and users. These requirements are established by a SP based on a
combination of its business objectives, expected service demand, current state of
its network, its financial condition, etc. This set of QoS requirements is not within
the scope of the Handbook.
3.1.14.2 Customer QoS Requirements

QoS requirements of the user/customer, is the statement of the level of quality of a
particular service required or preferred by the user/customer.

The level of quality may be expressed by the user/customer in technical or non-

technical language. A typical user/customer is not concerned with how a particular
service is provided, or with any of the aspects of the network's internal design, but
only with the resulting end-to-end service quality.
1) From the user's/customer's point of view, QoS is expressed by parameters
that:
2) Focus on user/customer-perceivable effects, rather than their causes
within the network
3) Do not depend in their definition on assumptions about the internal design
of the network
4) Take into account all aspects of the service from the user's/customer's
point of view
5) May be assured to a user/customer by the service provider(s)
6) Are described in network independent terms and create a common
language understandable by both the user/customer and the service
provider.
3.1.14.3 Service Providered Offered QoS

The third use of the QoS concept is in the specification of performance levels for
SLAs, i.e., the service provider’s commitment to the customer. This usage requires
that QoS be characterized in terms of quantifiable, measurable parameters. The
level of quality is expressed by values assigned to QoS parameters. These
parameters are usually designed to be understandable to the user/customer. Each
service would have its own set of QoS parameters
The E.800 QoS definition quoted in Section 0 does not provide guidance for
specifying quantifiable QoS targets. To address this need, ITU-T Recommendation
E.860 has modified the E.800 definition as follows:
“QoS is the degree of conformance of the service delivered to a user by a

provider in accordance with an agreement, i.e., an SLA, between them.”
The SLA Handbook uses the E.860 QoS definition. See Section 3.1.15 for a
discussion of how this concept of QoS is used for performance specifications in
SLAs.
3.1.14.4 Achieved/Delivered QoS

Achieved/Delivered QoS is based on direct or indirect measurements of the
service provided at the SAPs by the SP. The specific parameters to be measured,
the party responsible for obtaining the measurements, and the content and
frequency of performance reports are specified in the SLA.
The delivered QoS may or may not meet the commitments contained in the SLA.
Typically, the SLA will specify actions to be taken in these cases. Possible actions
include administrative changes by the SP to improve the service, payment of

penalties for not meeting quality objectives, or the payment of incentives for
exceeding quality objectives.
3.1.15 Service Performance Specification Model
Figure 3-13 describes the performance aspects of a generic service. The white
boxes in the figure represent abstract classes or service templates whereas the
shaded boxes represent specific instances of the service. The white boxes can be
thought of as containing lists of parameter names, whereas the shaded boxes
contain these same lists but also associates a value with each of the items in the
lists.
As shown in Figure 3-13 a service has three types of performance

characterizations, viz., Level of Service (LoS) specification, Quality of Service
(QoS) specification, and qualitative factors.
Qualitative factors are the non-measurable aspects of a service. Examples are the
manners of service installers, the style used in correspondence with the Customer,
sensitivity to a Customer’s personality, etc. Although possibly important to
Customer retention, such factors are not elements of SLAs.
The LoS specification is the set of parameters that specify how the service will
function. Examples include payload rate, error rate, delay, etc.
The QoS specification is a set of parameters that specify how much variation in the
LoS parameters the Customer could experience. That is, the QoS parameters
provide bounds for the delivered LoS parameters. If the delivered LoS lies within
the QoS bounds, the Service Provider has met its SLA quality commitments. If the
delivered LoS falls outside of the QoS bounds, an SLA violation has occurred.

Figure 3-13: Service Specification Model
Figure 3-13 illustrates three instances of Service A. The S1 and S2 service

instances have the same LoS but different QoS, e.g., 64 Kilobit per second clear
channel transport with different Bit Error Ratios. Service S3 has an LoS and an
QoS that are both different from those of S1 and S2.
3.1.16 Assessing Performance
The delivered QoS values provide a measure of how well the delivered service
matches the contracted service. As discussed in Section 0, service performance is
characterised by the combined aspects of service support, operability,
accessibility, retainability, integrity, and security performance. QoS and LoS
objectives may be set for each of these service performance components.
Figure 3-14 provides a conceptual view of the main factors contributing to service
performance. Each of the applicable factors associated with a given service would
be specified in an SLA. The parameters chosen as contributors to the QoS factors
may be service specific, technology specific, or service and technology
independent parameters. The parameters selected are those that are fundamental
to the service and that affect the Customer’s experiences.
Figure 3-14: Factors Contributing To Quality Of Service

It may be possible to algorithmically combine the chosen parameters into a single

QoS value or index that provides an overall view of how well the delivered service
meets the committed service. The amount that each of the parameters contributes
to the overall QoS could be defined by a weighting value which is agreed with the
Customer and specified in the SLA. Weighting takes account of the significance of
each of the criteria on a specific Customer’s view of the value of the service. In this
regard, a very important issue is the determination of whether a fault or malfunction
is causing:
1) No service outage. i.e., the service is fully available,
2) A partial service outage, i.e., degraded service is available,
3) A complete service outage, i.e., the service is unusable.
It can be quite difficult for Customers and Service Providers to specify the “grey
zone” of degraded service in the SLA. See Section 3.1.20 for a discussion on the
use of Service Degradation Factors.
Service Availability
3.1.17 Customer Perspective
Extensive research, based on an interview process at the senior business level of

Service Providers in North America, Europe and Asia, shows the need for the
development of a common understanding of service performance and the
standardization of service performance definitions.
Feedback from the above mentioned interview process as well as TMF members’
experience shows that “Service Availability” is the key parameter of interest to
Customers. Although standard industry definitions exist for network and network
element availability, cf., Figure 3-7 and Sections 3.1.6 and 3.1.7, service availability
has no generally agreed technical definition. This leads to misunderstandings and
Customer dissatisfaction. For example, if the Customer believes that "availability"
means their application is running without a problem, and the Service Provider
uses the same term to mean that the service is working (even if impaired), then a
mismatch in expectations is inevitable. Similarly, if a Service Provider contracts
with other providers for components of a service, the lack of common performance
terms makes it virtually impossible to construct a picture of end-to-end
performance.
The technical term serveability captures the essence of availability. ITU-T

Recommendation E.800 defines serveability as the ability of a service to be
obtained – within specified tolerance and other given conditions – when requested
by the user and continue to be provided without excessive impairment for a
requested duration. As service availability is widely used in a business context, the
Handbook series uses the term service availability rather than the more technical

and less well known term serveability. The Handbook series defines service
availability as E.800 serveability.
3.1.18 Service And Network Performance Perspective
Figure 3-15 shows the relationship between service availability and the service
performance factors described in Figure 3-7 and in Section 3.1.6. The relative
importance of Accessibility Performance, Retainability Performance, and Integrity
Performance to Service Availability must be determined on a case-by-case basis.
Figure 3-15: Relationship Of Service Availability To Service Performance
Table 3-2 illustrates a possible mapping of selected causes of service unavailability

to the service and network performance factors introduced in Section 3.7.
Table 3-2 Mapping Of Service Unavailability Causes
Service Performance Network Performance

Factor Factor
Capacity Shortfall Trafficability
Denial Of Service Security
Design Shortfall Planning
Misuse Operability
New Use Patterns Planning

Table 3-2 Mapping Of Service Unavailability Causes
Service Performance Network Performance

Factor Factor
Operator Error Security
Propagation Impairments Transmission
Reliability Dependability
Support Service Limitations Traffacibility / Planning
User Overload Planning
3.1.19 Computing Basic Service Availability
As previously noted, the telecommunications industry is moving toward solutions

that allow Customers to use service packages to support their communication
needs. These packages are built from Service Elements, ranging from the lower
OSI layers up to the application layers. The service elements may be organized in
a vertical layered fashion, e.g., IP over Frame Relay over SDH, and/or in a serial
fashion, e.g., a Voice over an IP network interworking with a Voice over a circuit
switched network.
There is a need to define a methodology to measure all the features provided

through a service package especially one that evaluates the Service Availability of
such packages. Service Availability (SA) is expressed as a percentage (SA%) to
indicate the time during which the contracted service (e.g. SVCs, PVCs, end-to-
end circuits including protocols, applications, etc.) is working at its respective
Service Access Points (SAP). Working in this context means that the applicable
levels of service accessibility, retainability, and integrity are being met.
The unavailability of a service at the SAP is defined as an outage. The duration of

this specific event is the outage interval. These concepts are used in the Service
Unavailability percentage (SUA%) and Service Availability percentage (SA%)
calculation given below.
SA% = 100% - SUA%
Where Service Unavailability SUA% is defined as:
Σ Outage Interval
SUA% = x 100%
Activity Time

3.1.20 Service Degradation Factor (SDF)
An important requirement is to assess whether or not an event affecting the

service at the SAP is causing a complete service outage (service completely
unusable) or a partial service outage (service degraded, but still usable).
In order to address this issue, a Service Degradation Factor (SDF) can be used in
the SUA calculation as follows:
Σ (Outage Interval x SDF)

SUA% = x 100%
Activity Time
Where 0 ≤ SDF ≤ 1
A list of SDF values with the corresponding event type can be defined in the SLA.
This procedure characterises the service in the SLA and can be stated according
to the Customer’s business need. A possible list of SDFs is shown in Table 3-3.
Table 3-3: Example OF Service Degradation Factors
SDF Event Type Duration Source (Time Information)
1 Service fully unavailable System 1 or System 2

0.8 Outage Type A System 3
0.6 Outage Type B System 4 or other
0.5 Outage Type C System 5
.. .. ..
. . .
Service considered
0 Customer happy with it
available
Table 3-4 presents the relationship between Billing, Availability, and Degraded
Performance. SDF enables the definition and orderly application of measures for
degraded performance.
Table 3-4: Billing, Performance And Availability Relationships
Billing Status Performance Level Availability Status
Full Billing Acceptable Performance

Available
* *
Conditional Billing Degraded Performance

Unacceptable Performance
No Billing Unavailable
No Performance
* Shaded area indicates an SDF value between 0 and 1.

It should be noted that it is very important to document the source of the time data,
e.g., Universal Time Coordinated (UTC), used in reports of the event that caused
an outage interval. This is especially important for services that span multiple time
zones.
3.1.21 SAP Weighting
Each SAP may be assigned a weight that indicates its importance to the
Customer. A service may be provided at many SAPs, not all of which are weighted
equally. For example, a service consisting of a server site connected to multiple
client sites is available at a number of SAPs i.e., one for the server and one for
each client. In this example, the weighting of the server SAP may be higher than
all of its client SAPs, indicating that a problem with the server SAP has a more
significant impact on the service than a problem at any of the client SAPs.
If the Customer’s business need requires a weighting of SAPs, the SUA% formula
can be extended with a SAP weighting factor as follows.
In those cases where the SLA is based on SAP Cover Time rather than full time
(SAP Activity Time), the following SUA% formula may be used.
Applicability of the preceding two formulas to connectionless services, e.g., IP-

based services is under discussion.

3.1.22 SAP Attributes And Parameters
Table 3-5 provides the essential SAP-related attributes and parameters that may
be used in SLAs.
Table 3-5: SAP Attributes And Parameters
Component Description Source
SAP Service Access Point (SAP) is a logical element Derived from

located on the interface between the Customer’s Ordering or an
domain and the Service Provider’s domain. It SLA template
represents the point to which a service is
delivered. A SAP can be weighted in accordance
with its business criticality. Weights when used
are defined in the SLA.
SAP Group A SAP Group represents a collection of SAPs Derived from

where service performance will be monitored Ordering or an
and reported. Each SAP normally belongs to one SLA template
(or more than one) SAP Group, and each SAP
Group contains at least one SAP. The
association between SAP Groups and SAPs is
defined in an SLA together with the required
computation rules and aggregation format. Note
that some explicit or implicit SLAs may not
require that performance reports be provided for
all SAPs.
Reporting The Reporting Period represents the period over Derived from
Period which Performance Reports are generated. It is Ordering or an
defined independently for each SAP Group SLA template
within the SLA.
SAP Activity A SAP Activity Interval (SAI) represents the Derived from
Interval duration of a specific active period (i.e. when the Ordering or an
Customer requires service from the SAP) within SLA template
a specified Reporting Period. It must be
measured separately for each active period of
every SAP within a SAP Group.

SAP Activity SAP Activity Time (SAT) represents the total Derived from
Time duration (sum of) of all SAP Activity Intervals of a Ordering or an
specific SAP within a defined Reporting Period. SLA template
SAP Cover SAP Cover Time (SCT) represents the interval Derived from
Time for which a Service Provider is responsible for Ordering or an
the agreed level of service at the SAP. SLA template
Note: A Customer could require service from a

SAP outside of the SAP Cover Time. In this
case, any outages that occur have no impact on
the Service Availability metric.
SAP Start SAP Start Time (SST) represents a SAP Activity Derived from
Time Interval starting time. Ordering or an
SLA template
SAP End SAP End Time (SET) represents the time at the Derived from
Time end of a SAP Activity Interval. Ordering or an
SLA template
SAP Outage SAP Outage Interval (SOI) represents the Derived from
Interval duration of a specific outage period within a Service
defined Reporting Period. An outage period is a Problem
period of service unavailability (e.g. due to a Resolution
fault) which occurs during a SAP Activity Interval
for a given SAP. Note that outages due to
causes excluded by the associated SLA (e.g.
force majeure) are not included in this interval.
An SOI is measured for each outage period for
every SAP within a SAP Group.
SAP Outage SAP Outage Time (SOT) represents the duration Derived from
Time of (sum of) all SAP Outage Intervals for a specific Service
SAP within a defined Reporting Period. Problem
Resolution
(exclusion
conditions from
an SLA
template)

SAP Weight SAP Weight (SW) is a number that represents Derived from
the relative priority attached to a SAP and Ordering or an
influences the relative significance placed on the SLA template
SAP by the Service Provider (and eventually the
Customer). It is defined independently for each
SAP within an SLA.
Committed Committed Time to Provide Service (CTPS) Derived from

Time to represents the earliest time at which the Ordering or an
Provide contracted service is to be available at a SAP. SLA template
Service
No Service No Service Provider Liability Interval (NSPLI) Derived from

Provider represents a time interval within a SAP’s life Ordering or an
Liability where the Service Provider has no liability. SLA template
Interval
Fault Report Fault Report Timestamp (FRT) represents the Derived from
Timestamp time recorded by a service management agent Service
when a fault is reported to it by an external actor Problem
(e.g. Customer, Management System, etc.). Resolution
Fault Fixed Fault Fixed Timestamp (FFT) represents the Derived from
Timestamp time recorded by a service management agent Service
when a fault is reported as resolved. Problem
Resolution
Time To Time to Repair (TTR) represents the difference Calculated from

Repair between FRT and FFT. This is the actual time Service
taken to fix the fault. Problem
Resolution
Service Service Restoration Timestamp (SRT) Derived from

Restoration represents the time recorded by a service Service
Timestamp management agent when a repair has been Problem
verified and the Customer has been informed. Resolution
Time to Time to Restore Service (TTRS) represents the Calculated from

Restore difference between FRT and SRT. It is the actual Service
Service time required to restore the service. Problem
Resolution

3.1.23 Service Availability Information Sources
One of the main difficulties with the Service Availability formula is identifying the
appropriate information sources for all of the required data elements. These data
elements are:
1) SAP Outage Interval,
2) SAP Activity Time,
3) SAP Cover time,
4) SAP Weighting,
5) SDF.
While SAP weights and SDFs can be found in an SLA, event related information
such as Outage Intervals and Activity Times must be obtained from Network
Element Managers (NEM) and/or Trouble Ticketing Systems (TTS). A Service
Provider will need both types of systems to manage the services provided to its
Customers. Usually these two systems operate independently. Therefore it is likely
that the Service Availability and other performance metrics computed from data in
one system will be different when data from the other system is used. This is a
potential source of confusion unless consistent Customer reporting schemes are
established.
3.1.24 Service Availability And Layered Protocols
When possible, it is useful to map services onto the ISO/OSI seven layer protocol
model. One example is a Service Provider to Network Provider SLA, where the
Service Provider buys transmission facilities and capacity (trunks) to build its own
network. Another example is a Customer to Service Provider SLA, where the
Customer out-sources its inter-company communication needs to the Service
Provider. In the first example, the service maps to the OSI layer 1 and in the
second example, to the application level, i.e., layer 7.
When dealing with lower layer services as defined in the ISO/OSI layer model, the
underlying technology determines the choice of the data source for the Service
Availability calculation. In this case, the specific Network Management System and
the parameters to use depend on the service, i.e., PL-LL, ATM, Frame Relay etc.
In the case of upper layer services it is not possible to refer to a specific delivery
technology, since the Customer is not interested in how the Service Provider
delivers the service, as long it is available. As a guiding principle, it can be
assumed that the final goal of Performance Reporting is to state the provided level
of service as close as possible to the Customer’s perception.
A practical approach is to use a Network Management System to detect failures

and to initiate the creation of a related trouble ticket in the TTS. However, after the
fault is cleared, the Service Provider must verify that the Customer’s service is
operational and must have Customer agreement on the service restoration time.
This can be done via automated interfaces between the Customer’s and the

Service Provider’s Customer Care Systems or via staff to staff communications

between the Customer and the Service Provider representatives. In this case a
report produced from data in the TTS can provide a view that reflects the
Customer’s perception, while data from NEMs can still be used to produce
technical reports about reliability, MTBF, etc.
3.1.25 Service Availability Levels
Service Availability values (SA%) are based on business requirements and should
be specified in the SLA. Factors that influence the SA% value include:
1) Type of service (e.g. PL-LL, PVC, SVC),
2) Specific protocols used (e.g. X.25, Frame Relay, ATM, etc.),
3) Network/service configuration (e.g. single point of failure vs. redundancy,
reliable network components, etc.),
4) Service Provider’s policy.
The following are some specific SA parameters that may be included in SLAs and
factors to consider when specifying these parameters.
1) Specification of a service applicability or service cover time, e.g., 08:00 -
18:00 Monday to Friday inclusive; 24 hours Monday to Sunday, should be
included in the SLA.
2) End-to-end Service Availability measurements/calculations should not be a
summarization of network element performance measures. To reduce the
complexity and to shield the single network element performance values,
Performance Reporting can use Trouble Ticket information to determine
and calculate the end-to-end Service Availability.
3) Service Availability measurements and calculations should also reflect
degraded service / degraded performance. Service degradation and
service availability are two related but in some cases separate matters. A
Service Provider may establish criteria and performance credits for service
degradation. Service degradation criteria relate to the service offered to the
Customer.
4) Where applicable, bandwidth availability should be specified in an SLA.
When specified, it should be measured and reported.
5) SAP availability should be calculated on a SAP by SAP basis to assist
reporting granularity. If this is not done, it is possible, in a large population
and/or over a long reporting period, to have a major failure at a single SAP
but report the service as exceeding performance requirements. For
example, global indicators should be reported, but individual failures should
also be noted. SLA commitments at a individual SAP must be explicitly set.
These values are statistically lower than Overall Service Availability.
6) Service Availability calculations must account for the fact that a Customer
may add and/or delete SAPs during a reporting period. One of the
following options can be used in these cases:

a) The average number of SAPs or a cut off date for determining the
number of SAPs may be used in the calculation. In ether case, the
mechanism must be agreeable to both parties and noted in an
attachment to the appropriate reports.
b) The service availability formula can take into account the time in which
every single SAP has been active within the reporting period.
Emergency Priority Service
Priority use of public circuit switched telecommunications services by authorized

users during periods of extreme congestion brought about by catastrophic events
has long been supported by service providers. For example, in the U. S. the
Government Emergency Telecommunications Service (GETS) is an existing
national switched voice and voice band data communications service that provides
authorized local, state, and federal government wire line users with priority access
to the Public Switched Network (PSN) services [GETS], [T1.631]. Work has also
started in the U. S. on a Wireless Priority Service (WPS) specification. Similar
services are available in many other nations.
The need for international standardization of the priority use of services during
emergencies has been recognized in ITU-T Recommendation E.106, Description
Of An International Emergency Preference Scheme (IEPS). E.106 focuses on
voice band services. More recently, Recommendation Y.12717, Framework(s) On
Network Requirements And Capabilities To Support Emergency Communications
Over Evolving Circuit-Switched And Packet-Switched Networks, presents an
overview of the basic requirements, features, and concepts for emergency
communications that evolving networks are capable of providing.
3.1.26 The Service Definition
Emergency Telecommunications Service (ETS) is defined as an explicit service

available to authorized users that provides priority access to and preferential use of
communications resources during periods of extreme service overload. Authorized
users, service overload, and ETS implementations are discussed next.
An authorized user is an individual or organization to whom a priority

assignment has been granted by a National Authority. Examples of authorized
users include National Executive Leadership, Policy Makers, Disaster Response/
Military Command and Control Staff, Public Health, Safety, and Law Enforcement
Officials, Public Services/ Utilities and Public Welfare and Disaster Recovery
leaders.
7
Y.1271 is expected to be approved at the February 2004 Meeting of ITU-T Study Group 13.

Although service providers routinely engineer their service to support peak

demands that are many times greater than the average level, periods of service
overload are still possible. These may be due to extremely heavy demand, e.g., for
wireless service in the vicinity of major spectator events, or to the loss of major
service resources due to natural or human caused disasters. During these periods
service demand greatly exceeds the available capacity resulting in a low
probability that any user will be able to use the service.
Priority service treatment requires that ETS users be identifiable, e.g., by the use of
end user identification and authentication methods or by using specified access
mechanisms. The service provider may support this service by employing
signaling and control protocols that identify the invocation of ETS, by exempting
the ETS from restrictive management controls and applying expansive
management controls, or by invoking a special emergency operating mode.
Table 3-6 contains a high level description of ETS Functional Requirements. See
[Y.1271] and [TR-79] for additional information on a generic description of ETS
Functional Requirements.
Table 3-6: ETS Functional Requirements
ETS Requirements Description
1. Enhanced Priority Emergency traffic needs assured capabilities regardless of

Treatment the networks traversed.
Networks should have protection against corruption of, or

2. Secure Networks unauthorized access to, traffic and control (fraud), including
expanded encryption techniques and user authentication,
as appropriate.
Due to its urgent and important nature, the use of
emergency telecommunications by selected users must be
3. Location protected from manipulation, interception or obstruction.
Confidentially Special security mechanisms to prevent the location of
specified users from being revealed to non-authorized
parties are needed..
Certain network functionalities should be capable of being
4. Restorability provisioned, repaired, or restored to required levels on a
priority basis.
5 Network Networks supporting emergency telecommunications
Connectivity should provide international connectivity when possible.
6. Interoperability Provide interconnection and interoperability among all

networks, (evolving or existing).

Table 3-6: ETS Functional Requirements
ETS Requirements Description
The communications infrastructure should support user and

7. Mobility terminal mobility including re-deployable, or fully mobile
communications.
8. Ubiquitous Public telecommunication infrastructure resources over

Coverage large geographic areas should form the framework for
ubiquitous coverage of emergency communications.
9. Survivability - ETS must be sufficiently robust to support surviving users
Endurability under a broad range of circumstances
10. Voice Circuit switched and packet switched networks need to

Transmission provide voice band quality service for emergency
communications users.
11. Scaleable Users should be able to select the capabilities of

Bandwidth emergency communications to support variable bandwidth
requirements.
ETS should perform consistently and precisely according to
12. Reliability –
their design requirements and specifications, and should
Availability
be usable with high confidence.
3.1.27 ETS Performance
ETS as defined in the previous sections uses the term service in a different sense
than that used in the Handbook. In Handbook terms, ETS is a collection of
performance parameters that can be associated with specific telecommunications
services. For example, GETS is a priority PSTN voice band service. Applying the
ETS requirements to a video service would be an example of a priority video
service.
Table 3-7 illustrates a mapping of the ETS requirements into the six service
performance factors defined in Section 3.1.6.
Table 3-7: ETS Performance Mapping
Support Operability Accessibility Retainability Integrity Security
1. Priority Treatment X X X
2. Secure X
3. Location X

Table 3-7: ETS Performance Mapping
Support Operability Accessibility Retainability Integrity Security

Confidentially
4. Restorability X X
5. Network X X X
Connectivity
6. Interoperable X
7. Mobile X X X
8. Ubiquitous X
9. Survivable X X X
10. Voice X X X
11. Scaleable X
12. Reliability X X
Selected Service Considerations
This section addresses a number of service performance topics that are of high
interest to many service customers.
3.1.28 Time To Restore Service
Time to Restore Service (TTRS) represents the time interval between the Fault
Report Time (FRT) and Service Restoration Time (SRT), i.e., the actual time
interval required to restore the service. Some Service Providers use the time when
the fault occurred as opposed to when it’s reported to compute the TTRS. Other
Service Providers use the time a trouble ticket opened but require that the fault
condition be confirmed before opening the trouble ticket.
ITU-T Recommendation E.800 defines Time to Restore as the time interval during
which an item is in a down state due to a failure. A time diagram in Figure 3-16
illustrates this definition. Note that “failure” is not the same as “fault.” For example,
a service could be said to have failed due to agreed maintenance actions such as

network reconfiguration affecting the service, as opposed to a network fault

affecting service.
It should be noted that there is a difference between Time to Repair (TTR) and
Time to Restore Service (TTRS). TTRS is only completed when the repair is
verified. The relationships are found in Figure 3-16 for the case of manual service
restoration. Other cases of services protected by other means may result in
different relationships.
Figure 3-16: Time To Restore Service (TTRS) Illustration
3.1.29 Time To Provide Service
The layered service concept illustrated in Figure 3-3 can be used to define Service
Provisioning as the implementation of different Service Elements, within or external
to the Service Provider’s domain, in order to offer a certain service at the Service
Provider to Customer interface, i.e., the SAP or SAP group.
Another useful concept is the SAP life cycle, or more precisely the SAP Activity
Interval (SAI). This time interval begins when a defined service is accepted, i.e.,
considered ready for use, and available to the Customer even if service is not
guaranteed within a specified Service Cover Time. The beginning of the SAI,
which may be defined as SAP Start Time (SST), is indirectly used in determination
of outages and Service Availability. The ordering process creates this information.
The sequence diagram for this process is shown in Figure 3-17.

Figure 3-17: Service Ordering Process Sequence Diagram
When a service order is confirmed, i.e., the Order Confirmation Time (OCT), both
the Customer and the Service Provider agree on service qualities, quantities and
configuration. The Service Provider must commit to provide the defined service by
a specified time, the Committed Time to Provide Service (CTPS).
Typically a Service Provider maintains a list of the CTPS for the various service
classes it offers. The CTPS is thus based on the:
1) Service Type, e.g., data, voice, application etc.,
2) Implementation Type, e.g., change request, configuration management
etc.,
3) Location Type, e.g., domestic, international, urban, rural, etc.
A CTPS may also be negotiated and defined on a SAP-by-SAP basis depending
on the Customer’s needs and the Service Provider’s resources and processes.
The Ordering Process initiates the service implementation phases. This includes
Service and Network Element Configuration, Resource Activation, Network
Element Internal Tests, a Bringing-Into-Service (BIS) Test, and a Customer
Acceptance Test. The latter test is considered to be the end of the Ordering
Process. The SAP Start Time (SST) or Ready For Service (RFS) time is
considered to be the completion time of a successful Customer Acceptance Test.
In many Service Provider organizations, this represents the time when the

responsibility for a service is transferred from the “Implementation” organization to

the “Operations” organization. The use of these terms varies among Service
Providers.
∆ T is defined as the difference between CTPS and SST for each SAP. See
Figure 3-18 for an illustration of this definition.
Figure 3-18: Time To Provide Service Tolerance
Obviously the target value for ∆ T is 0. If ∆ T is greater than zero, then this
information must be provided to the billing process to determine if rebates or other
actions are applicable. (See the following paragraphs for exceptions.) If ∆ T is
negative, the service fee is charged only if the Customer agrees to early service
activation.
As shown in Figure 3-18, a tolerance could be defined in an SLA such that a

specified range of values of ∆ T is considered to be mapped to 0, i.e., on time
service activation.
As discussed in Section 3.1.23, when Service Availability is based on Trouble

Ticket information, there may be “No Service Provider Liability” exceptions in the
SLA such as “Force Majeure” or “Unable to Access Customer Site” that influence
the interpretation of ∆ T.
In addition to providing all of the Service description information, the Service

Ordering process should provide the following information to other Service
Management processes on a SAP by SAP basis:
1) Committed Time to Provide Service (CTPS),
2) SAP Start Time (SST) or Ready For Service (RFS),
3) No Service Provider Liability Code,
4) Tolerance.
3.1.30 Service Delay
In principle, there are two types of delay to be considered:

1) Transit Delay through the network between SAPs,

2) Response Delay to requests including the delay experienced through

congested server equipment.
Delay variation, i.e., jitter, is present in both types of delay as network traffic levels
and routing mechanisms change. Response Delay may be outside the control of
the Service Provider or the Network Operator if it is due to server congestion in a
content provider domain. If Response Delay occurs outside of the Service
Provider’s domain, then it is out of scope for the Service Provider’s SLA. The focus
in this document is on SAP-to-SAP Transit Delay.
There are supporting network technology-specific issues that affect the delay
experienced at the service level. For example, ATM transport will affect the delay
experienced at the service level especially if the contracted service is a pure ATM
cell delivery service. In IP services it is known that delay may become a critical
factor for real-time services such as voice or video and for command/response
type services.
Delay has an impact on the perceived QoS at the application layer versus
delivered QoS at the network layer. Response Delay could be seen as Round Trip
Delay (RTD) from SAP to SAP excluding the application response function. This is
a technology-dependent parameter. For example, one could ping a network
access router to obtain just the Network RTD or could ping a host within a private
network and obtain information that includes congestion performance of the private
network and of applications running on the host. Measuring true end-to-end delay
at the application level is rather difficult and depends on the service type, the
supporting network technology and the desired measurement resolution and
accuracy. It may require synchronization of the two measuring devices at both
ends of the service connection or flow.
3.1.31 Service Access
Service access as used in this document specifies service user or SAP

populations. Four categories of user access are defined in the following
paragraphs. Although these categories are not applicable to all technologies, they
can, in general, be supported on a number of different technologies. A decision to
offer these service access categories rests with the service provider.
A closed user group describes a service access scheme where unidirectional or

bidirectional network connections or data flows are only supported among a
predefined set of users or SAPs. Examples of this type of access include IP virtual
private networks (VPN) and circuit switched closed user groups.
An open user group describes a service that is available to all users at all network
SAPs and supports a unidirectional or bidirectional network connection or data flow
between an arbitrary set of distinct users or SAPs. Examples of this type of access
are the public switched telephone network (PSTN) and the public Internet.
A closed access group and open destination group describes a service that can be
initiated by a predefined set of users or at a predefined set of SAPs and can
support a unidirectional or bidirectional network connection or data flow to an

arbitrary set of network users or SAPs. An example of this type of access group is
the Emergency Telecommunications Services described in Section 3.10.
An open access and closed destination group describes a service that can be
initiated by any service user at any SAP and can support a unidirectional or
bidirectional network connection or data flow to an arbitrary set of network users or
SAPs. Examples of this type of access are free phone services such as
information, 411 services, or emergency service, e.g., 911, 999 calls.
3.1.32 Throughput
There is a general agreement in the industry that throughput is related to delay but
not exclusively dependent on it. From a message point of view, throughput relates
to frames, protocol data units (PDU) etc. per unit time. FR and ATM services
specify a committed information rate (CIR). This parameter is a measure of the
efficiency with which the available bandwidth is used. CIR in FR is essentially the
same as basic bandwidth in a digital leased line.
3.1.33 Errors
For detailed definition and discussion of error performance, please refer to the SLA
relevant ITU-T Recommendations.

4 SLA Content And Management
Content Recommendations
This chapter contains recommendations for the content, management, and

support of SLAs and their associated performance parameters. Later chapters in
this Handbook assume that these recommendations have been adopted by SPs
and Service Customers. The recommendations have been grouped into four
categories. The first three categories generally follow the business process model
in the enhanced Telecom Operations Map (eTOM) [GB 921]. The fourth category
contains general recommendations. For the convenience of the reader, Figure 4-1
reproduces Figure 3.2 from the eTOM framework document [GB 921].
Figure 4-1: eTOM Level 0 View Of Level 1 Process Groupings

4.1.1 The Fulfillment Process
The recommendations in this section are concerned with the SLA negotiation and
engineering processes that take place during the fulfillment phase of the eTOM
business process model
Recommendation 1: The SLA should include clear and unambiguous definitions

of the following:
a) The measurable performance metrics and parameters that can be
guaranteed by the SP for a specific service in terms that the Customer
can understand and agree to.
b) Service performance measurement method, measurement period,
reporting period and reporting frequency.
c) Customer and SP responsibilities, e.g., maintaining relevant hardware
and software.
d) SP procedures to be invoked on violation of SLA commitments.
e) Any conditions that affect operability/commitment to support.
f) The types of reports associated with the service, including each
report’s content, format, destination, conditions and delivery media.
g) Service definitions for each service covered by the SLA.
h) Process for handling the specified boundary conditions.
i) Service cover time, i.e. the limits of SP support for different times of the
day/week/month/year, etc.
j) Dispute resolution procedures.
Recommendation 2: For any service the Customer should be able to select:
a) Parameters to guarantee.
b) Value ranges for the parameters.
Recommendation 3: When defining the service performance metrics for the
SLA, the following criteria should be considered:
a) Provide concrete repeatable measurements in a well-defined unit of
measurement without subjective interpretation.
b) Useful to users and SPs in understanding the performance they
experience or provide.
c) Measurable by SPs, their Customers and outside testing agencies.
d) Useful as specification in the formal documents to help high-
performance users purchase the capacity that they need and to verify
that it is actually met.
e) Useful for publication in data sheets.
f) Provide measurements separately from each SP in a value chain.

g) Useful for diagnostics, including a diagnostic mode which can be used

to sectionalize or identify the weak link in a long multihop, multi-
provider path.
Recommendation 4: Standards and targets must be set with a periodic (e.g.
annual) service performance review which should include procedures to update
the SLA according to changing Customer needs.
Recommendation 5: The SP needs to be able to support the following:

a) Thresholds for preventative activities that are to be initiated before an
SLA violation occurs,
b) A capability to store several values per parameter to support the need
for different values. For example, different values may need to be
stored depending on time of day or week,
c) The ability to collect information from underlying element and network
management systems, such as performance management systems
and traffic management systems.
4.1.2 The Assurance Process
The requirements in this section are concerned with the assurance processes after
the service has been provisioned and is being delivered to the Customer. They
affect mainly the monitoring of service quality levels and the reporting of
information to the Customer as specified in the SLA.
Recommendation 6: The SP must be able to monitor and measure the delivered

service performance against SLA commitments at a level acceptable to the
Customer and/or the regulatory authorities.
Recommendation 7: Accurate Customer-oriented information about all SLA

parameters must be made available to Customers on a real-time and/or periodic
basis as agreed in the SLA.
Recommendation 8: Strong access control and authentication must be provided

so that Customers are able to access their own data to the extent agreed in the
SLA.
Recommendation 9: The SP should provide a capability to detect degradation in

service performance, alert the Customer, and respond to performance events
affecting the Customer’s service and associated SLA.
Recommendation 10: The SP should provide a fault monitoring and tracking

capability to ensure that faults are identified, tracked, and resolved within time
frames defined in the SLA, and should notify Customers when these critical
milestones are not met.
Recommendation 11: Customers should be kept informed of potential deviations

from SLA coverage, including both scheduled and unscheduled maintenance. In

the case of failure, Customers should be notified of the approximate time that the
service will be resumed and should be kept informed about the progress of
problem resolution.
Recommendation 12: The SP should have soft thresholds for every parameter to
provide an early warning of impending trouble. To the degree specified in the SLA,
Customers should be kept informed of any service degradation that could lead to
possible SLA violations.
Recommendation 13: For a service involving multiple SPs, the Customer-facing

SP should account for degradation of service performance resulting from other
SPs or network operators. Arrangements should be made with the third parties
that will enable the Customer-facing SP to take appropriate action in case of SLA
violations caused by the third parties.
4.1.3 Customer Interface Management
These requirements are concerned with the interface between the Customer and
the SP and with how the SP should respond to Customer inquiries concerning a
service and its SLA.
Recommendation 14: Customers should have the capability to report troubles or

faults, request changes, and make inquiries about their services by telephone,
facsimile or electronically, and receive notifications in the same variety of ways.
Recommendation 15: The SP should provide a rapid response to Customer help

desk inquires concerning service quality levels.
Recommendation 16: The SP’s Customer Contact Points should have

information available on the status of any service about which the Customer could
inquire.
4.1.4 General Recommendations
The following recommendations are not easily associated with the eTOM process
model but are provided for completeness.
Recommendation 17: SLAs should be numbered, paged, dated and controlled

documents. This information is essential, since the performance reports reference
the SLA. The Performance Reporting process will gather SLA information from an
SP maintained Customer database.
Recommendation 18: When possible SLA should be modular to facilitate

attachment of service specific sections to the standard SLA.
Recommendation 19: Definitions for each service module should be specified in

the SLA and should be uniquely identified. The performance report process will
use the service identifier(s) in the SLA as the basis of the reports.

Recommendation 20: Specification of the Service Provider - Customer

responsibilities should be accurately documented. Service or performance
exclusions (e.g. announced maintenance windows, no access to Customer
premises, Customer caused service break, force majeur, etc.) should be clearly
defined in the SLA.
Recommendation 21: Customer responsibilities should be defined, e.g., the

preferred method of trouble reporting to the Service Provider and provision of
contact details
Recommendation 22: Where appropriate, penalties, administrative remedies,

and recovery periods should be defined.
Recommendation 23: Definitions of terms used in the service and performance

specifications should be included in the SLA. Each SLA or performance report
parameter should be defined in a clear and unambiguous way. Examples of such
terms include service, service access point, service break, service availability, etc.
Relating Offers, Products, Services And SLAs
When considering the terms Product and Service it is mportant to consider how
the distinction is applied within an operator’s business. Figure 4-2 and the
following text identify the different types of SLA that may exist within an
organization.
Customer
Product SLA
Business Service Supplier/

Assurance
Internal Partner
Supplier
SLA SLA
Network
Figure 4-2 SLA Universe
While individual services may be the focus for internal management purposes, in
most cases it is a combination of these services that are sold to the customer.

Figure 4-3 depicts a hypothetical product offering to the end customer. From this it
can be seen that services form components of products and an individual service
may form a component of one or many products. The way in which these
components are packaged with pricing and terms and conditions of the contractual
agreement form the basis of the offer, or proposition, to the customer. The scope
and terms of the offer are determined by marketing and it is this complete package
that the customer orders and on which the expectation of service is set. Service
level agreements are related to the offer.
End -to -End

SLA
Mobile IP IT
Access Transport Network
Network SLA SLA SLA
RADIUS
Firewall
DNS DHCP DNS DNS RADIUS
GPRS/UMTS ISP IT
IP Transport
TE Mobile Access Network Network
Domain
Domain Domain
IP Diff - Serv MPLS - TE Diff - Serv Diff - Serv

GTP
Mobile Network IP Transport IT Network Application
Service Access Service Service Access Service Access
Point Access Point Point Point
(SP BTS) (SP GGSN) (ISP IP Router) (ISP E - mail Server)
Figure 4-3 End-To-End SLA Management
It is also evident that products are customer based whereas services are more
network based although there is another level of granularity, the service
component that may be used by the operation's function for ring fencing roles and
responsibilities. For example an email service requires several service
components such as the email servers, RAN, GPRS core, ATM etc. Some of
these may be managed independently of each other within the operation’s
environment and may have internal SLAs (SLOs) against these components.
There may also be a service manager type role that will manage the end-to-end
service against an internal SLA that is effectively an aggregation of the service
components.
There are three distinct areas associated with the application of Service Level
Agreements (SLAs) within the operator’s business. The most obvious, and in
many cases the area that is currently under focus, is that of internal SLAs. Internal
SLAs are focused on managing components of the service delivery chain and are
aggregated to form the end-to-end service measurables. By their nature these
SLAs are often not truly customer focused in as much as they are not couched in
terms that understandable by the end customer. The key users of these SLAs are
the functions responsible for managing the service components and for managing
those components against agreed quality objectives. Other parts of the operator’s
business rely on internal SLAs to drive improved efficiencies and for understanding

the service delivery performance within the functions of the business. It should
also be noted that service level management is not restricted to network based
service components but must also be applied to non-network services e.g. billing
availability and accuracy.
As operators become more and more reliant on 3rd parties for the delivery of
services and content, the need to implement SLAs against those suppliers /
partners grows in importance. Indeed the implementation of SLAs in this area will
almost certainly improve the quality of content delivery. It will also enable the
operator to share the financial risk of service degradation with their 3rd parties.
These SLAs are similar in nature to the internal SLA discussed above and form
part of the end-to-end SLA but may also have an impact on the accounting
processes for paying for the content services.
The final area that needs to be considered is the end customer or external SLA. In
considering this area, the nature of the products sold to the customer needs to be
taken into account. While internally the focus may be on individual services, the
offering to the customer tends to be a product that consists of a number of services
which may be either network or non-network based.
Network
• Voice
• SMS
• Voicemail
• WAP
• Handset
• Customer Care
• Itemised Billing
• Per Second Billing
• Handset Replacement
• Insurance Non-Network
Figure 4-4 Product Components
Figure 4-4 illustrates the range of product components which could make up a
product offering. As can be seen some of these components are network derived,
however there are a number of the product components that have little or no
dependence on network resources. The SLA with the customer is likely to
encompass all aspects of the product including the non-network aspects. The
external SLA will consist of a wide ranging set of parameters worded in terms that
are understood by the customer. Deriving this set of SLA criteria requires a clear
understanding of what is important to the end user and is therefore best achieved
by discussion and negotiation with the users.
Much as the SLA management processes are an integral part of a SP’s total
service management solution, so too is the actual SLA an integral part of the
service provider’s product offerings - depicting exact details of the service, the
quality expectations, and the delivery process. This section introduces the major
components and relationships associated with an SLA. The goal of Section 0 is to:

1) Help SPs and Customers identify the components comprising SLAs and
the role of these components within a SP service offering.
2) Identify different aspects of SLAs at each link within the supply chain.
3) Help SPs find a mapping between SLAs and QoS parameters.
4) Provide inputs for evaluating impacts and requirements in different
operational process areas when a new service offering and its accociated
SLA are designed.
SLAs may be defined between an SP’s internal administrative units. This includes
allocating performance objectives to the internal administrative units for their part of
the network connection. The approach used to model SLAs with external
Customers can be applied to these intra-company administrative units.
Section 0 does not contain a prescription for creating contracts and SLAs. Rather,
it presents a conceptual model for analyzing the different roles, types of SPs and
Customers, and types of services. This model supports and structures the complex
task of mapping a Customer’s quality expectations into the SP’s terms.
Figure 4-5: Bundle Composition
4.1.5 Role Of SLAs Within Service Products
A SP maintains a number of products and services available for Customers to

order. A commercial offer represents a service package offered by the SP to the
Customer. In the Handbook Series a commercial offer is viewed as a single
service, e.g., an ATM PVC. The term commercial bundle is used to describe a

package that contains a collection of commercial offers, e.g., an xDSL access with
email and web hosting. The SP may package different commercial offers to meet
different Customer requirements. This is illustrated in Figure 4-5.
The commercial offers available to the Customer are composed of a number of

supporting service capabilities, or service elements. Each service element may be
associated with a level or quality of service.
A service element typically models technology-specific capabilities, e.g., an ATM

bearer service, an MPLS connection, an xDSL based access service, or
operational capabilities, e.g., help desk support. It represents the individual
features typically visible to Customers8. The functionality of any service element is
provided by the element itself or by one or more other service elements. Basic
service elements derive their functionality from one or more physical service
resources.
Service resources are the base level building blocks for composing the basic
service elements and are usually not visible to the Customer. The service
resources are the key elements over which the SP has control to manage the
levels of service offered and to measure the levels of service achieved. A service
decomposition example is described in Figure 4-9.
The service contract9 lies at the heart of the relationship between the Customer
and the Service Provider. The role of a service contract is illustrated in Figure 4-6
Figure 4-6: Service Contract Relationships
8
The level of Customer visibility will depend on the SP’s policy and on the “nature” of the service.
9
The actual relationship between the service contract and the SLA can be SP-specific; for instance, the SLA can be
considered part of the contract, or the SLA can be considered to be the contract.

4.1.6 Defining Service Commitments
The role of an SLA template is to capture the set of service objectives, the actions
to be taken for exceeding or for not meeting the specified objectives, and any
conditions under which the SLA does not apply. The composition of an SLA
template and its relation to an SLA is shown in Figure 4-7.
The service objectives are the representation of the service commitments

documented in the SLA. A service objective could be related to the entire
commercial bundle, to a service element, or to a single SAP. It is always visible to
the Customer.
Figure 4-7: Components Of An SLA Template
The production of an SLA template is an intrinsic part of service development.

These SLA templates relate to “standard” product/service offerings and contain
default values specified during the product/service development phase.
Once a Customer enters into negotiations to purchase a service, the SLA template
is used as the blueprint for the SLA. Depending on the type of service offered,
there may be extensive negotiations of the SLA terms between the Customer and
the SP. The SLA Template provides a baseline for these negotiations.
SLA templates effectively form part of the SP’s product catalogue. For the
Customer, the choice of service levels may be explicit in the service order, or may
be implicit in the commercial bundle description, e.g., a VIP bundle which
combines a set of gold level services.

Customers may order multiple service instances, e.g., five ATM PVCs. In these
cases, the SLA template may contain both parameters for each service instance
and for the group as a whole. For example, an SLA template related to a service
offering which includes a PDH access to a backbone network with a set of PVCs
crossing that network, could include parameters with threshold values set for each
PVC (e.g. Cell Loss Ratio on a single PVC in one direction) and also general
parameters calculated on the group of PVCs (e.g. Maximum Cell Loss Ratio for all
the PVCs).
4.1.7 SLA To Service Mapping
One of the key aspects of an SLA is the association of the required levels of
service to the specific details of a Service Instance. As defined in Chapter 3, the
Service Access Point (SAP) represents a logical point located between the
Customer and the SP domains. In the case of services supplied by different SPs,
the SAP characterizes a point on the boundary between the SP domains.
Figure 4-8: SAP Relationship And Activity Diagrams
The relationship between the SLA and the SAPs for the service instance provides
the mapping between the service level objectives and the physical service
resources that comprise the service. This gives the context in which to monitor the
delivered service performance in order to determine if the service level objectives
defined in the SLA are being met. Figure 4-8 illustrates these relationships and

specifies the role of Measurement Access Points (MAP). The activity diagram
shown in the figure describes how the measured data is processed. Note that the
MAPs are not required to be coincident with the SAPs and that the data used for
SLA validation may be derived from the MAP data.
4.1.8 Service Example
Figure 4-9 depicts an example of a commercial service consisting of an IP Access

service with email and web hosting. The underlying service capabilities are
supported by a number of service resources, such as the access network and
application servers. The combination of these service resources provides the basic
service elements from which commercial offers can be composed. The SLA
templates represent pre-defined, differentiated levels of service that specify the
service level objectives for a service element and are used to build the definition for
a commercial offer.
l
cia
er Residential Basic SOHO Basic SOHO PRO
m
m Internet Internet Internet
Co fers
Of
s
A late Basic Premium Residential SOHO SOHO PRO Web Hosting Web Hosting
SL mp Email Email Access Access Access Silver Gold
Te
ice s Email IP Access Web Hosting

r v nt
Se eme Service Service Service
El
ice es
e rv urc Email Authentication DHCP Access Network Web
S so Server Server Server Device Elements Server
Re
Figure 4-9: Service Composition Example
Multiple Domain SLAs
As previously discussed, a service element could depend on another service

element to provide an underlying service capability. For example, there are
dependencies between an IP connectivity service and an access service to an ISP
gateway, and between a mailbox service and an IP connectivity service.
Therefore, the service offering provided to the Customer could be built as a bundle
of services with or without mutual relationships. In these cases, the SLA template
should take into account dependencies between services because SLA
parameters are impacted by these relationships (e.g. availability of an IP
connectivity service depends on the availability of the access service). In addition,

dependencies between services could extend beyond the boundary of a single

contract.
A service element might depend on other service elements in different service

offerings from the same SP. Dependencies could span multiple SP domains (or
different organizations within the same SP, as in the case of internal SLAs). This is
illustrated in the example of Figure 4-10. In the provision of the ISP service to the
Customer, Service 1, there are a number of sub-domain services, Services 2-6,
that build up the end-to-end service delivery, each potentially being subject to an
SLA.
End-to-end Service
Customer
Service 1 Internet
Service
Provider
Service 2
Service 3
Access Service 6
Provider Service 5
Network
Network Service
Service 4 Service Provider
Provider
Figure 4-10: Service Delivery Across Multiple Service Domains
Where services cross multiple SP domains, the significance of ensuring

consistency of SLA parameters and their values in all the supporting SLAs must be
considered.
End-to-end Service
SLAa
SLA1
SLAb Service SLA2 Service
Provider 2 Provider 1
SLAc SLA3
Customers
Figure 4-11: Multiple Domain SLA Relationships - Case 1
There could be different types of SLAs, e.g., between SPs or between

administrative units within an SP. In the simple case there is a straightforward
relationship between capabilities of the supplied service and the requirements of
the end-to-end service as shown in Figure 4-11. Here Service Provider 1 can
make a direct correlation between Customer SLA a, b, and c and SLA 1, 2, and 3
with Service Provider 2.

End-to-end Service
SLAa
SLAb Service SLA4 Service

Provider 2 Provider 1
SLAc
Customers
Figure 4-12: Multiple Domain SLA Relationships - Case 2
The second type of SLA is illustrated in Figure 4-12. This type may be required
when Service Provider 2 cannot provide a service to Service Provider 1 at the
same level of granularity as Service Provider 1 provides to the end Customer. This
case can occur when a defined capacity within Service Provider 2’s backbone
network is reserved for Service Provider 1’s Customers. Given these decisions
that were made before the customers requirements were known, there may not be
a direct relationship between SLAs a, b, and c and SLA 4. In particular, it may not
be possible to specify performance parameters in SLA 4 that are based on the
parameters related to a single customer service. It may however, be possible to
use statistical indicators of the entire bundle provided by Service Provider 2 to
Service Provider 1.

5 SLA Management Tools
This chapter provides three tools that are useful for structuring the complex
process of SLA preparation and management. These tools are the six-stage
Service Life Cycle, the KQI Development Methodology, and the SLA Parameter
Framework.
The development of an SLA should span the complete life cycle of a service. The
six stage Life Cycle is described in detail in Section 0. When the Customer-
Provider interactions address each of these stages, the resultant expectations will
be better aligned and the relationship enhanced.
The KQI development Methodology identifies the customer based metrics that
capture the customer’s perception of quality of service. A top down approach with
regard to service offered is combined with a bottom up approach to assess
transactions necessary to delivery the service. This leads to a framework which
facilitates the identification of the mapping between network and service data from
which network and non-network data may be consolidated and aggregated into the
key quality indicators for the service.
There are many performance parameters in common use that have similar names
yet have drastically different definitions. The SLA Parameter Framework organizes
performance parameters into six categories based upon service and delivery
technology and upon performance measures for an individual service instance and
for averages across all service instances. The SLA Parameter Framework is
described in Section 0. Note that the specific values for service performance
parameters are arrived at through the contract negotiation process and are beyond
the scope of the Handbook.
The Service Life Cycle
SLA management requires interaction between many of the eTOM processes [GB
921]. In order to analyze these interactions more thoroughly, various lifecycle
stages or phases must be considered separately. The life cycle of an SLA is
composed of the six phases shown in Figure 5-1.
The life cycle phases are introduced in the following subsections. A set of use
cases and the corresponding eTOM processes are presented in Annex H. These
use cases are not intended to be prescriptive but serve to illustrate one approach
to the process flows involved in SLA management.

Figure 5-1: Service And Associated SLA Life Cycle
The six phases used to analyze SLA Management are:

1) Product/Service Development,
2) Negotiation and Sales,
3) Implementation,
4) Execution,
5) Assessment,
6) Decommission.
Each phase is discussed in the following subsections. Note that a continuous
feedback process is assumed to be used to among all parties.
5.1.1 The Product/Service Development Phase
The Product/Service Development Phase supports service planning and

development activities including market forecasting and defining and constructing
a catalogue of available service products. Service products are specified in terms
of their functionality and operating characteristics. SLA templates are also created
in this phase.
Application support for Product/Service Development helps the SP determine what

services, service levels, and quality levels to offer, what parameters to measure
and what parameter values to specify for each service. It is also important that the
impact of the introduction of a new service on the operation of existing services be
identified.

The Product/Service Development Phase can be initiated by a number of different

events. Internal and/or external factors may indicate that it’s time to develop new
services and their associated SLA templates. Typical initiating events include
market demand, competitive pressures (not always the same as market demand),
internal indicators of service performance, and an evaluation of the success of
active SLAs.
The Product/Service Development phase of the SLA life cycle covers:

1) Identification of Customer needs,
2) Identification of appropriate product characteristics, e.g., levels of service to
be offered, service parameters to be used, parameter values to be offered,
3) Identification of network capabilities,
4) Preparation of standard SLA templates.
Each product description identifies the relevant SLA parameters and indicates
whether an SLA parameter value can be selected individually or whether
parameter dependencies exist that require all of the dependent parameters to be
selected. A discussion of typical SLA parameters can be found in Chapter 3.
The exit criteria for this phase are new product descriptions with the corresponding
SLA Templates.
5.1.2 The Negotiation And Sales Phase
The Negotiation and Sales Phase includes negotiating service options, Level of
Service and Quality of Service parameters, and potentially, changes in the values
of service parameters from those specified in the template. The scope of the
negotiation and sales phase may depend on the service and the type of Customer.
For example, a SP may offer only pre-defined service levels to residential or
SOHO Customers, but may enter into negotiations with large corporate
Customers.
During the sales and ordering process, the SP captures Customer-specific

information for a particular service offering and verifies the order’s feasibility. This
requires the verification of available network resources and the verification of the
capability to meet the specified level and quality of service.
The model presented here assumes that the Customer is contracting for multiple
service instances that will be delivered during the contract period. In general, this
phase will be approximately the same for each individual service sale that involves
an SLA.
This phase includes:

1) Selection of the values of SLA parameters applicable to specific service
instances,
2) The costs incurred by the Customer when signing the SLA,

3) The costs incurred by the SP when an SLA violation occurs or the amount
of incentive payments when the committed service levels are exceeded.
4) Definition of reports associated with product. Note that the time and
frequency of report generation depends on the relevant SLA parameters,
e.g., availability over a unit of time, such as one day, week, month, quarter,
or year.
The exit criterion for this phase is a signed contract.
5.1.3 The Implementation Phase
The Implementation Phase of the life cycle covers the activities associated with
enabling and activating service instances. This may involve deploying new network
and/or service resources or configuring existing equipment. Network resources are
configured to support the required level and quality of service specified in the SLA.
The Implementation Phase processes will be executed differently by every SP but
the overall results will be the same.
There are three aspects to the Implementation Phase. These are:

1) Configuration of SP resources to support the product/service itself, i.e.,
provisioning,
2) Configuration of a specific service instance for a Customer that meets the
SLA specifications (service configuration),
3) Service instance activation.
In this document, the Implementation Phase includes resource provisioning. Note
that some SPs may place provisioning in a different life cycle phase. However, the
Implementation Phase always includes the preparation for and the instantiation of
the individual Customer product.
The exit criterion for this phase is the instantiated, tested, and accepted product.
5.1.4 The Execution Phase
The Execution Phase covers the operation of the services specified in the SLA.
These include:
1) Normal in-service execution and monitoring,
2) Real-time reporting and service quality validation,
3) Real-time SLA violation processing.
5.1.5 The Assessment Phase
The Assessment Phase has two parts. The first assessment focuses on a single
Customer’s SLA and on the QoS delivered to this Customer. The second
assessment occurs during the period when the SP is reviewing its overall quality

goals, objectives, and risk management procedures. This later assessment is part
of an overall internal business review.
The individual customer periodic assessment addresses:

1) Delivered Quality of Service,
2) Customer satisfaction,
3) Improvement potential,
4) Changing customer requirements.
The Internal Business Review addresses:
1) Delivered Service Quality for all Customers,
2) Realignment of service goals,
3) Realignment of service operations,
4) Identification of service support problems,
5) Creation of different SLA service levels.
5.1.6 The Decommissioning Phase
The decommissioning phase addresses issues related to customer premises

equipment and wiring associated with the discontinued service. Possible SLA
related issues include:
1) Responsibility for removal of equipment and wiring,
2) Removal schedule commitments,
3) Access to the Customer’s premises,
4) Consequent change procedures.
Use Cases And Scenarios
The following use cases are present in Annex H.
The use cases address:

5) Product development with a new SLA
6) Negotiations And Sales
7) Implementation Of An Order
8) Normal Execution
9) Execution With An SLA Violation
10) Assessment

KQI Development Methodology
This section provides an overview of the method developed to identify the

customer based metrics that capture the customer’s perception of quality of
service. A top down approach with regard to service offered is combined with a
bottom up approach to assess transactions necessary to delivery the service. This
leads to a framework which facilitates the identification of the mapping between
network and service data from which network and non-network data may be
consolidated and aggregated into the key quality indicators for the service.
The approach is illustrated in Figure 5-2.
Service
Step 1 Scenarios
Analyse
Step 2 Timeline
Identify Service
Step 3 Topology
Step 4 Develop Matrix
Identify
Steps 5 & 6 Develop KQIs
Measurements
KQIs 3GPP SA5
Figure 5-2 KQI Methodology
Starting with the business problem and working down the stack the methodology
derives the Key Quality Indicators and the required measurement and metrics to
calculate them.
5.1.7 Service Scenarios
Services need to be considered according to the desired range of products being

offered to customers. Each service being considered or offered is then
decomposed into its service delivery components. The components are then
analysed and aggregated to determine an ideal range of service element
performance and quality measurements which are valuable in deducing the overall
KQI’s for the service.

The service scenarios or range of services offered by the service provider will be
unique to the particular service provider according to business case drivers.
Similarly the range of applicable KQI’s will vary according to service providers
chosen or preferred range of services and the availability of applicable
measurements needed across the service delivery components and systems
needed to delivery the service.
5.1.8 Analyse Timeline
The scenarios are set against a timeline, developed to represent both the
customer’s and supplier’s actions from the initial point of contact through to
cessation of the service.
To each of these scenarios the timeline is applied as shown in Figure 5-3 resulting
in more specific Customer Experience Timelines. The bottom half of the time line
maps the customers interactions with the service at different points in the life-cycle.
The top half of the timeline considers the effect of those actions on the supplier of
service and the options or impacts that need to be considered in the analysis.
Supplier Interaction considerations
•Marketing contact •Multiple •Transient?

•Quality of info activation routes •May hit usage problem •‘Self-inflicted’ Do you notify customer
•Expectation set •CuCa •Self help vs CuCa call •Service conflicts if not impacted?
•Direct sales •Priority
•Service interruption •Who knows
first? Accuracy
Multiple info Notify of
•Impact
sources on successful
•Content dependent •Response
product/service activation Why?
•Defined ‘sub-service’
Pre-sales Service Ordering In-life Experience
First user
experience Receive
Find out Change
bill
about Service Personalise personalisation
service Activated service
Report
Cease
problem
Subsequent service
Provision Request usage
service for service Experience
customer
problem
Problem
Decide to buy resolved
Customer
advised
Figure 5-3 Customer Experience Timeline
Applying each scenario to the timeline provides more specific timeline actions and
prompts review of the interactions from a customer perspective which may need to
be measured. By taking a top-down approach the full range of both network and
non-network related interactions are identified.

.At this stage there is a business judgement as to which are the significant
interactions which are mapped in detail in the next step.
5.1.9 Identify Service Topology
Before the KPIs and measurements can be derived, the complete service topology
needs to be understood.
The service delivery path must describe the service resources which comprise the
end to end topology. This will cover the network components, supporting system
components, for example billing systems, key process components and reliance
on 3rd party suppliers relationships, as well as the relationships between the
service elements.
New services will include components that already exist in other services. These
components or service resources may be considered as reusable components. An
individual service resource may simultaneously be a service offered to the
customer and a component in another service.
Some of these service elements may be sourced from a third party, inside or
outside an enterprise.
5.1.10 Develop Transaction Matrix
Each of the actions from the individual timelines can then be broken down to
discrete customer actions, then to the technical actions and represented as a
transaction matrix.
The matrix is developed by mapping the columns of the matrix to the service
resources that were identified previously. For clarity they should follow the primary
service delivery path.
The rows of the matrix are the user interactions which were selected for analysis in
step 2. The sub-actions are listed and their path through the service resources
plotted.
Figure 5-4 gives an example of part of a transaction matrix.

Figure 5-4 Developing The Transaction Matrix
5.1.11 Develop KQIs
The transaction matrix provides a mechanism to identify the KQIs necessary to

monitor the service. Figure 5-5 shows how the transaction ,matrix may be
developed on to identify the KQIs, indicated in red in the figure.
The service resource row of the table identifies the resource availability KQIs that
should be considered. A degradation of availability of any of the resources in the
transaction table is likely to affect the service quality. An aggregation of these
KQIs may be used to form a combined KQI (C-KQI) for a single indication of the
end-to-end service availability. At the highest level of aggregation, this KQI is
sometimes referred to as the Service Index.
Figure 5-5 Developing KQIs From The Matrix

The transaction flow arrows identify the points where information is passed
between service resources. These are potential points for identifying accuracy
KQIs and can again be aggregated to form one or more KQIs that provide a higher
view of service quality.
Working down the worksheet the transaction arrows flowing from left to right and
the corresponding ‘response’ arrows flowing in the opposite direction, provide an
indication of where speed (time) based KQIs may be required for measuring the
service quality. The aggregated KQIs may span multiple transactions.
A further KQI type may be extracted from the table although these are not as
obvious as those discussed above. These KQIs are measurements of ‘simplicity’
or ease of use. For example given a service that involves presenting the user with
a number of options, a measurement of the time between the system issuing the
menu or prompt and the time taken for the user to respond may provide an
indication of the clarity of the menu or prompt options.
5.1.12 Identify Measurements
The Transaction matrix allows the identification of: the metrics and measurements
that are required to monitor the KQIs.
The identification of the measurements is not detailed here as it relates specifically

to the service resources in question.
None the less the process of developing a desired measurement framework

according to service and reconciling the range of desired measurements into KQI’s
for the service presents the necessary “bottom up” verification that KQI’s being
established support the offered customer SLA conditions for a service.
Additionally, the service provider may desire that different SLA terms apply to
differing customer groups necessitating that the service provider develops KQI
sets according to the desired range of SLA classes (premium and non premium
service assurance) for a single service. i.e. same service product being offered at a
differing Grades of Service or service availability guarantee levels, for the service.
The companion document to this handbook, Network Measurements, GB923b,

contains descriptions of desirable network system element measurements which
have been identified during the life of the WSMT team for submission to 3GPP
SA5.
The methodology described in this document is designed to support the SLA

parameters described above through the identification of KQIs that represent
(potential) parameters in the SLA. The hierarchical nature of KQIs described in
this document supports parameters across all aspects of the service whether
technology specific, service specific or technology/service independent. The
methodology also supports the concept of aggregated KQIs that provide an overall
indicator of performance and individual performance KQIs that may be used to
measure the quality experienced by an individual user or the service degradation
of an individual component within the service delivery chain.

The SLA Parameter Framework
This section introduces and defines the service parameter framework. The intent
here is not to specify actual parameter values since these are commercially
sensitive and subject to negotiation between the SP and its Customer. The
objective is rather to define a method of classifying service parameters and listing
and defining them in a consistent manner within the SLA.
The set of SLA service parameter values is an element of a contract between two
parties. Whether the SLA and its service parameter values are considered part of
the contract or an adjunct to it varies from provider to provider.
There are numerous business parameters contained in a contract that are not
covered by this Handbook. For example, while SLA violations and remedies are
discussed in terms of the parameters that may identify the violation, mechanisms
for payment and/or other required actions are not included since these are unique
to each contract and the commercial agreement between the parties concerned.
Similarly, proprietary underlying systems and processes used to support SLAs are
not described. However, see Annex H for selected use cases describing SLA
support within the eTOM process framework.
5.1.13 Network Bearer Services And Application Services
The scope of an offered service needs to be clearly defined. For example, is it a

network bearer service supporting, but independent of, the application carried, or is
it an application service such as voice, video, or sound program, supported by
server layer network connections? Services based on ATM technology can be
both - an ATM network bearer service used to support IP-based, FR-based or
circuit-based services, or a pure cell stream delivery service. A parameter
measured between (or at) service access points of a bearer service is a NP
parameter to the provider of the bearer service, but a service parameter to the user
or client of the bearer service. ATM is therefore a good example of both a service
and a supporting network technology. Similar arguments can be applied to IP. It
can be a supporting network technology or purely a packet delivery service.
In should be noted that in some settings an SLA is considered to be a “Business

Application Programming Interface (API)” and the QoS as a kind of “Network API”.
The usefulness of this characterization depends to some extent on whether a
network bearer service or an application service is being considered. It also
depends on whether the technical QoS aspects are considered to be part of the
SLA/Contract or an adjunct to it. In general terms, a service is a product provided
by one entity to another for which payment may be made.
5.1.14 Parameter Categories
It is important to distinguish among performance parameters that are applicable to

all services and all network technologies, those that are service-specific, and those
that are network technology-specific. The first parameter category is referred to as

the Technology/Service Independent category in the Handbook. This distinction

was made early in the TM Forum work on Performance Reporting (see [TMF 701])
and was later refined to distinguish between the individual user view and the
aggregate view. These categories and views are shown in Figure 5-6.
Service Parameter Categories

Technology Service Technology/Service
Specific Specific Independent
Individual Parameter Parameter Parameter

Service User View List 1 List 2 List 3
View Parameter Parameter Parameter
Aggregate
View List 4 List 5 List 6
Figure 5-6: Service Parameter Category Framework
Figure 5-7 illustrates a typical relationship between the service functions defined in
Section 0 and the three parameter categories. In most cases the Service Specific
parameters refer to a service’s primary functions.
Technology Service Specific Technology/Service

Specific Independent
Primary Functions X X X
Enabling Functions X X
OAM Functions X X
Figure 5-7: Service Functions-Parameter Categories Relationship
5.1.15 Service Views
The rows in the service parameter table distinguish between the individual user
view of the service and the aggregated view. The individual user view is
associated with a SAP or SAP Group and covers service properties such as the
service interface or the maximum service down-time that an individual service user
could experience during a specified time period. The aggregated view essentially
captures the average performance over all service users during a specified time
period and includes items such as service billing and aggregate availability. It is
important to distinguish between single event requirements and aggregated
requirements from the user’s perspective. For example, if only aggregated
availability is specified over a billing period, it would be possible for a single user

outage to shut down that user entirely while the aggregated service requirement is
met. The single user view parameters can be used to define the maximum down
time for a single event and the minimum up-time between events. This detail could
be lost at the aggregated requirements level.
The SP's perspective is not the same as the Customer's, and internally at least,
the SP must consider issues such as revenue generation/continuity, differentiated
services, and the cost to maintain networks and services. These issues might
feature in the “internal SLA” between departments of a SP or between one SP
(retailer) and another (wholesaler). Note that availability performance can be
specified in all six categories.
5.1.16 The Service Parameter Table Examples
Figure 5-8 illustrates some typical parameters that may be found in the Service
Parameter Table.

Physical Service type or Maximum down-time
Individual
interface bundle of one event
User View
Service details
View Monthly Billing method Aggregate availability
Aggregate
reported (usage- or over all users
View
parameters time-based)
Figure 5-8 Typical Service Parameters
Some services may contain both technology-specific and service-specific

parameters, while some may contain only one or the other. The examples shown
in Figure 5-9 and in Figure 5-10 illustrate these cases.

Individual Speed Delay, Availability,Max. time
Service User View Throughput to restore
View Aggregate Total UAS Delay MTBF, MTTR, MTRS
View distribution
Figure 5-9: IP Service With DSL Access


Individual CER, CLR, CTD, CDV - all max. Availability, Max. time
Service User View values to restore
View Aggregate CER, CLR, CTD, CDV - all MTBF, MTTR, MTRS
View mean values and totals
Figure 5-10: ATM Cell Delivery Service
5.1.17 Service/Technology Independent Parameters
Service/technology independent service parameters are those which are often (if
not always) specified in an SLA. Examples include Percentage Availability, MTBO
or MTBF, OI, MTPS, MTRS, time to first yield, average call response time, etc.
These are sometimes referred to as “operational performance criteria10,” and some
are required to be reported to regulatory authorities by SPs on a regular basis,
e.g., time to first yield. Included in this set might be integrated or consolidated
billing for a basket of services, accuracy of billing and payment terms.
Other service/technology independent factors are billing period, security (of both
service access and information transfer/delivery) and the specification of alternate
routing/redundancy of network connections providing the service, possibly
including avoidance of Common Points of Failure (CPoFs). For many mission-
critical services, these factors are very important and need consideration. In an
ebusiness environment, they may be critical to the survival of the business,
particularly for large companies and financial institutions.
An additional aspect of network technology independence is server reliability for

those services that use computer server “farms”. One might consider this
technology-dependence of the service offered as opposed to dependence on
network technology supporting the service. It is suggested that this issue be
treated as a service-specific parameter.
Acceptability is a new technology/service independent measure. It describes the

attitude of users to new technology and to new technical applications, e.g., mobile
Internet access. Acceptability can be defined as the ratio of the total number of
people in a service target group and the number of people actually using a service.
It has been proposed as an alternative to service availability as the measure of
Customer satisfaction, c.f., Section 0.
10
This terminology is not aligned with the service performance terminology used in E.800 and in this document.

It should be noted that most of the service/technology independent parameters are

specified and measured with respect to time. Thus access to accurate time of day
information is critical to monitoring and assessing the delivered QoS.
Time of day synchronization across multiple SPs, NOs and time zones can be
difficult. The ITU has standardized time stamping of events and information
exchange in terms of UTC - Universal Recorded Time. ITU-T Study Group 2 has
developed a Network Management Recommendation that tracks the time from the
occurance/detection of a network defect through all the stages of reporting,
remedial actions taken, etc., to the time when the physical repair is completed.
This time recording scheme is discussed further in Section 0.
5.1.18 Technology-Specific Parameters
Technology-specific service parameters are related to the telecommunications

technology supporting the service, particularly when the service offered is a
network bearer service. Examples previously discussed include ATM parameters
and PDH/SDH/SONET layer parameters. In addition, technology-specific
parameters such as physical characteristics of the SAP need to be specified.
Some of the technology-specific parameters may not be relevant to the service
end user, but need to be considered by the SP or between NOs and/or SPs. The
decision on which parameters to include in an SLA is an individual choice for each
service contract.
Examples of QoS parameters for each network technology layer follow:

1) Physical media layer: copper/optical cable and terrestrial/satellite radio
parameters of Loss, Crosstalk, Delay, Dispersion, and Q-factor.
Note: renting of unbundled copper loop, copper coaxial cable and optical
fiber are now services provided by some NOs. Similarly, renting of
microwave radio transceiver towers and satellite bandwidth are also
services.
2) xDSL layers: system parameters of Bit Rates (up - and downstream),
Bits/Hz, Reach, Radiation, Crosstalk.
3) PDH/SDH layers: BBE, ES, SES, SEP, Jitter, Wander, Slip events and
their derived parameters of BBER, ESR, SESR, SEPI; UAS, Availability,
Pk-Pk Jitter, TIE, and MTIE.
4) ATM layers: CE, CL, CM, SESATM, SECB, CD events and their derived
parameters of CER, CLR, CMR, SECBR, CTD, CDV, UAS, Availability,
Throughput, Utilization. Associated with these are traffic descriptors or
traffic profile parameters specified in the service contract including PCR,
SCR, MCR, MBS, PEI and CDVT.
5) FR layers: lost or corrupted frame events and their derived parameters of
Frame Loss Ratio of committed frames (FLRc), Frame Transfer Delay
(FTD), Availability, Throughput, Utilization. Associated with these are traffic
descriptors or traffic profile parameters specified in the service contract
including PIR, and CIR.

6) IP layer: lost or corrupted packet events and their derived parameters of IP

Packet Loss Ratio (IPLR), IP Packet Transfer Delay (IPTD), IP Packet
Delay Variation (IPDV, sometimes called Packet Jitter), Availability,
Throughput, and Utilization.
One of the biggest challenges is mapping the Service/NP parameters between
different network technology layers and determining their impact on the highest-
level service client in use.
5.1.19 Service Specific Parameters
Service-specific performance parameters are typically related to the application

supported and include service-specific or application-specific technology
parameters such as reliability and availability of computer servers, databases, etc.
For example, as ebusiness expands, computer server parameters will become
increasingly important and impact the overall availability of the service offered.
As noted in Section 0, Service Availability is widely considered the most significant

service parameter. Service Availability depends on the combined aspects of
service accessibility, retainiability and integrity. Availability measures are
summarized in Figure 5-11. Additional information on Service Availability is found
in Section 0.
Measure Estimation Units Example

Availability ∑Up-times x 100 (%) 99.9%
∑Up-times + ∑Down-times
Unavailability ∑Down-times x 100 (%) 0.1%
∑Up-times + ∑Down-times
Mean accumulated down- ∑down-times accumulated over (hours) 8.76 hrs
time over a given time a given time interval over one
interval year
Figure 5-11: Availability Performance Measures
The availability measures have been further refined and expanded in Section 0 to
account for SAP weighting.
Examples of service-specific parameters for selected services are:

1) Voice telephony: call connectivity and quality measures
ABR/ASR/CCR/CSR/NER; network connection failures and retainability,
Customer Affecting Incidents (CAIs) and Defects Per Million (DPM); PSTN
speech and 3.1 kHz audio loudness (speech level), attenuation, noise,
crosstalk, echo, and distortion; ISDN call set-up failures and delay,
propagation delay (including differential delay between B-channels), G.821

error performance, premature release, release failure and delay, and CLI
reliability.
Note: with the increasing use of digital network technology, control and
management of echo has become increasingly important, even for quite
close destinations from a caller. For Voice over IP (VoIP), delay and echo
are two of the major hurdles to overcome.
2) Data: BER, % EFS, errored PDUs, lost PDUs, UAS, Transport Parameters
such as loss, attenuation, group delay distortion, noise, impulse noise , and
analog parameters.
3) Facsimile: image quality, character error rate, call cut-off, modem speed
reduction, transaction time and availability.
4) Mobile telephony: call completion rate, call dropout rate, noise, echo,
distortion and availability.
5) Sound program: noise, crosstalk, stereo channel interference, distortion
and availability.
6) Support & maintenance: service penetration (e.g. telephones per 100
population), supplying service instruction and information, access to SP
(e.g. answering requests, response times), service supply and removal
(e.g. MTPS), and service repair (e.g. MTTR).
5.1.20 Service Degradation
Network and service performance will inevitably vary over time as equipment ages
and external influences take effect. Unexpectedly large variations in traffic levels in
the supporting network may also impair service. Unforeseen events such as
floods, hurricanes, earthquakes, or intentional acts may cause server service
disruption. The provisioning of network resources alone is not sufficient to ensure
that the contracted performance is sustained. Monitoring and management of the
performance factors specified in the SLA are also important to retaining Customer
satisfaction and loyalty, and avoiding any SLA violations and penalties. Monitoring
is required to detect and locate the source of the service degradation. This requires
that the performance levels be monitored at various points along a connection, not
simply at its origin and destination. Although the latter is of most interest to the
service end user, the former provides valuable information on the location of the
source of the degradation. This requires monitoring of real-time traffic flows in
different network segments. Detailed description of monitoring methods is outside
the scope of this Handbook.
5.1.21 Management Of Service And Network Performance
An adequate assessment of service and network performance can only be

obtained by judiciously defining a set of parameters that captures the service
aspects of greatest interest to the Customer. A SP may (usually will) use more
stringent performance requirements in its design, commissioning, operation, and
service subcontracting specifications than those committed to in SLAs. In practice,

performance management consists of insuring that the delivered performance

meets or exceeds the different performance objective values.
Note that for international networks and services, the performance objectives are
specified by ITU-T Recommendations.. In many cases, these Recommendations
also allocate the performance objectives to different portions of the network in such
a way that each network provider is aware of its responsibilities.
Some combination of the service mechanisms provided by OSI layers 1, 2, and 3

will be the basis for translating end user requirements into technology-specific
performance parameters. This process must include techniques for distributing
performance requirements among carriers supporting various segments or layers
of a service. This may be done by allocating performance objectives to the various
parties providing the service. Real-time responses are required to address network
resource demand fluctuations. Impacts on performance among user flows on the
same bearer service must be avoided. Thus performance monitoring as well as
good network planning and design are needed. The close coupling between
network traffic engineering and performance noted in Section 3.1.10 cannot be
overemphasized. Depending on the network technologies employed, a range of
performance allocation approaches are available. Detailed discussion of these is a
network management issue and outside the scope of this Handbook.
SLA Data Management
The effective management of all the related Service and Customer data is the
principal challenge to providing truly integrated SLA Management. SLA
Management functions need to combine, correlate, assess, and act on a wide
variety of data sources to effectively meet the fulfillment and assurance levels
specified in SLAs. There is a need to draw on many data sources within a SP’s
Operations Support System (OSS) environment, such as information on
Customers, services, and service performance as shown in Figure 5-12.
The Network Data Management process is supported by a number of functions,

each one collecting different types of raw performance data from different sources.
For example, Network Performance Data is composed of raw network
performance data from network elements and network element management
systems. Process Performance Data is raw operational process performance data
from systems such as Trouble Ticketing and Provisioning. Application & Server
Performance Data is composed of raw service performance data from other
applications (e.g. email, web servers and DNS).

Customer
Details Customer SLA
Performance Data SLA Reports
Service SLA
Instances Contracts
Service QoS &

Performance Data
Service SLA QoS Reports

Descriptions Templates
Raw
Performance
Data
Product & Service Implementation
Development
Negotiation & Sales Execution & Assessment
Figure 5-12: SLA Related Data
As shown in Figure 5-13, raw process data and service configuration details
related to operational process parameters are aggregated to provide service level
quality metrics from the technology, service and process performance data. QoS
Analysis & Reporting and SLA Proactive Monitoring use the service performance
data to correlate service performance against set operating targets and SLA
guarantees.
Customer/SLA Customer
SLA & QoS
Layer Reporting
SLA
Proactive
Monitoring
QoS
Analysis
& Reporting
Service
Layer
Service
Performance
Data
Aggregation
Data & Server

Application
& Server Process
Collection Network Performance Performance
Layer Performance Data Collection Data Collection
Data Collection
E.g. Trouble Ticketing,

E.g. ATM, FR, IP E.g. Web Server, DNS
Service Provisioning
Data Collection & Aggregation

Execution & Assessment (out of scope of current Handbook work)
Figure 5-13: SLA Performance Data Collection

The Customer SLA Reporting is covered in the following section.
5.1.22 Role Of In-Service Monitoring
At a network level, continuous In-Service Monitoring (ISM) of NP is preferable for

detecting degradation in performance and its impact on the delivered services.
This is increasingly possible using built-in digital signal overhead such as framing
bytes, Error Detection Codes (EDCs) and Performance Report Messages (PRMs).
The objective is to provide pro-active performance monitoring and reporting such
that network layer degradations are discovered early and action taken before SLA
commitments are violated. Degraded Performance Limit (DPL) and Unacceptable
Performance Limit (UPL) thresholds can be set within network elements. When
these limits are reached, notifications are sent to network management systems.
These management systems in turn filter, correlate, integrate, and process the
performance events that may result in alarms, and generate network-level trouble
reports and trouble tickets that report service-affecting situations. See ITU-T Rec.
M.2140 for a comprehensive discussion of these processes [M.2140]. Further
information can also be found in the ITU-T TMN M.3xxx-series Recommendations.
Figure 5-14 represents implied relationships between the engineered level for the
NP and commitments made in an SLA.
Figure 5-14: Performance Levels For Related Services

6 SLA Performance Reporting
This chapter addresses those aspects of performance reporting that support

commitments contained in an SLA. It does not address other reporting
requirements that are known to exist but which are not explicitly required by the
SLA.
Measurement And Reporting Intervals
6.1.1 Measurement Considerations
The three main sources of performance data are network measurements,

Customer interviews and Customer complaints. The user perception of
performance is based on both the provisioning and the operation of the service. To
cover all aspects of performance, measurements should be carried out at, or as
near as possible to, the service access points and at each network node. This
guideline raises the issues of accuracy, scalability, and cost.
Monitoring at the Customer Premises Equipment (CPE) requires at least one

service monitor per end point. This is desirable because the level of performance
seen by the monitored traffic is nearly the same as that experienced by the
Customer’s traffic. However, this is costly and difficult to apply to large networks.
Additionally, it can result in large amounts of management traffic being transported
across the network, thereby increasing the congestion. Furthermore, the SP may
not own the CPE and may not have continuous access to it.
Measurements may be made manually, semi-automatically or completely

automatically using test calls or live traffic. However, it should be noted that
measurements made during test calls are not truly representative of the
performance experienced by live traffic, particularly for packet-based networks and
services. Such data is only an estimate of the likely service experienced by the
user. For these results to be meaningful, the test calls must be sent along an
equivalent connection that follows the same route and is assigned the same
service parameters as the customer calls. This is possible with an ATM permanent
virtual connection, but unlikely in a dynamically switched network. Furthermore,
test call monitoring traffic competes with the Customer’s traffic and therefore may
increase network congestion.

6.1.2 Events And Reporting
The time line aspect of reporting network incidents affecting performance is

illustrated in Figure 6-1.
Figure 6-1: Time Line For Reporting Network And Service Incidents
Definitions of the significant time points shown in Figure 6-1 are defined in Table
6-1.
Table 6-1: Significant Times For Performance Reporting
T0 The time that a defect first appears in the network regardless of whether or
not any Customer service is impacted.
T1 The time the first Customer attempt or use is impacted.
T2 The time that the network problem (defect) is detected by the Network
Manager. The detection can be via a system or verbal, e.g., a Customer
trouble report. If the detection is from an OS, the detection time is the time
when the exception occurred, not when first seen.
T3 The time that a network management control action occurred to minimize or

eliminate the Customer impact.
T4 The time the defect was referred to another group (maintenance,

provisioning, routing, etc.).
T5 The time when appropriate notifications started.
T6 The time Customer impact stopped due to NM control action, restoration or

hardware/software repair made.
T7 The time physical restoration was completed.

The measurement and recording of the time points and intervals shown in Figure
6-1 have been suggested as a way of characterizing service performance and NP
in terms of “best in class,” “world class,” and “average” bands.
As noted earlier, many of the performance parameters are time-related. There are
two aspects to this - the sampling or measurement period over which each
parameter is calculated, and the reporting interval over which the parameters are
averaged and reported. The sampling periods that have been traditionally used are
every second, every minute, every 15 minutes or every 24 hours. The reporting
period is typically one month. Thus, real-time performance parameters are typically
measured over the sampling period, stored in a database and reported once a
month. The choice of Customer reporting interface implementation will be
influenced by a number of factors, including the contracted reporting interval.
Performance Reporting
Performance Reporting is defined as one of the components of the Customer

QoS/SLA Management process in the eTOM Customer Relationship Management
process. This is illustrated in Figure 6-2.
Figure 6-2: eTOM Customer Relationship Management Processes

6.1.3 Role Of The Performance Reporting Process
The Performance Reporting Process provides the service Customer with all of the
performance reports specified in the SLA. Routine reports include reports of the
performance of a service vis-à-vis the SLA specifications, reports of developing
capacity problems, and reports of Customer usage patterns.
In addition, this process responds to performance inquiries from the Customer.
6.1.4 Process Functions Addressed
The process functions that are addressed within this document include:
1) Scheduling the Customer reports,
2) Collecting performance data,
3) Compiling the Customer’s reports,
4) Delivering reports to the Customer.
The Reporting Functional Interfaces
Performance Reporting is not a stand alone application. It depends on numerous

Operations Support System (OSS) functions for performance related data. Figure
6-3 illustrates Performance Reporting function’s relationships with other OSS
functions and its interface to the Customer.

Figure 6-3: Performance Reporting Interface
Figure 6-3 shows only the interrelationships required for Performance Reporting.
The remaining interfaces, although essential for providing information to other
processes, are out of scope of the Performance Reporting interface.
Reporting Scenarios
The following subsections present message sequences that correspond to

different scenarios for passing a performance report across the reporting interface.
6.1.5 Reporting With Acknowledgement
The first scenario illustrated in Figure 6-4 assumes that an acknowledgement of

the receipt of the report by the Customer is suported. This enables the Service
Provider to resend the report if the acknowledgement is not received. This
scenario typically occurs when a report is sent automatically (even by facsimile) to
the Customer as soon as it becomes available.
This scenario also shows that a copy of the information sent to the Customer is
retained on the Service Provider’s system. This does not mean that the archived
information is accessible on-line by the Customer. The mechanisms for Customer
access to report information stored in the SP’s system as well as the length of the
time for which the information is available are specified in the SLA.

Figure 6-4: Reporting With Acknowledgement
6.1.6 Reporting Via Drop-Off
The second scenario is illustrated in Figure 6-5. This scenario describes the case
where a slower than real time reporting service is used (e.g. e-mail, loading an
HTML file on a Web server, etc.) between the Service Provider and the Customer.
The Customer’s access to the retrieval service and to the data in the “mailbox“ is
not under the Service Provider’s control. i.e., it is provided by a third party. Note
that in some cases the Service Provider could act as the third party.

Figure 6-5: Reporting Via Drop-Off
Figure 6-6: Reporting With Acknowledgement And Optional Logging
6.1.7 Reporting On Demand
The third scenario is illustrated in Figure 6-6. This scenario describes a Service
Provider operated data management service from which the performance reports

can be retrieved. The Customer is provided with access to this data management
service. This access is typically on-line.
After the Customer acknowledges receipt of the requested reports, these reports
are deleted from the Service Provider’s data management service.
6.1.8 Changing The Reporting Mode
The fourth scenario is illustrated in Figure 6-7. In this scenario a Customer

changes the Performance Reporting mode. The specific change made in the
example is to the reporting interval.
Figure 6-7: On-line Performance Reporting Control
State Model
This section contains the Performance Reporting process state model.

Performance Reporting is a periodic activity which collects data during each
reporting cycle. It then generates customer reports that typically include a
summary of any SLA violations that have occurred.
A performance report can be visualized as a dynamic object which is constructed

from data collected during the reporting period and transferred from the Service
Provider to the Customer on a scheduled basis. Once the receipt of a specific
report is acknowledged, it can be archived by the Service Provider. Typically data
collection for the next performance reporting period starts before the report for the

just completed period is compiled and made available to the Customer. There is,
therefore, a need for two reporting processes to be active for a relatively short time
interval. Figure 6-8 provides a high level view of the reporting process state
model.
Figure 6-8: Performance Reporting Process State Model
6.1.9 Events And State Transitions
The following table shows the relationship between Performance Reporting Events
and the states for the Performance Reporting Process.
Table 6-2: Performance Reporting Events And States
Event State

Table 6-2: Performance Reporting Events And States
Event State
A new service is activated The initialization state is entered. The

that requires the generation Performance Report is formatted, and links
of Performance Reports for a are established for accessing the required
Customer. data.
Initialization complete. The process exits the initialization state and

enters the logging state. In this state data is
received and accumulated.
Performance Reporting The process exits the logging state and

Period ends. enters the report compiling state. Final
calculations are completed.
Report compilation The process exits the compiling state and

complete. enters the report transfer state. A copy of the
report is repeatedly sent to the customer until
a successful transfer occurs or the number of
transfer attempts limit is exceeded.
Report successfully The process exits the transfer state and

transferred. enters the awaiting reply state. The process
remains in this state until a successful reply is
received or the reply timer is exceeded.
Reply received. The process for this report ends.
Reporting Intervals
There are a number of different time intervals associated with the performance
reporting process. The following sections define these intervals.
6.1.10 Measurement Interval
A Measurement Interval refers to the time interval in which a parameter is

measured in the network. For example, a parameter may be the number of errored
seconds that occurred over a fifteen-minute measurement interval. Common
measurement intervals are 15 minutes and 24 hours.

6.1.11 Data Collection Interval
A Data Collection Interval refers to the frequency with which performance statistics
(parameter values) are retrieved from network equipment. For example data may
be collected on a weekly, biweekly, or monthly basis. This interval does not have
to be the same as the measurement interval because network devices typically
provide a data storage capability. In any case, the data collection interval must
contain a discrete number of measurement intervals.
6.1.12 Aggregate Interval
An Aggregate Interval is the time interval over which the raw data is summarized in
a particular report. For example, raw 15-minute data may be aggregated into one-
hour or one-day periods for reporting purposes. The data aggregation period must
contain a discrete number of measurement intervals or data collection intervals.
6.1.13 Example
A Frame Relay network measures traffic statistics and stores them in 15-minute
intervals. A statistics collection process retrieves this data once a day. Once a
calendar quarter, the Service Provider delivers three reports to the Customer
based on this data. Each report covers one month of traffic data summarized by
day.
In this example, the measurement interval is 15 minutes, the data collection

interval is 24 hours, the aggregate interval is one day, the reporting period is one
month, and the reporting frequency is quarterly.
Types Of Reports
Basically, Performance Reporting provides two types of reports. These are the
LoS/QoS reports and the Traffic Data/Utilization reports.
The LoS/QoS reports provide overall assessment of service levels and service
quality as specified by the SLA parameters. The Traffic Data report provides usage
measurement information for the service.
The following basic Information is provided in text, graphs and/or tables format.
1) Summary information,
2) Trends,
3) Exceptions,
4) Comparisons,
5) Snapshots.

Common Report Formats
All reports should have a common report header providing the following
information:
1) Customer Information
a) Customer Name, e.g., name of the entity on the billing record,
b) Customer ID, an internally assigned identifier for the Customer,
c) Customer Contact Name, i.e., name of the Customer contact for
performance reporting matters the contact’s organizational unit,
d) Customer Contact Information, e.g., address, phone numbers, e-mail,
etc. for the Customer contact person.
2) Service Provider Information
a) Service Provider Name, e.g., name of the Service Provider for the
specific service,
b) Service Provider Contact Name, e.g., the contact person or
organization of the Service Provider for the specific service,
c) Service Provider Contact Information, e.g., address, phone
numbers, e-mail, etc. for the Service Provider contact person.
3) Service Information
a) Service Identifier, a unique identifier for a Customer service. This
identifier is a key to request performance data and outage
information,
b) Service Type Code, an enumerated code which identifies a service
type, e.g., FR PVC, CR PVC, DS-1, E-1, etc.,
c) Service Descriptions ID, an identifier which points to a textual
description of the service,
d) Service Profile Descriptions, e.g., descriptions of configuration
parameters and corresponding values,
e) SAP Information, e.g., SAP’s address, SAP’s weighting, etc.
4) Report Information
a) Report Type, LoS/QoS report or Traffic Data report,
b) Reporting Period, start and end time of the reported interval,
c) Boundary Conditions, e.g., information on addressed boundary
conditions, e.g., where outages cross reporting interval boundaries,
d) Suspect Flag, the flag is set if the report is suspected to contain
unreliable or incomplete data.

Performance Report Content
LoS/QoS reports will contain:

1) Contracted/guaranteed SLA value(s), e.g., SA%, Bit Error Ratio, Cell Loss
Ratio, etc.,
2) Service Independent (operational criteria) measurements,
3) Service Dependent measurements,
4) Technology Dependent measures.
6.1.14 Service-Independent Measurements
As outlined earlier, a key performance parameter is Service Availability. Further

service-independent measurements could include:
1) Total number of SAP outage intervals,
2) Time to Restore for a specific SAP,
3) Exceeding Committed Time-to-Restore: if the SLA specifies a Committed
Time-to-Restore value for any outage, this measurement provides a
percentage of outages where service was not restored within the
committed time,
4) Mean Time to Restore for a specific SAP/SAP Group,
5) Mean Time Between Failures for a specific SAP/SAP Group.
This list should be seen as informative only. It is outside the scope of this
document to standardize the above-mentioned parameters in the Customer to
Service Provider SLA. However, by using the proposed Service Availability
calculation formula in Section 0, Service Providers will have all information
available to perform the respective calculations.
Traffic Data Report Content
Traffic Data Reports enable Customers to determine how the contracted services
are being used. This allows the Customer and the Service Provider to plan for
future services based on traffic patterns and to verify if they are over/under using
the services they are currently subscribing to. Typical services for which traffic
reports can be provided include:
1) Leased Line Service,
2) ATM Cell Relay PVC Service,
3) Frame Relay PVC Service,
4) IP Service.

7 Relationship To TMF Initiatives
NGOSS
SLAs and the supporting tool fall in the Business View quadrant of the NGOSS
framework shown below, defining the business need for Service Measurement.
Figure 7-1 NGOSS Framework
eTOM
Figure 7-2 is based on the TM Forum eTOM and shows the processes involved in
defining the various types of SLAs and relating them to the organizational functions
that typically own them; Customer / Marketing and Operations.

S/P
Operation’s Domain S/P SLA SLA Perf. Data
Objectives
Supply Chain Supply Chain S/P S/P
Capability Dev & Change Performance SLA
Mgmnt Mgmnt Management Management
KQI / KPI
SLA Reqs Mapping etc S/P
SLA Data
Requirements
Target Target Target Actual
Product KQIs Service KPIs Data Resource Service
Product Resource Data
Dev. & Dev. & Data Quality
Offer Dev.
Retirement Retirement Collection Analysis & Rpt
Actual
SLA KQIs &
Templates
SLAs Customer
Order QoS/SLA
Violations
Handling Mgmnt
Customer / Marketing Domain
Manage
Internal SLA
Figure 7-2 Simplified eTOM Process Flow
The following text provides a summary of the derivation and application of service
based measurements based on the eTOM process framework version 3.
It should be noted that in the latest version of eTOM, version 3.0, an additional
Level 2 process Resource Quality Analysis Action & Reporting has been added.
As the eTOM team will further elaborate on the significance of this new process,
we will update the WSMT methodology mapping in future releases of this
document.
The flow of service data shown in this section is based on a hierarchy of key
indicators as described above across the end to end process starting from the
product development process through to managing the Service Level Agreements
associated with the offering. As indicated in the figure below, there are three
distinct types of SLA:
Customer SLAs
• aimed at the total product offering to the customer and are usually
subject to a formal contract between the customer and the
operator.
• written in terms that the customer understands and based on the
end to end delivery of the product components.
Supplier Partner SLAs
• placed to ensure that the performance objectives are met for

service components tat are provided by a third party.
• derived from or form part of the contractual agreement between the
supplier / partner and the operator.

Internal SLAs
• aimed at service elements or groups of service elements

• subject to agreements between organisational functions within the
operators’ business
It is important to recognize that the flow is product rather than service driven as it is
products, rather than services, that are offered to the end customer.
Fundamental to the process flow is the fact that the SLA and the component
clauses and requirements are designed at the very beginning of the product and
service design i.e. within the Product Offer process. These SLA requirements then
form part of the design requirements for the product development process and
onwards as KQIs and KPIs into the service and resource development process.
Thus Customer Perceived Quality criteria are traceable throughout the
development processes or in other words ‘quality is designed in’. Additionally the
recommended process flow encompasses the quality objectives for third party
service delivery components and the thus defines the SLA with the partner /
supplier. The top down process flow also enables the operator to define internal
SLAs (or SLOs) against the internal business functions responsible for managing
the service components within the operators business and that these quality
objectives reflect the SLA clauses that are offered to the end user.
A detailed mapping is included in Annex .K.
SID
The Shared Information Data Model (SID) underpins the NGOSS framework by
defining the data entities and relationships used by the business. Figure 7-3
illustrates the main areas where interaction with the SID team has focused.

1..*
Customer
Commercial
Contract
Offer
Defines
Uses
(P)KQI
Defines
SLA
Uses
Uses
Product
SLA Defines
Template
Uses
Defines
Uses
(S)KQI
Defines
Service
Defines
Uses
Service
Defines Element
KPI
Defines
Service
Resource
Figure 7-3 Key Service Measurement Entities

References
[E.106] Description Of An International Emergency Preference Scheme (IEPS), ITU-T

Recommendation E.106, Geneva, March 2000.
[E.490.1] Overview Of Recommendations On Traffic Engineering, ITU-T

Recommendation E.490.1, Geneva, January 2003.
[E.600] Terms And Definitions Of Traffic Engineering, ITU-T Recommendation E.600,

Geneva, March 1993.
[E.800] Terms And Definitions Related To Quality Of Service And Network

Performance Including Dependability, ITU-T Recommendation E.800, Geneva,
August 1994.
[E.801] Framework For Service Quality Agreement, ITU-T Recommendation E.801,

Geneva, October 1996.
[E.860] Framework For A Service Level Agreement, ITU-T Recommendation E.860,

Geneva, June 2002.
[FRF.13] Service Level Definitions Implementation Agreement, FRF.13, Frame Relay

Forum Technical Committee, Freemont, CA, August 1998.
[G.803] Architecture Of Transport Networks Based On The Synchronous Digital

Hierarchy (SDH), ITU-T Recommendation G.803, Geneva, March 2000.
[G.805] Generic Functional Architecture Of Transport Networks, ITU-T

Recommendation G.805, Geneva, March 2000.
[G.872] Architecture Of Optical Transport Networks, ITU-T Recommendation G.872,

Geneva, November 2001.
[GB 910] Telecom Operations Map, GB 910, Approved Version 2.1, TeleManagement
Forum, Morristown, NJ, March 2000.
[GB 917-1] SLA Management Handbook - Executive Overview, Member Reviewed Version
2, TeleManagement Forum, Morristown, NJ, January 2005.
[GB 917-3] SLA Management Handbook - Service and Technology Examples, Member
Reviewed Version 2, TeleManagement Forum, Morristown, NJ, January 2005.
[GB 917-4] SLA Management Handbook – Enterprise and Applications, The Open Group,
2004.

[GB 921] enhanced Telecom Operations Map, GB921, Approved Version 3.0,
TeleManagement Forum, Morristown, NJ, June 2002.
[GB 923] Wireless Service Measurements Handbook, Approved Version 3.0,

TeleManagement Forum, Morristown, NJ, March 2004.
[GETS] Government Emergency Telecommunications Service (GETS) Program,

www.ncs.gov/n2/default.htm.
[I.326] Functional Architecture Of Transport Networks Based On ATM, ITU-T

Recommendation I.326, Geneva, March 2003.
[I.350] General Aspects Of Quality Of Service And Network Performance In Digital

Networks, Including ISDNs, ITU-T Recommendation I.350, Geneva, March
1993.
[I.371] Traffic Control And Congestion Control In B-ISDN, ITU-T Recommendation

I.371, Geneva, March 2000.
[ITU-Hbk] Handbook on Quality of Service and Network Performance, ITU-T, Geneva,

1984, revised 1993.
[M.60] Maintenance Terminology and Definitions, ITU-T Recommendation M.60,

Geneva, March 1993.
[M.1535] Principles For Maintenance Information To Be Exchanged At Customer Contact

Point (MICC), ITU-T Recommendation M.1535, Geneva, May 1996.
[M.2140] Transport Network Event Correlation, ITU-T Recommendation M.2140,

Geneva, February 2000.
[M.3010] Principles For A Telecommunications Management Network, ITU-T

Recommendation M.3010, Geneva, February 2000.
[M.3013] Considerations For A Telecommunications Management Network, ITU-T

Recommendation M.3013, Geneva, February 2000.
[NMF 503] Service Provider To Customer Performance Reporting Business Agreement,

NMF 503, Issue 1.0, TeleManagement Forum, Morristown, NJ, March 1997.
[P806] Project P806, Deliverable 1, The EQoS Framework – Version 2, EURESCOM,

September 1999.
[T1.631] Signalling System No 7 (SS7) – High Probability Of Completion (HPC) Network

Capacity, T1.631, ANSI.
[TMF 044] TM Forum Glossary, TMF 044, Public Version, Version 0.2, March, 2003.
[TMF 506] Service Quality Management Business Agreement, TMF 506, Evaluation
Version Issue 1.5, TeleManagement Forum, Morristown, NJ, May 2001.

[TMF 701] Performance Reporting Concepts & Definitions Document, TMF 701, Version
2.0, TeleManagement Forum, Morristown, NJ, November 2001.
[TR-79] Overview Of Standards In Support Of Emergency Telecommunications Service

(ETS), T1.TR.79-2003, Alliance For Telecommunications Industry Solutions,
2003.
[WP-SLA] White Paper on Service Level Agreements, Best Practices Committee,

Application Service Provider Industry Consortium, 2000.
[X.641] Information Technology – Quality Of Service: Framework, ITU-T

Recommendation X.641 Geneva, December 1997.
[X.642] Information Technology – Quality Of Service – Guide To Methods And

Mechanism. ITU-T Recommendation X.641 Geneva, Sepember1998
[Y.1271] Framework(s) On Network Requirements And Capabilities To Support

Emergency Communications Over Evolving Circuit-Switched And Packet-
Switched Networks, ITU-T Recommendation Y.1271 Geneva, October 2004.

Acronyms
2G 2nd Generation
3G 3rd Generation
3GPP Third Generation Partnership Project
ABR Available Bit Rate
ABT ATM Block Transfer
ACA Australian Communications Authority
AIP Application Infrastructure Provider
ANSI American National Standards Institute
ANT Access Network Transport
API Application Programming Interface
ARPU Average Revenue Per User
ASP Application Service Provider
ASPIC Application Service Provider Industry Consortium
ASR Answer/Seize Ratio
ATC ATM Transfer Capability
ATIS Alliance for Telecommunications Industry Solutions
ATM Asynchronous Transfer Mode
BBE Background Block Error
BBER Background Block Error Ratio
BER Bit Error Ratio
BICC Bearer-Independent Call Control
B-ISDN Broadband Integrated Services Digital Network
CATV Cable Television (Community Antenna Television)
CBR Constant Bit Rate
CCR Call Completion Record
CD Cell Delay
CDR Call Data Record
CDV Cell Delay Variation
CDVT Cell Delay Variation Tolerance
CE Cell Error
CEM Customer Experience Management

CER Cell Error Ratio

CIM Common Information Model
CIR Committed Information Rate
CL Cell Loss
CLI Calling Line Identifier
CLR Cell Loss Ratio
CM Cell Misinsertion
CMR Cell Misinsertion Ratio
CN Core Network
CNM Customer Network Management
COPS Common Open Policy Service
CPE Customer Premises Equipment
CPoF Common Point of Failure
CTD Cell Transfer Delay
DBR Deterministic Bit Rate
DCE Data Circuit-Terminating Equipment
DiffServ Differentiated Services
DLCI Data Link Connection Identifier
DMTF Distributed Management Task Force
DNS Domain Naming Service
DPL Degraded Performance Limit
DS Differentiated Services
DSCP DiffServ Code Point
DSL Digital Subscriber Line
DSS Digital Subscriber SIgnalling System
DTE Data Terminating (Termination) Equipment
ECBP End-to-end Connection Blocking Probability
EDC Error Detection Code
EDGE Enhanced Data rates for GSM Evolution
EFS Error Free Seconds
EQoS EURESCOM Quality of Service
ES Errored Second
ESR Errored Second Ratio
eTOM enhanced Telecom Operations Map
ETSI European Telecommunications Standards Institute
EURESC European Institute for Research and Strategic Studies in Telecommunications

OM
FDD Frequency Division Duplex
FR Frame Relay
FRAD Frame Relay Access Device
FSA Framework Study Area
FTD Frame Transfer Delay
FTP File Transfer Protocol
G-CDR Gateway GPRS Support Node – Call Detail Record
GERAN GSM/EDGE Radio Access Network
GFR Guaranteed Frame Rate
GGSN GPRS Gateway Support Node
GII Global Information Infrastructure
GoS Grade of Service
GPRS General Packet Radio Service
GPRS General Packet Radio Service
GSM Global System for Mobile communication
HCPN Hybrid Circuit-switched/Packet-based Network
HTTP Hyper Text Transfer Protocol
IAB Internet Architecture Board
ICSP Information And Communications Service Provider
IESG Internet Engineering Steering Group
IETF Internet Engineering Task Force
IMT International Mobile Telecommunications
IMT-2000 International Mobile Telecommunications-2000
IN Intelligent Network
INMD In-service Non-intrusive Measuring Device
IntServ Integrated Services
IOPS.OR Internet Operators Group
G
IP Internet Protocol
IPDV IP Packet Delay Variation
IPER IP Packet Error Ratio
IPLR IP Packet Loss Ratio
IPPM IP Performance Metrics
IPTD IP Packet Transfer Delay
IRTF Internet Research Task Force

ISDN Integrated Services Digital Network

ISM In-Service Monitoring
ISO International Organization for Standardization
ISP Internet Service Provider
IST Information Society Technologies
ISV Independent Software Vendor
IT Information Technology
ITAA Information Technology Association of America
ITU-R International Telecommunication Union – Radiocommunication Sector
ITU-T International Telecommunication Union – Telecommunication Standardization
Sector
KPI Key Performance Indication
KQI Key Quality Indication
LAN Local Area Network
LDP Label Distribution Protocol
LSR Label Switching Router
MBS Maximum Burst Size
MCR Mean Cell Rate
MIB Management Information Base
MOS Mean Opinion Score
MPEG Moving Picture Coding Experts Group
MPLS Multiprotocol Label Switching
MTBF Mean Time Between Failures
MTBO Mean Time Between Outages
MTIE Maximum Time Interval Error
MTPS Mean Time to Provide Service
MTRS Mean Time to Restore Service
MTTP Mean Time to Provision
MTTR Mean Time To Repair
MVNO Mobile Virtual Network Operator
NAP Network Access Point
NER Network Effectiveness Ratio
NGN Next Generation Network
NGOSS New Generation Operations Systems and Software
NII National Information Infrastructure
N-ISDN Narrow band Integrated Services Digital Network

NM Network Management
NMC Network Management Centre
NMDG Network Measurement Development Group
NMF Network Management Forum
NNI Network-Node Interface
NO Network Operator
NOC Network Operations Centre
NP Network Performance
NP&D Network Planning and Development
NPC Network Parameter Control
NSP Network Service Provider
NTE Network Terminating Equipment (Element)
OAM Operations, Administration, and Maintenance
Oftel Office of Telecommunications (British)
OI Outage Intensity
ONP Open Network Provision
OS Operations System
OSI Open Systems Interconnection
OSS Operational Support System
OSS Operations Support System
OTN Optical Transport Network
PC Personal Computer
PCR Peak Cell Rate
PDA Personal Digital Assistant
PDH Plesiochronous Digital Hierarchy
PDN Public Data Network
PDN Public Data Network
PDP Packet Data Protocol
PDU Protocol Data Unit
PEI Peak Emission Interval
PHB Per Hop Behavior
PIB Policy Information Base
PIN Personal Identification Number
PIR Peak Information Rate
PLM Product Line Management
PNO Public Network Operator

POH Path OverHead

POP Point Of Presence
POTS Plain Old Telephone System
PPA Planning, Provisioning, And Administration
PRM Performance Report Message
PS Packet Switched
PSTN Public Switched Telephone Network
PVC Permanent Virtual Circuit
QoS Quality of Service
QOSF Quality of Service Forum
QSDG Quality of Service Development Group
RAN Radio Access Network
RFC Request for Comments
RFI Request for Information
RFP Request for Proposal
RFSD Ready For Service Date
RSVP Resource Reservation Protocol
SA Service Availability
SAP Service Access Point
SBR Statistical Bit Rate
S-CDR Serving GPRS Support Node – Call Detail Record
SCR Sustainable Cell Rate
SDH Synchronous Digital Hierarchy
SDP Service Delivery Point
SE Service Element
SECB Severely Errored Cell Block
SECBR Severely Errored Cell Block Ratio
SEP Severely Errored Period
SEPI Severely Errored Period Intensity
SES Severely Errored Second
SESR Severely Errored Second Ratio
SGSN Serving GPRS Support Node
SID Shared Information and Data
SLA Service Level Agreement
SLO Service Level Objective
SLS Service Level Specification

SLSU Service Level Specification and Usage

SMI Structure of Management Information
SMS Short Message Service
SOC Service Operations Centre
SOHO Small Office Home Office
SONET Synchronous Optical Network
SP Service Provider
SP&D Service Planning and Development
SQM Service Quality Management
SVC Switched Virtual Circuit
TCA Traffic Conditioning Agreement
TCP Transmission Control Protocol
TDD Time Division Duplex
TDM Time-Division Multiplexing
TEWG Traffic Engineering Working Group
TFT Traffic Flow Template
TIE Time Interval Error
TIPHON Telecommunications and Internet Protocol Harmonization over Networks
TMF TeleManagement Forum
TMN Telecommunications Management Network
TOM Telecom Operations Map
TSAG Telecommunication Standardization Advisory Group
TSP Telecom Service Provider
TT Trouble Ticket
TV Television
UAS Unavailable Seconds
UBR Unspecified Bit Rate
UMTS Universal Mobile Telecommunications System
UNI User-Network Interface
UPC User Parameter Control
UPL Unacceptable Performance Limit
UTC Universal Time, Coordinated
UTRA UMTS Terrestrial Radio Access
VAR Value Added Reseller
VC Virtual Circuit
VCI Virtual Circuit Identifier

VOD Video On Demand

VoIP Voice over IP
VPI Virtual Path Identifier
VPN Virtual Private Network
WAN Wide Area Network
WAP Wireless Access Protocol
WAP Wireless Access Protocol
WSMT Wireless Service Measurement Team
WTSA World Telecommunications Standardization Assembly
XIWT Cross-Industry Working Team
XML Extensible Markup Language

Annex A - Terms and Definitions
Terms and definitions used in this Handbook are mainly based on the TM Forum
Glossary [TMF 044], on the Performance Reporting Concepts and Definitions
Document [TMF 701], and on internationally agreed definitions published by the
ITU. For example, ITU-T Recommendation M.60 [M.60] contains Maintenance
Terminology and Definitions. In this chapter, only some key terms related to SLAs,
QoS and performance are defined and their source identified. For the purposes of
this Handbook, some definitions have been modified and/or extended. Where
multiple definitions are in use within the industry, all are given. Not all of the terms
and definitions in this Annex are necessarily used in this volume of the Handbook
but are included as they are used in other volumes or are expected to be relevant
in later versions of the Handbook series11. For further information, please consult
the previously referenced documents and the ITU-T’s Sector Abbreviations and
defiNitions for a teleCommunications tHesaurus Oriented (SANCHO) database at
http://www.itu.int/sancho/index.asp.
Active (condition) – condition (e.g. alarm) not cleared (ITU-T Rec. M.2140).
*Administration (task) – a broad group of functions that sustain

telecommunication services once they have been established. Administration
generally consists of network administration and service administration. Network
administration ensures that the network is used efficiently and that Grade of
Service (GoS) objectives are met. Service administration includes such diverse
support functions as billing, collecting, and switching service evaluation (ITU-T
Rec. M.3010).
Administrative Domain – a collection of systems and sub-networks operated by

a single organization or administrative authority. It may be subdivided into a
number of routing domains (ITU-T Rec. X.400).
*Aggregate Interval – the time period over which raw data is summarized in a
particular report. For example, raw 15-minute data may be aggregated into one-
hour or 24-hour intervals for reporting purposes (TMF 701 modified).
Alarm – an alerting indication of a condition that may have immediate or potential

negative impact on the state of service resources, e.g., network element,
application, system, etc. (ITU-T Rec. M.3010 modified).
*Alarm Surveillance – a set of TMN management functions which provide, in

near real-time, detection and indication of failures (ITU-T Rec. M.3010).
11
Terms and definitions not yet used are marked with a *.

*Anomaly – a discrepancy between the actual and desired characteristic of an

item. The desired characteristic may be expressed in the form of a specification.
An anomaly may or may not affect the ability of an item to perform a required
function (ITU-T Rec. M.20).
Availability Performance – the ability of an item to be in the state to perform a

required function at a given instant of time or at any instant of time within a given
time interval, assuming that the external resources, if required, are provided. Note
that this ability depends on the combined aspects of the reliability performance, the
maintainability performance and the maintenance support performance of an item.
In the definition of the item, the external resources required must be delineated.
The term availability is used as an availability performance measure (ITU-T Rec.
M.60).
Bearer Service – a type of telecommunication service that provides the capability

for the transmission of signals between user-network interfaces (ITU-T Rec. I.112).
Clear – the end of a fault; the termination of a standing condition (ITU-T Rec.
M.2140).
Connection – an association of transmission channels, circuits or flows, switching

and other functional units set up to provide a means for a transfer of information
between two or more points in a telecommunication network (ITU-T Rec. Q.9
modified).
*Connection Quality – the collective effect of service performance, which

determines the degree of satisfaction of a user with the particular connection (ITU-
T Rec. M.3010).
Commercial Offer - Commercial Offers are sold to customers. They are the
marketing mix and consist of, the product, pricing, the contract, the SLA etc.
Customer – a Customer is an entity which receives services offered by a Service

Provider based on a contractual relationship. It may include the role of a network
user (ITU-T Rec. M.3010).
The term Customer refers to companies or organizations that make use of

telecommunication services provided by a Service Provider. The Customer is the
ultimate buyer of a network service, but the end user may or may not be the one
who pays for the service (TMF 701 modified).
Customer Contact Point – a physical or conceptual point at which a Service

Provider can interact with any Customer of the offered service for the purpose of
maintaining communication services (TMF 701 modified).
Customer Details – information about the Customer, sometimes called Customer

profile.
Customer Premises Equipment (CPE) – any network equipment sited at the

Customer’s premises used to provide the contracted service. Note that the CPE

may be owned and operated by the Customer or the Service Provider (extracted
from TMF 701).
Customer SLA Performance Data – correlation of the service quality and

performance data against specific Customer service instances to provide specific
performance data against individual service instances and SLAs.
Customer to Service Provider Interface – the boundary of information exchange

between the Customer (whether end Customer or another Service
Provider/Network Operator) and their Service Provider (TMF 701 modified).
*Data Collection Interval – the period over which performance parameters are
accumulated to compute each stored measurement and to detect maintenance
threshold crossings (ITU-T Rec. M.2140).
The time interval when statistics are retrieved from the network. This interval does
not have to be the same as the measurement interval because the network
devices may buffer statistics so that a number of them may be collected later (TMF
701).
Defect – a defect is a limited interruption of the ability of an item to perform a

required function. It may or may not lead to a maintenance action depending on
the results of additional analysis (ITU-T Rec. M.20).
Degradation – the presence of anomalies or defects in the absence of a fault

(ITU-T Rec. M.2140).
Degraded Service – the presence of anomalies or defects that cause a

degradation in QoS, but do not result in total failure of the service.
Emergency Telecommunications Service - An explicit service available to

authorized users that provides priority access to and preferential use of
communications resources during periods of extreme service overload.
Event – an instantaneous occurrence that changes the global status of an object.

This status change may be persistent or temporary, allowing for surveillance,
monitoring, and performance measurement functionality, etc. Events may or may
not generate reports; they may be spontaneous or planned; they may trigger other
events or may be triggered by one or more other events (ITU-T Rec. X.700).
*Event Correlation Process – a process that accepts events as input, performs

one or more event correlation sub-processes, and reports events as output (ITU-T
Rec. M.2140).
*Event Correlation Sub-process – a single step in an event correlation process

*Event Report Message – a message sent from one physical system to another
that contains information about an event (ITU-T Rec. M.2140).

*Event Set – the set of all events that are grouped by a selection process for direct
comparison or patterning (ITU-T Rec. M.2140).
Failure – the termination of the ability of an item to perform a required function.

Note that after a failure the item has a fault (ITU-T Rec. M.20).
Fault – the inability of an item to perform a required function, excluding that

inability due to preventive maintenance, lack of external resources or planned
actions. Note that a fault is often the result of a failure of the item itself, but may
exist without prior failure (ITU-T Rec. M.20).
*Fault Management (FM) – a set of TMN management functions which enable

the detection and localization of faults, the scheduling of repairs, and the testing
out and return to service of repaired equipment (ITU-T Rec. M.3010).
Grade of Service (GoS) – the designed service quality, also known as

guaranteed QoS, used as a comparison with delivered (measured) QoS. A
Service Provider commits a particular GoS to their Customers and the QoS is a
measurement of what was actually delivered (TMF 701 modified).
An alternative definition is offered below based on ITU-T Study Group 2 work.
GoS is the minimum level of service quality designed into the network supporting
the service and maintained by traffic planning and engineering management
actions depending on traffic densities over the duration the service is offered or
used. As such, GoS represents a guaranteed expected level of service quality for
any connection in the same QoS class of a specified service at any instant, and
may in fact be improved upon depending on traffic loading of the network.
*Impairment – a condition that causes anomalies or defects without causing a

failure (degrades the performance of a resource without causing a failure) (ITU-T
Rec. M.2140).
Indication – an intermediate output of the event correlation process. A notification,

indicating a persistent network, application or system-detected trouble condition.
The three types of indication are fault indication, impairment indication, and trend
indication (ITU-T Rec. M.2140 modified).
*Independent Event – an event that is not currently superceded by another event

Key Performance Indicators - Key Performance Indicators provide a

measurement of a specific aspect of the performance of a service resource
(network or non-network) or group of service resources of the same type. A KPI is
restricted to a specific resource type.
Key Quality Indicators - provide a measurement of a specific aspect of the

performance of the product, product components (services) or service elements
and draw their data from a number of sources including the KPIs.

Mean Time Between Failures (MTBF) – the average time between failures of the
service.
Mean Time Between Outages (MTBO) – the average time between outages of
the service.
Mean Time to Provide Service (MTPS) – the average time to actually provide a
specified service from the date of signing a contract to provide service. This may or
may not be specified in the SLA.
Mean Time To Repair (MTTR) – the average time to repair service resources.
Mean Time to Restore Service (MTRS) – the average time to restore service
after reporting a fault; this time includes the time to sectionalize and locate the
fault. This may or may not be specified in the SLA.
Measurement Interval – the time interval over which each performance

parameter is measured. For example, a parameter may be the number of errored
seconds which occurred over a fifteen minute measurement interval (TMF 701
modified).
Network Operator (NO)/Provider – a company or organization which operates

and provides telecommunication network paths and connections as a business.
These may be direct to end Customers (in which case the NO is also a Service
Provider) or under contract to Service Providers who in turn provide services to
end Customers.
Network Performance (NP) – the ability of a network or network portion to

provide the functions related to communications between users. Note that NP
applies to the Network Provider’s planning, development, operations and
maintenance and is the detailed technical part of QoS, excluding service support
performance and human factors. NP is the main influence on serveability
performance. NP measures are meaningful to Network Providers and are
quantifiable at the part of the network to which they apply. QoS measures are only
quantifiable at a Service Access Point (SAP) (ITU-T Rec. E.800).
Notification – information emitted by a managed object relating to an event that

has occurred within the managed object; information passed from one
Management Application Function (MAF) to another regarding an event (ITU-T
Rec. X.710 and M.3010).
Operations – these include the operation of work centers, technical support

centers, support systems, test equipment, methods and procedures, as well as the
personnel and training required to install and maintain all the elements that
constitute the network capability underlying the relevant services (ITU-T Rec.
M.3010).
Offer - An offer is an aggregation or bundling of Products or Services for sale to a

Customer.

*Operations System – the OS is the stand-alone system which performs

Operations Systems Functions (OSFs). For operational purposes, the
management functionality may be considered to be partitioned into layers, such as
network element management layer, network layer, service layer and business
layer (ITU-T Rec. M.3010).
Partner - A Partner has a stronger profit and risk-sharing component in their

Business Agreement with the Enterprise, than a Supplier would have. A Partner
generally is more visible to the Enterprise's customer than a Supplier would be. A
partner might be part of an alliance, a joint service offering, etc.
Performance Management (PM) – a set of TMN management functions which

enable the performance (i.e. the ability to reproduce the signal) of the network
services to be measured and corrective actions to be taken (ITU-T Rec. M.3010).
Performance Report – a statement of performance achieved over a given

measurement interval and made available to the Customer by a variety of
methods. These include printed or electronic reports provided on a regular basis,
stored reports in a database accessible by the Customer or on-demand reports.
Two basic types of reports are normally available – QoS performance against SLA
guaranteed values and traffic data/utilization reports (extracted from TMF 701).
Product - Product is what an entity (supplier) offers or provides to another entity

(customer). Product may include service, processed material, software or
hardware or any combination thereof. A product may be tangible (e.g. goods) or
intangible (e.g. concepts) or a combination thereof. However, a product ALWAYS
includes a service component.
Quality of Service (QoS) – the collective effect of service performances which

determine the degree of satisfaction of a user of the service. Note that the quality
of service is characterized by the combined aspects of service support
performance, service operability performance, service integrity and other factors
specific to each service (ITU-T Rec. E.800).
Quality of Service Reports – reports generated from the service quality and
performance data to report the performance of the service as a whole.
Raw Performance Data – raw performance data collected from various data
sources including the network and service resources, such as network elements,
network and element management systems, and network and application servers.
In addition, data collected for the SP’s OSSs, such as trouble ticketing, order
processes, maintenance and support, Customer care, etc.
*Ready for Service Date (RFSD) – the specified date in the contract at which the
contracted service is ready for operation.
Reporting Period – the period at which performance reports are generated. It is

defined independently for each SAP Group within the associated SLA (TMF 701).

Resource - Resources represent physical and non-physical components used to

construct Services. They are drawn from the Application, Computing and Network
domains, and include, for example, Network Elements, software, IT systems, and
technology components.
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 software components as well as the underlying communications
medium. The Customer sees all of these components as an amalgamated unit
(TMF 701 modified).
Service Access Point (SAP) – a logical or physical element located on the

interface between a Customer’s domain and the Service Provider’s domain,
representing the point at which a service is delivered. A SAP can be weighted in
accordance with a business-critical factor that is defined in the SLA (TMF 701
modified).
Service Access Point Group – a group of SAPs against which Service

Availability must be reported. Each SAP normally belongs to one (or more than
one) SAP Group and each SAP Group contains at least one SAP. The association
between SAP Groups and SAPs is defined within the associated SLA, according
to the required computation and aggregation format (TMF 701).
Service Availability (SA) – a measure of the fraction of time during a defined

period when the service provided is deemed to be better than a defined QoS
threshold. SA is measured in the context of an SLA between the Customer and the
Service Provider concerned. It is expressed as a percentage (SA%) to indicate the
time during which the contracted service (e.g. SVCs, PVCs, end-to-end circuits
including protocols, applications, etc.) at the respective SAPs is operational.
Operational means that the Customer has the ability to use the service as
specified in the SLA (TMF 701 modified).
Note that the calculation of the SA may include weighting of the SAPs as noted
above. The detailed formula is contained in TMF 701 and ITU-T Rec. M.1539.
*Service Degradation Factor (SDF) – a factor agreed between the Customer and
the Service Provider used to weight the service availability calculation when the
service is still available, but degraded from its contracted QoS (extracted from
(TMF 701).
Service Descriptions - details of the service product catalogue offered by the SP.
Service Element – a service element comprises one or more network or service

resources that are combined with other service elements to provide a service
(TMF 701 modified).
Service Instance – a service that has been instantiated for a Customer.
Service Level Agreement (SLA) – a formal negotiated agreement between two

parties, sometimes called a Service Level Guarantee. It is a contract (or part of

one) that exists between the Service Provider and the Customer, designed to
create a common understanding about services, priorities, responsibilities, etc.
(TMF 701 modified).
An SLA or Contract is a set of appropriate procedures and targets formally or

informally agreed between Network Operators/Service Providers (NOs/SPs) or
between NOs/SPs and Customers, in order to achieve and maintain specified
Quality of Service (QoS) in accordance with ITU (ITU-T and ITU-R)
Recommendations. The SLA may be an integral part of the Contract. These
procedures and targets are related to specific circuit/service availability, error
performance, Ready for Service Date (RFSD), Mean Time Between Failures
(MTBF), Mean Time to Restore Service (MTRS), Mean Time To Repair (MTTR)
Service Level Agreement Contracts – individual-specific SLA contracts between

the SP and the Customer with the specific service details, agreed levels of service
quality, reporting schedules, and details of actions to be taken when the service
quality guarantees are not met.
Service Level Agreement Reports – reports generated from the Customer SLA
quality and performance data to report the performance of the specific service
instance for a specific Customer against an SLA.
Service Level Agreement Templates – definitions of the standard grades of

service which can be offered with an SLA, for example, templates to describe gold
and silver service characteristics.
Service Level Objective - An internal form of an SLA that exists between

functions with a business. An SLO is less formal than an SLA in as much as it is
not supported by a formal contract between the two parties.
Service Provider (SP) – a company or organization that provides

telecommunication services as a business. SPs may operate networks, or they
may simply integrate the services of other providers in order to deliver a total
service to their Customers. Providing a telecommunication service to any one end
Customer may involve multiple SPs, where one provider may “sub-contract” with
other providers to fulfil the Customer’s needs (TMF 701).
Note that the term Service Provider is now being used generically and may include
Telecom Service Providers (TSPs), Internet Service Providers (ISPs), Application
Service Providers (ASPs) and other organizations that provide services, e.g.,
internal IT organizations that need or have SLA capabilities or requirements.
Service QoS and Performance Data – aggregated service quality and

performance data combined from the many disparate raw data sources.
*Service Support Performance – the ability of an organization to provide a

service and assist in its utilization. Note that an example of service support
performance is the ability to provide assistance in commissioning a basic service,

or a supplementary service such as the call waiting service or directory enquiries

service (ITU-T Rec. E.800).
Service Resource - represent physical and non-physical components used to

construct Services. They are drawn from the Application, Computing and Network
domains, and include, for example, Network Elements, software, IT.
*Standing Condition – a condition that has duration, beginning with a failure and
ending with a clear (ITU-T Rec. M.2140).
Subscriber - The Subscriber is responsible for concluding contracts for the

services subscribed to and for paying for these services.
Supplier - Suppliers interact with the Enterprise in providing goods and services,
which are assembled by the Enterprise in order to deliver its products and services
to the Customer.
Supply Chain - ’Supply Chain’ refers to entities and processes (external to the
Enterprise) that are used to supply goods and services needed to deliver products
and services to customers
Telecommunications Management Network (TMN) – a TMN provides the

means used to transport and process information related to management of the
telecommunication network (ITU-T Rec. M.3010).
Telecommunication Service – that which is offered by a Service Provider to its

Customers in order to satisfy a specific telecommunication requirement. Note that
bearer services and teleservices are types of telecommunication service. Other
types of telecommunication service may be identified in the future (ITU-T Rec.
I.112 modified).
*Threshold Crossing Alert – a transient condition declared when a performance

monitoring parameter reaches or exceeds a preset threshold (ITU-T Rec. M.2140).
*Thresholding – a process which is involved in decision making and which

compares the actual value of a parameter with a predetermined value to decide
whether an alarm action needs to be initiated (ITU-T Rec. M.3010).
Third Party Service Provider - The Third Party Service Provider provides
services to the Enterprise for integration or bundling as an offer from the enterprise
to the Customer. Third party service providers are part of an enterprise’s
seamless offer. In contrast, a complementary service provider is visible in the offer
to the enterprise’s customer, including having customer interaction.
Time to First Yield – the time interval between initiating service and the first
reportable service-impacting event.
Transient Condition – a condition that has no duration, a one-time report (ITU-T

Rec. M.2140).

Trouble – the perception of a fault or degradation that is judged to require

maintenance attention (ITU-T Rec. M.2140).
User – a person or a machine delegated by a Customer to use the services and/or

facilities of a telecommunication network or service offering. (ITU-T Rec. I.112
modified).
Value Chain - An arrangement of business relationships and agreements

between market players that are co-operating to deliver an end to end service and
products to a end customer.
Value Network - The enterprise as the hub a value network is a key concept of e-
business. The value network is the collaboration of the enterprise, its suppliers,
complementors and intermediaries with the customer to deliver value to the
customer and provide benefit to all the players in the value network. e-Business
success and, therefore part of the definition of a value network, is that the value
network works almost as a vertically integrated organization to serve the customer.
Vendor - Synonymous with Supplier

Annex B - Executive Summary For Volume 1
Demonstrably in the modern business world e-business has either a direct or indirect impact on all
business enterprises. More and more companies are increasingly dependent on
telecommunication services as a core component of business strategy. The quality of
telecommunication services is therefore rapidly becoming a significant factor in the success or
failure of businesses, particularly with regard to availability and reliability. It is the Service Level
Agreement (SLA) that defines the availability, reliability and performance quality of delivered
telecommunication services and networks to ensure the right information gets to the right person
in the right location at the right time, safely and securely. The rapid evolution of the
telecommunications market is leading to the introduction of new services and new networking
technologies in ever-shorter time scales. SLAs are tools that help support and encourage
Customers to use these new technologies and services as they provide a commitment from SPs
for specified performance levels.
The TM Forum SLA Handbook (GB 917 Version 1.5) was released by the TM Forum in June
2001. The objective of GB 917 was to assist Customers and Telecommunication Service
Providers (SP) with understanding the fundamental issues involved with developing
telecommunication services SLAs and SLA management. GB 917 Version 1.5 incorporates the
concepts within the Performance Reporting Concepts and Definitions Document (TMF 701) and
the Telecommunication SP to Customer Performance Reporting Business Agreement (NMF 503)
documents. These two documents offer a valuable extension to GB 917.
GB 917 Version 1.5 was based on the traditional telecommunications SP to Customer relations
embedded within the International Telecommunication Union (ITU) Telecommunication
Management Network (TMN) Framework model and the TM Forum generated
Telecommunications Operating Model (TOM) functional processes. Since GB 917 Version 1.5
there have been many significant advances within the telecommunications SP industry. There is
now a need to address these recent advances in the context of how telecommunication SP to
Customer relations are managed and the impacts on SLAs and SLA management.
The more important external and internal telecommunication SP advances that have made
significant influential impact and need to be taken into consideration are, inter alia:
• A new breed and types of Service Providers such as, Internet, Application and
Content;
• New services enablers such as Security and Mobility;
• A move towards network centric architectures enabling e-commerce;
• A realization that Enterprise Customer issues need to be given greater consideration

and prominence;

• Increased Enterprise Customer and SP expectations;
• A significant increase in the number of interconnections and interfaces to enable end-

to-end services;
• The need for greater and improved use of automation;
• An awareness of the limitations of SP internal processes such as, improvements to

Operational Support Systems (OSS);
• The need to address deregulation within the telecommunications industry;
• Moves towards a more seamless SP to Customer Service Access Point (SAP) or

Service Delivery Point (SDP).
The main impact of recent telecommunication advances is added complexity to SP-Customer

relations. Added complexity was recognized by the TM Forum in 2001 by acknowledging that the
TOM model lacked sufficient detail to account for recent telecommunication advances and
embarked on a new SP and Customer relation management paradigm. This new management
paradigm has evolved into what is now referred to as the enhanced TOM (eTOM). The eTOM
includes those processes necessary to manage SLAs and Quality of Service (QoS).
The TM Forum SLA/QoS Handbook Team also realized that the first GB 917 SLA Management
Handbook lacks sufficient detail and management processes to cater for the breadth of SLAs
needed within a modernized Telecommunication SP industry. GB 917 Version 1.5 has therefore
been revised to include the SLA management processes necessary to handle recent
telecommunication advances as well as the TMF instigated eTOM.
The revised TM Forum SLA Handbook is designated GB 917 Version 2 and structured as a four
Volume suite. Volumes 1, 2 and 3 focus on telecommunication services SPs, Suppliers and
Customers whereas Volume 4 focuses on Enterprise business applications and associated
telecommunication services. The four volumes are entitled:
• Volume 1 – SLA Management Handbook - Executive Overview;
• Volume 2 – SLA Management Handbook - Concepts and Principles;
• Volume 3 – SLA Management Handbook - Service and Technology Examples;
• Volume 4 – SLA Management Handbook - Enterprise Perspective.
Volume 1 is written for Chief Executive Officers (CEO) and Board of Directors members. It is a
concise introduction to SLA Concepts, Business Case, Benefits, and Consequences for
telecommunication service customers, SPs, and hardware and software suppliers. Volume 1 also
addresses where SLAs reside within the modern market place.
Volume 2 is written for the telecommunication and supplier managers. It provides the detail behind
SLA principles such as Service Access Point (SAP), Service Delivery Point (SDP), SLA
management process mapping onto eTOM, service parameter framework, and measurement and
reporting strategies.

Volume 3 is written for Telecommunication and Supplier implementers. It describes how to apply
the SLA principles defined in Volume 2 to a representative set of technologies. Volume 3 also
includes a checklist of items typically included within telecommunication service SLAs.
Volume 4 is written for enterprise managers and implementers. It addresses business application
and services as well as internal and external network services. In this context it generically
describes enterprise performance requirements for end-to-end services. A number of enterprise
business applications of SLAs are described in detail.
For business enterprises, be they end Customers, SPs or Suppliers, to embrace SLAs a business
case must be made. Volume 1 approaches the business case from the point of view that
information related to product lines and transfer of information enabled by telecommunication
services and networks is the life blood of business enterprises. It is business enterprise
information that must be properly understood, managed and assured for business enterprises to
sustain growth and not fail.
Understanding business information is termed Information Management (IM). Protecting business

information is termed Information Assurance (IA). Telecommunication services and networks are
indispensable for conducting commercial, government and academia business. However, service
and network Level of Service (LoS) and QoS performance is only as good as that supported by
the service and network architecture design. This limitation may result in telecommunication
services and networks under performing against the desired business enterprise requirement
thereby introducing business risks that may have far reaching consequences to the survival of
business enterprises. Therefore for enterprises to be assured of business survival, business
application LoS and QoS performance requirements must be accurately mapped into the
telecommunication services and networks QoS performance parameters, metrics and thresholds
incorporated within business enterprise internal and external SLAs. Ultimately, it is the CEO that is
responsible for corporate business enterprise IM, IA and determining business application LoS
and QoS performance. The telecommunication service and networks supporting business
enterprises must provide capability to meet the required LoS and QoS performance needs. For
business enterprises to commit to and embrace SLAs there is a need to conduct a Balance of
Investment (BoI) to be assured that SLAs will benefit the business. The SLA BoI must into account
all factors associated with SLA benefits, consequences, incurred whole life costs, improved
revenue and profitability, understanding the content of business information as well as the required
level of LoS and QoS performance. Volume 1 introduces some of the major benefits and
consequences for end Customers, SPs and Suppliers when implementing, embracing and
supporting SLAs. The listed benefits and consequences is not intended to be all inclusive.
For end Customers, SPs and Suppliers CEOs and Board members accepting that adopting SLAs
is considered a progressive adjunct to business enterprise strategy, Volume 1 provides suggested
possible next steps towards implementing, embracing and supporting SLAs. These next steps
range from a review of business strategies, gap analysis, information content, processes, cost-
benefit analysis, current services and supporting SLAs, training needs analysis to future service
plans, marketing strategies and outsourcing strategies.
For convenience Volumes 2, 3 and 4 Executive Summaries are at Annexes A, B and C to this
Volume 1 Executive Overview.


Annex C - Executive Summary For Volume 3
The Service Level Agreement (SLA) Management Handbook series consists of

four volumes. These are Volume 1, Executive Overview, Volume 2, Concepts And
Principles, Volume 3, Service And Technology Examples, and Volume 4,
Enterprise Perspective. The series has a common conceptual base with each
volume concentrating on specific topics. The volumes may be read in any order
although it is suggested that Volumes 2 and 4 be read before Volume 3. It is
expected that the readers of Volume 1 are interested in an overview of the SLA
Management process that is sufficient to enable them to provide management
guidance to their organizations. For reader convenience, the Executive Summaries
for Volumes 1, 2, and 4 are in the Annexes to this document.
The objective of the SLA Management Handbook series is to assist two parties in
developing a Service Level Agreement (SLA) by providing a practical view of the
fundamental issues. The parties may be an “end” Customer, i.e., an Enterprise,
and a Service Provider (SP) or two Service Providers. In the latter case one
Service Provider acts as a Customer buying services from the other Service
Provider. For example, one provider may supply network operations services to
the provider that supplies leased line services to its customers. These relationships
are described as the Customer-SP interface and the SP-SP interface.
This volume of the Handbook briefly reviews the essential elements of the
concepts and principles presented in Volume 2. Using this as a base, a check list
of items for potential inclusion in SLAs is presented. This is then followed by seven
examples of the application of the SLA concepts and principles.
The SLA check list contains numerous lists of items that may be included in an
SLA. These lists were derived from TMF member contributions, information
provided by user groups and by standardization bodies. Not all of these items will
be relevant to a specific SLA. The order of the items in the list does not imply a
priority. These items may be consolidated or may be disaggregated as needed.
Topics covered include service descriptions, service level and service quality
specification, service monitoring and reporting, and tariffs and billing issues.
This volume concludes with high level examples of how the principles and
concepts defined in Volume 2 can be applied. It should be noted that the services
used in the examples can become quite complex in particular instances. The intent
in this document is to retain only the essential aspects of the services while
illustrating the use of the SLA Parameter Framework.
Note that all parameter values that appear in this document are for illustrative
purposes only and are not intended to represent industry agreements or

recommendations. Service parameter values are ultimately based on business

needs and will be established via the SLA negotiation process.
The examples herein include lease line services, emergency and disaster relief
services, ATM Cell Delivery and IP based virtual private networks (VPN).
The SLA Management Handbook series incorporate earlier work that appears in
the Performance Reporting Concepts and Definitions Document [TMF 701], in the
Service Provider to Customer Performance Reporting Business Agreement [NMF
503] and in Service Quality Management Business Agreement [TMF506].

Annex D - Executive Summary For Volume 4
This volume addresses the enterprise issues in the provision of end-to-end Service
Level Agreements (SLA) and comes as a collaboration between the Open Group,
representing the enterprise, and the Telemanagement Forum, addressing the
service provider markets. This work was further inspired by survey data gathered
on behalf of the Open Group by Sage Research which indicated great interest in
SLAs in the enterprise but a large gap between where enterprises are considering
SLAs and where standards bodies, such as the IETF, are currently concentrating
their efforts.
The scope of the market addressed by ‘enterprise’ is very broad and business
practices diverse. It was therefore necessary generalize the applications used by
an enterprise that SLA metrics could be applied, measured and reported in a
contractual manner.
In the attempt to describe enterprises generically, an application is considered as a

collection of applications that fulfill the enterprise objectives. Such objectives would
include raising revenue (commercial), giving taxes (government), curing patients
(healthcare) and defending a nation (operational defense). In support of these
objectives the enterprise needs to deploy a number of business applications.
These applications would include call center, trading, information delivery,
manufacture, distribution etc.
To enable the business applications, a number of business services, e.g., voice,

video conferencing, email, transaction processing and telemetry and network
services (IP, Ethernet, DSL etc.) need to be deployed to an agreed level (the
service level), maintained and reported. There is some cases a hierarchical or peer
to peer relationship between these services that must be considered.
This work uses the concept of key quality and performance indicators (KQI/KPI)
developed by the TMF Wireless Services Measurement Handbook (GB 923). The
importance of the KQI/KPI concept is that it allows the provider of the service to
concentrate on the quality, rather than the performance of a service as in the past.
The relationship between the KQI and the performance metrics, KPI could be
identical for the simple case or complex, derived empirically or inferred from a
number of KPI and other data. The mapping between the KQI and KPI forms an
important part of the SLA negotiation.
For each of the generic business services discussed, the KQI are determined and
then KPI for the services and methods tabulated.
The form of an SLA is discussed and special attention is made between the form
of an SLA between internal parties and external parties, especially in terms of

penalties. A monitored and reporting process is then discussed allowing for real
time, near real time and historical reporting of both asynchronous events and
polled parameters.
A number of use cases are considered to validate the approach. The first is a
common example where Voice over IP (VoIP) is used to connect remote sites of
an enterprise to a corporate HQ. Data is also supported but only on a best effort
basis. The second scenario is from the Open Groups Mobile Management
Forum’s work on the ‘Executive on the Move’ where an executive is considered to
have voice and data connectivity wherever they are, in the office, in transit (car,
airplane), at home or at a remote site. Voice, data and video (conferencing) are
also supported for the executive. The final scenario is a naval application where
voice, data and video applications are supported in a highly distributed and
arduous environments. The VoIP and naval scenarios envisage a common IP
infrastructure and uses a differentiated services (DiffServ) marking scheme to
separate the different service domains for prioritization.

Annex E – Performance Specification References
This annex identifies additional documents that address Performance Specification

and Reporting related issues. As these documents are frequently revised, the
reader is advised to verify that she/he is using the latest version.
E.1 Guidelines For References
Document review is an ongoing process within the TM Forum’s SLA/QoS Team.

The documents listed in the following subsections are not deemed to be
exhaustive. Suggestions of new references (with location and availability) are
welcome and should be sent to the Editor.
E.1.1 Conditions
There are two categories of service conditions that drive reporting, viz., the loss of
service and degraded service. Loss of service is somewhat more easily
determined at almost any point along the service path. Degradation of service is
more difficult to determine.
E.1.2 Essential Findings
There are many well developed documents addressing Performance Reporting for
numerous network elements. No standards were found that directly apply to the
end-to-end service the Customer has purchased. The user is not capable of (nor
interested in) summarization of all of the individual NE (Network Element)
performance metrics. Where several networks support a service, the aggregation
of all of the individual NE degradation reports is not practical. Therefore more direct
measures of the user (end-to-end) service appear to be required for degradation
reports. No standards were located that address this issue directly.
The following sections reference other documents that address elements related to
the subject of Performance Reporting. Where possible the issue of the document
has been identified. This list is not exhaustive. Additions should be communicated
to the Editor.
E.2 Document List
Unless otherwise noted, all of the documented in the following table are ITU-T
documents. Documents noted [*] remain to be reviewed.

Document Title
E.540 Overall GoS of the international part of an international connection
Overall GoS for international connections (subscriber-to-
E.541
subscriber)
E.543 GoS in digital international telephone exchanges
GoS and new performance criteria under failure conditions in
E.550
international telephone exchanges
E.720 ISDN GoS concept
E.721 Network GoS parameters in ISDN
E.771 GoS for land mobile services
E.775 UPT GoS concept
E.724 GoS parameters and target GoS objectives for IN-based services
Terms and Definitions Related to Quality Of Service and Network
E.800
Performance Including Dependability (08/94)
Model for the serviceability performance on a basic call in the
E.810
telephone network [*]
Models for the allocation of international telephone connection
E.830
retainability, accessibility and integrity[*]
Connection accessibility objective for the international telephone
E.845
service[*]
Connection retainability objective for the international telephone
E.850
service[*]
E.855 Connection integrity objective for international telephone service[*]
General aspects of QoS and network performance in digital
I.350
networks, including ISDN[*]
Recommendations in other series concerning network
I.351
performance objectives that apply at reference point T of ISDN[*]
Network performance objectives for connection processing delays
I.352
in an ISDN
I.360 series
M.3100 Generic network information model
M.3400 TMN management functions
Q.822 Performance Reporting Management functions
General Quality Service Parameters for Communication via
X.140
Public Data Networks 09/92
User Information Transfer Performance Parameters for public
X.144
frame relay data networks

Document Title
Performance for Data Networks Providing International Frame
X.145
Relay SVC Service
Definition Of Customer Network Management Service For Public
X.161
Data Networks
Framework(s) On Network Requirements And Capabilities To
Y.1271 Support Emergency Communications Over Evolving Circuit-
Switched And Packet-Switched Networks
ISO/IEC
QoS Basic Framework 01/95 (will become CD 113236-2 in Aug.
JTC21/SC21-
95)
N9309
RACE Service Management documents
RFC 1604 Service management requirements Frame Relay Forum.
CCITT Handbook on Quality of Service and Network Performance
Frame Relay Forum Quality of Service Working Group (Working document August
1993)
T1A1.3/93-011R2 -T1 Performance Standards Contribution Doc
Note: E.3xx, E.5xx and E.8xx documents remain to be assigned.
E.3 Document Abstract
E.771
The Grade of Service (GoS) parameters for land mobile services are parameters
which primarily describe the interface between Service Providers and/or a
Supplier. The mobile telephone subscriber/end user normally does not ask for GoS
parameters. The probability of end-to-end blocking and connection cut-off due to
unsuccessful handover is highly dependent of the network resources.
E.800
Quality of Service and Dependability Vocabulary, provides a vocabulary of terms

and their relationships. 376 terms are defined. [The reader is cautioned that the
08/94 version of E.800 is substantially different from earlier editions. Reference
numbers and sections have been changed.] The following should be noted.
1) A general framework for performance concepts is shown in Figure 1/E.800
which also include planning and provisioning.
2) The distinction made between QoS and Network Performance is shown in
Figure 1/E.800.
3) A set of measures for QoS and Network Performance is discussed. The
method of measurement is not addressed.

E.800 appears to be a superset of ISO/IEC JTC21/SC21-N9309. Coordination

between these documents is not clear.
M.3100
This document contains definitions of GDMO-based object classes that represent

the network information model. These managed object classes are intended to be
applicable across different technologies, architectures and services.
None of the included definitions are specifically aimed at performance

measurement. There is an attribute "availabilityStatus", derived from X.721, but
this refers to Service Availability - i.e. whether the resource is operational,
degraded, in test, etc., - and is concerned with fault status, rather than
performance.
The parameter "c.2.9.1 - alarmEffectOnServiceParameter" might be considered to

have some relevance to Performance Reporting, but it is not specific on the
impact.
M.3400
This document contains descriptions of TMN Management Functions. Section 2 of

the document is specifically on Performance Management and includes some
functional descriptions of interest.
Q.822
This document is entirely concerned with performance management. It focuses on

describing parameter value collection and the threshold setting aspects of
performance management for a Q3 Interface. This document has an NE - MIB
management orientation and is too detailed for reporting service performance at
the Customer interface. An aggregation of these parameters across multiple
providers will be difficult. The majority of the document is concerned with the
mechanisms of performance management, rather than the content of the specific
performance measures, but this may be of interest also. Full GDMO definitions are
provided in the document. Extraction of even the major objects would still be a
considerable body of text.
X.140
A primary value of this document is Figure 1/X.140 which defines the three phases
of a communication event: Call Establishment, Data Transfer, and
Disengagement. Performance is measured during each phase by three key
parameters: Speed, Accuracy and Dependability. This 3 by 3 matrix appears to
provide a strong foundational model for other documents addressing performance
and availability.
Specific emphasis is made for switched data services such as X.25 and X.21.
Performance measures are specified at the point where a Public Data Network
terminates at the user site at physical layer one. The OSI user perceived QoS

performance is not addressed (Figure 2/X.140). References are drawn to circuit

switching in X.130 and X.131, to packet switching in X.134 and X.137, and to OSI
network service performance in X.213. Two parameters classes are addressed,
viz., performance during normal service operation and availability parameters
describing the frequency and duration of service outages.
X.144
This document is very well developed for detailing the performance of PVC
operation in the data transfer phase. The reader is drawn to X.140 for the basic
construction of the three phases of a data connection: Call Establishment, Data
Transfer, and Disengagement. During the PVC data transfer phase various
parameters are discussed as measures of performance and availability. Of
particular value are Figure 5/X.144 that shows statistical populations used in
defining selected accuracy and dependability parameters, Table 1/X.144 that
shows the four Outage criteria for the availability decision parameters, and
Appendix I/X.144 that describes sampling techniques and sampling periods for
availability.
X.145
This document is a companion to X.144 and addresses the call establishment and
disengagement phases for SVC operation. Two outage criteria for the availability
decision parameters for SVCs are described in Table 9/X.145 in addition to the
four criteria described in Table 1/ X.144 for PVCs.
X.161
X.161 defines the management services which may be provided to a Customer

and collectively described as Customer Network Management (CNM). CNM is a
service which provides the Customer with an ability to access (and in some cases
modify) management information relating to the services provided to them by the
network.
X.161 defines the management services and supporting functions for CNM. This
recommendation is intended to complement TMN specifications and provide a
specification for the non-TMN environment. X.161 is related to:
1) X.160 - Architecture for CNM for public data networks
2) X.162/X.163 - Definition of Management Information for CNM. The CNM
services defined in X.161 are classified into six groups, viz., Fault,
Accounting, Configuration, Performance and Security Management,
(FCAPS) and CNM supporting services.
Y.1271
Y.1271 provides core requirements and capabilities to support emergency
communications. In particular, Section 8 of the Recommendation describes core
requirements from a technology neutral perspective.

FRF-QoS
This document contains definition for transfer delay on Frame Relay circuits and
networks. Suggested measures are defined.
RFC 1604
The document is a very useful MIB for service management of Frame Relay.
However, it does not contain definitions of performance measures. The information
may be useful, but the reader must abstract the MIB field contents to gain useful
QoS measures.
T1A1.3/93-011R2
This contribution contains definitions for PVC availability and Mean time between
service outages. It uses the same definitions as X.144.
21n9309 QoS - Basic Framework
This document is an excellent reference for terms and definitions related to QoS. It
is an extension of X.200 and provides a basic framework for QoS in terms of:
1) Characterization,
2) Requirements specification,
3) Management.
It does not address detailed specification of QoS mechanisms. The writers have
developed text that is specifically directed to the larger issues of systems
management (not the specific requirements of networks). Readers should benefit
from the higher level thinking and terminology. However, it should be read from the
users’ point of view and the end-to-end character of the network application. The
attempt to define QoS at generic interfaces between systems (or elements) has
been accomplished. The reader should be alert to specific details in their own
application that may modify the approach of 9309.
Critique: The subject of statistics is addressed from the point of view of necessity
to compress the data resulting from measurements. In very large networks the
amount of data potentially available will be staggering, therefore statistical
reduction and summarization of data is important.
What is missing is the economic necessity to address sampling approaches to

obtain data measurements. Ubiquitous gathering and storing of data on all circuits
all of the time will not become an economical reality within the foreseeable future.
With limited compute power in the network elements and the added cost of placing
“probes” at many locations, the ability to obtain measures of quality requires
consideration of sampling processes. Usual issues include frequency of scanning
and dwell time, as well as scheduling specified hours and days.
This document should become a starting place as a “reference check” for

definitions.

E.4 Directory
This subsection provides a mapping of topics into the various source docuements.
Management References
Subject Source Subject Source
Accounting X.161 Performance X.161
Fault Management X.161 Performance Management M.3400
Alarm Indication Q.822 Mean Time Between PVC X.144

Outages
Access delay X.140 Performance Analysis M.3400
Accuracy and 9309, Performance Monitoring M.3400

Dependability FRF-QoS,
X.144
Availability E800; 9309 Protection Switching Q.822

; FRF-QoS
Bit-Based X.144 PVC Availability X.144, T1A1.3

Conformant Traffic
Distortion Ratio
Capacity QoS 9309 Reliability – QoS 9309
Controlled Slip Q.822 Residual Frame Error Ratio FRF-QoS,

X.144
Code Violation Q.822 Retainability E.800
Counts Fame Relay RFC1604 Servability Performance E.800

Activity
Disengagement- X.140 Severely Errored Seconds Q.822

Delay
Errored Seconds Q.822 Speed Of Service - Frame FRF-QoS

Transfer Delay
Extra Frame Rate FRF-QoS, Transmission Performance E.800

X.144

Management References
Subject Source Subject Source
Frame Based X.144 Time – QoS 9309

Conformant Traffic
Distortion Ratio
Frame Loss Ratio FRF-QoS, Unavailable Seconds Q.822

X.144
Integrity – QoS 9309 User Information Bit Loss X.144

Ratio
Interruptions E.800 User Information Transfer X.140, X.144

Delay
Loss Of Signal Q.822 User Information Frame X.144

Loss Ratio
Alarm Report X.161 Alarm Effect On Service M.3100

Parameter
Alarm Quality Of X.161

Service
Alarm Effect On M.3100

Service Parameter

Annex F – Report Information Sources
F.1 Information Required For Service Availability Calculation
The calculation of SAP outage intervals may be done in conjunction with Trouble
Ticketing systems, specifically by passing the Trouble Ticket information on
affected SAPs from the Trouble Ticketing system to Performance Reporting
process. If this is done by notifying the Performance Reporting process of open
and closed Trouble Tickets, an issue arises with unclosed Trouble Tickets which
will distort the derived Availability calculations for affected SAPs.
See Section 0 for details on calculating Service Availability.
F.2 Additional Information For Performance Reports
Some service providers wish to report on additional QoS related parameters such
as:
1) TTR: Time to Restore for a specific SAP,
2) MTTR: Mean Time to Restore for a specific SAP/SAP Group,
3) MTBF: Mean Time Between Failure for a specific SAP/SAP Group.
It is not within the scope of this document to standardize the above mentioned
parameters for the customer to service provider SLAs. However, by using the
proposed Service Availability calculation formula, service providers will have all
information available to perform the respective calculations.
F.3 Information Required From The Network
The Performance Management Operations System Function (PM-OSF) on the

Network Management Layer (NML) has the overall knowledge of the network.
Given a Managed Object Instance (e.g., a Leased Line circuit ID), it is capable of
determining which Trail Termination Points to collect data from. The actual
mechanism that a PM-OSF uses to collect data from the physical network is

beyond the scope of this document. The Performance Reporting process assumes
the following functionality is supported in the PM-OSF:
1) The PM-OSF in the NML must be able to maintain and/or retrieve PM
history data for a particular network connection on an end-to-end basis.
2) The number of instances of performance history data and aggregation
intervals can be set by the Performance Reporting process based on the
performance reporting aggregation intervals for each service.
3) The PM-OSF supports a registration capability that permits the
Performance Reporting process to register a list of Managed Object
Instances for periodical reporting. The registration process should allow the
specification of the managed object instance and the set of performance
monitoring data attributes. At the end of a collection interval, the PM-OSF
should report the data to the Performance Reporting process.
4) The PM-OSF must allow ad hoc query of history data.
F.4 The Use Of Common Objects
The Performance Reporting process may also use of common objects to:
1) Identify all SLAs in force for a Customer,
2) Identify service characteristics which may be referenced by individual
SAPs,
3) Identify all SAPs for a given Service, e.g., for a multi-party connection.
F.5 Initial Administrations
The Performance Reporting process depends on information from a Service

Ordering function. Once the service order information is received and a
Performance Reporting Request is received, a customer account will be
established if needed, and the service record and associated SLA ID will be
stored. Customer log-in and access control procedures will also be initialized.
F. 6 Data Collection
At the service activation time, the Performance Reporting process will initiate the
data collection process. There are two sources for service performance data, the
Trouble Ticketing system for service availability and the PM-OSF on the NML for
network impairment and traffic data.

The data collection process involves client registration and establishing the
periodical reporting mechanism in the Trouble Ticketing system and PM-OSF if
supported. In the absence of a registration and reporting functionality, the
Performance Reporting process will set up a data polling mechanism.
F.7 Data Computation And Aggregation
After the receipt of data from the PM-OSF or the Trouble Ticketing system, the
delivered service performance levels will be computed. For example, the Trouble
Ticketing system will provide the outage duration associated with each Trouble
Ticket for a particular service. The PR-OSSF will calculate the Service Availability
level, and if desired, TTR, MTTR, and MTBF, for a particular aggregation interval.
The customer may choose to receive reports that span several aggregation
intervals. The service provider may choose an “atomic” aggregation interval for
each report type. For example, as QoS metrics are typically defined over longer
time periods than traffic data metrics, a service provider may choose a month as
the atomic aggregation interval for QoS reports and an hour as the atomic
aggregation interval for traffic data reports. Reports based on longer aggregation
intervals can be derived from the atomic aggregation intervals, e.g., quarterly and
annual reports for QoS; daily and monthly reports for traffic data.
The number of history reports available for customer access for each report type is
a local policy issue.

Annex G - Perceived And Delivered Performance
Numerous debates have arisen over the difference between quality as perceived
by the end user and the delivered quality as measured by the Service Provider.
This annex provides one approach to defining measures that can be verified by
both the end user and the Service Provider. Perceived performance12 and
delivered performance are indeed two separate, though highly related measures.
These measures are derived from user data while the user is on the line, thereby
providing an accurate indication of actual performance. Increasing demands for
high availability levels require in-service measures. This process described in this
annex is applicable to services that are operational (and might be degraded below
the SLA threshold). Services that have failed completely are not addressed. There
is usually less debate over hard service outages (faults).
G.1 Application
The method described in this annex focuses on the transport phase of the
connection between user SAPs. The method applies in cases where the
connection was established manually (PVC) and in cases where various semi-
automated or automated mechanisms were used.13.
This method uses in-service measurements. It does not interrupt the user data
flow. In fact the measures are based upon the user data. User messages are
selected for analysis because they flow end-to-end. The same assessment can be
made at any point along the path (even though the transport mechanisms may
vary)14. Although some lower layer protocols place message traffic into packets,
frames, or cells with possibly fixed payload capacities, the technique is most easily
implemented by analysis of user messages in their original form.
12
Perceived performance includes the combined performances of the application, the communications
link(s), and any servers being addressed by the application.
13
Call establishment and release (e.g. Figure 3/X.140) is not addressed herein.
14
Where several SPs comprise the end-to-end connection, each SP can make the same measure (as the
user).

Measurements are made at the appropriate protocol layer where the (user) system
at the SAP controls the message error recovery mechanism using a
retransmission procedure.
G.2 Process
Messages flowing from SAP A to SAP Z will be subject to a finite number of errors.
Current technology utilizes various schemes, e.g., the use of various Cyclic
Redundancy Check (CRC) methods, to detect if one or more message bits have
been corrupted in the transmission process. A single bit error may cause the
message to be discarded.
Receipt of a single errored message may cause not only the errored message to
be retransmitted, but it may require that all all intervening messages be
retransmitted to maintain the proper message sequencing. Frequently, the industry
uses a “repeat all after” process15. The common industry term for the maximum
number of outstanding messages is the window size. Typical window sizes range
from 8 to 128. Under extreme, but not impossible, circumstances over 100
messages could be retransmitted to recover from a single bit error16.
When a transmission technology or protocol segments a user message, the

segmentation process itself may provide a mechanism to detect segment errors in
addition to the mechanism used for the message itself. Correlation between
segment errors and user message errors can become very complicated. Therefore
utilization of user messages is a more direct method of measurement.
Table C.1: Perceived and Delivered Service Availability Terms
SA Parameter Basic Measure Definition

SA Delivered Errored Messages17 Delivered Messages
SA Perceived Repeated Messages18 Useful Messages
15
Although some protocols provide for a selective reject mechanism, implementation has been minimal.
Nevertheless, the same process would be applicable and the perceived performance might converge
toward the delivered performance.
16
Satellite links have large delays and use a large window size to increase throughput.
17
Calculation of errored messages may vary depending on the specific error recovery process.
18
Calculation of repeated messages may vary depending on the specific error recovery process.

G.3 Delivered SA
The Service Provider designs a service to deliver a minimum number of errors.

Therefore, the established objective is the number of delivered (good) messages.
Delivered performance can be calculated as follows:
 Errored Messages 
SA Delivered = 1 −  x 100%
 Total Messages 
G.4 Perceived SA
The User requires a specified level of message availability to support a given

mission. The user’s internal communication software will establish a window size
that may be dynamically adjusted under error conditions. Perceived performance
can be calculated as follows:
G.5 Numerical Example
A common availability level used for digital data services is 99.98% error free
seconds19,20. This equates to two “bad” seconds in 10,000 seconds. A comparable
message objective is two “bad” messages in 10,000 messages. If one message in
10,000 is “bad”, the delivered performance is twice as good as the objective.
However, if there are seven outstanding messages, then eight messages21 must
be repeated. A perceived performance of eight in 10,000 is four times worse than
the objective. The Service Provider has an opportunity to provide the higher
availability level required to achieve the perceived objective of the user,(albeit at a
premium price.
19
The values are provided for illustration and do not constitute a recommendation.
20
99.85% error free seconds equals 17 errored seconds in a 24 hour day
21
Seven repeated messages plus the original errored message

G.6 Further Work
Users will not always be transmitting message traffic during the measurement
intervals. Further work is needed to develop sampling techniques. At various
network technology layers, in-service monitoring techniques are already provided
to estimate errors and availability. Sampling techniques should be developed at
the application layer to optimize the use of measurement and traffic bandwidth
resources. Confidence levels should be established that correlate with the sample
frequency, duration, time of day, and user traffic encountered22.
Note: U.S. Patent 5,481,548 may cover certain implementations of the methods
described in this contribution. Hekimian Laboratories is the owner of the Patent
and has provided a “Patent License Availability” statement for TeleManagement
Forum members.
22
This not intended to be an exhaustive list of parameters.

Annex H - SLA Lifecycle Use Cases
The following use cases present a high level view of the data flows and process
actions required to support the SLA life cycles phases. By examining each phase,
the detailed ramifications of SLA management on the baseline eTOM processes
can be evaluated. The inputs and outputs listed below are selected based on their
relevance to SLA/QoS management and do not include flows that are required to
support other management objectives. Note that eTOM processes may participate
in more than one life cycle phase.
The use cases which follow relate the life cycle phases discussed in Section 0 to
the eTOM [GB 921] processes that support SLA management.
The use cases address:

1) Product development with a new SLA
2) Negotiations And Sales
3) Implementation Of An Order
4) Normal Execution
5) Execution With An SLA Violation
6) Assessment

H.1 Product Development With A New SLA
Figure H-1: Creation Portion Of Product Development
In Figure H-1 the information flow of the first part of the creation of a service is
depicted.
1) Customer requirements are gathered either over time or as a result of a
Customer RFP. These requirements are for services with SLAs that do not
currently exist in the sense that the service is not yet offered, an SLA for
the service is not defined, or the Customer requirements exceed the
current SLA parameter definitions. This information flow includes the
service description for the base service (SAP, SAP technology, access
technology, speeds, overall circuit parameters (e.g. CIR), etc) and the QoS
parameters required by the Customer23.
SALES: would take the disparate requests from separate customers, examine the
current catalogue of services for close matches, estimate the business potential for
new Customers, additional revenue from existing Customers, plus the value of
retained revenue, and pass the requests to service planning and development.
Part of this function is sometimes performed in a group termed Product Line
Management or Marketing.
2) The Customer requirements combined with the potential market value for
this new service and the estimated service lifetime is passed to Service
Planning and Development.
SP&D: splits the requirements into operations-specific requirements and
network/technology requirements. (Service) Architectural alternatives for providing
23
See Chapter 3 for level of service and quality of service definitions.

the new service are weighed, and the operations impacts of the different
architectures are balanced against the different potential impacts of changing
service needs (emerging technologies that could drive Customer demand in a
different direction, e.g., VoIP, or Soft Switch). This creates preferences or priorities
being placed on the underlying technology requested from the network. These
requests are then sent to the Network Planning and Development process block.
The order of flows 3 and 5 can be parallel.
3) Detailed network requirements are forwarded to the Network Planning and
Development process block to obtain network costs (capital and expense),
and the time frame that would be required to implement the new service
with the technical SLAs as specified. This flow indicates all the technical
parameters (service-specific and technology-specific) needed for the SLA
support, including technology preferences (not hard and fast rules),
performance parameters, geographic requirements (potentially including
phasing), and time frame requirements.
Figure H-2: Product Development With A New SLA, Steps k to m
NP&D: analyzes the new service requirements against its existing network
inventory and operations support structure including both network and operations
capacity and geographic coverage. During this analysis, NP&D examines the
current network experience for performance and reliability, and formulates a cost
to upgrade the network, field operations, and support systems to provide the new
service, including a realistic time frame. NP&D may need to flow data to all other
network layer process blocks to arrive at the estimate. It may also need to issue
RFI/Ps to get new equipment costs.
4) Cost (expense and capital) and time estimates are returned to SP&D.
These may include specific technology recommendations if during the
NP&D investigation it was determined that one technology was not mature
enough to support the QoS or Service Availability requested.
5) Optional: Query to SQM to obtain current network quality figures for
intended infrastructure and geography. May request Customer QoS
reports if responding to RFP or periodic Customer review.

SQM: processes the required information for delivery back to SP&D.

6) Response to query.
SP&D: evaluates feasibility of service based on cost and revenue projections, and
network technology availability. If feasible, it creates service descriptions and SLA
templates.
Phase continues on Figure 5.3.
Figure H-3: Product Development With A New SLA, Steps m+1 to n
SP&D: analyzes all returned data and determines the possible SLAs that will meet
the company's risk model.
7) SP&D returns the permissible SLA parameters with values to Sales (PLM)
with ranges of values, required financial returns necessary to cover risks,
geographic restrictions, and lead time before the SLAs may be offered.
8,9,10,11,12) Notices of new service parameters go to most of the rest of the
organization for inclusion into standard business practices.
H.2 Negotiation And Sales
Figure H-4 depicts the data flow during the Negotiation and Sales phase of an SLA
product. The end of this phase is a signed SLA with both Customer and SP
knowing exactly what is expected of each other, what is covered and when, and
what recourse is available.

Figure H-4: The Negotiation and Sales Phase of SLA Management
1. The Customer inquiry for a product contract including SLAs is passed to

Selling.
2. Selling requests information about the Customer from Retention & Loyalty
(whether an existing Customer or not, Customer history, etc.).
3. If required, a pre-order feasibility check may be carried out. Selling requests

Order Handling to do this. (Steps 3 to 7 are therefore optional).
4/5.Order Handling checks availability and feasibility with Service Configuration &
Activation and, if external service components are required, with S/P Buying.
6. Service Configuration & Activation investigates available capacity and requests

Resource Provisioning to check resource capacity and availability of the
resources required to support the service instance(s).
7. The check is completed and Order Handling confirms the product availability to
Selling.
8. Selling enters into negotiations with the Customer and an offer with SLA details
is made to the Customer.
9. The Customer responds to the offer and further negotiations may take place
with Selling.
10. Selling may request additional details from Service Configuration & Activation.

11. Service Configuration & Activation may request further details from Resource
Provisioning.
12. Negotiations are completed, and the Customer signs a contract containing
agreed details of the QoS and SLA parameters.
H.3 Implementation Of An Order
During implementation, a Customer’s individual order is taken from Customer

request to working accepted instance (see Figure H-5). During this time frame, the
service infrastructure is specifically built out to allow for the individual Customer
request, the individual components are put into service and activated. Any testing
for Quality purposes is conducted, and the Customer is notified that the service is
turned up, with some form of (positive) response from the Customer reflecting
acceptance of the product instance.
Figure H-5: Implementation Flow Of SLA Instantiation
1. An order against an existing contract with SLAs is passed to Order Handling.

This order can be by phone, facsimile, or via an E-Bonding arrangement.
2. The order enters the service configuration process. This may be through a
direct customer web interface, or through other electronic ordering channels
(i.e. this and step 1 may be the same step) or passed on from Order Handling
to Service Configuration & Activation.

3/4.The order, along with the SLA parameters, enters provisioning, starting the
applicable installation and provisioning timers. Service Configuration &
Activation configures the requested service instance(s) and sends the
appropriate requests both to Resource Provisioning for internal resources as
well as to S/P Buying for external service components required.
5. S/P Buying passes the order to S/P Purchase Order Management for S/P
delivery.
6. S/P Purchase Order Management issues orders for Suppliers and Partners.
7. Resource Provisioning provisions and tests resources to support the required

service KQIs and updates Manage Resource Inventory.
8. Resource Provisioning reports the results of its actions to Service

Configuration & Activation.
9. S/P Purchase Order Management confirms to Service Configuration &

Activation that external provision is complete.
10. S/P Purchase Order Management informs S/P Performance Management of

the external service components to be monitored.
11. Service Configuration & Activation tests the additional service instance(s) on
an end-to-end basis and ensures that service KQIs are supported. It updates
Manage Service Inventory with the new service instance(s) and their KQIs.
12. Service Configuration & Activation requests Service Quality Management to

initialize monitoring of the new service instance(s).
13. Service Quality Management requests Resource Performance Management to

initialize monitoring for the provisioned resources.
14. S/P Performance Management informs Service Quality Analysis, Action &
Reporting that monitoring has been initialized for external service components.
15. Service Quality Management informs Service Configuration & Activation that
monitoring has been initialized.
16. Service Quality Management sends details of the newly ordered service
instance(s) to Customer QoS/SLA Management for later SLA processing.
17. Service Configuration & Activation informs Order Handling that the service
instance(s) have been tested and activated and are ready for use.
18. Order Handling informs the Customer of the activated service instance(s), and
the Customer indicates acceptance. This may be electronic from the same
systems used in step 1.
19. After the Customer has indicated acceptance, Order Handling informs
Retention & Loyalty, Billing & Collections Management, and Customer

QoS/SLA Management that the service instance(s) have been activated and
are ready for use by the Customer.
H.4 Normal Execution
Normal execution, also known as steady state, is the phase where the Customer
receives service on all the contracted and instantiated service instances. This
section first analyzes in Case A, a situation where no service outages or other
alerts occur and the Customer is billed for the service used (Figure H-6), and then
analyzes in Cases B and C, the situation where although service outages occur,
no outage exceeds either the individual or aggregated parameters set in the SLA
(Figure H-7 and H-8). In the first case of normal operation, a Supplier/Partner is
also involved; in the second case, the outages are within the Service Provider
enterprise and so do not involve a Supplier/Partner.
Figure H-6: Normal Execution Case A: Normal Performance Data
The steps shown in Figure H-6 for Case A are as follows:
1) During normal operation, performance data that is used for general

monitoring of service levels as well as for longer-term capacity prediction is

collected on an ongoing basis from the service-providing infrastructure by

Resource Data Collection & Processing.
2) During normal operation, performance data from external service
components of third Party SPs is sent on an ongoing basis to S/P
Performance Management for general monitoring of service levels, as well
as for longer-term Supplier/Partner capacity prediction.
3) Resource Data Collection & Processing sends performance data to
Resource Performance Management for further analysis.
4) Resource Performance Management sends resource performance reports
to Service Quality Analysis, Action & Reporting for QoS calculations, and
averaging to maintain statistical data on the supplied service instances.
5) S/P Performance Management sends external service component
performance reports to Service Quality Analysis, Action & Reporting for
QoS calculations, and averaging to maintain statistical data on the supplied
service instances.
6) Resource Data Collection & Processing sends resource usage data to
Service & Specific Instance Rating for rating service usage.
7) Third Party SPs send their usage and charging data to S/P Settlements &
Billing Management.
8) S/P Settlements & Billing Management analyzes the data and passes it on
to Service & Specific Instance Rating for rating service usage.
9) Service Quality Analysis, Action & Reporting analyzes the performance
reports received and sends overall service quality reports to Customer
QoS/SLA Management so that it can monitor and report aggregate
technology and service performance.
10) Customer QoS/SLA Management checks the service quality reports it
receives against the individual Customer SLA and establishes that no SLA
violation has occurred. Customer QoS/SLA Management sends periodic
service level reports to the Customer on either a requested or agreed
basis.
11) Service & Specific Instance Rating sends charging details to Billing &
Collections Management.
12) Billing & Collections Management generates bills for the Customer on
either a requested or agreed basis.

Figure H-7: Normal Execution Of SLA Service: Cases B And C: Threshold

Crossing Alerts And Resource Failure Alarms
The steps shown in Figure H-7 for Cases B and C are as follows:
1. Notifications are collected from the service-providing infrastructure by

Resource Data Collection & Processing on an ongoing basis. In Cases B and
C these notifications are in the form of:
2B. Threshold Crossing Alerts that represent congestion or performance

degradation in a congestable resource that forces slowed or diminished
capacity to perform Customer services. Resource Data Collection &
Processing sends all performance data to Resource Performance
Management, which identifies a resource performance problem and requests
Resource Trouble Management to discover the cause of the alert and
possible impact on service performance.
2C. Alarms that represent the failure of a component that affects the service of
one or more Customers. Resource Data Collection & Processing sends data
on alarms to Resource Trouble Management for further action.
3. Resource Performance Management sends details of the Threshold Crossing

Alerts to Service Quality Management so that various notifications and other
steps may be taken to ensure that required service KQI levels are maintained.
4/5.Depending on the nature of the problem, Resource Trouble Management

either triggers automatic resource restoration procedures itself and informs
Service Problem Management of its actions or it raises alarm reports to

Service Problem Management, indicating the time and potential duration of

any outage to allow Service Problem Management to determine potential
alternate actions to minimize service impact.
6. Service Problem Management and Service Quality Management correlate

their information about the problem.
7. Service Quality Management sends details of the service impact of Threshold

Crossing Alerts and Alarms to Customer QoS/SLA Management.
8. Customer QoS/SLA Management checks the Customer SLA and obtains

information on the significance of the Customer from Retention & Loyalty and
undertakes various notifications and other steps in order to prevent Customer
SLAs from being violated, e.g., clocks started, tracking initiated.
9. Customer QoS/SLA Management may inform the Customer of the QoS

degradation, depending on the significance of the Customer and the extent of
the degradation.
10. If Resource Trouble Management has not been able to trigger automatic
resource restoration, Service Problem Management requests Service
Configuration & Activation to undertake the required corrective actions. (Steps
10 to 17 are therefore carried out only if automatic resource restoration did not
take place).
11. As the problems have been notified in the resource layer, Service
Configuration & Activation will require changes to be made to the underlying
infrastructure per contractual agreements. This requirement is sent to
Resource Provisioning for activation.
12. Resource Provisioning undertakes the required resource configuration

changes to ensure that resources meet service KQIs.
13. Resource Provisioning generates updates for Manage Resource Inventory.
14. Resource Provisioning reports the results of the changes as well as the time
taken and all other infrastructure and operational parameters to Service
15. Service Configuration & Activation generates updates for Manage Service
Inventory.
16. Service Configuration & Activation reports on the actions undertaken to

Service Problem Management.
17. Service Problem Management sends details of the corrective actions to

Service Quality Management for incorporation into ongoing service quality
monitoring and management.

Figure H-8: Normal Execution of SLA Service – Cases B And C – Steps 18

to 26
18. Notifications and performance data are collected from the service-providing
infrastructure by Resource Data Collection & Processing.
19. Resource Data Collection & Processing sends performance data to Resource
Performance Management for further analysis.
20. Resource Performance Management establishes that the resources are

meeting their KPIs and informs Resource Trouble Management that the
trouble has been rectified.

21. Resource Performance Management sends resource performance reports to

Service Quality Management for QoS calculations and averaging to maintain
statistical data on the supplied service.
22. Resource Trouble Management informs Service Problem Management of the

closed resource trouble report.
23. Service Quality Management analyzes the resource performance reports and
sends a rectification report to Service Problem Management when it is
established that the troubles causing the Threshold Crossing Alerts or Alarms
have been resolved and that the service is meeting its KQIs.
24. Service Quality Management sends overall service quality reports to Customer
QoS/SLA Management so that it can monitor and report aggregate technology
and service performance.
25. Customer QoS/SLA Management checks the service quality reports it

receives against the Customer SLA and establishes that no SLA violation has
occurred. It may inform the Customer of the quality restoration, depending on
the significance of the Customer and the extent of the degradation.
26. Customer QoS/SLA Management sends periodic Service Performance reports

to the Customer on either a requested or agreed basis.
H.5 Execution With SLA Violation
From time to time, service conditions will exceed the parameters specified in the
SLA. At least two cases need to be examined, one where the SP detects the
outage first, and one where the Customer detects and reports it first. The second
case is depicted in Figures H-9 and H-10.

Figure H-9: Customer Detected SLA Violation
The steps shown in Figure H-9are as follows:
1. The Customer perceives service degradation and reports the visible

parameters to Problem Handling.
2. Problem Handling sends details of the problem as reported by the Customer to

Customer QoS/SLA Management and Retention & Loyalty.
3. Retention & Loyalty returns information to Problem Handling on the

significance of the Customer.
4. Customer QoS/SLA Management checks the Customer SLA and undertakes

various steps for tracking the problem in order to prevent the Customer SLA
from being violated, e.g., clocks started, tracking initiated. It determines
potential priorities or other actions dependent on the type of Customer SLA
and informs Problem Handling.
5. Problem Handling sends a detailed problem report with contract commitment

data and request prioritization to Service Problem Management for normal flow
handling.
6/7.Service Problem Management investigates whether there is a problem,

possibly engaging Resource Trouble Management for further investigation,
and then requests Service Quality Management to correlate its findings.

8. Service Quality Management either confirms the trouble report or, if no

problem is noted, returns the actual service performance to Service Problem
Management.
Service Problem Management then carries out one of the three following
alternatives:
Alternative a
9a. If there is no problem, Service Problem Management sends the actual service
performance to Problem Handling.
10a. Problem Handling informs the Customer of the actual service performance as
well as Retention & Loyalty for future reference and Customer QoS/SLA
Management so that any steps initiated can be terminated.
The flow continues at step 17.
Alternative b
9b. In some cases, Service Problem Management requests automatic resource

restoration procedures from Resource Trouble Management.
10b. Resource Trouble Management undertakes the required procedures and

sends details of the actions to Service Problem Management.
11b. Service Problem Management informs Service Quality Management of the

corrective actions.
The flow continues at step 17.
Alternative c
9c. In other cases, Service Problem Management requests Service Configuration

& Activation to undertake the required corrective actions.
10c. Service Configuration & Activation will require changes to be made to the
underlying infrastructure per contractual agreements. This requirement will be
sent to Resource Provisioning for activation.
11c. Resource Provisioning undertakes the required resource configuration

changes to ensure that resources meet service KQIs.
12c. Resource Provisioning generates updates for Manage Resource Inventory.
13c. Resource Provisioning reports the results of the changes as well as the time
taken and all other infrastructure and operational parameters to Service

14c. Service Configuration & Activation generates updates for Manage Service
Inventory.
15c. Service Configuration & Activation reports on the actions undertaken to

Service Problem Management.
16c. Service Problem Management sends details of the corrective actions to

Service Quality Management for incorporation into ongoing service quality
monitoring and management.
Figure H-10: Customer Detected SLA Violation – Steps 17 – 26

statistical data on the supplied service.

20. Service Quality Management analyzes the resource performance reports and
sends a rectification report to Service Problem Management when it
establishes that the problem has been resolved and that the service is meeting
its KQIs.
21. Service Problem Management reports that the problem has been resolved to
Problem Handling.
22. Problem Handling informs the Customer and receives acknowledgement from
the Customer that the problem is resolved.
23. Service Quality Management reports the problem resolution to Customer

QoS/SLA Management. Customer QoS/SLA Management checks the details
against the Customer SLA and establishes that an SLA violation has occurred.
24. Customer QoS/SLA Management reports the violation rebate to Billing &
Collections Management for billing adjustment and to Retention & Loyalty for
future reference.
25. The Customer is notified in semi real-time about the actions taken on their
behalf.
26. Billing & Collections Management bills the Customer at the end of the billing
cycle with the SLA agreed treatment included.
H.6 Assessment
During the assessment phase, SLAs are examined to determine if they still fit the
business needs. There are several triggers for the assessment, including periodic
either per service or overall, Customer triggered reevaluation, Customer exit, etc.
Figure H-11 shows Case A where Customer SLA needs have changed, because
the Customer’s business needs have changed and there is no SLA meeting these
needs, leading to an assessment of the potential for an enhanced product SLA.
Figure H-12 shows Cases B and C where internal assessments at the CRM and
service layers lead to a realignment of infrastructure support for SLA parameters
and service KQIs respectively. In these flows, Level 3 processes from the
Operations Support & Readiness vertical are included for increased clarity.

Figure H-11: Assessment Initiation Case A: Customer Needs Have

Changed
The steps shown in Figure H-11 for Case A are as follows:
1. The Customer discusses changed requirements with Selling.
2. Selling checks the significance of the Customer with Retention & Loyalty.
3. Selling is unable to meet the Customer’s requirements with existing product

SLAs. It sends details of the Customer request to Support Selling for analysis.
4. After analyzing the request, Support Selling passes it on to Product

Development & Retirement for a reassessment of the existing product SLA(s).
5. Product Development & Retirement reassesses the SLA parameters and

sends a request for development of an enhanced product SLA to the Product
Development processes.

Figure H-12: Assessment Initiation Cases B and C: Internal Assessments
1B. Enable Customer Quality Management receives SLA reports for trend analysis
(mainly from Customer QoS/SLA Management). Enable Customer Quality
Management establishes that given SLAs are being violated too often, require
excessive rebates, and that the service KQIs are not supporting the Product
KQIs.
1C. Enable Service Quality Management receives service quality reports for trend
analysis (mainly from Service Quality Analysis, Action & Reporting). Enable
Service Quality Management establishes that the service being provided is not
meeting the required levels on an average basis.
2. Enable Customer Quality Management requests Enable Service Quality

Management to undertake the required service class KQI improvements so
that they will support the SLAs more adequately.
3. Enable Service Quality Management analyses the problems and requests

Enable Service Configuration & Activation to undertake the required corrective
actions to improve the service class KQIs.
4. Enable Service Configuration & Activation requests changes in the

infrastructure from Enable Resource Provisioning.
5. Enable Resource Provisioning takes corrective action to ensure that resources

meet the service class KQIs.
6. Enable Resource Provisioning generates updates for Manage Resource

Inventory.
7. Enable Resource Provisioning reports details of its actions to Enable Service

8. Enable Service Configuration & Activation generates updates for Manage

Service Inventory.



statistical data on the supplied service instances.
12. Service Quality Management analyzes the resource performance reports

received and sends overall service quality reports to Customer QoS/SLA
Management, so that it can monitor and report aggregate technology and
service performance.
13. Service Quality Management sends service quality reports to Enable Service
Quality Management for trend analysis, where it is established that the service
being provided is now meeting the required levels on an average basis.
14. Customer QoS/SLA Management sends SLA reports to Enable Customer

Quality Management for trend analysis, where it is established that given SLAs
are now consistent with SLA requirements.

Annex I – Example Of KQI Methodology
This annex uses a sample business scenario to provide an illustration of the way in
which the method may be applied.
A commercial transaction between a mobile user and a Mobile Service Provider:
A customer uses her PDA to order flowers for delivery to her Aunt in hospital. To
achieve this she:
1) Subscribes to the service
2) Customizes the service
3) *Accesses the service
4) *Selects the appropriate option from the menu
5) *Chooses a bouquet
6) *Enters the delivery instructions and her message
7) *Enters her security PIN
8) *Receives confirmation of the transaction.
9) *Tracks progress on the florist’s delivery tracking service
10) Receives notification from the delivery service that the flowers have been
delivered and accepted and the cost has been added to her phone bill.
11) Checks her phone bill
* These steps are included in the analysis matrix

To each of these scenarios we applied the Customer Experience Lifecycle
resulting in an individual Customer Experience Timeline.

•Selects service option

•Chooses bouquet
•Enters credit card details
•Enters delivery instructions and message
•Gets confirmation of sale
Checks credit
card bill
Receives thank you SMS from Aunt

which confirms that flowers did arrive
Pre-sales Service Ordering In-life Experience
First user
experience Receive
Find out Change
bill
about Service Personalise personalisation
service Activated service
Report
Cease
problem
Subsequent service
Provision Request usage
service for service Experience
customer
problem
Problem
Decide to buy resolved
Customer
advised
Figure I-1 Commercial Transaction Timeline
For the purposes of the following steps in the analysis example only the in-life
experience aspects of the timeline will be considered. However the methodology
for the analysis of the other phases of the timeline is the same. From the timeline
therefore we are able to identify the main activities of a subscriber using the Flower
Service.
Based on the timeline and the scenario, each the service resources in the service
delivery path required to deliver the Flower Service and the associated transaction
flows are identified to build an end-to-end service delivery diagram and used to
form the x and y axis of the transaction matrix.
It should be noted that the level of detail contained in the service delivery path
diagram (and hence the transaction matrix) is implementation specific and is driven
by the level of granularity required for managing the service. It should also be
noted that the granularity does not have to be consistent across the entire path
and will typically be at a greater level of detail for parts of the path that are
managed within the service provider’s business whereas components of the path
provided by a third party may be managed at a much higher level.
The following diagram provides a possible service path to support this example.

GSM RAN GSM Core Content Network

TE TE
HLR SMSC Flower
SMTP Service
WAP DCN
http
Gateway
Server
CSD Bearer
BSC RXCDR DCN
MSC/VLR
BTS
Mobile Access Content 3rd Party

Access
Customer
Service
Figure I-2 Flower Service Topology
This diagram identifies the key service resources for delivering the flower service.
In this case the components have been aggregated to a higher level and are
identified as:
1) GSM Radio Access Network
2) GSM Core Network
3) Content Access Network
4) Content Provider
In practice it is likely that a lower level of modeling would be used for some (or all)
of these components but in the interests of clarity these higher level aggregated
service resources are used in the following analysis.
By applying the methodology described in step 4 in the previous section, the

service resources identified above are used to create the x-axis or column headers
of the spreadsheet and the user actions for the y axis or rows. The dialogue steps
(or transactions) between the user and the service resources are then entered into
the spread sheet to create a complete flow from point of starting the use of the
service through to closing the dialogue. Figure I-3 shows a small part of this
analysis as applied to the flower service example and from it we are able to see a
snapshot of the transaction flow between the user and service resources from the
point of connecting in to the service through to the point of closing the session.

Figure I-3 Completed Matrix Example
Availability KQIs
Having completed the first pass of the matrix, it is now possible to identify a
number of KQIs that *may* be required for managing the service quality. Typically
the service resources across the x-axis indicate the components in the service
delivery path whose availability will impact service delivery. Therefore availability
KQIs need to be developed for these components. In this example these KQIs
are:
• Access_network_Availability
• Core_network_Availability
• Content_access_Availability
These in turn are aggregated to form a single KQI :
• fs_Availability
Accuracy KQIs
Using the same matrix, the accuracy KQIs may be derived by analyzing the
transaction arrows. Each arrow represents a potential point for measuring the
accuracy of the data transfer between the service resources or a service resource
and the end user. In this example the following lists the accuracy KQIs considered
necessary to support the flower service are:
• service_menu_transfer_accuracy
• flower_service_menu_transfer_accuracy
• picture_transfer_accuracy
• message_data_transfer_accuracy
• PIN_transfer_accuracy
• fs_menu_transfer_accuracy
• flower_service_menu_transfer_accuracy
In a similar way it is possible to identify from the transaction flows (arrows) the
‘success’ KQIs for the service. In this example these have been identified in the
matrix as:
• service_menu_access_success_rate
• transaction_success_rate
• session_completion_rate
• service_menu_access_success_rate
• fs_access_rate

• status_enquiry_success_rate
• session_completion_rate
Through the examination of the y-axis the critical request and response timings
may be identified. The analysis of this axis therefore provides the speed or time
KQIs these again may be aggregated to form higher level KQIs. For the Flower
Service, the following KQIs and their contributing KQIs have been identified (the
high level KQIs are shown as the major bullet item and their contributing KQIs as
sub-bullets):
• fs_connection_establishment_time
• service_menu_access_time
• service_menu_user_response_time (simplicity)
• fs_access_time
• fs_buy_transaction_time
• fs_menu_download_time
• flower_picture_transfer_time
• availability_confirmation_time
• delivery_instructions_confirmation_time
• PIN_confirmation_time
• order_confirmation_time
• fs_session_completion_time
• fs_status_check_transaction_time
• fs_access_time
• fs_menu_download_time
• fs_status_access_time
• fs_status_request_time
• fs_status_session_completion_time

Service Index Aggregated KQI KQI
SRa_Availability %
E2E_Service_Availability % SRb_Availability %
SRc_Availability %
SRa-SRb_Accuracy
SRa-SRc_Accuracy
E2E_Service_Accuracy % SRb-SRc_Accuracy
SRb-SRa_Accuracy
SRc-SRa_Accuracy
Service_Index SRc-SRb_Accuracy
Action1_ave_response_time*
Service_Transaction_completion_Time* Action2_ave_response_time*
Action3_ave_response_time*
User_Action1_Response_Time*
Action1_Response_Simplicity_Indicator
Figure I-4 KQI Hierarchy
Note the use of some KQIs in computation of more than one higher level KQI.
This is quite deliberate and a key advantage in the methodology as it provides the
reuse of computed data. The measurements are shown in Figure I-4 in an
alternative format for clarity.
In some cases the speed KQIs may also provide some indication of the simplicity
of the service. For example the time for a user to respond to a prompt or menu
may be an indication of the clarity of that prompt or the menu structure.
Service Index
It can be useful to derive a single indicator for the overall service quality. A service
index of this form is an aggregation of all of the higher level KQIs. It should
however be noted that the service index is often computed from various types of
KQIs e.g. time, percentage, it is therefore necessary to normalise this data as part
of the aggregation algorithm. Normalisation is a complex subject and is beyond the
current scope of this document.

Annex J – Key Quality Indictor Format
Based on the description of a KQI it is proposed that a KQI will be defined by the
following parameters:
Mandatory/ Weighting
Parameter Type Remarks
Optional Factor
Alpha-
Unique Identifier M NA
numeric
The weighting factor for all

Measurement
M KQI or KPI >0 - 1 measurements parameters
Parameter 1
should equal 1.
The Co-ordinated Universal

Measurement Time (UTC) string, that enables
O (see note
Parameter 1 String the identification of the time
3)
Time Zone zone the underlying KPI’s is/are
originated from.
Measurement
O Ditto >0 - 1
Parameter 2

O (see note
Parameter 2 String the identification of the time
3)
originated from.
Measurement
O Ditto >0 - 1
Parameter n

O (see note
Parameter n String the identification of the time
3)
originated from.

Optional Factor
This is the algorithm to be

applied to calculate the KQI
value from the combination of
Transformation measurement parameters and
M NA NA
Algorithm their weighting factors. The
simplest form of algorithm is ‘=’
where a single KPI becomes a
KQI.
This is the value that is used to

determine whether the
calculated KQI is within the
Objective Value O NA NA
target value. The value is used
to determine whether a violation
should be generated
The determine of whether a

breach occurs if the calculated
value is above or below the
objective value is determined by
Violation
O +ve or -ve NA this field. i.e. if this filed is –ve a
direction
violation or warning will be
generated if the calculated value
drops below the objective value
or warning threshold.
Optionally a % value may be

specified to give a warning that
Warning level O % NA
a KQI objective is in danger of
violating
This parameter introduces a

hysteresis factor to the warnings
Abatement
O % NA and alarms to prevent oscillation
threshold
between an alarm and a clear
condition.
This is the period over which the

Measurement
M Minutes NA KQI performance is calculated
Period
(see note 1)
How many times a value can

remain un-updated without
Grace Periods O # NA violation of the SLA in reference
to the Measurement Period and
/ or KQI reporting period

Optional Factor
A KQI measurement period may

be controlled by specifying a
start and stop time for the KQI
e.g. for a KQI that is only
A UTC
applicable between 9 a.m. and
string
5 p.m. this field would be set to
Active/Inactive A 09:00,17:00
O NA
period
If the two field is preceded with
I UTC
the letter A, the time period has
string
to be included, if preceded with
the letter I, the time period has
to be excluded from the
measurement.

Time (UTC) string, which
permits the identification of the
KQI Time Zone O UTC String time zone that the KQI is
originated from. Can be derived
from homogeneous KPI or
timestamp if valid.
List of days that the KQI

measurement is active or
inactive e.g. for a KQI that is
Active/Inactive A Day list measured from Monday through
O NA
days or I Day list Friday the list would be A
2,3,4,5,6 To exclude Saturday
and Sunday’s the list would be I
6,7
Note 1: As a KQI may be defined by a number of measurement parameters that

have differing sample periods it must use a sliding window technique for
calculating the current value. The current value will therefore be updated in ‘real
time’ as new data becomes available and aggregated over the time specified by
the measurement period.
Note 2: The Weighting Factor is optional. When applied it must be included for all
parameters. If omitted the effective weighting factor for all parameters are to be
considered as equal.
Note 3: If the time zone for parameter one is not stated then local time is assumed.
If the time zone for the subsequent parameters is not stated then the same time
zone for parameter 1 is applied.

KQI Sliding Window

Reporting
sample sample
Parameter 1 sample 1 sample 2 sample 3 4 5 sample 6
sample
Parameter 2 1 sample 2 sample 3
Parameter 3 sample 1 sample 2
KQI report 1
report 2
report 3
report 4
KQI reporting period
Figure J-1 KQI Sliding Window

Annex K – eTOM Mapping
The following text and figure provides a detail breakdown of the derivation and
application of service based measurements based on the process framework of
the eTOM (version 3).
The flow of service data shown in this section is based on a hierarchy of

measurements as described in the Section 0 and shows the end to end process
starting from the product development process through to managing the Service
Level Agreements associated with the offering.
RM&O Sales & Channel

Order Handling
Selling SLA Templates Readiness Management
Resource
usage SLA
Templates Target Product Target Product
KQIs KQIs
Product
Product & Offer Proposition
SLAs and Development &
Capability Delivery Requirements Retirement
Service catalogue Target Service

Target Internal SLA Customer QoS/
KQIs for Configuration &
Product Management SLA Management
Target KQIs Service Activation
Domains KQIs
Target KQIs Aggregrated
service
Target KPI
usage Internal definitions for
Service Strategy & Service & Ops. Technical SLAs and Service SLA/Service
measures KQIs Resources KQI mapping
Policy Capability Delivery & External SLAs Service Dev.
& Retirement
Service Plans
KQI/KPI
KQI usage mapping
Service
Target KQIs
Usage
Target KQI
Required Service KPIs for Resource
Element KPIs Actual Service Measurements Target KP I
Service Planning & definitions for
Element KPIs
Commitment Service
Supply Chain Resources
Capability
Resource & Ops. Availability
Service Resource
Capability
Element KPIs Development
Service Delivery Resource Data
Identify
Usage Resource Collection, Service Quality
Measurements Analysis & Analysis & Rpt
Control
Partner/S
upplier SLA Objectives
SM&O Supply chain

Readiness development
Resource usage RM&O
& change Readiness
mngmnt
The starting point for the flow is the Selling Process that captures the customer
expectations and drives these into the Product & Offer Capability Delivery process
where the outline SLA requirements for the product are derived and provided to
the Product Development & Retirement process. This process defines the SLA
templates for the product and provides the templates to the Order Handling
process. These SLA templates form the outlines for accepting customer orders.
The product target KQIs that define the quality objectives of the product are
derived by the Product Development & Retirement process from the SLA
requirements and passed to both Order Handling and Sales Channel
Management to assist with the product definition used for customer interaction.
Product Development & Retirement also delivers the product target KQIs to the
Service Strategy & Policy process that in turn provides the associated policy for

the definition of technical services to Service Development & Retirement via the
Service Planning and Commitment process. The same product target KQIs are
provided for the Service & Ops Capability Delivery process to enable it to
determine the technical measures and external SLA requirements to be provided
for Service Development & Retirement.
Target KQIs are also provided directly to the Service Development & Retirement
process. This process ‘decomposes’ these product KQIs into discreet service
KQIs, the KPIs and other KQIs that form that service KQI. This process will map
the product KQIs using where possible, existing KQIs and KPIs and will where
necessary define new key indicators. Where new KPIs are required, these are
sent to Resource & Ops Capability Delivery process that decomposes the
performance indicators into internal and external service resources and drives the
Resource Development and Supply Chain development & Change Management
processes respectively where they are decomposed into service resource
measurements. These measurements are provided to Resource Data Collection,
Analysis & Control for the collection of data from the service resources.
Additional information provided for the Service Development & Retirement process
from Service Planning and consists of service planning and forecasting information
that is used to ensure that the service objectives are sustainable over the longer
term i.e. as service utilisation increases.
Service
Service Quality SM&O Service Quality
KQI Violations Configuration &
Analysis & Rpt Readiness Analysis & Rpt
Activation
KQI Violations
for root
cause analysis
Other
Achieved
Achieved KPIs
KPIs Resources
Resource Problem Internal SLA Manage Achieved KPIs

Management Violations Internal SLA
KPI Violations
Analysis of KPI Violations

aggregated Real Time Performance
KPI Resource Problem
and usage data
performance
Resource
Restoration KPI Violations
Resource Quality Resource Data

Correlated
KPI Violations Analysis, Action & usage data
Collection &
RM&O Network Level Measurements Reporting Control
Readiness - Achieved KPI
Real Time Performance

Target KPI Target KPI and usage data
definitions for Service definitions for
Development & Supplier/Partner
Service Service
Retirement Performance Data
Resources Resources
Resource Resource Resource S/P Performance Resources

Measurements
usage Development Management (Equipment)
The target KPI definitions for service resources generated by Service

Development & Retirement are used by the RM&O Readiness and Resource
Quality Management sub processes as the quality objectives for the day-to-day
monitoring and analysis of groups of resources to ensure that the services that
depend on these resources are delivered efficiently.

The data that is processed by Resource Data Collection & Control is defined by
the target KPI definitions from the Service Development & Retirement process
and the resource measurements information identified by Resource Development.
This enables this process to aggregate the data and to pass it to the Resource
Quality Analysis Action & Reporting process that evaluates the real time
performance and usage data against the target KPIs. The process then provides
achieved KPI data to the RM&O Readiness, Service Configuration & Activation,
Service Quality Analysis & Reporting and SM&O Readiness processes. The KPI
violations are also provided to the Manage Internal SLA process (not explicitly
identified in the eTOM) to provide real time proactive management of SLA
focussed at the service resources. Data extracted by this process is also passed
to the S/P Performance Management process for the evaluation of quality levels of
parts of the service delivery chain that are outside of the provider’s business
boundary.
Customer QoS/
Manage Internal
SLA Problem Handling
SLAs
Management
KQI Violations
SM&O
Support & Process SLA violations
Management Analysis of aggregated
Target KQIs
forservice (ORT) KQI performance
KQI Violations
Service Problem
Target KQIs Management
forservice
SM&O Analysis of aggregated
KQI performance
Service Agrregated KQI Readiness R/T KQI
Development & performance Performance KQI Violations
Retirement
Customer QoS/
KQI Violations SLA
Management
R/T KQI
Achieved KPIs
Performance
Service Planning Service usage
Service Quality
Service Analysis & Rpt
Achieved KPIs
Configuration &
Service usage
Activation Supplier/Partner
KPI Violations SLA Violations
Achieved KPIs KQI/KPI Supplier/Partner

mapping Performance
KQI Violations
Target KQI
for root
Target KPI cause analysis
Service definitions for
Development & Service
Retirement Resources
Resource Data
Service Resource
Collection, S/P Performance
Development & Problem
Analysis & Management
Retirement Management
Control
Service Quality Analysis & Reporting is the hub of the service assurance process
model. By mapping the KPI data from Resource Data Collection, Analysis &
Control and using the mapping and target information from Service Development
& Retirement, the process is able to calculate the actual values for each KQI and
to compare these against the objectives for that KQI. Additional information from
Supplier Partner Performance Management (where appropriate) provides the
complete picture of end-to-end service quality. The two key outputs of the Service
Quality Analysis & Reporting process are;
Real time achieved KQI performance data sent to:
SM&O Readiness for longer term reporting and planning

Customer QoS/SLA Management for customer SLA compliance calculation
Manage Internal SLA for internal SLA compliance calculation
(the real time nature of this data enables proactive SLA management)
KQI violations
SM&O Readiness for longer term reporting and planning
Customer QoS/SLA Management for customer SLA compliance calculation
Manage Internal SLA for internal SLA compliance calculation
Service Problem Management for service problem tracking and to initiate

corrective action.
Resource Problem Management for resource problem tracking and to initiate

corrective action.
Customer
Service Quality R/T Achieved KQI

Analysis & Rpt Customer Information
on real time service status
Billing Adjustments
Customer Interface
Retention & Loyalty Management
SLA
Performance
SLA Performance
R/T Achieved KQI and violations
Target KQIs SLA Violations

Product for Product Sales & Channel Billing and
Development & Mgmnt
Retirement
SLA violation Collections
Target KQIs #Rebate authiority
for Product
SLA Management
Violations
SLA
CRM Readiness Order Template Problem Handling violations
including SLAs Order Handling Service Problem
(Ordering Readiness) Customer Specific SLAs (Real Time) for Handling
RCA
SLA Template
SLA Template
Customer QoS/
SLA SLA
Violations SLA Violations
Analysis of aggregated Management
KQI performance
KQI Violations KQI Violations

Service
Development & Real Time
Retirement SM&O KQI Service Quality
Readiness performance Analysis & Rpt
The KQI performance data and violations provided to the Customer QoS / SLA
Management process enable real time proactive management of specific
customer SLAs. By mapping the KQIs against the SLAs provided via the CRM
Readiness (Order Readiness) and Order Handling process, this process is able to
calculate actual SLA performance and to present this information to the customer
via Customer Interface Management. SLA violations or degradations are handled
through the interface with Problem Handling and Sales & Channel Management
processes and, where appropriate, corrections to customer billing is invoked by

sending violation information to Billing Collections and Management. To complete

the ‘management loop’, Problem Handling is able to invoke corrective action via its
interface with Service Problem Handling.
Resource Data
Service Resource & Ops.
Collection,
Capability
Development & Analysis &
Delivery
Retirement Control
Partner/Supplier
SLA Objectives S/P Problem
KQIs Reporting &
Management
Supplier/Partner
Performance Data
Supplier/Partner
SLA Violations
Supply Chain Supply chain S/P Performance S/P Settlements

Partner/Supplier SLA Supplier/Partner
Capability SLA development Objectives Management SLA Violations & Billing Mgmnt
Availability & change mngmnt (&SLA)
External to Organisation:
Supplier/Partner
Suppliers & Partners Supplier/PartnerSLA Violations
S/P Performance
Service Quality SLA Performance
Analysis & Rpt data
Service Quality
Analysis & Rpt
Where service resources outside of the provider’s business boundary are used to
complete the service delivery chain, Supplier / Partner service levels are managed
based on the KQIs provided by Service Development & Retirement and
processed, by Supply Chain Capability Availability and Supply Chain Development
& Change Management, into Supplier Partner SLA objectives. From the data
provided by Resource Data Collection Analysis & Control and S/P Service Quality
Analysis & Reporting, S/P Performance Management (and SLA Management) is
able to track Supplier / Partner service levels and to provide performance data into
Supplier / Partner Problem Reporting for tracking of service level problems, into
Service / Partner Settlements and Billing Management for accounting (rebate)
purposes and to Service Quality Analysis & Reporting for overall end-to-end
service level management.

Administrative Appendix
This Appendix provides additional background material about the

TeleManagement Forum and this document. In general. sections may be included
or omitted as desired, however a Document History must always be included..
About this document
This is a TM Forum Guidebook. The guidebook format is used when:

¾ The document lays out a ‘core’ part of TM Forum’s approach to
automating business processes. Such guidebooks would include
the Telecom Operations Map and the Technology Integration Map
but not the detailed specifications that are developed in support of
the approach.
¾ Information about TM Forum policy, or goals or programs is
provided, such as the Strategic Plan or Operating Plan.
¾ Information about the marketplace is provided, as in the report on
the size of the OSS market.
Document Life Cycle
GB 917-2 is the initial version of Volume 2 of the SLA Management Handbook

Version 2.0. The four Volumes of Version 2.0 of the SLA Management Handbook
supercede the previous versions of the SLA Management Handbook.
<<If there is anything unique about the life cycle, explain it here. For example, the
Operating Plan is to be updated at least twice a year, to show a rolling 12-month
forward view of programs. If nothing special, just put in the next paragraph.>>

Document History
Version History
<This section records the changes between this and the previous document
version as it is edited by the team concerned. Note: this is an incremental number
which does not have to match the release number>
Version Date Modified By Description of changes

Modified
Development Version October 2002 First mapping of existing text into Vol
1.0 2
Development Version February 2003 Revised Version for Brussels

1.1
Development Version May 2003 Revised Version for Malvern Meeting

1.2
Development Version August 2003 Revised Version for Team Conference

1.3 Call
Development Version December SLA/QoS Team Review Version

1.4 2003
Development Version January 2004 Revised Version For Dublin Team

1.5 Meeting
Member Review Version April 2004 Submitted for TMF Member Review
2.0
Member Evaluated Ver January 2005 Modifications prior to web posting.

2.1
Team Version 2.2 January 2005 Modified template for next version
generation.
Team Version 2.3 May 2005 Input to Nice Team Meeting
Team Version 2.4 10 June 2005 Tina O'Sullivan Updated Logo & address, other minor
cosmetic changes. Version to be sent
to Approvals Committee.
Member evaluation 20-July-05 Tina O’Sullivan Final modification prior to web posting
Version 2.5 for Member Evaluation.
Release History
<This section records the changes between this and the previous Official
document release>

Release Number Date Modified Modified by: Description of

changes
Release 2.5 06-June-05
Document History
How To Obtain Copies
This document version is available from the TMF Central Web Site.
How To Comment On This Document
Readers are encouraged to provide comments to the SLA Management Team via
email.
Suggestions for comments:
In order to reduce file size, comments should reference only relevant paragraphs,
including identifying paragraph headers.
1) Be specific. Consider that you might be on a team trying to produce a
single text through the process of evaluating numerous comments. We
appreciate significant specific input. We are looking for more input than a
“word-smith”, however, structural help is greatly appreciated where clarity
benefits.
2) What to look for: errors, omissions, lack of clarity and missing references to
other accomplished work (please cite exact applicable section(s) of other
documents).
3) Suggestions to further develop or expand a specific area are welcome.
However, the reader should be aware that this work is intended to be a

handbook, not an exhaustive thesis, and it is not the intent to duplicate

other work.
4) Email all comments to the document Editor, Tobey Trygar,
ttrygar@telcordia.com, with a copy to the team leader, Kelly Flynn-Muller,
kmuller@internap.com.
Acknowledgments
TeleManagement Forum would like to thank the following individuals for

contributing their time and expertise to Version 2.5 of Volume 2 of the SLA
Management Handbook series.
¾ Greg Bain, National Communications System (NCS)
¾ David Banes, TenTen Communications
¾ Debbie Burkett, TeleManagement Forum
¾ Kelly Flynn-Muller, Internap Network Services (Team Leader)
¾ Jane Hall, GMD FOKUS
¾ Malcolm Sinton, QinetiQ, (Team Leader 2002 – 2004)
¾ Carolyn Smithson, O2
¾ Tobey Trygar, Telcordia Technologies (GB 917 Volume 2 Editor)
A number of people and organizations have provided input and comments to the
SLA Management team on its work. Although not an exhaustive list, the
TeleMangement Forum also extends a thank you to the following individuals for
their interest and support.
¾ The Open Group
¾ Sandro Borioni, Sodalia SpA
¾ Stephen Cross, Nortel Networks
¾ Bill DeYoung, Verizon (Team Sponsor to 2001)
¾ Jock Embry, Opening Technologies
¾ John Gormont, Spirent Communications
¾ Peter Huckett, ACTERNA
¾ Peter Jasion, Tivoli
¾ Håkan Kappelin, Ericsson
¾ Mahmood Karbasi, Oracle
¾ Veli Kokkonen, Sonera
¾ Han-Young Lee, Korea Telecom

¾ Hans Pettersson, EHPT

¾ Ranveer (Ran) Rathore, NASA
¾ Paul Short, TeleManagement Forum
¾ Alessandro Zorer, Sodalia SpA
¾ Lightsey Wallace, Lightsey Enterprises (Team Leader 2001 - 2002)
The Wireless Service Measurements (WSM) Handbook was prepared by the
following members of the WSM Team:
¾ Aline Allul, Evidian
¾ Richard Arthur, Compaq
¾ Ian Best, Comnitel Technologies (Team Leader)
¾ Steve Bowker, WatchMark
¾ Andy Chalmers, Orange
¾ Richard Deininger, Marconi
¾ Christian Dinten, Agilent Technologies
¾ Rosario Drogo De Iacovo, TILab
¾ Phil Green, Vodafone
¾ Dia Helmy, NEC America
¾ David High, AirCom
¾ Peter Holland, Lucent Technologies
¾ Peter Huckett, Acterna
¾ Håkan Kappelin, Ericsson
¾ Veli Kokkonen, Sonera
¾ Martina Kurth, Lucent Technologies
¾ Ahcène Latrèche, Evidian
¾ Marta Liminiana, Telefonica Moviles España
¾ Tim Lock, ADC
¾ Scott Marshall, Agilent Technologies
¾ Steve McElvanney, TCSI
¾ Loles Noves, Telefonica Moviles España
¾ Michael Orzessek, Agilent Technologies
¾ Pertti Pielismaa, Nokia
¾ Laure Reillier, WatchMark
¾ Sam Sida, ADC
¾ Carolyn Smithson, O2 (GB 923 Editor)

¾ Thomas Tenevall, KI Consulting
About TeleManagement Forum
TeleManagement Forum is an international consortium of communications service

providers and their suppliers. Its mission is to help service providers and network
operators automate their business processes in a cost- and time-effective way.
Specifically, the work of the TM Forum includes:
Establishing operational guidance on the shape of business processes.
Agreeing on information that needs to flow from one process activity to
another.
Identifying a realistic systems environment to support the
interconnection of operational support systems.
Enabling the development of a market and real products for integrating
and automating telecom operations processes.
The members of TM Forum include service providers, network operators and
suppliers of equipment and software to the communications industry. With that
combination of buyers and suppliers of operational support systems, TM Forum is
able to achieve results in a pragmatic way that leads to product offerings (from
member companies) as well as paper specifications.

SLA Management Handbook: Concepts and Principles

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SLA Management Handbook: Concepts and Principles

Uploaded by

Copyright:

Available Formats

SLA Management Handbook

Concepts and Principles

Member Evaluation, Version 2.5 July 2005

TeleManagement Forum 2005

The TeleManagement Forum (“TM Forum”) has

240 Headquarters Plaza

GB917-2 Version 2.5 TeleManagement Forum 2005 Page ii

The Service Level Agreement (SLA) Management Handbook series consists of

Service Providers have historically reported the performance of their networks

GB917-2 Version 2.5 TeleManagement Forum 2005 Page iii

GB917-2 Version 2.5 TeleManagement Forum 2005 Page iv

GB917-2 Version 2.5 TeleManagement Forum 2005 Page v

Service Measurement Considerations...................................................................................20

GB917-2 Version 2.5 TeleManagement Forum 2005 Page vi

3.1.20 Service Degradation Factor (SDF) ....................................................................... 50

GB917-2 Version 2.5 TeleManagement Forum 2005 Page vii

5.1.5 The Assessment Phase ........................................................................................83

GB917-2 Version 2.5 TeleManagement Forum 2005 Page viii

6.1.8 Changing The Reporting Mode .......................................................................... 107

GB917-2 Version 2.5 TeleManagement Forum 2005 Page ix

Document Life Cycle.............................................................................................................199

GB917-2 Version 2.5 TeleManagement Forum 2005 Page x

Figure 1-1: Service Delivery Relationships ......................................................................4

Figure 1-2: The SLA Management Handbook Documents ............................................4

Figure 2-1: SLA At The Customer-Service Provider Interface.................................... 15

Figure 2-2: Service Provider Centric eTOM Business Relationship Model.............. 16

Figure 2-3 End-To-End Service Challenge ................................................................... 17

Figure 2-4 Customer Viewpoint Of Service.................................................................. 18

Figure 3-1: Service Functions And Service Resources .............................................. 23

Figure 3-2: Networks Services - Business Services And Applications ................... 24

Figure 3-3: Layered Service Architecture...................................................................... 25

Figure 3-4: Customer Contact Point Reference Model................................................ 27

Figure 3-5: Simplified ATM/SDH/PDH Network............................................................. 28

Figure 3-6: A Service Access Point Example ............................................................... 29

Figure 3-7: Network Performance – Service Performance Relationship ................. 31

Figure 3-8: Traffic Engineering Tasks Per E.490.1....................................................... 35

Figure 3-9 Key Indicator Hierarchy................................................................................ 37

Figure 3-10 KQI Identification......................................................................................... 38

Figure 3-11: Four Views Of Quality Of Service ............................................................. 42

Figure 3-12 Inter-Relationships Between Various Viewpoints Of QoS .................... 43

Figure 3-13: Service Specification Model...................................................................... 46

Figure 3-14: Factors Contributing To Quality Of Service............................................ 46

Figure 3-15: Relationship Of Service Availability To Service Performance ............. 48

Figure 3-16: Time To Restore Service (TTRS) Illustration........................................... 61

GB917-2 Version 2.5 TeleManagement Forum 2005 Page xi

Figure 3-17: Service Ordering Process Sequence Diagram........................................62

Figure 3-18: Time To Provide Service Tolerance..........................................................63

Figure 4-1: eTOM Level 0 View Of Level 1 Process Groupings ..................................66

Figure 4-2 SLA Universe..................................................................................................70

Figure 4-3 End-To-End SLA Management ....................................................................71

Figure 4-4 Product Components ....................................................................................72

Figure 4-5: Bundle Composition .....................................................................................73

Figure 4-6: Service Contract Relationships...................................................................74

Figure 4-7: Components Of An SLA Template..............................................................75

Figure 4-8: SAP Relationship And Activity Diagrams ..................................................76

Figure 4-9: Service Composition Example ....................................................................77

Figure 4-10: Service Delivery Across Multiple Service Domains ...............................78

Figure 4-11: Multiple Domain SLA Relationships - Case 1..........................................78

Figure 4-12: Multiple Domain SLA Relationships - Case 2..........................................79

Figure 5-1: Service And Associated SLA Life Cycle ....................................................81

Figure 5-2 KQI Methodology ...........................................................................................85

Figure 5-3 Customer Experience Timeline....................................................................86

Figure 5-4 Developing The Transaction Matrix ............................................................88