GB917-2 - Ver2!0!040422 - Concepts and Principles

SLA Management Handbook
Volume 2
Concepts and Principles
GB 917-2
Version 2.0
April 2004
SLA Management Handbook Vol 2
Page i
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:
89 Headquarters Plaza North - Suite 350
Morristown, NJ 07960 USA
Tel No. +1 973 292 1901
Fax No. +1 973 993 3131
TM Forum Web Page: www.tmforum.org
TeleManagement Forum 2004
GB 917-2 Version 2.0
Page iii
Acknowledgements
TeleManagement Forum would like to thank the following individuals for contributing
their time and expertise to the production of the SLA Management Handbook series.
Greg Bain, National Communications System (NCS)
David Banes, TenTen Communications
Debbie Burkett, TeleManagement Forum
Jane Hall, GMD FOKUS
Peter Huckett, ACTERNA
Ranveer (Ran) Rathore, NASA
Malcolm Sinton, QinetiQ, (Team Leader)
Tobey Trygar, Telcordia Technologies (Volume 2 Editor)
Lightsey Wallace, Lightsey Enterprises (Team Leader 2001 - 2002)
A number of people and organizations have provided input and comments to the
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 Jasion, Tivoli
Hkan Kappelin, Ericsson
Mahmood Karbasi, Oracle
Veli Kokkonen, Sonera
Han-Young Lee, Korea Telecom
Hans Pettersson, EHPT
Paul Short, TeleManagement Forum
Alessandro Zorer, Sodalia SpA
Page v
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
interconnection of operational support systems,
to
support
the
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 lead to product offerings (from
member companies) as well as paper specifications.
Page vii
About This Document

This is a TM Forum Guidebook. The guidebook format is used when:
The document lays out a core part of TM Forums 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.
Document History
Version
Date
Purpose
Development Version 1.0
October 2002
First mapping of existing text into Vol 2
February 2003
Revised Version for Brussels
May 2003
Revised Version for Malvern Meeting
August 2003
Revised Version for Team Conference Call
December 2003
SLA/QoS Team Review Version
January 2004
Revised Version For Dublin Team Meeting
Member Review Version 2.0
April 2004
Submitted for TMF Member Review
Page viii
SLA Management Handbook - Vol 2
Time Stamp
This version of the SLA Management Handbook is valid until a revision is issued.
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, Malcolm Sinton,
mjsinton@qinetiq.com.
Page ix
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 two tools that provide the foundation for
clarifying management roles, processes, responsibilities and expectations. These are
the Life Cycle of the Service and the SLA Parameter Framework.
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.
Page x
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].
Page xi
Table of Contents
Notice ................................................................................................................................................ i
Acknowledgements ...................................................................................................................... iii
About TeleManagement Forum.................................................................................................... v
About This Document.................................................................................................................. vii
Document Life Cycle ...............................................................................................................vii
Document History....................................................................................................................vii
How To Obtain Copies ...........................................................................................................viii
How To Comment On This Document .................................................................................. viii
Executive Summary ...................................................................................................................... ix
Table of Contents .......................................................................................................................... xi
List of Figures ............................................................................................................................. xvii
List Of Tables ............................................................................................................................... xix
Chapter 1 -
Introduction ............................................................................................................. 1
1.1
The Drivers For Service Level Agreements................................................................... 1
1.2
SLA Business Relationships........................................................................................... 2
1.3
Scope .............................................................................................................................. 3
1.4
Handbook Benefits.......................................................................................................... 6
1.4.1
Service Providers .................................................................................................... 6
1.4.2
Customers ............................................................................................................... 6
1.4.3
Equipment And Software Vendors ......................................................................... 6
1.5
Notes For Readers.......................................................................................................... 7
1.6
Overview.......................................................................................................................... 7
Chapter 2 2.1
Business Considerations .................................................................................... 11
Introduction.................................................................................................................... 11
2.1.1
SLAs In The Evolving Marketplace....................................................................... 11
2.2
The Business Model ..................................................................................................... 12
2.3
Business Benefits.......................................................................................................... 14
2.3.1
Customer Benefits................................................................................................. 14
2.3.2
Service Provider Benefits...................................................................................... 15
Page xii
2.3.3
Supplier Benefits ................................................................................................... 15
2.4
Service Performance Parameter Selection ................................................................. 15
2.5
Service Measurement Considerations......................................................................... 16
2.5.1
Performance Parameters And Metrics................................................................. 16
2.5.2
Performance Measurement Methodology............................................................ 17
2.6
Anticipating Change...................................................................................................... 18
Chapter 3 -
Telecommunications Services ........................................................................... 19
3.1
Service Characterization .............................................................................................. 19
3.2
The Enterprise View ..................................................................................................... 20
3.3
Service Elements.......................................................................................................... 20
3.4
Service Containment And Management Domains ...................................................... 22
3.5
Customer Contact Point Reference Model .................................................................. 22
3.6
Service Access Points .................................................................................................. 23
3.6.1
Definition................................................................................................................ 23
3.6.2
SAP Examples ...................................................................................................... 24
3.6.3
Multiple SAP Services........................................................................................... 25
3.6.4
Single SAP Services ............................................................................................. 25
3.6.5
Regulatory Issues ................................................................................................. 26
3.7
Performance Perspectives ........................................................................................... 26
3.7.1
Service Performance Factor Definitions............................................................... 27
3.7.2
Network Performance Factors.............................................................................. 27
3.7.3
Events And Performance Parameters ................................................................. 28
3.7.4
Network Performance - Service Performance Distinctions ................................. 28
3.7.5
The Role Of Traffic Engineering ........................................................................... 30
3.8
Quality Of Service......................................................................................................... 31
3.8.1
User Perception..................................................................................................... 31
3.8.2
Customer Satisfaction........................................................................................... 33
3.8.3
Views Of QoS........................................................................................................ 33
3.8.4
Service Performance Specification Model ........................................................... 34
3.8.5
Assessing Performance........................................................................................ 35
3.9
Service Availability ........................................................................................................ 37
3.9.1
Customer Perspective........................................................................................... 37
3.9.2
Service And Network Performance Perspective.................................................. 37
3.9.3
Computing Basic Service Availability ................................................................... 39
3.9.4
Service Degradation Factor (SDF) ....................................................................... 39
Page xiii
3.9.5
SAP Weighting ...................................................................................................... 40
3.9.6
SAP Attributes And Parameters ........................................................................... 41
3.9.7
Service Availability Information Sources .............................................................. 44
3.9.8
Service Availability And Layered Protocols .......................................................... 45
3.9.9
Service Availability Levels..................................................................................... 45
3.10 Emergency Priority Service .......................................................................................... 46

3.10.1 The Service Definition ........................................................................................... 47
3.10.2 ETS Performance.................................................................................................. 49
3.11 Selected Service Considerations ................................................................................. 50
3.11.1 Time To Restore Service ...................................................................................... 50
3.11.2 Time To Provide Service....................................................................................... 51
3.11.3 Service Delay......................................................................................................... 53
3.11.4 Service Access...................................................................................................... 53
3.11.5 Throughput ............................................................................................................ 54
3.11.6 Errors ..................................................................................................................... 54
Chapter 4 4.1
SLA Content And Management .......................................................................... 55
Content Recommendations.......................................................................................... 55
4.1.1
The Fulfillment Process......................................................................................... 56
4.1.2
The Assurance Process........................................................................................ 57
4.1.3
Customer Interface Management......................................................................... 58
4.1.4
General Recommendations.................................................................................. 58
4.2
Relating SLAs To Product Offerings ............................................................................ 59
4.2.1
Role Of SLAs Within Service Products ................................................................ 60
4.2.2
Defining Service Commitments ............................................................................ 61
4.2.3
SLA To Service Mapping ...................................................................................... 63
4.2.4
Service Example ................................................................................................... 63
4.3
Multiple Domain SLAs .................................................................................................. 64
Chapter 5 5.1
SLA Management Tools....................................................................................... 67
The SLA Life Cycle ....................................................................................................... 67
5.1.1
The Product/Service Development Phase ........................................................... 68
5.1.2
The Negotiation And Sales Phase........................................................................ 69
5.1.3
The Implementation Phase................................................................................... 70
5.1.4
The Execution Phase............................................................................................ 70
5.1.5
The Assessment Phase........................................................................................ 70
5.1.6
The Decommissioning Phase............................................................................... 71
GB 917 -2 Version 2.0
Page xiv
5.2
Use Cases And Scenarios ........................................................................................... 71
5.3
The SLA Parameter Framework .................................................................................. 72
5.3.1
Network Bearer Services And Application Services ............................................ 72
5.3.2
Parameter Categories........................................................................................... 73
5.3.3
Service Views........................................................................................................ 74
5.3.4
The Service Parameter Table Examples ............................................................. 74
5.3.5
Service/Technology Independent Parameters..................................................... 75
5.3.6
Technology-Specific Parameters ......................................................................... 76
5.3.7
Service Specific Parameters................................................................................. 77
5.3.8
Service Degradation.............................................................................................. 78
5.3.9
Management Of Service And Network Performance .......................................... 79
5.4
SLA Data Management................................................................................................ 79
5.4.1
Chapter 6 6.1
Role Of In-Service Monitoring............................................................................... 81

SLA Performance Reporting............................................................................... 83
Measurement And Reporting Intervals ........................................................................ 83
6.1.1
Measurement Considerations............................................................................... 83
6.1.2
Events And Reporting........................................................................................... 84
6.2
Performance Reporting ................................................................................................ 85
6.2.1
Role Of The Performance Reporting Process ..................................................... 85
6.2.2
Process Functions Addressed.............................................................................. 86
6.3
The Reporting Functional Interfaces............................................................................ 86
6.4
Reporting Scenarios ..................................................................................................... 87
6.4.1
Reporting With Acknowledgement ....................................................................... 87
6.4.2
Reporting Via Drop-Off ......................................................................................... 87
6.4.3
Reporting On Demand.......................................................................................... 88
6.4.4
Changing The Reporting Mode ............................................................................ 89
6.5
State Model ................................................................................................................... 90
6.5.1
6.6
Events And State Transitions ............................................................................... 91
Reporting Intervals........................................................................................................ 92
6.6.1
Measurement Interval ........................................................................................... 92
6.6.2
Data Collection Interval......................................................................................... 92
6.6.3
Aggregate Interval................................................................................................. 92
6.6.4
Example................................................................................................................. 93
6.7
Types Of Reports.......................................................................................................... 93
6.8
Common Report Formats............................................................................................. 93
6.9
Page xv
Performance Report Content........................................................................................ 94
6.9.1
Service-Independent Measurements ................................................................... 94
6.10 Traffic Data Report Content.......................................................................................... 95

References..................................................................................................................................... 96
Acronyms ...................................................................................................................................... 99
Annex A - Terms and Definitions .............................................................................................104
Annex B - Executive Summary For Volume 1 ........................................................................112
Annex C - Executive Summary For Volume 3 ........................................................................113
Annex D - Executive Summary For Volume 4 ........................................................................114
Annex E Performance Specification References ...............................................................116
E.1 Guidelines For References............................................................................................116
E.1.1
Conditions............................................................................................................116
E.1.2
Essential Findings ...............................................................................................116
E.2 Document List .............................................................................................................116

E.3 Document Abstract .....................................................................................................118
E.4 Directory ......................................................................................................................122
Annex F Report Information Sources...................................................................................124
F.1
Information Required For Service Availability Calculation.........................................124
F.2
Additional Information For Performance Reports ......................................................124
F.3
Information Required From The Network...................................................................124
F.4
The Use Of Common Objects ....................................................................................125
F.5
Initial Administrations ..................................................................................................125
F. 6 Data Collection............................................................................................................125
F.7
Data Computation And Aggregation ..........................................................................126
Annex G - Perceived And Delivered Performance ................................................................127

G.1 Application...................................................................................................................127
G.2 Process........................................................................................................................128
G.3 Delivered SA ...............................................................................................................129
G.4 Perceived SA ..............................................................................................................129
G.5 Numerical Example.....................................................................................................129
G.6 Further Work ...............................................................................................................130
Annex H - SLA Lifecycle Use Cases........................................................................................131
H.1 Product Development With A New SLA .......................................................................132
H.2 Negotiation And Sales...................................................................................................134
H.3 Implementation Of An Order .........................................................................................136
Page xvi
H.4 Normal Execution .......................................................................................................... 138

H.5 Execution With SLA Violation ....................................................................................... 143
H.6 Assessment ................................................................................................................... 147
Page xvii
List of Figures
Figure 1-1: Service Delivery Relationships ..................................................................... 3
Figure 1-2: Structure Of The SLA Management Handbook Series .............................. 4
Figure 2-1: Service Provider Centric eTOM Business Relationship Model .............. 13
Figure 2-2: SLA At The Customer-Service Provider Interface.................................... 13
Figure 3-1: Service Functions And Service Resources............................................... 19
Figure 3-2: Networks Services, Business Services And Business Applications ... 20
Figure 3-3: Layered Service Architecture...................................................................... 21
Figure 3-4: Customer Contact Point Reference Model................................................ 23
Figure 3-5: Simplified ATM/SDH/PDH Network............................................................. 24
Figure 3-6: A Service Access Point Example................................................................ 25
Figure 3-7: Network Performance Service Performance Relationship ................. 26
Figure 3-8: Traffic Engineering Tasks Per E.490.1 ....................................................... 30
Figure 3-9: Three Views Of Quality Of Service.............................................................. 33
Figure 3-10: Service Specification Model ...................................................................... 35
Figure 3-11: Factors Contributing To Quality Of Service ............................................ 36
Figure 3-12: Relationship Of Service Availability To Service Performance ............. 38
Figure 3-13: Time To Restore Service (TTRS) Illustration........................................... 50
Figure 3-14: Service Ordering Process Sequence Diagram ....................................... 51
Figure 3-15: Time To Provide Service Tolerance.......................................................... 52
Figure 4-1: eTOM Level 0 View Of Level 1 Process Groupings.................................. 55
Figure 4-2: Product Composition.................................................................................... 60
Figure 4-3: Service Contract Relationships .................................................................. 61
Page xviii
Figure 4-4: Components Of An SLA Template ............................................................. 62

Figure 4-5: SAP Relationship And Activity Diagrams ................................................. 63
Figure 4-6: Service Composition Example.................................................................... 64
Figure 4-7: Service Delivery Across Multiple Service Domains................................. 65
Figure 4-8: Multiple Domain SLA Relationships - Case 1 ........................................... 65
Figure 4-9: Multiple Domain SLA Relationships - Case 2 ........................................... 66
Figure 5-1: Service And Associated SLA Life Cycle.................................................... 68
Figure 5-2: Service Parameter Category Framework.................................................. 73
Figure 5-3: Service Functions-Parameter Categories Relationship ......................... 73
Figure 5-4 Typical Service Parameters ......................................................................... 74
Figure 5-5: IP Service With DSL Access........................................................................ 75
Figure 5-6: ATM Cell Delivery Service............................................................................ 75
Figure 5-7: Availability Performance Measures............................................................ 77
Figure 5-8: SLA Related Data .......................................................................................... 80
Figure 5-9: SLA Performance Data Collection.............................................................. 80
Figure 5-10: Performance Levels For Related Services.............................................. 81
Figure 6-1: Time Line For Reporting Network And Service Incidents....................... 84
Figure 6-2: eTOM Customer Relationship Management Processes ......................... 85
Figure 6-3: Performance Reporting Interface ............................................................... 86
Figure 6-4: Reporting With Acknowledgement ............................................................ 87
Figure 6-5: Reporting Via Drop-Off................................................................................. 88
Figure 6-6: Reporting With Acknowledgement And Optional Logging .................... 89
Figure 6-7: On-line Performance Reporting Control.................................................... 90
Figure 6-8: Performance Reporting Process State Model .......................................... 91
Page xix
List Of Tables
Table 3-1: Service And NP Specification Characteristics ........................................... 29
Table 3-2 Mapping Of Service Unavailability Causes .................................................. 38
Table 3-3: Example OF Service Degradation Factors.................................................. 40
Table 3-4: Billing, Performance And Availability Relationships................................. 40
Table 3-5: SAP Attributes And Parameters ................................................................... 41
Table 3-6: ETS Functional Requirements ...................................................................... 48
Table 3-7: ETS Performance Mapping............................................................................ 49
Table 6-1: Significant Times For Performance Reporting........................................... 84
Table 6-2: Performance Reporting Events And States................................................ 91
Page 1
Chapter 1 - Introduction
1.1 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.
Page 2
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 Customers 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 its 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.
1.2 SLA Business Relationships

A Service Level Agreement (SLA) is 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
Page 3
for specifying the Level of Service (LoS) and the 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 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
1.3 Scope
Volume 2 of the SLA Handbook series addresses SLA Principles. It is part of the
four volume series on SLA Management. Figure 1-2 describes the relationship
among the four volumes. Annexes 2 through 4 contain the Executive Summaries
from the other three volumes. The SLA Handbook series was jointly developed by
the TeleManagement Forum and the Open Group.
Page 4
Figure 1-2: Structure Of The SLA Management Handbook Series

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 two tools, viz., the six-stage Service Life Cycle and the
SLA Parameter Framework. These tools are the key technical contributions of
Volume 2.
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
The main focus of this Handbook is on business and government Customers as opposed to SPs as customers of other
SPs.
Page 5
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
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
Page 6
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.
1.4 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.4.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
SPs internal processes, assigning internal processes according to SLAs, and
responding to SLA requirements from other SPs.
The Handbook helps an SP introduce operational changes, improve internal
measurements and reporting, enrich Customer relations and differentiate itself
from its competitors.
1.4.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.
1.4.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 clients needs through Volume 3 examples of services to be managed
and the performance parameters to be measured, reported and processed.
Page 7
1.5 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 edgeto-edge service is one that spans a Service Providers 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.
1.6 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 SPs 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.
Page 8
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 servicespecific 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
Page 9
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.
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.
Page 11
Chapter 2 - Business Considerations
2.1 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.
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 SPs standard reports.
Page 12
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.
2.2 The Business Model

The SLA Handbook makes use of the TM Forums 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-1 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-1 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
providers 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-1 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.
Page 13
Figure 2-1: Service Provider Centric eTOM Business Relationship Model

Figure 2-2 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 partys views, requirements and responsibilities. See Chapter 4 for
additional information on SLA content and roles.
Figure 2-2: SLA At The Customer-Service Provider Interface
Page 14
2.3 Business Benefits

2.3.1 Customer Benefits
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 endto-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 technologyspecific service and network parameters and the technology/serviceindependent 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
SPs 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
services 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.
Page 15
2.3.2 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 Customers 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.3.3 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.
2.4 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:
See Chapter 3 for a detailed discussion of service parameters.
Page 16
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.
2.5 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.5.1 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.
Page 17
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.5.2 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.
Page 18
2.6 Anticipating Change

Since it is highly likely that a Customers 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.
Page 19
Chapter 3 - Telecommunications Services
3.1 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,
Page 20
service resources enable service functions. The three fundamental types of service
resources are hardware/software resources, staff resources, and intellectual
property/licenses resources.
3.2 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 Business Applications

The Enterprises 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.
3.3 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
Page 21
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.
The integrating Service Provider (Service Provider 1) must then ensure that the
See Section 3.9 for a discussion of Service Availability.
See Section 3.6 for a discussion of SAPs and SAP Groups.
Page 22
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.
3.4 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.
3.5 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
Page 23
Providers 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 Customers 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.
3.6 Service Access Points

3.6.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 Providers responsibility therefore includes a
service and its associated service elements that are provided at the specified
SAPs.
Page 24
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.6.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
Page 25
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 Providers responsibility may, where permitted by law, include all or parts
of the CPE, the access lines and the Providers backbone network/service
platform.
Figure 3-6: A Service Access Point Example
3.6.3 Multiple SAP Services

When the service-related interactions or traffic between Customer locations cross
the boundary of a Service Providers 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.6.4 Single SAP Services

When the service-related interactions or traffic between a Customer and Service
Provider cross the boundary of the Service Providers 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 Providers Web server via a SAP.
2) Receiving service performance management reports from the Service
Provider at the Customers SAP.
3) Exchanging trouble reports between the Customer and the Service
Provider at the Customers SAP.
Page 26
4) Exchanging invoices, ordering requests, and billing information between

the Customer and the Service Providers facility involving a single SAP.
3.6.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.
3.7 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
Page 27
3.7.1 Service Performance Factor Definitions

The service performance factors are defined in the following paragraphs. See
Section 3.8 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.7.2 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.
Page 28
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.7.3 Events And Performance Parameters

The distinction between the Customers 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 services 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.7.4 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
Time to first yield is defined as the time interval between initiating service and the first reportable service-impacting
event.
Page 29
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 userperceivable 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
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 not 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.
Page 30
3.7.5 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.
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.
See Section 3.8 for the E.800 definition of QoS.
Page 31
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 Operators 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.
3.8 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.
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.8.1 User Perception

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 users perception of QoS is relative or
absolute. For example, is the users 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
Page 32
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 userperceived 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 IPbased 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.
Page 33
3.8.2 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.8.3 Views Of QoS

Figure 3-9 is a class diagram that shows the three 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.
Figure 3-9: Three Views Of Quality Of Service
3.8.3.1 Traffic Engineering Applications

As noted in Section 3.7.5, 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
Page 34
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.7.5 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.8.3.2 Target Values

The second use of the QoS concept is in the specification of performance levels
for SLAs, i.e., the service providers commitment to the customer. This usage
requires that QoS be characterized in terms of quantifiable, measurable
parameters.
The E.800 QoS definition quoted in Section 3.8 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.8.4 for a
discussion of how this concept of QoS is used for performance specifications in
SLAs.
3.8.3.3 Delivered QoS

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.8.4 Service Performance Specification Model

Figure 3-10 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.
Page 35
As shown in Figure 3-10 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 Customers 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-10: Service Specification Model

Figure 3-10 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.8.5 Assessing Performance

The delivered QoS values provide a measure of how well the delivered service
matches the contracted service. As discussed in Section 3.7, service performance
Page 36
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-11 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 Customers experiences.
Figure 3-11: 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 Customers 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,
Page 37
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.9.4 for a discussion on the
use of Service Degradation Factors.
3.9 Service Availability

3.9.1 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.7.1 and 3.7.2, 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.9.2 Service And Network Performance Perspective

Figure 3-12 shows the relationship between service availability and the service
performance factors described in Figure 3-7 and in Section 3.7.1. The relative
importance of Accessibility Performance, Retainability Performance, and Integrity
Performance to Service Availability must be determined on a case-by-case basis.
Page 38
Figure 3-12: 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
Factor
Capacity Shortfall
Denial Of Service
Trafficability
Security
Design Shortfall
Misuse
Planning
Operability
New Use Patterns

Operator Error
Network Performance
Factor
Planning
Security
Propagation Impairments
Transmission
Reliability
Dependability
Support Service Limitations

User Overload
Traffacibility / Planning
Planning
Page 39
3.9.3 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-toend 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.9.4 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 Customers business need.
Page 40
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)
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
available
Customer happy with it
..
.
..
.
..
.
Table 3-4 presents the relationship between Billing, Availability, and Degraded
Performance. SDF enables the definition and orderly application of measures for
degraded performance.
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.
Table 3-4: Billing, Performance And Availability Relationships
Billing Status
Performance Level
Full Billing
Acceptable Performance
Conditional Billing*
Degraded Performance*
Availability Status
Available
Unacceptable Performance
No Billing
Unavailable
No Performance
* Shaded area indicates an SDF value between 0 and 1.
3.9.5 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.
Page 41
If the Customers 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., IPbased services is under discussion.
3.9.6 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
SAP
Description
Source
Service Access Point (SAP) is a logical element Derived from

located on the interface between the Customers Ordering or an
domain and the Service Providers 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.
Page 42

Component
Description
Source
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
Period
The Reporting Period represents the period over Derived from

which Performance Reports are generated. It is Ordering or an
defined independently for each SAP Group SLA template
within the SLA.
SAP Activity
Interval
A SAP Activity Interval (SAI) represents the Derived from

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
Time
SAP Activity Time (SAT) represents the total Derived from

duration (sum of) of all SAP Activity Intervals of a Ordering or an
specific SAP within a defined Reporting Period.
SLA template
SAP Cover
Time
SAP Cover Time (SCT) represents the interval Derived from

for which a Service Provider is responsible for Ordering or an
SLA template
the agreed level of service at the SAP.
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
Time
SAP Start Time (SST) represents a SAP Activity Derived from

Interval starting time.
Ordering or an
SLA template
SAP End
Time
SAP End Time (SET) represents the time at the Derived from
end of a SAP Activity Interval.
Ordering or an
SLA template
Page 43

Component
Description
SAP Outage
Interval
SAP Outage Interval (SOI) represents the

duration of a specific outage period within a
defined Reporting Period. An outage period is a
period of service unavailability (e.g. due to a
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
Time
SAP Outage Time (SOT) represents the duration Derived from

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
Time to
Provide
Service
Committed Time to Provide Service (CTPS) Derived from

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

represents a time interval within a SAPs life Ordering or an
where the Service Provider has no liability.
SLA template
Fault Report
Timestamp
Fault Report Timestamp (FRT) represents the

time recorded by a service management agent
when a fault is reported to it by an external actor
(e.g. Customer, Management System, etc.).
Source
Derived from
Service
Problem
Resolution
Derived from
Service
Problem
Resolution
Page 44

Component
Description
Source
Fault Fixed
Timestamp
Fault Fixed Timestamp (FFT) represents the Derived from

time recorded by a service management agent Service
when a fault is reported as resolved.
Problem
Resolution
Time To
Repair
Time to Repair (TTR) represents the difference Calculated from

between FRT and FFT. This is the actual time Service
taken to fix the fault.
Problem
Resolution
Service
Restoration
Timestamp
Service
Restoration
Timestamp
(SRT)
represents the time recorded by a service
management agent when a repair has been
verified and the Customer has been informed.
Time to
Restore
Service
Time to Restore Service (TTRS) represents the Calculated from

difference between FRT and SRT. It is the actual Service
time required to restore the service.
Problem
Resolution
Derived from
Service
Problem
Resolution
3.9.7 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.
Page 45
3.9.8 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 Customers 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 Customers service is
operational and must have Customer agreement on the service restoration time.
This can be done via automated interfaces between the Customers and the
Service Providers 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
Customers perception, while data from NEMs can still be used to produce
technical reports about reliability, MTBF, etc.
3.9.9 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 Providers 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.
Page 46
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.
3.10 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
Page 47
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.10.1 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.
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.
Y.1271 is expected to be approved at the February 2004 Meeting of ITU-T Study Group 13.
Page 48
Table 3-6: ETS Functional Requirements

ETS Requirements
Description
1. Enhanced Priority
Treatment
Emergency traffic needs assured capabilities regardless of

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

unauthorized access to, traffic and control (fraud), including
expanded encryption techniques and user authentication,
as appropriate.
3. Non-Traceability
A limited number of high level leadership emergency

communications users may need to be able to use
emergency services without risk of usage being traced (i.e.,
without risk of user or location being identified).
4. Restorability
Certain network functionalities should be capable of being

provisioned, repaired, or restored to required levels on a
priority basis.
5. Interoperability
Provide interconnection and interoperability among all

networks, (evolving or existing).
6. Mobility
The communications infrastructure should support user and

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

large geographic areas should form the framework for
ubiquitous coverage of emergency communications.
8. Survivability Endurability
ETS must be sufficiently robust to support surviving users

under a broad range of circumstances
9. Voice
Transmission
Circuit switched and packet switched networks need to

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

emergency communications to support variable bandwidth
requirements.
11. Affordability
Operators should leverage network capabilities to minimize

cost.
12. Reliability
Availability
ETS should perform consistently and precisely according to

their design requirements and specifications, and should
be usable with high confidence.
There is support in SG 13 to replace non-traceability in Y.1271 with a requirement that specify that only the location of
an emergency user may need to be hidden.
Page 49
3.10.2 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.7.1.
Table 3-7: ETS Performance Mapping

Support
1. Priority Treatment
Operability
Accessibility Retainability Integrity

X
Security
2. Secure
3. Non-Traceability
4. Restorability
5. Interoperable
6. Mobile
7. Ubiquitous
8. Survivable
9. Voice
10. Scaleable
11. Affordable
12. Reliability
Page 50
3.11 Selected Service Considerations

This section addresses a number of service performance topics that are of high
interest to many service customers.
3.11.1 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 its 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-13
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-13 for the case of manual service
restoration. Other cases of services protected by other means may result in
different relationships.
Figure 3-13: Time To Restore Service (TTRS) Illustration
Page 51
3.11.2 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 Providers 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-14.
Figure 3-14: 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:
Page 52
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 Customers needs and the Service Providers 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-15 for an illustration of this definition.
Figure 3-15: 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-15, 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.9.7, 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.
Page 53
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.11.3 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
Providers domain, then it is out of scope for the Service Providers 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.11.4 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
Page 54
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.11.5 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.11.6 Errors
For detailed definition and discussion of error performance, please refer to the SLA
relevant ITU-T Recommendations.
Page 55
Chapter 4 - SLA Content And Management
4.1 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
Page 56
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

reports 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 highperformance 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.
Page 57
g) Useful for diagnostics, including a diagnostic mode which can be used

to sectionalize or identify the weak link in a long multihop, multiprovider 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 Customers 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
Page 58
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 SPs 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.
Page 59
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.
4.2 Relating SLAs To Product Offerings

Much as the SLA management processes are an integral part of a SPs total
service management solution, so too is the actual SLA an integral part of the
service providers 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 4.2 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 SPs 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 4.2 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 Customers quality expectations into the SPs
terms.
Page 60
4.2.1 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-2.
Figure 4-2: Bundle Composition

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 Customers9. 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.
The level of Customer visibility will depend on the SPs policy and on the nature of the service.
Page 61
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-6.
The service contract10 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-3
Figure 4-3: Service Contract Relationships
4.2.2 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-4.
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.
10
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.
Page 62
Figure 4-4: 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 SPs 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).
Page 63
4.2.3 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-5: 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-5 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.2.4 Service Example

Figure 4-6 depicts an example of a commercial service consisting of an IP Access
service with email and web hosting. The underlying service capabilities are
Page 64
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.
cia
er
m
m
Co fers
Of
Residential Basic
Internet
s
A late
SL mp
Te
ice s
rv nt
Se eme
El
Basic
Email
Premium
Email
SOHO Basic
Internet
Residential
Access
Email
Service
ice es
rv urc
e
S so
Re
Email
Server
SOHO PRO
Internet
SOHO
Access
SOHO PRO
Access
Web Hosting
Silver
IP Access
Service
Authentication
Server
DHCP
Server
Access
Device
Web Hosting
Gold
Web Hosting
Service
Network
Elements
Web
Server
Figure 4-6: Service Composition Example
4.3 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-7. 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.
Page 65
End-to-end Service
Customer
Internet
Service
Provider
Service 1
Service 2
Service 3
Access
Provider
Service 6
Service 5
Service 4
Network
Service
Provider
Network
Service
Provider
Figure 4-7: 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
SLAc
Service
Provider 2
SLA2
Service
Provider 1
SLA3
Customers
Figure 4-8: 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-8. 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.
Page 66
End-to-end Service
SLAa
SLAb
Service
Provider 2
SLA4
Service
Provider 1
SLAc
Customers
Figure 4-9: Multiple Domain SLA Relationships - Case 2

The second type of SLA is illustrated in Figure 4-9. 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 2s backbone
network is reserved for Service Provider 1s 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.
Page 67
Chapter 5 - SLA Management Tools

This chapter provides two tools that are useful for structuring the complex process
of SLA preparation and management. These tools are the six-stage Service Life
Cycle 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 5.1. When the CustomerProvider interactions address each of these stages, the resultant expectations will
be better aligned and the relationship enhanced.
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 5.3. 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.
5.1 The SLA 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.
Page 68
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.
Page 69
The Product/Service Development Phase can be initiated by a number of different

events. Internal and/or external factors may indicate that its 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 orders 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,
Page 70
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
Customers SLA and on the QoS delivered to this Customer. The second
assessment occurs during the period when the SP is reviewing its overall quality
Page 71
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 Customers premises,
4) Consequent change procedures.
5.2 Use Cases And Scenarios

The following use cases are present in Annex H.
1) Product development with a new SLA
a) New SLA for an existing product
b) New product with new SLA
2) SLA/contract negotiations
3) Individual product instance and associated SLA sells support
4) Basic service execution including:
a) Steady state operation with no problems
Page 72
b) Steady state operation with degraded performance, no SLA violation

c) Steady state operation with SP detected SLA violation
d) Steady state operation with Customer reported problem no SLA
violation
e) Steady state operation with Customer reported problem SLA
violation
5) Periodic Customer assessment
6) Periodic business assessment
5.3 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.3.1 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.
Page 73
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.3.2 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-2.
Service Parameter Categories

Technology
Specific
Service
View
Service
Specific
Technology/Service
Independent
Individual
User View
Parameter
Parameter
Parameter
List 1
List 2
List 3
Aggregate
View
Parameter
Parameter
Parameter
List 4
List 5
List 6
Figure 5-2: Service Parameter Category Framework

Figure 5-3 illustrates a typical relationship between the service functions defined in
Section 3.1 and the three parameter categories. In most cases the Service Specific
parameters refer to a services primary functions.
Technology
Specific
Service Specific
Technology/Service
Independent
Primary Functions
Enabling Functions
OAM Functions
Figure 5-3: Service Functions-Parameter Categories Relationship
Page 74
5.3.3 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 users 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.3.4 The Service Parameter Table Examples

Figure 5-4 illustrates some typical parameters that may be found in the Service
Parameter Table.
Technology
Specific
Service
View
Service
Specific
Technology/Service
Independent
Individual
User View
Physical
interface
details
Service type or
bundle
Maximum down-time
of one event
Aggregate
View
Monthly
reported
parameters
Billing method
(usage- or
time-based)
Aggregate availability
over all users
Figure 5-4 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-5 and in Figure 5-6 illustrate these cases.
Page 75

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

Technology
Specific
Service
View
Service
Specific
Technology/Service
Independent
Individual
User View
CER, CLR, CTD, CDV - all max.

values
Availability, Max. time

to restore
Aggregate
View
CER, CLR, CTD, CDV - all

mean values and totals
MTBF, MTTR, MTRS
Figure 5-6: ATM Cell Delivery Service
5.3.5 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 criteria11, 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 missioncritical 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
11
This terminology is not aligned with the service performance terminology used in E.800 and in this document.
Page 76
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 3.9.
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 6.1.
5.3.6 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.
Page 77
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 highestlevel service client in use.
5.3.7 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 3.9, 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-7. Additional information on Service Availability is
found in Section 3.9.
Measure
Availability
Estimation
Units
Example
Up-times x 100
(%)
99.9%
(%)
0.1%
(hours)
8.76 hrs
over one
year
Up-times + Down-times
Unavailability
Down-times x 100
Up-times + Down-times
Mean accumulated down- down-times accumulated over

time over a given time a given time interval
interval
Figure 5-7: Availability Performance Measures
Page 78
The availability measures have been further refined and expanded in Section 3.9
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.3.8 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.
Page 79
5.3.9 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.7.5 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.
5.4 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 SPs
Operations Support System (OSS) environment, such as information on
Customers, services, and service performance as shown in Figure 5-8.
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).
Page 80
Customer
Details
Service
Instances
Customer SLA
Performance Data
SLA Reports
SLA
Contracts
Service QoS &
Performance Data
Service
Descriptions
QoS Reports
SLA
Templates
Raw
Performance
Data
Implementation
Product & Service

Development
Execution & Assessment
Negotiation & Sales
Figure 5-8: SLA Related Data

As shown in Figure 5-9, 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 & QoS
Reporting
Customer/SLA
Layer
SLA
Proactive
Monitoring
QoS
Analysis
& Reporting
Service
Layer
Service
Performance
Data
Aggregation
Data
Collection
Layer
Network
Performance
Data Collection
E.g. ATM, FR, IP
Execution & Assessment
& Server
Application
& Server
Performance
Data Collection
E.g. Web Server, DNS
Process
Performance
Data Collection
E.g. Trouble Ticketing,

Service Provisioning
Data Collection & Aggregation

(out of scope of current Handbook work)
Figure 5-9: SLA Performance Data Collection

The Customer SLA Reporting is covered in the following section.
Page 81
5.4.1 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-10 represents implied relationships between the engineered level for the
NP and commitments made in an SLA.
Figure 5-10: Performance Levels For Related Services
Page 83
Chapter 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.
6.1 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
Customers 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 Customers traffic and therefore may
increase network congestion.
Page 84
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.
Page 85
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.
6.2 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.2.1 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.
Page 86
In addition, this process responds to performance inquiries from the Customer.
6.2.2 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 Customers reports,
4) Delivering reports to the Customer.
6.3 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 functions 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.
Page 87
6.4 Reporting Scenarios

The following subsections present message sequences that correspond to
different scenarios for passing a performance report across the reporting interface.
6.4.1 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 Providers 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 SPs 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.4.2 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 Customers access to the retrieval service and to the data in the mailbox is
not under the Service Providers control. i.e., it is provided by a third party. Note
that in some cases the Service Provider could act as the third party.
Page 88
Figure 6-5: Reporting Via Drop-Off
6.4.3 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 Providers data management service.
Page 89
Figure 6-6: Reporting With Acknowledgement And Optional Logging
6.4.4 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.
Page 90
Figure 6-7: On-line Performance Reporting Control
6.5 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.
Page 91
Figure 6-8: Performance Reporting Process State Model
6.5.1 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
A new service is activated

that requires the generation
of Performance Reports for a
Customer.
The initialization state is entered. The

Performance Report is formatted, and links
are established for accessing the required
data.
Initialization complete.
The process exits the initialization state and

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

enters the report compiling state. Final
calculations are completed.
Page 92
Table 6-2: Performance Reporting Events And States

Event
State
Report compilation
complete.
The process exits the compiling state and

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
transferred.
The process exits the transfer state and

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.
6.6 Reporting Intervals

There are a number of different time intervals associated with the performance
reporting process. The following sections define these intervals.
6.6.1 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.6.2 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.6.3 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 onehour or one-day periods for reporting purposes. The data aggregation period must
contain a discrete number of measurement intervals or data collection intervals.
Page 93
6.6.4 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.
6.7 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.
6.8 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 contacts organizational unit,
d) Customer Contact Information, e.g., address, phone numbers, e-mail,
etc. for the Customer contact person.
Page 94
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., SAPs address, SAPs 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.
6.9 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.9.1 Service-Independent Measurements

As outlined earlier, a key performance parameter is Service Availability. Further
service-independent measurements could include:
Page 95
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 3.9, Service Providers will have all information
available to perform the respective calculations.
6.10 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.
Page 96
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

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

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 921]
enhanced Telecom Operations Map, GB921, Approved Version 3.0,

TeleManagement Forum, Morristown, NJ, June 2002.
[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.
Engineering,
Networks,
ITU-T
ITU-T
Page 97
[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

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:

Recommendation X.641 Geneva, December 1997.
Network,
Framework,
ITU-T
ITU-T
Page 98
[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 PacketSwitched Networks, ITU-T Recommendation Y.1271 Geneva, February 2004.
Page 99
Acronyms
3GPP
ABR
ABT
AIP
ANSI
ANT
API
ASP
ASPIC
ASR
ATC
ATIS
ATM
BBE
BBER
BER
BICC
B-ISDN
CATV
CBR
CCR
CD
CDR
CDV
CDVT
CE
CER
CIM
CIR
CL
CLI
CLR
CM
CMR
CN
CNM
COPS
CPE
CPoF
CTD
DBR
DCE
Third Generation Partnership Project

Available Bit Rate
ATM Block Transfer
Application Infrastructure Provider
American National Standards Institute
Access Network Transport
Application Programming Interface
Application Service Provider
Application Service Provider Industry Consortium
Answer/Seize Ratio
ATM Transfer Capability
Alliance for Telecommunications Industry Solutions
Asynchronous Transfer Mode
Background Block Error
Background Block Error Ratio
Bit Error Ratio
Bearer-Independent Call Control
Broadband Integrated Services Digital Network
Cable Television (Community Antenna Television)
Constant Bit Rate
Call Completion Record
Cell Delay
Call Data Record
Cell Delay Variation
Cell Delay Variation Tolerance
Cell Error
Cell Error Ratio
Common Information Model
Committed Information Rate
Cell Loss
Calling Line Identifier
Cell Loss Ratio
Cell Misinsertion
Cell Misinsertion Ratio
Core Network
Customer Network Management
Common Open Policy Service
Customer Premises Equipment
Common Point of Failure
Cell Transfer Delay
Deterministic Bit Rate
Data Circuit-Terminating Equipment
Page 100
DTE
DiffServ
DLCI
DMTF
DNS
DPL
DS
DSCP
DSL
DSS
ECBP
EDC
EDGE
EFS
EQoS
ES
ESR
ETSI
EURESCOM
FDD
FR
FRAD
FSA
FTD
G-CDR
GERAN
GFR
GGSN
GII
GoS
GPRS
GSM
HCPN
HTTP
IAB
ICSP
IESG
IETF
IMT
IN
INMD
IntServ
IOPS.ORG
IP
IPDV
IPER
IPLR
IPPM
IPTD
IRTF
ISDN
Data Terminating (Termination) Equipment

Differentiated Services
Data Link Connection Identifier
Distributed Management Task Force
Domain Naming Service
Degraded Performance Limit
Differentiated Services
DiffServ Code Point
Digital Subscriber Line
Digital Subscriber SIgnalling System
End-to-end Connection Blocking Probability
Error Detection Code
Enhanced Data rates for GSM Evolution
Error Free Seconds
EURESCOM Quality of Service
Errored Second
Errored Second Ratio
European Telecommunications Standards Institute
European Institute for Research and Strategic Studies in Telecommunications
Frequency Division Duplex
Frame Relay
Frame Relay Access Device
Framework Study Area
Frame Transfer Delay
Gateway GPRS Support Node Call Detail Record
GSM/EDGE Radio Access Network
Guaranteed Frame Rate
GPRS Gateway Support Node
Global Information Infrastructure
Grade of Service
General Packet Radio Service
Global System for Mobile communication
Hybrid Circuit-switched/Packet-based Network
Hyper Text Transfer Protocol
Internet Architecture Board
Information And Communications Service Provider
Internet Engineering Steering Group
Internet Engineering Task Force
International Mobile Telecommunications
Intelligent Network
In-service Non-intrusive Measuring Device
Integrated Services
Internet Operators Group
Internet Protocol
IP Packet Delay Variation
IP Packet Error Ratio
IP Packet Loss Ratio
IP Performance Metrics
IP Packet Transfer Delay
Internet Research Task Force
Integrated Services Digital Network
ISM
ISO
ISP
IST
ISV
IT
ITAA
ITU-R
ITU-T
LAN
LDP
LSR
MBS
MCR
MIB
MOS
MPEG
MPLS
MTBF
MTBO
MTIE
MTPS
MTRS
MTTP
MTTR
NAP
NER
NGN
NII
N-ISDN
NM
NMDG
NMF
NNI
NO
NP
NP&D
NPC
NSP
NTE
OAM
OI
ONP
OS
OSI
OSS
OTN
PC
PCR
Page 101
In-Service Monitoring
International Organization for Standardization
Internet Service Provider
Information Society Technologies
Independent Software Vendor
Information Technology
Information Technology Association of America
International Telecommunication Union Radiocommunication Sector
International Telecommunication Union Telecommunication Standardization
Sector
Local Area Network
Label Distribution Protocol
Label Switching Router
Maximum Burst Size
Mean Cell Rate
Management Information Base
Mean Opinion Score
Moving Picture Coding Experts Group
Multiprotocol Label Switching
Mean Time Between Failures
Mean Time Between Outages
Maximum Time Interval Error
Mean Time to Provide Service
Mean Time to Restore Service
Mean Time to Provision
Mean Time To Repair
Network Access Point
Network Effectiveness Ratio
Next Generation Network
National Information Infrastructure
Narrow band Integrated Services Digital Network
Network Management
Network Measurement Development Group
Network Management Forum
Network-Node Interface
Network Operator
Network Performance
Network Planning and Development
Network Parameter Control
Network Service Provider
Network Terminating Equipment (Element)
Operations, Administration, and Maintenance
Outage Intensity
Open Network Provision
Operations System
Open Systems Interconnection
Operations Support System
Optical Transport Network
Personal Computer
Peak Cell Rate
Page 102
PDH
PDN
PDP
PDN
PDU
PEI
PHB
PIB
PIR
PLM
PNO
POH
POP
PPA
PRM
PS
PSTN
PVC
QoS
QOSF
QSDG
RAN
RFC
RFI
RFP
RFSD
RSVP
SA
SAP
SBR
S-CDR
SCR
SDH
SDP
SE
SECB
SECBR
SEP
SEPI
SES
SESR
SGSN
SLA
SLO
SLS
SLSU
SMI
SOHO
SONET
SP
SP&D
Plesiochronous Digital Hierarchy

Public Data Network
Packet Data Protocol
Public Data Network
Protocol Data Unit
Peak Emission Interval
Per Hop Behavior
Policy Information Base
Peak Information Rate
Product Line Management
Public Network Operator
Path OverHead
Point Of Presence
Planning, Provisioning, And Administration
Performance Report Message
Packet Switched
Public Switched Telephone Network
Permanent Virtual Circuit
Quality of Service
Quality of Service Forum
Quality of Service Development Group
Radio Access Network
Request for Comments
Request for Information
Request for Proposal
Ready For Service Date
Resource Reservation Protocol
Service Availability
Service Access Point
Statistical Bit Rate
Serving GPRS Support Node Call Detail Record
Sustainable Cell Rate
Synchronous Digital Hierarchy
Service Delivery Point
Service Element
Severely Errored Cell Block
Severely Errored Cell Block Ratio
Severely Errored Period
Severely Errored Period Intensity
Severely Errored Second
Severely Errored Second Ratio
Serving GPRS Support Node
Service Level Agreement
Service Level Objective
Service Level Specification
Service Level Specification and Usage
Structure of Management Information
Small Office Home Office
Synchronous Optical Network
Service Provider
Service Planning and Development
SQM
SVC
TCA
TCP
TDD
TDM
TEWG
TFT
TIE
TIPHON
TMF
TMN
TOM
TSAG
TSP
TT
TV
UAS
UBR
UMTS
UNI
UPC
UPL
UTC
UTRA
VAR
VC
VCI
VOD
VoIP
VPI
VPN
WAN
WAP
WTSA
XIWT
XML
Page 103
Service Quality Management

Switched Virtual Circuit
Traffic Conditioning Agreement
Transmission Control Protocol
Time Division Duplex
Time-Division Multiplexing
Traffic Engineering Working Group
Traffic Flow Template
Time Interval Error
Telecommunications and Internet Protocol Harmonization over Networks
TeleManagement Forum
Telecommunications Management Network
Telecom Operations Map
Telecommunication Standardization Advisory Group
Telecom Service Provider
Trouble Ticket
Television
Unavailable Seconds
Unspecified Bit Rate
Universal Mobile Telecommunications System
User-Network Interface
User Parameter Control
Unacceptable Performance Limit
Universal Time, Coordinated
UMTS Terrestrial Radio Access
Value Added Reseller
Virtual Circuit
Virtual Circuit Identifier
Video On Demand
Voice over IP
Virtual Path Identifier
Virtual Private Network
Wide Area Network
Wireless Access Protocol
World Telecommunications Standardization Assembly
Cross-Industry Working Team
Extensible Markup Language
Page 104
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 series12. For further information, please consult
the previously referenced documents and the ITU-Ts 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 onehour 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).
12
Terms and definitions not yet used are marked with a *.
Page 105
*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 (ITUT Rec. M.3010).
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
Customers 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).
Page 106
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.
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
Page 107
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
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.
Page 108
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 Providers 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).
*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).
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).
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
Page 109
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 SPs 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).
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 Customers domain and the Service Providers 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
Page 110
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 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 Customers 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.
Page 111
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).
*Standing Condition a condition that has duration, beginning with a failure and
ending with a clear (ITU-T Rec. M.2140).
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).
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).
Page 112
Annex B - Executive Summary For Volume 1

The Executive Summary for Volume 1 was not available at the time this document
was released for member review. It will be added before the document becomes
available to the public.
Page 113
Annex C - Executive Summary For Volume 3

The Executive Summary for Volume 1 was not available at the time this document
was released for member review. It will be added before the document becomes
available to the public.
Page 114
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
Page 115
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
Forums 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.
Page 116
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 Forums 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.
Page 117
Document
Title
E.540
Overall GoS of the international part of an international connection
E.541
Overall GoS
subscriber)
E.543
GoS in digital international telephone exchanges
E.550
GoS and new performance criteria under failure conditions in

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
E.800
Terms and Definitions Related to Quality Of Service and Network

Performance Including Dependability (08/94)
E.810
Model for the serviceability performance on a basic call in the

telephone network [*]
E.830
Models for the allocation of international telephone connection

retainability, accessibility and integrity[*]
E.845
Connection accessibility objective for the international telephone

service[*]
E.850
Connection retainability objective for the international telephone

service[*]
E.855
Connection integrity objective for international telephone service[*]
I.350
General aspects of QoS and network performance in digital

networks, including ISDN[*]
I.351
Recommendations in other series concerning network

performance objectives that apply at reference point T of ISDN[*]
I.352
Network performance objectives for connection processing delays

in an ISDN
for
international
connections
(subscriber-to-
I.360 series
M.3100
Generic network information model
M.3400
TMN management functions
Q.822
Performance Reporting Management functions
X.140
General Quality Service Parameters for Communication via

Public Data Networks 09/92
X.144
User Information Transfer Performance Parameters for public

frame relay data networks
Page 118
Document
Title
X.145
Performance for Data Networks Providing International Frame

Relay SVC Service
X.161
Definition Of Customer Network Management Service For Public

Data Networks
Y.1271
Framework(s) On Network Requirements And Capabilities To

Support Emergency Communications Over Evolving CircuitSwitched And Packet-Switched Networks
ISO/IEC
JTC21/SC21N9309
QoS Basic Framework 01/95 (will become CD 113236-2 in Aug.

95)
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.
Page 119
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
Page 120
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.
Page 121
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.
Page 122
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
Performance Monitoring
M.3400
Protection Switching
Q.822
Bit-Based
X.144
Conformant Traffic
Distortion Ratio
PVC Availability
X.144, T1A1.3
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

Activity
Servability Performance
E.800
DisengagementDelay
X.140
Severely Errored Seconds
Q.822
Errored Seconds
Q.822
Speed Of Service - Frame FRF-QoS

Transfer Delay
Extra Frame Rate
FRF-QoS,
X.144
Transmission Performance E.800
Accuracy
Dependability
and 9309,
FRF-QoS,
X.144
Availability
E800; 9309
; FRF-QoS
Page 123
Management References
Subject
Source
Subject
Source
Frame
Based X.144
Conformant Traffic
Distortion Ratio
Time QoS
9309
Frame Loss Ratio
FRF-QoS,
X.144
Unavailable Seconds
Q.822
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
Loss Ratio
Alarm Report
X.161
Alarm Quality
Service
Frame X.144
Alarm Effect On Service M.3100

Parameter
Of X.161
Alarm Effect On M.3100

Service Parameter
Page 124
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 3.9 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:
Page 125
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
Page 126
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.
Page 127
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 performance13 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 semiautomated or automated mechanisms were used.14.
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)15. 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.
13
Perceived performance includes the combined performances of the application, the communications
link(s), and any servers being addressed by the application.
14
Call establishment and release (e.g. Figure 3/X.140) is not addressed herein.
15
Where several SPs comprise the end-to-end connection, each SP can make the same measure (as the
user).
Page 128
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 process16. 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 error17.
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 Messages18
Delivered Messages
SA Perceived
Repeated Messages19
Useful Messages
16
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.
17
Satellite links have large delays and use a large window size to increase throughput.
18
Calculation of errored messages may vary depending on the specific error recovery process.
19
Calculation of repeated messages may vary depending on the specific error recovery process.
G.3
Page 129
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:
SA Delivered = 1
G.4
Errored Messages
x 100%
Total Messages
Perceived SA
The User requires a specified level of message availability to support a given
mission. The users 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
seconds20,21. 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 messages22 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.
20
The values are provided for illustration and do not constitute a recommendation.
21
99.85% error free seconds equals 17 errored seconds in a 24 hour day
22
Seven repeated messages plus the original errored message
Page 130
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 encountered23.
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.
23
This not intended to be an exhaustive list of parameters.
Page 131
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 5.1 to
the eTOM [GB 921] processes that support SLA management.
The use cases address:
4) Product development with a new SLA
e) New SLA for an existing product
f)
New product with new SLA
5) SLA/contract negotiations
6) Individual product instance and associated SLA sells support
7) Basic service execution including:
g) Steady state operation with no problems
h) Steady state operation with degraded performance, no SLA violation
i)
Steady state operation with SP detected SLA violation
j)
Steady state operation with Customer reported problem no SLA

violation
k) Steady state operation with Customer reported problem SLA

violation
8) Periodic Customer assessment
9) Periodic business assessment
Page 132
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 Customer24.
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
24
See Chapter 3 for level of service and quality of service definitions.
Page 133
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.
Page 134
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.
Page 135
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.
Page 136
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 Customers 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.
Page 137
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.
Page 138
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:
Page 139
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.
Page 140
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
Page 141
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.
Page 142
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.
Page 143
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.
Page 144
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.
Page 145
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
Page 146
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.
Page 147
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 Customers 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.
Page 148
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 Customers 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.
Page 149
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
Page 150
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.

GB917-2 - Ver2!0!040422 - Concepts and Principles

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

GB917-2 - Ver2!0!040422 - Concepts and Principles

Enviado por

Direitos autorais:

Formatos disponíveis

SLA Management Handbook

Concepts and Principles

SLA Management Handbook Vol 2

TeleManagement Forum 2004

GB 917-2 Version 2.0

SLA Management Handbook Vol 2

TeleManagement Forum 2004

GB 917-2 Version 2.0

SLA Management Handbook Vol 2

About TeleManagement Forum

Enabling the development of a market and real products for

TeleManagement Forum 2004

GB 917-2 Version 2.0

SLA Management Handbook Vol 2

About This Document

Document Life Cycle

Development Version 1.0

First mapping of existing text into Vol 2

Development Version 1.1

Revised Version for Brussels

Development Version 1.2

Revised Version for Malvern Meeting

Development Version 1.3

Revised Version for Team Conference Call

Development Version 1.4

SLA/QoS Team Review Version

Development Version 1.5

Revised Version For Dublin Team Meeting

Member Review Version 2.0

Submitted for TMF Member Review

TeleManagement Forum 2004

GB 917-2 Version 2.0

SLA Management Handbook - Vol 2

How To Obtain Copies

How To Comment On This Document

GB 917-2 Version 2.0

TeleManagement Forum 2004

SLA Management Handbook - Vol 2

TeleManagement Forum 2004

GB 917-2 Version 2.0

SLA Management Handbook - Vol 2

GB 917-2 Version 2.0

TeleManagement Forum 2004

SLA Management Handbook - Vol 2

The Drivers For Service Level Agreements................................................................... 1

SLA Business Relationships........................................................................................... 2

Service Providers .................................................................................................... 6

Equipment And Software Vendors ......................................................................... 6

Notes For Readers.......................................................................................................... 7

Business Considerations .................................................................................... 11

SLAs In The Evolving Marketplace....................................................................... 11

The Business Model ..................................................................................................... 12

Service Provider Benefits...................................................................................... 15

TeleManagement Forum 2004

GB 917-2 Version 2.0

SLA Management Handbook - Vol 2

Supplier Benefits ................................................................................................... 15

Service Performance Parameter Selection ................................................................. 15

Service Measurement Considerations......................................................................... 16

Performance Parameters And Metrics................................................................. 16

Performance Measurement Methodology............................................................ 17

Telecommunications Services ........................................................................... 19

Service Characterization .............................................................................................. 19