Professional Documents
Culture Documents
GB917-2 - Ver2!0!040422 - Concepts and Principles
GB917-2 - Ver2!0!040422 - Concepts and Principles
Volume 2
GB 917-2
Version 2.0
April 2004
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
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
to
support
the
Page vii
Document History
Version
Date
Purpose
October 2002
February 2003
May 2003
August 2003
December 2003
January 2004
April 2004
Page viii
Time Stamp
This version of the SLA Management Handbook is valid until a revision is issued.
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
1.2
1.3
Scope .............................................................................................................................. 3
1.4
Handbook Benefits.......................................................................................................... 6
1.4.1
1.4.2
Customers ............................................................................................................... 6
1.4.3
1.5
1.6
Overview.......................................................................................................................... 7
Chapter 2 2.1
Introduction.................................................................................................................... 11
2.1.1
2.2
2.3
Business Benefits.......................................................................................................... 14
2.3.1
Customer Benefits................................................................................................. 14
2.3.2
Page xii
2.3.3
2.4
2.5
2.5.1
2.5.2
2.6
Anticipating Change...................................................................................................... 18
Chapter 3 -
3.1
3.2
3.3
Service Elements.......................................................................................................... 20
3.4
3.5
3.6
3.6.1
Definition................................................................................................................ 23
3.6.2
3.6.3
3.6.4
3.6.5
3.7
3.7.1
3.7.2
3.7.3
3.7.4
3.7.5
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
3.8.5
Assessing Performance........................................................................................ 35
3.9
3.9.1
Customer Perspective........................................................................................... 37
3.9.2
3.9.3
3.9.4
Page xiii
3.9.5
3.9.6
3.9.7
3.9.8
3.9.9
Content Recommendations.......................................................................................... 55
4.1.1
4.1.2
4.1.3
4.1.4
General Recommendations.................................................................................. 58
4.2
4.2.1
4.2.2
4.2.3
4.2.4
4.3
Chapter 5 5.1
5.1.1
5.1.2
5.1.3
5.1.4
5.1.5
5.1.6
Page xiv
5.2
5.3
5.3.1
5.3.2
Parameter Categories........................................................................................... 73
5.3.3
Service Views........................................................................................................ 74
5.3.4
5.3.5
5.3.6
5.3.7
5.3.8
Service Degradation.............................................................................................. 78
5.3.9
5.4
5.4.1
Chapter 6 6.1
6.1.1
Measurement Considerations............................................................................... 83
6.1.2
6.2
6.2.1
6.2.2
6.3
6.4
6.4.1
6.4.2
6.4.3
Reporting On Demand.......................................................................................... 88
6.4.4
6.5
6.5.1
6.6
Reporting Intervals........................................................................................................ 92
6.6.1
6.6.2
6.6.3
Aggregate Interval................................................................................................. 92
6.6.4
Example................................................................................................................. 93
6.7
Types Of Reports.......................................................................................................... 93
6.8
6.9
Page xv
6.9.1
Conditions............................................................................................................116
E.1.2
F.2
F.3
F.4
F.5
F. 6 Data Collection............................................................................................................125
F.7
Page xvi
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
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
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.
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.
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
The main focus of this Handbook is on business and government Customers as opposed to SPs as customers of other
SPs.
Page 5
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.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.
Page 7
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
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
Page 11
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.
Page 12
Page 13
Page 14
Page 15
Page 16
Page 17
Page 18
Page 19
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.
Page 21
Page 22
Page 23
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.
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.
Page 26
Page 27
Page 28
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
User-oriented
Provider-oriented
Service attribute
Page 30
Page 31
Page 32
Page 33
Page 34
Page 35
Page 36
Page 37
Page 38
Trafficability
Security
Design Shortfall
Misuse
Planning
Operability
Network Performance
Factor
Planning
Security
Propagation Impairments
Transmission
Reliability
Dependability
Traffacibility / Planning
Planning
Page 39
Outage Interval
SUA% =
x 100%
Activity Time
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
Event Type
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
..
.
..
.
..
.
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
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.
Description
Source
Page 42
Description
Source
SAP Group
Reporting
Period
SAP Activity
Interval
SAP Activity
Time
SAP Cover
Time
SAP Start
Time
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
Description
SAP Outage
Interval
SAP Outage
Time
SAP Weight
Committed
Time to
Provide
Service
No Service
Provider
Liability
Interval
Fault Report
Timestamp
Source
Derived from
Service
Problem
Resolution
Derived from
Service
Problem
Resolution
Page 44
Description
Source
Fault Fixed
Timestamp
Time To
Repair
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
Derived from
Service
Problem
Resolution
Page 45
Page 46
Page 47
Y.1271 is expected to be approved at the February 2004 Meeting of ITU-T Study Group 13.
Page 48
Description
1. Enhanced Priority
Treatment
2. Secure Networks
3. Non-Traceability
4. Restorability
5. Interoperability
6. Mobility
7. Ubiquitous
Coverage
8. Survivability Endurability
9. Voice
Transmission
10. Scaleable
Bandwidth
11. Affordability
12. Reliability
Availability
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
Operability
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
Page 51
Page 52
Page 53
Page 54
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
Page 56
Service cover time, i.e. the limits of SP support for different times of the
day/week/month/year, etc.
j)
Page 57
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.
Page 59
Page 60
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
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
Page 63
Page 64
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
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
SLAa
SLA1
SLAb
SLAc
Service
Provider 2
SLA2
Service
Provider 1
SLA3
Customers
Page 66
End-to-end Service
SLAa
SLAb
Service
Provider 2
SLA4
Service
Provider 1
SLAc
Customers
Page 67
Page 68
Page 69
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.
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.
Page 72
Page 73
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
Technology
Specific
Service Specific
Technology/Service
Independent
Primary Functions
Enabling Functions
OAM Functions
Page 74
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
Page 75
Service
Specific
Technology/Service
Independent
Individual
User View
Speed
Delay,
Throughput
Availability,Max. time
to restore
Aggregate
View
Total UAS
Delay
distribution
Service
Specific
Technology/Service
Independent
Individual
User View
Aggregate
View
11
This terminology is not aligned with the service performance terminology used in E.800 and in this document.
Page 76
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.
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
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).
Page 79
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
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
& Server
Application
& Server
Performance
Data Collection
Process
Performance
Data Collection
Page 81
Page 83
Page 84
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
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
T4
T5
T6
T7
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.
Page 86
Page 87
Page 88
Page 89
Page 90
Page 91
State
Initialization complete.
Performance Reporting
Period ends.
Page 92
State
Report compilation
complete.
Report successfully
transferred.
Reply received.
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.
Page 94
Page 95
Page 96
References
[E.106]
[E.490.1]
[E.600]
[E.800]
[E.801]
[E.860]
[FRF.13]
[G.803]
[G.805]
[G.872]
[GB 910]
[GB 921]
[GETS]
[I.326]
Engineering,
Networks,
ITU-T
ITU-T
Page 97
[I.350]
[I.371]
[ITU-Hbk]
[M.60]
[M.1535]
[M.2140]
[M.3010]
[M.3013]
[NMF 503]
[P806]
[T1.631]
[TMF 044]
TM Forum Glossary, TMF 044, Public Version, Version 0.2, March, 2003.
[TMF 506]
[TMF 701]
[TR-79]
[WP-SLA]
[X.641]
Network,
Framework,
ITU-T
ITU-T
Page 98
[X.642]
[Y.1271]
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
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
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
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
Page 104
12
Page 105
Page 106
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
(ITU-T Rec. M.2140).
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
Page 109
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)
(ITU-T Rec. M.1340).
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
Page 112
Page 113
Page 114
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
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
E.541
Overall GoS
subscriber)
E.543
E.550
E.720
E.721
E.771
E.775
E.724
E.800
E.810
E.830
E.845
E.850
E.855
I.350
I.351
I.352
for
international
connections
(subscriber-to-
I.360 series
M.3100
M.3400
Q.822
X.140
X.144
Page 118
Document
Title
X.145
X.161
Y.1271
ISO/IEC
JTC21/SC21N9309
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
Page 120
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
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
Code Violation
Q.822
Retainability
E.800
Servability Performance
E.800
DisengagementDelay
X.140
Q.822
Errored Seconds
Q.822
FRF-QoS,
X.144
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
FRF-QoS,
X.144
Unavailable Seconds
Q.822
Integrity QoS
9309
Interruptions
E.800
Loss Of Signal
Q.822
User Information
Loss Ratio
Alarm Report
X.161
Alarm Quality
Service
Frame X.144
Of X.161
Page 124
F.1
F.2
F.3
Page 125
F.4
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
F.7
Page 127
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.
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
22
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
Page 131
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)
j)
Page 132
24
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.
Page 134
Page 135
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.
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.
Page 139
S/P Settlements & Billing Management analyzes the data and passes it on
to Service & Specific Instance Rating for rating service usage.
Page 140
Page 141
Page 142
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
Page 144
Page 145
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.
17. Notifications and performance data are collected from the service-providing
infrastructure by Resource Data Collection & Processing.
18. Resource Data Collection & Processing sends performance data to Resource
Performance Management for further analysis.
19. Resource Performance Management sends resource performance reports to
Service Quality Management for QoS calculations and averaging to maintain
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
Selling checks the significance of the Customer with Retention & Loyalty.
Page 149
Page 150