TMFC2198 GB924 - V1 (1) .0 - Me - 031004

Service Framework
GB924
Member Evaluation version 1.0 September, 2003

TeleManagement Forum 2003
Service Framework Page ii
EXECUTIVE SUMMARY
Service Providers have been faced with the common problem for some time of
integrating their OSS and BSS solutions in such a way that they share a common
data model that will enable end-to-end process automation. While the NGOSS
programme addresses this problem the service providers are having problems
relating their own processes, user roles and operating requirements to the NGOSS
model.
To enable OSS and BSS solution providers to provide a fully integrated solution they
need to implement a common data model. To achieve this it is necessary to map the
service providers’ requirements to the NGOSS model. Currently, the mechanism to
achieve this is not available.
This Guide Book discusses the nature of the problem and the requirements for a
common framework that will support the service providers’ terminology, processes,
user roles and concepts and relate them to an underlying NGOSS implementation.
Finally the Guide Book suggests a number of activities that result from the problem
analysis to lead towards the definition of the common service framework.
GB924 v1.0 TeleManagement Forum 2003

Service Framework Page iii
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

Service Framework Page iv
Acknowledgments
This document was prepared by the members of the TeleManagement Forum

Service Framework team (SFT):
Duncan Vardy, ADC
Philip Bevins, ADC
Flavio Sticozzi, Agilent
David Milham, Btexact
Stuart Clelland, CGEY
Yee Liu Williams, CH2M Hill (Equador)
Ian Best, Comnitel
Richard Mishra, Cramer
Kevin Dorton, CSG Systems
Jane Hall, Frauenhofer Fokus
Sandro Mazziotta, HP
Patrick May, IntaMission
Simon Holland, IntaMission
John Strassner, Intelliden
Ed Grossman, Joule Software
Ulla Koivukoski, Nokia (Team Leader)
Elena Lialiamou, Nokia
Pertti Pielismaa, Nokia
Carolyn Smithson, O2
Andrew Chalmers, Orange
Dr. Peter Leipner, PSI
Martin Huddleston, QinetiQ
Veli Kokkonen, TeliaSonera
Munir Cochinwala, Telcordia Technologies
Claude Hary, Trendium
Joanna Archer, University College London
Phil Green, Vodafone

Service Framework Page v
Shahriar Shahriari, WatchMark

Nitin Bhandari, Wipro
Debbie Burkett, TM Forum Staff Support

Service Framework Page vi
About this document
This document is an initial draft Guidebook. It provides information on the current

situation, highlighting the business problem the industry is facing in this area in
creating, deploying and managing the services.
Document Life Cycle
This is an initial release of the Guide Book and is currently focused on the problem
area as a whole. Future releases of this document will evolve into a guidebook that
not only finds common ground on terminology surrounding the problem area, but also
will provide guidelines for systematically approaching solutions. A document of this
type is considered to represent a snapshot of the industry situation at the time of
writing it. This guidebook will be remaining under formal TMF change control.
Document History
Version Date Purpose

Version 0.1 04/03 First issue of document
Version 0.2 06/03 First team review
Version 0.3 06/03 Team review in Camberley
Version 0.4 07/03 Team review in Helsinki. Roles included.
Version 0.5 07/03 Team review in Newport Beach. Final
version
Version 0.6 08/03 Prepared for Strategy Management Team
Approval (dfb)
Version 1.0 09/03 Updated template items prior to Member
Evaluation.

Service Framework Page vii
About TeleManagement Forum
TeleManagement Forum is an international consortium of communications service

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

Service Framework Page viii
Table of Contents
Notice .................................................................................................................................................................iii
Acknowledgments ...........................................................................................................................................iv
About this document .......................................................................................................................................vi
Document Life Cycle ................................................................................................................................. vi
Document History .................................................................................................................................... vi
About TeleManagement Forum ....................................................................................................................vii
Table of Contents ...........................................................................................................................................viii
Table of Figures.................................................................................................................................................x
Introduction ........................................................................................................................................................1
Document Overview...................................................................................................................................1
Document Structure ...................................................................................................................................1
Terms Used in this Document ...................................................................................................................2
Introduction .................................................................................................................................................5
Guide Book Scope and Context ................................................................................................................6
Perspective .................................................................................................................................................7
Objective .....................................................................................................................................................8
Benefits Gained by Solving this Business Problem..................................................................................9
For Service Providers............................................................................................................................9
For Network Providers...........................................................................................................................9
For Network Infrastructure Vendors .....................................................................................................9
For Software Vendors ...........................................................................................................................9
For System Integrators..........................................................................................................................9
Business Scenario................................................................................................................................... 10
Business Roles and the Service Framework............................................................................................. 12
Introduction .............................................................................................................................................. 12
Product Manager..................................................................................................................................... 14
Business Function .............................................................................................................................. 14
Framework Application....................................................................................................................... 14
Product Solution Designer / Architect..................................................................................................... 16
Service Designer / Manager ................................................................................................................... 16
Service Component Builder.................................................................................................................... 17
Connectivity Builder................................................................................................................................. 18
Service Implementer ............................................................................................................................... 18

Service Framework Page ix
Service Operator ..................................................................................................................................... 19

Product End User .................................................................................................................................... 19
Subscriber and End User Support.......................................................................................................... 20
Domain Analyst ....................................................................................................................................... 20
Revenue Assurance Analyst .................................................................................................................. 20
System Manager ..................................................................................................................................... 21
Process Manager .................................................................................................................................... 21
Resolution Proposals .................................................................................................................................... 22
Proposal................................................................................................................................................... 22
Appendix 1- Example Scenario: The MMS Service .................................................................................. 23
Process Definition.................................................................................................................................... 23
Context of MMS Service Delivery...................................................................................................... 24
Stage 1: Design and Build MMS ............................................................................................................ 27
Stage 2: Launch New Service ........................................................................................................... 28
Stage 3: Customer orders MMS........................................................................................................ 29
Stage 4: Customer uses MMS........................................................................................................... 30
Stage 5: Customer experiences problem.......................................................................................... 31
Customer experiences problem - external interfaces....................................................................... 31
Customers experience problem - internal interfaces........................................................................ 31
Appendix 2: Common Requirements ......................................................................................................... 33
General rules ...................................................................................................................................... 33
Functionality........................................................................................................................................ 33
Reporting Requirements .................................................................................................................... 37
Product Marketing and Customer Facing ......................................................................................... 40
Service Operations ............................................................................................................................. 42
Resource Management...................................................................................................................... 45
Partner Management ......................................................................................................................... 47

Service Framework Page x
Table of Figures
Figure 1. The scope of Guide Book related to the eTOM model 6

Figure 2. Service Decomposition 9
Figure 3: MMS scenario stages in product lifecycle model 13
Figure 4: MMS scenario stages mapping to eTOM 14
Figure 5: Service attributes relationship with the operations processes 15
Figure 6: Roles to MMS Service Design Mapping 17
Figure 7: Business context of the MMS delivery entities 24
Figure 8: Business Scenario in the Context of eTOM 26

Service Framework 1
Introduction
Networks and services are evolving; new technologies are introduced more rapidly
than existing ones are retired leading to bigger and more complex networks and
services. At the same time there is a greater need for automation and optimisation of
business processes. Also, the operator focus is moving from managing the network
technologies to managing the end-user service experience, which demands different
management solutions. The current mechanisms are having difficulty handling new
challenges and at the same time reducing the operating costs.
There is also a window of opportunity for the operators to catch new revenue streams
by developing, deploying and managing new feature-rich services - if the right tools
are there.
The whole process of service planning, deployment and assurance needs to be easy,
quick, systematic and reliable. This calls for efficient and inter-working tools in the
service creation, deployment and assurance areas. There are issues that need to be
solved in these areas to boost the service take-up in the industry.
This initial release of the guidebook will look at crucial business problems in the
service planning, deployment and assurance value chain. The analysis will lead to a
set of proposals that will eventually provide a mapping of the business requirements
to NGOSS implementation using a common service framework, i.e., map the user
perspective to an NGOSS process and data model.
Document Overview
This document will illustrate the business problem with a concrete scenario and
example and then look at the requirements needed to solve the problem. Although
there are some pointers to relevant TMF projects, this document does not take a
position on the actual data model. Instead, it describes the required service
framework.
This initial release of the guidebook is meant to act as a basis of further work to
identify the relevant TMF projects to solve the business problem and establish the
solution as a standard service management practice.
Document Structure

Service Framework Page 2
This document concentrates on describing the business problem in the service

development and management area. It shows an example scenario and lists a set of
business requirements.
Terms Used in this Document
The following definitions (unless specified otherwise) are extracted from TMF044 that
is the common definition document of the TMF. The definitions in TMF 044 are
derived in the most part from other TMF released documents and these are
referenced below.
Contracts
Technology-neutral specification of an interface to a service; a Contract represents

the unit of binding in the technology-neutral architecture. [TMF053]
A legal business agreement, with terms and conditions, between two parties for the
supply of goods or services. [The Oxford English Dictionary]
End User
The End User is the actual user of the Products or Services offered by the Enterprise.
The end user consumes the product or service. See also Subscriber below. [eTOM
Terminology Annex]
Key Performance Indicators (KPIs)
Key Performance Indicators provide a measurement of a specific aspect of the

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

product components (services) or service elements and draw their data from a
number of sources including the KPIs.
Parameters
(Logical) resource values set through operations functions
Resources (Physical or Logical)
Resources represent physical and non-physical components used to construct

Services. They are drawn from the Application, Computing and Network domains,
and include, for example, Network Elements, software, IT systems, and technology
components. [eTOM Terminology Annex]
Service

Services are developed by a Service Provider for sale within Products. The same
service may be included in multiple products, packaged differently, with different
pricing, etc. [eTOM Terminology Annex]
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. [GB917]
Service Assurance
All actions taken to ensure that standards and procedures are adhered to and that the
delivered service meets performance requirements.
Service Enablers
Service resources and skills/capabilities of the processes
Service Instance
The implementation of the service in production
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.
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). [GB917], [ITU-T Rec. M.1340]
SLA Template
An SLA violation occurs when the contractually agreed service level for a single
service class or group of service classes has been breached. SLA violations are
attributable to individual customers or groups of customers. [GB917]
Service Management
Management of Services to meet customer’s requirements. [ITIL]
Service Quality Management
The Service Quality Management process monitors and manages the performance of
each class of service against the quality objectives.

Service Topology
A service topology is a pattern for composing a distributed application. Different types

of topologies will exist in computing environments. Typically, a physical network will
have a topology as identified by the actual wires connecting the computing devices.
At the next level of abstraction, the logical network, an addressing scheme may utilise
a point-to-point topology that abstracts the participants from the physical schema.
Above all of this, the service topology abstracts the participants from both the physical
and logical network. Thus the service network may have a single or composite
topology. This topology is abstracted from the lower layers. One can be on a hub &
spoke physical network, where packets are directed along a point-to-point logical
network and utilise a hub & spoke service-brokering mechanism (like WSO)
Subscriber
The Subscriber is responsible for concluding contracts for the services subscribed to
and for paying for these services. [eTOM Terminology Annex]
User
Any entity that can be identified and hence authenticated. [T1.252], [TMF053] See
End User above. [eTOM Terminology Annex]
A person or a machine delegated by a Customer to use the services and/or facilities

of a telecommunication network or service offering. [GB917], [ITU-T Rec. I.112
modified]

Business Problem Description
Introduction
Service providers are looking for new revenue streams through feature-rich new
services. However, the introduction of these new services is complex, error-prone,
time and effort consuming because there is no structured way to model, deploy and
manage them.
Service providers also need to reduce Opex and Capex whilst accelerating new
revenue growth. These business drivers are forcing consolidation of OSS within intra
organisation units, but not yet between organisations. The drive is to
comprehensively link network resource knowledge to service knowledge and exploit
all integral processes and data to maximum effect, achieve total data integrity and
eliminate (or reduce) revenue leakage.
The principal barriers to achieving these Service Orientated Operational gains are the
cost of change and the resistance to overhauling business critical OSS and BSS
implementations, both in terms of technology and processes /culture. Consolidation is
not the entire solution; key functional and process limitations must be resolved in
order to achieve maximum return.
One way to mitigate the problem is to introduce a systematic way to model and
manage the services. Both service providers and software vendors have tried that on
their own. However, due to the lack of guidelines and standards in this area each
attempt has resulted in a new methodology. This means that the installed solutions
are not compatible with each other. It also creates a big barrier for B2B interfaces in
the value chain, putting e.g., 3rd party content providers in a difficult position to get
access to the services.
This project is not applying any specific business model. Every organization has its
own business models, which change from time to time. The service framework needs
to be flexible enough to survive even dramatic changes in those business models.
The framework is aimed at providing a ‘user friendly’ representation that ‘insulates’

the end user from the complexities and terminology of the underlying implementation
model. In the same way that an implementation model is designed to achieve the
maximum efficiency and flexibility in the resultant solution, the user framework has to
provide all end users with a clear and efficient ‘user model’ supporting the user
community’s specific terminology.
It is NOT the purpose of this Guide Book to provide a ‘software’ model upon which
OSS / BSS solutions will be implemented. It does however provide a high level
framework for user presentation, service structure, terminology and workflow support.
This will then lead to a mapping of this framework (or user model) into the SID
implementation model.

Guide Book Scope and Context
The initial release of the guidebook will look mainly at the Service Development &
Management and Service Management & Operations processes, as defined in
GB921 (eTOM), to understand what the processes require of the service framework
and how the framework could improve the processes. The main focus is in those
processes and activities that are shown with a red box in the figure. The service
framework will cover the entire service layer of the eTOM from SIP to Operations. It
will focus on the service modelling, deployment and assurance areas. The initial
release of the guidebook will look at related areas in SIP where design and
development reuse of service models and data could occur and thus standardization
is needed. It will also look at CRM and Resource Management & Operations for
dependent processes and Customer and S/PRM for the processes that exchange
service related data.
Customer
Strategy, Infrastructure and Product Operations
Strategy & Infrastructure Product Operations Support Fulfillment Assurance Billing
Commit Lifecycle Mgmt Lifecycle Mgmt & Readiness
Marketing and Offer Management Customer Relationship Management
Service Development & Management Service Management & Operations
Resource Development & Management Resource Management & Operations
Supply Chain Development & Management Supplier/Partner Relationship Management
Enterprise Management
Strategic & Enterprise Planning Brand Management, Market Enterprise Quality Mgmt, Process Research & Development
Research & Advertising & IT Planning & Architecture & Technology Acquisistion
Financial & Asset Stakeholder & External Human Resource s Disaster Recovery , Security
Management Relations Management Management & Fraud Management
© TeleManagement Forum October, 2001
Figure 1. The scope of Guide Book related to the eTOM model
The service framework will also need to cover some of the ongoing work in TMF
which looks at a general process model for supporting industry standard forms of B2B
(eTOM) and the associated modelling of the entities and objects for the external B2B
relationships (SID). The B2B scope is illustrated as red bullets in the figure in
Customer and Supplier/Partner Relationship Management area.
The commercial product offering is not in the scope of this initial release of the
guidebook, though the re-use of service models and data in these areas will be
investigated as above. The technology specific resources will also not be covered in

this phase. The service framework must be extensible enough to fully cover the
product and technology areas.
The service framework will follow the common TMF definitions, whenever possible, of
products, services & resources and the relationships between these entities as
described in TMF044 Glossary.
Perspective
The Guide Book looks at product creation, order, activation, operation and revenue
assurance inter-organisationally.
Processes Impacted:
Product Lifecycle Management [all SIP aspects in the Service Layer]
Service Fulfilment
Service Assurance
Revenue Assurance
Inter- process dependency:

The standardised Service Framework and its Data View are required to resolve the
stated business problems, consists of the following key features to satisfy inter-
process dependencies:
Common Service Framework containing the Service Description and the
Service Topology, using SID concepts as follows:
o Common Service Specification
o Common Service Characteristics
o Common Service Attributes
Role based Service Abstraction or ‘Data View’ [the Service, Physical and data
artefacts of the model abstraction appropriate to the role and process function]
Correlation framework between Service and Resources, where a Service may
be a compound service of other services and or other resources. This is
necessary in order to generate data artefacts for use in the Service
Abstraction; correlation must satisfy hierarchical or distributed inventory
paradigms.
New Functional Areas:

Standardisation of a Service Definition
Correlation of existing OSS service models with the standard
Ability to utilise the same service framework with OSS developed using both
hierarchical and distributed inventory relationship paradigms
Algorithm development to create the service model abstractions and data
views from service and resource [inventory] entities, logical or physical, for
OSS application use of the data
OSS exploitation of a standard Service Model and data view, e.g. design,
provisioning, configuration, revenue assurance etc
eTOM and B2B processes to support the Service Definition, Data Views and
OSS exploitation, within the enterprise and between enterprises.

Objective
The objective is to describe the business problem in service management area and to
propose how to solve those issues. This Guide Book also looks at the service
framework from the business point-of-view, describing the context and the ground
rules of how to use the various bits in the service environment. The target is a
framework that truly supports business needs.
The successful completion of the first phase involves:
A business problem statement
What is required to solve the problems
How to continue the work
Documentation of the above into a Guide Book
The subsequent steps are likely to involve (to be defined at the completion of the
first step):
Description of the service framework
Guidelines for using the service framework
How to bridge the business view of the issues to system design
How the NGOSS concepts satisfy business requirements
Identification of NGOSS framework improvements
The figure below shows the service decomposition issue.
SLA / QoS
Management
Customer
Provisioning
RG
SC R
R
RG
Service R
Enabling Services R
R
RG R
SC
RG
Billing
SC – Service Com ponent
RG –Resource Group
R –Resource

Figure 2. Service Decomposition
Benefits Gained by Solving this Business

Problem
For Service Providers

Faster introduction of new services
Increased number of services in (manageable) portfolio
Reduced service development costs
Reduced system integration costs
Reduced service operations costs
Managed service levels
Simplified mechanisms for service provisioning and information sharing
with business partners like Network and Content Providers
New revenue streams from niche services
For Network Providers

Managed service levels
Reduced service operations costs
Simplified mechanism for service provisioning and information sharing
with business partners like Service and Content Providers.
For Network Infrastructure Vendors
Better understanding of the requirements of service management from

the point of view of network and service management systems as well
as network elements.
Better interworking capabilities in a multi-vendor environment
For Software Vendors

Common service framework in the industry eases integration and
reduces the integration required, allowing broader interoperability.
Software development focused on value-adding applications
For System Integrators

Focus integration costs more on value-added services and operational
efficiencies and less on the mechanics of OSS and BSS integration.
Better understanding of common carrier requirements
Known Service Management requirements lead to repeatable solutions
Pre-integrated solutions to support the common framework

Business Scenario
The following business scenario covers the development, launch and in-life
management of a service and illustrates the various stages of the life cycle of a
service.
Service Design and Build
Marketing initiates a project to create a new product that is based on Multimedia

Messaging Service (MMS). The proposition outline is defined and the product design
options identified, including a combination of existing service and network
components and new capabilities. A new 3rd party supplier will provide the MMS
capability.
As the design process proceeds, target service levels for the product and underlying
services and components are defined. This includes the quality objectives at each
level of the service decomposition. From these subscriber SLAs, internal SLOs and
3rd party supplier SLAs may be defined.
As the design moves into build, all of the Systems and Infrastructure components are
tested and integrated and the final service testing completed; in parallel the care and
operations processes are agreed upon and tested.
Service Launch
Preparations are completed for the launch of the product to the consumer market
The product portfolio is updated with details of the MMS service and Care,
Operations and Billing make final preparations to support MMS. Final product
acceptance checks are completed and all the supporting systems are primed to
recognise MMS as live product.
Customer Orders service
Beccie sees the advertising for MMS and decides to try it; she logs in via the operator
portal and registers as a pre-pay user.
Customer uses service
Beccie wants to send a picture message to a friend; she takes a photo, adds a
message and sends it.
Later that day, Beccie checks her credit and sends another message; she gets a text
message back from 2nd friend that confirms that he received the picture message.
Beccie calls the first friend and discovers he didn’t get the message.

Customer experiences problem - external interfaces
Beccie calls customer services to complain that her friend has not received the
message. The Care agent checks service status and advises Beccie that a temporary
fault had delayed the delivery; the service failure is flagged as occurring within the 3rd
party supplier of MMS service.
Customers experience problem - internal interfaces
Service Management Centre Notified of Problem
The help desk receives a notification of a problem; the service is initially marked as in
jeopardy. The personnel at the help desk are now able to obtain a big picture view of
the business priority of the problem (e.g. in terms of value or current usage) and
initiate appropriate actions to ensure that business revenue loss is minimised. The
help desk personnel are able to quickly identify the resolver groups and actions
needed to resolve the issues.
Operations Teams; Network, Server and Application resolver groups
The operations team is notified by e-mail or SMS that there is a problem. Observing
the problem from a service perspective they are quickly able to drill down to
automated test results already compiled for each probable cause. The command
and control system is able to access the components most likely to be causing the
problem to further analyse and resolve the issue.
The fault monitoring systems detect a problem with the MMS service, which is
localised to the 3rd party supplier; NOC is advised that the estimated time to fix is
1hour. The SLA is flagged as in jeopardy and then recorded as breached by the 3rd
party supplier. The Service and Vendor managers are notified.
The problem resolution is monitored and the status is updated to the trouble
management system after it has been resolved. Customer support is notified about
the resolution of the problem to enable them to close the customer trouble report and
inform Beccie that the problem has been resolved.

Business Roles and the Service Framework
Introduction
In order to define the requirements of the common service framework it is necessary

to understand the roles of the individuals and business functions that will use the
framework. It should be noted that these roles are not intended to be specific job
functions. They act only as a vehicle to capture the requirements for the framework.
The framework provides an evolving visualisation of a service and the various

attributes of that service. It effectively becomes a transport mechanism enabling the
various roles within the business to communicate using a common ‘language’.
It should be noted that the roles identified in this section are not intended to be
exhaustive and are used as examples only. Across different businesses, it is likely
that there will not be an exact match for these roles or the tasks that they are
responsible for. However, it is intended that the roles described below collectively
cover the entire end-to-end life cycle management of a service and will therefore
provide a guide for readers to map their own roles onto the service framework.
There are functionalities in the service framework that are common to many roles.
Among these, the service framework must support quality objectives for each of the
service components in the service delivery path. It must also provide high-level quality
criteria to match the end user perspective. It is likely that the quality objectives will
form the clauses within the SLA template for the service that will be instantiated in the
contract with the end user. Each role is responsible to define the relevant KQIs for
each level of the service framework, i.e., for each service component, the end-to-end
service and the product itself.
A mapping of the MMS service lifecycle stages to the eTOM is shown in the figures
below. The service framework would by necessity support the roles and views of
each of the eTOM level 2 process blocks. The numbering reflects the stages in the
MMS business scenario.

MMS Service Business Scenario vs Product Lifecycle Model
Modify/
Develop Sell Provide Bill Service Report
Exit
Stage 5
Stage 1 Stage 2 Stage 3 Stage 4
Stage 1: Design and Build MMS: “Marketing initiate a project …”

Stage 2: Launch New Service: “Preparations are completed for the launch of the
product …"
Stage 3: Customer orders MMS “Beccie sees the advertising for MMS and decides to
try it …”
Stage 4: Customer uses MMS “Beccie goes out and wants to …”
Stage 5: Customer experiences problem - external interfaces “Beccie calls customer
services to complain …”
Stage 5: Customers experience problem - internal interfaces “The fault monitoring
systems detect …”
Figure 3: MMS scenario stages in product lifecycle model

eTOM Business Process Framework – Level 2 View

Strategy, Infrastructure & Product Operations
Strategy & Commit Infrastructure Product Lifecycle Operations Support Fulfillment Assurance Billing
Lifecycle Mgmt. Management & Readiness
Marketing & Offer Management Customer Relationship Management
Market
Market
Strategy
Product
Product&& Product
Product&& Marketing
Marketing Product
Product Marketing
Marketing CRM
CRMOperations
Operations
2 3 4 5 Customer
CustomerInterface
Interface
Strategy&& Offer Offer Capability Development Commu -- Support&&Process

Support
2 2
Offer Offer Capability Development Commu Process
Policy
Policy Business
Business Portfolio
Portfolio Delivery
Delivery
1
&& nications
nications Management
Management Selling
Selling 5 Problem
ProblemHandling
Handling
1
Planning
Planning&&
Commitment 1 Capability
Capability
Delivery
Retirement
Retirement
2
&&
Promotion
Billing
Billing&&
3
Commitment Delivery Promotion Collections
Collections
5
CRM
CRMOperations Marketing Order CustomerQoS
QoS/ /SLA Management
3
Operations Marketing Order Customer SLA Management
Readiness
24
Readiness Fulfil
l ment
Fulfill ment Handling
Handling Management
Management
Product
Product&&Offer
Offer CRM
CRM Sales
Sales&& Product,
Product, Response
Portfolio Response
PortfolioStrategy, Capability Channel Marketing
Policy
Strategy,
Policy&&Planning
Planning
Capability
Delivery
Delivery 2 Channel
Development
Development
Marketing
&&Customer
Customer
1 2 3
Sales
Sales&&Channel
4Performance
Performance
Assessment
Assessment
Channel
Management
Management Retention
Retention&&Loyalty
Loyalty
Service
Service Service
Service Service
Service&& Service
Service Service
Service
SM&O
SM&OSupport
Support&&Process
Management
Management
Process Service
Service
Configuration
5 Service
ServiceProblem
ProblemManagement
Management
Service&
Service&
Specific
Specific
Strategy
Strategy&&
1
Planning
Planning&& Operations
Operations Development
Development
4Performance
Performance
3 Configuration
&&Activation
Activation
3
Instance
Instance
1 1
Policy
Policy Commitment
Commitment Capability
Capability && Assessment
Assessment Rating
Rating
1 3 4 5
Delivery Retirement Service
ServiceManagement
Management&& Service
ServiceQuality
QualityAnalysis,
Analysis,
Delivery Retirement Operations
OperationsReadiness
Readiness Action
Action&&Reporting
Reporting

5Resource
ResourceProblem
ProblemManagement
Management
RM&O
RM&OSupport
Support&&Process
Process Resource
5
Resource Management Resource Quality
QualityAnalysis,
Resource&& Resource
Resource&& Resource
Resource&& Resource Resource
Technology Technology Operations
1 Resource
Development
4
Resource
Performance
Management Provisioning
& Allocation
Resource
Action
Analysis,
Action&&Reporting
Reporting
3
Technology Technology Operations Development Performance
Strategy
Strategy&&
Policy
Policy 1 Plan
Plan&&
Commitment
Commitment 1
Capability
Capability
Delivery
Delivery
Assessment
Assessment
1 3 4
Resource
ResourceManagement
Management
OperationsReadiness
&& Operations Readiness
to Service Instance
3 Resource
ResourceData
DataCollection,
Collection,Analysis
Analysis&&Control
Control

S/PRM
S/PRM
S/P S/P
S/PPurchase
Purchase S/P
S/PProblem
Problem S/P
S/P
S/PRM S/P Settlements
S/PRMOperations
OperationsSupport
Support&& Order Reporting
Reporting&& Performance Settlements
5 5
Buying
3 3
Order Performance
3
Supply
Supply Supply
Supply Supply
Supply Supply
SupplyChain
Chain Supply
Supply Process Buying &&Billing
Chain Chain Chain Development Chain ProcessManagement
Management Management
Management
Billing
Management
Chain Chain Chain Development Chain Management
1 1 1 4
Strategy
Strategy&& Planning
Planning&& Capability
Capability &&Change
Change Performance
Performance
Policy Commitment Availability Management Assessment S/P
S/PRelationship
RelationshipManagement
3 3 4 5
Policy Commitment Availability Management Assessment Management
Operations Supplier/
Partner Interface
InterfaceManagement
OperationsReadiness
Readiness Supplier/Partner Management
Enterprise Management
Strategic & Enterprise Brand Management, Market Research Enterprise Quality Management, Process & Research & Development Technology
Planning & Advertising IT Planning & Architecture Process
Process Acquisition
Strategic
Strategic&& Enterprise
Enterprise Group
Group Information
Information Architecture
Architecture
Business
Business Business
Business Architecture
Architecture Enterprise
Enterprise Brand
Brand Market
MarketResearch
Research Advertising
Advertising Knowledge
Knowledge Enterprise
EnterpriseQuality
Quality Systems
SystemsStrategy
Strategy Management
Management&& Research
Research&& Technology
Technology
Development
Development Planning
Planning Planning
Planning Management
Management &&Analysis
Analysis Management
Management &&Planning
Planning Support
Support Development
Development Acquisition
Acquisition
Financial & Asset Stakeholder & External Relations Human Resources Disaster Recovery, Security &
Management Management Management Fraud Management
PR
PR&&Community
Community Shareholder
Shareholder Employee
Employee&&Labor
Labor Disaster
DisasterRecovery
Recovery
Financial
Financial Real
RealEstate
Estate Procuremant
Procuremant Regulatory
Regulatory Legal
Legal Relations
Relations Relations
Relations HR
HRPolicies
Policies Workforce
Workforce Workforce
Workforce Relations
Relations Security
Security Fraud
Fraud &&Contingency
Contingency
Management
Management &&Practices
Practices Strategy
Strategy Development
Development Management
Management Planning
Planning
Figure 4: MMS scenario stages mapping to eTOM
Product Manager
Business Function
This role is responsible for the creation of a new product from a market perspective
and managing existing ones or the inception of a new product idea. This role is
responsible for the business case and the profitability of the product.
Framework Application
The service framework provides a ‘template’ that the product manager will use to
‘describe’ the services within a product in a common format that is easily understood
by other roles responsible in the design and deployment of the new service(s).
From a process perspective, each attribute in the framework must be ‘owned’ by a

business process and the role(s) within the organisation responsible for that process.
Thus the end-to-end business process ensures that all attributes of the service

identified within the framework are correctly designed, assessed, implemented and
managed.
The framework must therefore support all of the attributes of the service and the life-
cycle management of those attributes. For example, all of the processes responsible
for design of a new service will ensure that all appropriate attributes of the service as
identified within the common framework will be completed. The attributes include
information on the cost of developing and delivering the service to support the
business case analysis.
The framework therefore becomes a common point for the business processes
associated with the service.
Figure 5: Service attributes relationship with the operations processes

Product Solution Designer / Architect
Business Function
This role architects the service to match the customer / market requirements to the
realisation of the product. He translates the business requirements, given by the
product manager, to the service requirements.
The role decomposes the product definition into the underlying services and uses the
framework to identify whether those services exist, and whether changes are
required, or new services need to be created. This role then carries out the high level
design for new services or the modifications to the existing services.
The framework must therefore support attributes that reflect the market requirements
for the service. Typically this will include the definition of the service itself i.e. the end-
to-end service delivery chain and various performance criteria for the service (KPIs
and KQIs).
This role needs to extract information from the service framework of the
(in)compatibility and the pre-requisites of the services.
Service Designer / Manager
Business Function
This role has overall responsibility for the service from inception throughout the
service lifecycle. Note: The product manager carries the overall responsibility of the
product.
This role is responsible for building the detailed service specifications and ongoing
management of the services against them. This includes defining the requirements
for the OSS for managing the new service.
This role will use the framework to extract the information for the detailed design of
the new service as provided by earlier roles in the total process. For example using
the attributes populated from the market requirements, this role will refine those
attributes into an achievable implementation and will populate other attributes based
on the results of the design work.
The service framework needs to support attributes of the service that would reflect the
OSS systems required to manage the service.

Below the figure explains the share of responsibility of the above-described roles
regarding the service decomposition.
Product
Product Manager MMS
MMS to MMS MMS to Legacy MMS to eMail

Product
Function
Product Architect
Service Legacy
Video Picture Audio eMail Service
Designer / Picture
Manager
Service
Component MMSC SMSC GPRS eMail Service
Builder Component
(Element)
Figure 6: Roles to MMS Service Design Mapping
Service Component Builder
Business Function
This role analyses, designs, implements, tests and releases the components required
for the delivery of the service. This role might be executed by e.g., network engineer
and / or 3rd party content provider.
From a service / product perspective, this role builds or modifies existing components
e.g. service elements, that provide some or all parts of the service delivery path.
The component builder uses the information from the service framework to implement
the service components (service elements) described within the framework according
to the attributes associated with those components e.g. performance criteria.

The structure and content of the framework must therefore be capable of describing
the service and its topology such that it will enable the component builders to
construct the service as designed.
Connectivity Builder
Business Function
This role delivers the platform systems that provide the services as required by the
business. This role is delivering the connectivity of the service components released
in earlier phases. This role may be realised across various job functions such as IP
network engineer, transmission engineer, security specialist etc.
From a service / product perspective, this role is ensuring that the new service is
delivered end-to-end.
With the framework populated with the service design by earlier business processes,
the connectivity builder must be able to understand all of the service components and
the service topology required for that service delivery and either extract or design the
infrastructure necessary to implement the complete delivery path.
Service Implementer
Business Function
This role integrates, tests and commissions a service and associated OSS / BSS
against the requirements and releases the new service.
From a service / product perspective, this role is responsible for developing the
operational plan for managing the service and for the deployment of that service.
The service implementer will also be responsible for making sure that all of the
necessary support systems are in place to enable the efficient management of the
service to the designed operational criteria e.g. quality objectives.
The framework must provide this role with all aspects of the service necessary for the
effective deployment, evaluation and management of the service. Using the
framework, the service implementer must be able to understand the topology of the
service (vertical and horizontal), the quality objectives of all of the components within

that service topology and the parties within the organisation or third party providers
responsible for delivering the service components in line with the quality objectives
defined in the framework.
The service implementer will be responsible for implementing the necessary changes
in the various support systems that will be used to manage the service.
Service Operator
Business Function
The service operator is responsible on a day-to-day basis for the delivery of the
service. Typically this role will be an NMC or SMC operative relying on support
systems to provide real-time or historical performance data or implementation data
about the service and its delivery components.
The framework must provide an accurate representation of the service, its

implementation i.e. the service delivery components, performance criteria and
component contact / owner details to enable the support systems used by this role to
present the appropriate information in a way that accurately reflects the actual
deployment. The framework must therefore translate the underlying data model
implemented by the support systems and as deployed into the service delivery chain,
into a user (friendly) view of the service and all of its attributes.
Product End User
Business Function
The end user is the actual consumer of the product or service. For the purposes of
this section we will consider the end user and the subscriber i.e. the person that pays
for the service, to be the one and same role as the functionality provided by the
service framework would be the same for both. There may therefore be a contract
between the service provider and the end user for the supply of the service with
contract clauses relating to various aspects of service performance i.e. an SLA.
The end user perspective on the delivery of a service is likely to be significantly

different to that within a service provider organisation. It is therefore necessary for the
framework to support both an implementation view of the service i.e. a horizontal
topology showing all the components of the delivery path, and an end user view and

terminology that is unlikely to require the same level of granularity of service delivery.
The framework needs to support abstracted information, access control (user
partitioning) and terminology translation.
Subscriber and End User Support
Business Function
This role provides presales and post-sales support for the subscribers and end users.
The framework gives access to e.g., the product features, service performance
objectives for SLA management, actual service performance from end user
perspective and service delivery information.
Domain Analyst
Business Function
This role is a domain expert who carries out tasks such as root-cause analysis,
capacity management, continuous improvement etc.
The service framework provides this role with a view to extract information on the
service topology and attributes; capacity, trends, relationships and reporting.
Revenue Assurance Analyst
Business Function
This role is a specific type of domain analyst in the area of revenue assurance.
The service framework provides a service decomposition that gives for example
access to the actual utilisation of the service components that can be compared to
the billed utilisation.

System Manager
Business Function
This role is taking care of the management tasks of the service resources. This role
can be realised by e.g., UNIX administrator.
The framework will provide the system manager with the ability to extract information
on service resource attributes such as quality objectives and their violations,
utilisation and information so that system managers can understand the impact of
failures and planned works on the services supported by their resources.
Process Manager
Business Function
This role is responsible for the operations processes that are necessary for managing
the service.
The service framework provides information about the delivery and objectives of a
service that enables the process manager to figure out which operations processes
are affected when services are introduced or modified.

Resolution Proposals
Proposal
As a result of the analysis of the requirements the following potential activities have
been identified.
Extend the mapping of the service framework to eTOM to cover
business processes and user roles to further identify the impact on the
functionality supported by the framework.
Map the service framework definition to the SID model. This activity may
also identify additional requirements on the service framework and the
NGOSS model.
Produce a Guide Book describing the service framework in detail, the
NGOSS mapping as described above and the methodology of how to
apply the framework. The proposal is to extend the framework to support
different data models, e.g., NGOSS based and legacy. The objective
here is to enable the migration from legacy to NGOSS solutions with the
support of the common service framework.

Appendix 1- Example Scenario: The

MMS Service
Process Definition
Service management is an emerging focus area concerned with end-to-end service

delivery quality and management. There is an increasing focus on the monitoring and
management of Service Level Agreements (SLAs) between the customer and
internal and external suppliers (for example, B2B) involved in the service delivery
value chain; this makes it difficult to adopt an end-to-end Service Quality
Management (SQM) strategy. Service management at its lowest level needs to
ensure that the specified quality of end-to-end service delivery is attained and
measured over identified service resources. This requires identification and collection
of performance metrics from the related resources and elements involved in the
physical and technical delivery of services and sub-services across a
communications infrastructure.
For the purposes of this Guide Book, service topology requirements are discussed in
the context of Multimedia Message Service (MMS), an identified ‘killer application’
that offers the capability of sending multi-media ‘content’ across one or more access
or transmission boundaries. The Service framework should ensure standardisation
and a common configuration framework to:
Faster service creation
Faster and more accurate end user provisioning
Better problem management to ensure quicker resolution
Improved revenue assurance
Ensure that service quality objectives are achieved against business
objectives
The monitoring of Key Performance Indicators (KPI) against quality objectives
The monitoring of Supplier/Partner Key Quality Indicators (KQI) against the
service level agreements (SLAs)
Sharing of service information between multiple parties in a consistent
manner by using a common definition

Context of MMS Service Delivery
The use of a populated Service framework allows service specification information to

be shared between multiple service providers without the need to declare
commercially sensitive or proprietary information. The relevance of a common service
framework therefore is fundamental; it not only impacts the practical physical
monitoring of performance metrics but also affects the interactions and contractual
relationships between all parties involved in the service delivery chain. A service
framework underpins B2B negotiations and reconciliation between multi-party
providers dependent on contracted Key Performance Indicators (KPIs) and Key
Quality Indicators (KQI). This in turns impacts pricing, billing and the clarity of the end
product offering to the customer.
Whilst the technology required to deliver multi-media content to customers exists and
is being deployed, the models and practice for service quality monitoring of these new
services is still emerging. Figure 7 outlines the business context of the main entities
and illustrates the complexity of multi-party MMS interactions between identified
service providers. The framework draws on the principles of the eTOM business
framework where the key points are:
Subscriber, SLA, Prepayment Service Provider Domain
SLA, Response Time

Multimedia
Multimedia
Content Service
Customer Customer Care Value
Content Added
Service
Operations Provider
Service Provider
Provider
(MVNO)
SLA, B2B
Authorisation
SLA, Response Usage
SLA
Time
MMS Customer
Usage Service
Multimedia
Bank Credit Multimedia
Content Service
Security Multimedia
Content Service
Service Management Provider
Agency Content Service
Provider
Operations
Provider
SLA, B2B
SLA, B2B
Usage
Usage SLA
Network
Credit Check Service SLA, B2B
Usage
Hardware Equipment Network Application, Software

Vendors Operations Vendors
KPI
KPI
KPI
Figure 7: Business context of the MMS delivery entities

1. The Service Provider has the customer-facing role and interacts with the
other 3rd Party service providers. It provides the MMS product to the Customer at the
service levels agreed to in the SLA.
2. The Service Provider has agreements in the form of internal SLAs with the
Network Operations. In the case of the Mobile Virtual Network Operator (MVNO)
scenario, there would be a wholesale agreement for network usage to the MVNO to
deliver the service to the customer.
3. The Content Service Provider maps to the Value Added Service Provider
role in eTOM supplying content. These providers supply content (i.e., multimedia) to
the Customer via the Service Provider and so have a B2B relationship only with the
Service Provider. SLAs regulate the products they deliver and content usage is
accounted for in the business relationship with the Service Provider, which then
passes the charges onto the customer through its marketing product offer.
4. The Network Operations (internal Network Infrastructure Provider) maps to

the Third Party Service Provider role in eTOM as it provides bandwidth and
connectivity to the Service Provider. [The scenario is based on the assumption the
business is organized as separate operating business units with accountability to
meet the SLA for supply chain delivery.] As such, an internal accounting relationship
exists between the Service Provider and the Network Operations.
5. The Hardware, Equipment Vendors and Application Solution Vendors also

are mapped to the Third Party Service Provider role. Again, there are SLAs
regulating the product delivered and product usage is accounted for in the business
relationship with the Service Provider.
The wireless industry is developing rapidly and any service management solution
requires a service framework that will to respond to new business requirements
accordingly. As the 3G market matures, service models will allow service providers to
offer service quality as a competitive advantage. In the short term, the SLA contracts
will likely be relatively simple, where QoS is not viewed as a strategic differentiator but
as fundamental to launching new services. In today’s market the challenge is not to
meet specific and established framework requirements but rather to be flexible
enough to meet any new requirements.
The following business scenario covers the development, launch and in-life
management of a service and illustrates the usage of the Service Framework at the
various stages of the life cycle of a service.

CU STOMER
STRATEGY, INFRASTRUCTURE & PRODUCT OPERATIONS

Strategy & Infrastructure Product Operations Fulfillment Assurance Billing
Commit Lifecycle Lifecycle Support &
Management Managemen Readiness
Marketing & Offer Management t Customer Relationship Management
3
1 2 4
ENTERPRISE MANAGEMENT
Strategic & Enterprise Brand Management, Enterprise Quality Mgmt, Research & Development
Planning Market Research & Process & IT Planning & & Technology Acquisition
Advertising Architecture
Financial & Asset Stakeholder & External Human Resources Disaster Recovery,
Management Relations Management Management Security & Fraud
Management
Figure 8: Business Scenario in the Context of eTOM

Stage 1: Design and Build MMS
“Marketing initiate a project to create a new product using Multimedia Messaging

Services (MMS). The proposition outline is defined and the product design options
identified, including a combination of existing service and network components and
new capabilities. It is established that a new 3rd party supplier will provide the MMS
capability.
As the design process proceeds, the target service levels for the product defined and
SLAs are negotiated with the selected 3rd party supplier.
As the design moves into build, all of the Systems and Infrastructure components are
tested and integrated and the final service testing completed; in parallel the care and
operations processes are agreed and tested.”
The Design and Build of the MMS Service process maps to the first level Strategy,
Infrastructure and Product Lifecycle Management in eTOM. The network infrastructure,
application and IT resources must be deployed according to the plans set by Resource
Development in line with market product offering and partner-supply chain
feasibility/availability. These processes also initiate and complete business agreements
(SLA) with the supply chain to allow delivery of the business and technical capabilities
required to meet the service provider’s commitment to the customer. Project management
and planning develop process management framework links to enterprise management.
eTOM Process 1: Design and Build MMS
Marketing Define MMS product offering value proposition to the customer -

product components and pricing.
Service Define SLA and service management framework (including 3rd party
providers)
Define customer service levels
Resource Identify MMS service resource requirements
Build and develop systems infrastructure
Partner/Supply Negotiate/Agree internal and external SLAs with providers
Enterprise Define project scope and timescales
Plan and agree process management framework

Stage 2: Launch New Service
“Preparations are completed for the launch of the product to the consumer market.
The product portfolio is updated with details of the MMS service and Care,
Operations and Billing make final preparations to support MMS. Final product
acceptance checks are completed and all the supporting systems are primed to
recognise MMS as live product.”
The Launch Service process maps to the first level of Operational Readiness
in the eTOM business framework. This process ensures that the service is
operationally ready for launch and will support entry level and forecasted
growth necessary for the future needs of its current customers and potential
new customers. The Launch Service includes process and procedure
implementation, systems changes and customer documentation. It also
undertakes rollout and testing of the service, capacity management, costing of
the service and the ability of the enterprise to deliver services according to
requirements.
eTOM Process 2: Launch New Service (OR)
Marketing Run marketing campaign
Prepare product collateral
Update product portfolio
Service Brief/Update customer care, service operations and billing
Conduct end-to-end service customer acceptance testing
Go live to production and rollout of MMS
Resource Testing of service resources against SLA for MMS
Capacity management and costing of service for OPEX
Partner/Supply Finalize channels to market
Enterprise Project Management

Stage 3: Customer orders MMS
“Beccie sees the advertising for MMS and decides to try it; She logs in via the SP
portal and registers as a pre-pay user.”
The Customer Orders MMS is mapped to the first level of Fulfillment in the
eTOM. From a service provider’s perspective this process needs to ensure the
speed and response times of the sub-processes involved in selling or order
handling, service configuration and activation and customer interface
management. This will involve SLAs with the customer as well as internal
SLAs with functional departments.
eTOM Process 3: Provision MMS product (Fulfilment)
Marketing Customer logs in via portal and registers as prepay order
Customer confirms agreement and sends order
Customer services receive order and sends to order handling
Service Customer Order subscriber details updated; customer notified when

service activated
Internal work order for service configuration and activation
Service operations notified
Customer QoS and SLA Management update
Resource Resource provisioning and allocation to service instance to customer
Capacity management for performance and routing
Lead time notification
Partner/Supply Notify 3rd Party Providers of service activation and provisioning
3rd Party Credit Check Agency notified
External resource provisioning completed
Enterprise Project Management and monitoring

Stage 4: Customer uses MMS
“Beccie wants to send a picture message to a friend; she takes a photo, adds a
message and sends it.
Later that day, Beccie checks her credit and sends another message; she gets a text
message back from 2nd friend, which confirms that he received the picture message.
Beccie calls the first friend and discovers he didn’t get the message.”
Customer using MMS is mapped to the first level of Assurance in the eTOM
with the underlying process of service management. From a service provider’s
perspective this process needs to ensure a proactive approach to service
management. This requires processes to ensure that the delivery of the
service does not go wrong. For example, adequate resources are allocated for
problem management and monitoring the network to pre-empt outages.
eTOM Process 4: Manage MMS product (Assurance)
Marketing Customer interface information on customer complaints about QoS

drops that need immediate response
Notification about particular customer SLAs that would imply special

actions or priorities (e.g. new customers)
Service Guarantee response to QoS/SLA violations under a predefined

threshold (i.e. service breakdowns or functional degradations)
Notification of any new service classes and details of quality level

thresholds and restoration procedures and operations that affect
network
Resource Identification of service resource elements that affect overall service

performance and need short-term analysis and resolution
Partner/Supply Identification of 3rd party service resource elements that affect overall
service performance and need short-term analysis and resolution
Enterprise Project control

Stage 5: Customer experiences problem
Customer experiences problem - external interfaces
“Beccie calls customer services to complain that her friend has not received the
message. The Care agent checks service status and advises Beccie that a temporary
fault has delayed the delivery; the service failure is flagged as occurring within the 3rd
party supplier of MMS service”
Customers experience problem - internal interfaces
“The fault monitoring systems detect a problem with the MMS service, which is
localised to the 3rd party supplier; NOC is advised that estimated time to fix 1hr. The
SLA is flagged as in jeopardy and then recorded as breached by 3rd party suppliers
failures. The Service and Vendor managers are notified.”
Customer experiencing a problem and raising this with Customer Services

function is mapped to the first level of Assurance in the eTOM. The
underlying process is problem management and resolution. This process
ensures that the Customer receives a speedy response and effective
resolution to queries and problems. The process input is customer complaints.
It raises trouble tickets and tracks them to completion or refers technical
problems to the appropriate network operations fault desk. Customer service
analyses problem reports by category, solution and efficiency of handling in
dealing with the customer.
eTOM Process 5: Customer Care
Marketing Receives customer complaint
Provide information to customer on reporting faults / troubleshooting.
Notify customer of resolution
Service Check service status; identification of major faults
Comply with SLAs for resolving faults;
SLA flagged as in jeopardy
Process and escalation procedures

Resource Ensure that adequate resource to deal with problems.
Partner/Supply Notification of 3rd Party SLA breach

Product and vendor managers notified
Define areas of responsibility / who deals with which fault types
Process for penalties and breach of SLA
Enterprise Monitor project
Identify common problems; abnormal business – impacting problems
Renegotiate of SLA

Appendix 2: Common Requirements
The following provides the service framework requirements derived from the analysis
of the MMS scenario and underlying process definitions. Note that these
requirements are not structured and maybe not very consistent. It is anticipated that
the later version(s) of this document will contain the actual business requirements
based on these raw requirements.
General rules
HP-003 A Service instance can belong to several Service Groups.
HP-001 Object Model must allow defining associations between sub-service

Components/Resource
HP-002 For each association is possible to define upper and lower cardinality
(ex:0..1 ---2..N)
COM-003 Versioning The service framework must support version control i.e. an
attributes of each service entity must include the version of that entity.
Rationale
The configuration or collection of data and the format of the data associated with a
service entity may vary depending on the version of that entity. It is therefore
important that systems using the data framework are able to automatically modify the
way in which they interact with a service entity based on the version information.
Functionality
These requirements describe the overall functionality required of / from the framework
NOK-003 Flexibility The service framework must enable flexible building of

relationships between various service entities based on diverse business needs.
Rationale.
Different organisations may want to build the service chains differently due to
competitive reasons. Also, the business models are likely to change over time. The
service framework must support the changes in business environment.

NOK-005 Usage data collection The service framework must include usage data
collection requirements for the service entities.
Rationale.
The usage data is used for monitoring the service performance and for charging. The
service framework will not collect or store the data, it only gives the requirements
what data should be collected, where and how.
NOK-006 Network independence The service framework must be network

independent.
Rationale.
The frequent changes in the network (rollout, network expansions, optimisations,

maintenance breaks etc.) must not have any effect to the service framework.
Tel 001 Visualization The framework should provide the ability to model the
relationships between services, systems, and resources, in a way that would allow
the visualization of the different component of a service.
Issue is the kind of information the framework should contain. Framework contains
dependencies but different deployments may not allow representation of information
for visualization. For instance, a leased service may only allow ingress and egress
points and not details of equipment. Some information, even in a leased
service/network can be derived over time. What kind of support should the framework
provide?
Tel 002Templates The service framework must allow for the use of templates for the
definition of the service or service entities within the framework.
Most services and service entities are likely to be heavily based on existing or generic
services, therefore it must be possible to build service framework based on templates
that are instantiated when an actual service is deployed from the templates. This
instantiation may result in the modification of some attributes of the template.
How are templates managed? When new attributes are added, is it the same
template or a different version? If a deployment requires adding new attributes, does
it affect the service framework and/or template?
Tel 003 Adding of new relationships
Who can add new relationships? If each provider/vendor adds new relationships, how
is coordination and compatibility managed?

Tel 004 Subscriber Information
What type of subscriber information should be modelled? Should handheld be

modelled? How are new handhelds and their capabilities introduced into the
framework? Should SIM cards be modelled?
Tel 005 From service framework to service offering
Going from a framework to offering implies additional attributes, translation of

marketing terms such as gold to network resources such as bandwidth and addition
of billing plans? Should the framework support the different types of offering for
services? Is this just another template? Are there multiple type of service catalogues,
i.e. offering vs. definition vs. deployment
Tel 006 Naming The service framework should allow for naming convention support.
The naming convention may be "described" to the service framework based on
naming structure. Each object can be uniquely defined in the framework but a provide
will have their own names for services objects.
Since provide naming convention is outside the scope of the service framework, what
mechanisms need to be included in the framework for support of external naming
schemes?
COM-004 Aliasing The service framework must support an infinite number of alias
names for each service entity.
Rationale
The utopia of a common naming convention across all OSS and BSS systems is
unlikely to ever be fully achieved (especially across multiple businesses). The service
framework must therefore allow systems to relate the service entity names used by
other systems with the names used internally.
Tel 007 Capture information to support business / investment decision making

process
Should the service framework be extended to support business/investment decision-
making? If so, what should be included? What are the depreciation models of
equipment?
Tel 008 Data Management (usage, reporting, storage)

The service framework must include usage data collection requirements for the
service entities. The service framework will not collect or store the data, it only gives
the requirements what data should be collected, where and how.

Does the framework impose any requirements about a data repository? Common
reporting and access is needed but what should be imposed from the framework, if
anything? For example, should interfaces to the data be part of the service
framework? Or does a service repository have to be defined?
Tel 009 Framework Instantiation and support for FCAP

Framework instantiation will require sequencing and ordering of actions across OSSs
What support should the framework provide?
Should the framework provide support for escalation/notification points?
NOK-001 Attributes The service framework must support all service attributes that
are needed during the whole service lifecycle. Each service attribute can be
associated to one or more service entities.
Rationale
The service framework needs to be complete to be able to define and manage the
whole service chain during its lifecycle.
Identify ownership of attributes entered by user (content related).
COM-006 Attribute Inheritance The service framework must allow for inheritance of
attributes from other service entities. This must include reference to other entities
within the service delivery framework (vertical or horizontal) or from entities outside of
the service framework.
HP-005 User can add unlimited number of additional attributes (i.e. properties) to
statically describe instances.
NOK-002 Extensibility The service framework must be extensible. New service

entities and attributes must be possible to be introduced at any time into the service
framework.
Rationale.
Services may need to start using new service entities, e.g., due to network or service
technology change (WCDMA, MMS..).
COM-005 KPI / KQI data The service framework must include KPI / KQI information
for each service entity
Rationale

The provisioning of service components in a service delivery chain must (in the
future) include the key indicator information required for measuring the service
delivery performance of the service entity.
(Note: This may be a name for the key indicator pointing to separate KPI/KQI entity
within the framework.)
Identify service metrics that will be required (performance criteria etc.)
Support jeopardy management of SLAs
Support 3rd party settlement
Support identification of financial liability in event of failure
Support geographical considerations in service design (may be limitation on

service).
Support identification of utilization, capacity, and QoS, operating tolerances and

limitations
HP-004 Calculation Expressions (from KPI to KQI) can be modeled as elementary

block (several inputs indicators can be used to calculate a KQI).
AGI-002 Parameter Indicators Ability to associate KPI/KQI to specific resource type.

The KPI/KQI will be inherited by the service framework and may be monitored.
Reporting Requirements
In fact, what seems to be needed is the capability to support data-warehousing

functionality. The service provider will not know what questions to ask. Reporting
capability is needed on well-known processes only, which have less of a value for
introducing new customer services.
Customer Service Operations [CSO] – considers the processes and procedures

that are in place in the current environment. Specifically this will relate to the
identified business process, scenarios, users and existing OSS infrastructure to
support the goal of service levels and management of customers, services and
products. Reporting should be viewed, in this context, from an overall business
process and end-user perspective of customer service representative for resolving
service level issues as it impacts customer experience.

It must be possible to report on performance and customer service aspects as it

impacts service level agreements [SLA] as it relates to service delivery to end
customer. (End user SLA measures needs to be present into the ‘provisioning’ of
the service)
It must be possible to report on network performance issues or validate that the

network is engineered to meet the SLA’s proposed products and services to its
customers.
It must be possible to validate the network resources, topology and connectivity

and creation to service elements where it impacts viability in provisioning of a
service to an end customer.
It must be possible for the service framework to support statistical reporting of

traffic movement and profiling of customers that can be used for improved service
delivery and launch of new services and products used by CSR.
It must be possible to report giving a complete overview of the level of service

quality offered and identify the areas were problems exist in order to be pro-active
in customer service response.
Service Management Infrastructure [SMI] – Report requirements used for

monitoring the overall performance of the service that is effective measurement of a
customer’s experience. This area would require more detailed analysis in line with
definition of an OSS infrastructure where future requirements would look at end-to-
end performance and reporting that requires access to different logical areas of the
framework. Discussion around application areas of billing and provisioning systems
integration.
It must be possible to report on potential problems with the individual network or

service elements of the architecture. The purpose is to ensure quality or
guaranteed service levels to end customers
It must be possible to monitor usage trends, and proactively identify, and resolve
potential capacity issues likely to cause network degradation. In order to fine tune
and optimise the delivery performance to SLA parameters that impacts internal
technical infrastructure.
It must be possible to report and define variation reporting of network

performance as it relates to customer QoS and/or segmentation. For example,
this may be required primarily as a means for detecting loss of revenue or launch
of new services for customers.
It must be possible that the framework supports the querying of threshold values
for key performance and quality indicators that is used to ensure customer
service levels are guaranteed.

It must be possible to provide reports for identifying and resolving performance

issues where 3rd party service provider involved or reporting in conjunction with
equipment manufacturer
A lower level of reporting for more detailed network performance is recommended

in this area.
Service Management Roadmap [SMR] – the opinion is that the ultimate goal for
SMF is a service management environment that needs to be designed for change in
product life cycle management. This area looks at the business decision-making
reporting requirements as it relates to product launch or merging of new services.
It must be possible to report on customer service aspects as it impacts service

level agreements [SLA] as it relates to viability of launching new services and
products to end customer.
It must be possible to validate the network elements, path and connectivity to

network and application elements where it impacts viability in provisioning of a
particular service to end customer.
It must be possible to report on overall packaging, bundling of service offering that

may require integration with other systems (e.g. Billing) to ensure consistency,
reliability and integrity of service package to customer.
It must be possible for the service framework to support statistical reporting of

“traffic” movement and profiling of customers that can be used for improved
service delivery and launch of new services and products.
It must be possible to report on customer satisfaction, customer usage patterns

that can be considered in the marketing forecasts of future usage demands
services that can introduce to the market.
Escalation / notification points Support notification of restoration of service;

optimize mobilisation of fix team (internal and external)
Framework must contain knowledge of notification rules and identities
The service framework is a central repository that must provide reporting

transparency of underlying data across different functional groupings and/or
remote parts of an organisation involved within service management framework.
The service framework must be able to support the management reporting

capabilities, display and/or report generation requirements from different types of
user for the purposes of decision-making or operational administration at a group
or regional level.
The service framework must be able to support the audit trail/history reporting in
different application and/or uses of the service framework.

It must be possible for different user groups to query underlying data on an ad-
hoc basis.
It must be possible to integrate a 3rd Party report generation tool to access

underlying shared information.
The service framework must be able to support concept of reporting security

linked to users which allows for different levels of application of restricted or
shared access to information.
The service framework must ensure the consistency, referential integrity of

access to the base data for report generation where information may come from
number and range of different sources.
Product Marketing and Customer Facing
Marketing and Customer Care functions are dependent on the end-to-end quality of
services, supporting sub-services (i.e., Service Provider or 3rd party) where the
customer perception of quality is concerned with both the technical delivery of
network services and as well as the responsiveness to problem management and
customer relationships. For marketing, service framework provides a common view
across the evolving services, which in turn depend on an evolving set of underlying
technologies. The identified requirements for consideration are:
PM1. Products and Services Reference - The service framework must be able to
provide a reference data point to all identified products and services important to the
business. It should be possible to categorise a number of services and/or sub-
services that can be packaged or bundled that define a product offering to the market
and can be mapped to the service delivery path.
PM2. Customer and Subscriber Reference - The service framework must be

able to provide a reference data point to customer and subscriber information. It
should be flexible to support and define hierarchical structure of services and sub-
services reflecting customer segmentation linked to product offering. For example,
service may be defined as MMS type and segmented according to revenue growth
based on traffic patterns (e.g., low, average, high); or more generically as in retail for
general customers (e.g., identifying roaming entry point, retail shops, geographic
areas)
PM3. Business Entities and Service Resources Reference - The service

framework must support the linkage of business entities to service resources or
elements that deliver the service to the targeted end customers.
PM4. Customer Profile, 3rd Party and Product Offering - The service framework
must be able to provide a cross-reference point to customer profile, 3rd Party and
product offering that allows for revenue analysis across different types of services
providing indication of the revenue impact and profitability related to end customers.

PM5. Front of Office to Back-end OSS components - The service framework

must be able to hold information and link to back-end OSS components (quality
monitoring, alarm analysis, trouble ticketing and workforce change management etc.)
flow through to the front-end OSS components (customer SLA, customer order and
problem management) that enables customer care complaints about QoS drops that
need immediate response.
PM6. Key Quality Indicators Reference - The service framework must be able to
maintain information to include the value of key quality indicators of services (KQI);
their dependencies on services and sub-services that impact on the overall service
that enables notification to customer where SLAs imply special actions or priorities
(e.g., premium customers). For example, for premium customers the information may
be used to implement a pro-active service quality management strategy to predict
and record the impact of potential or actual outages and their planned or unplanned
status that likely impact their premium customers.
PM7. Product/Service Life Cycle Reference - The service framework must be

able to provide linkage to and support the maintenance of reference data that reflects
a product/service life cycle in relation to technical or non-technical configuration
change that will impact the customer. For example, the purpose of a change may be
to introduce a new product or technology; to increase capacity (for general customers
and/or for a specific enterprise customer); or to fix immediate faults or technical
problems. The scope of the change may be to roll out a new type of element, or
additional instances of an existing type of element, or upgrade existing elements; or
to adjust the interactions between existing elements to improve quality of service.
Tel 011SLA - KPI/KQI Mapping
Mapping from SLA to KPI/KQI, needs to be implemented when service framework
objects are bound to actual equipment.
Is the mapping a part of the service framework?
Should jeopardy management be part of the framework or is it a part of the OSSs?
Should service framework must include KPI / KQI information for each service entity?
What about mapping and extending when specific network resources are bound to
the object?
Should the provisioning of service components into a service delivery chain must
include the key indicator information required for measuring the service delivery
performance of the service entity.
AGI-006 Loading The service framework must implement an interface to allow

loading of existing "service data". (Quality of data and re-sync of the data will have an
impact on the correctness of the service framework)
AGI-001 Navigation Ability to model the relationships between services, systems,

and resources, in a way that would allow the visualization of the different component
of a service.

AGI-004 Views Different view of the service, based on the customer standpoint, or
the network standpoint, must be possible. Possibly, partial view of the service
framework may be possible.
AGI-003 Layering Independence Service framework and its conceptual

representation must be independent from the data source/network layer it is based
upon in its particular instantiation.
Service Operations
A Service Framework is seen as enabler for Service Operations for the management
between the technical management of network resources (managed by KPI of
network operations), and the linkage through to business operations (managed by
key quality indicators). A common service framework enables the sharing and
consistency of information flow across the organisational functional boundaries to
support business process and workflow from technical and non-technical aspects of
the business.
S1. Service Modelling Bottom Up - The service framework must be able to

support a common set up of service resources and elements that can be defined
bottom-up to the highest level that is explicitly configured (e.g., cells and hosting,
circuit, server cluster, gateways etc) to allow for the monitoring of performance of
each service resources involved in the service delivery path.
COM-001 Vertical Relationships The service framework must contain relationship

information that identifies the parent and child (north / south) service entities.

Service A Service B
Serviice Group 1 Service Group 2 Service Group 3
Service Service Service Service Service Service

Resource a Resource b Resource c Resource d Resource e Resource f
Rationale
It must be possible from the service framework to be able to construct the service
topology ‘tree’ such that from any point in the tree it is possible to drill down to lower
level entities or upwards to higher order entities.
S2. Service Modelling Top Down - The service framework must be able to
model services that are defined top-down, to the lowest level of sub-service where
quality needs to be explicitly managed to the identified service element layer.
COM-002 Horizontal Relationships The service framework must contain

relationship information that identifies the peer (east / west) relationships

Example Architecture for

GSM WAP Service
HLR SMSC E-mail

SMPP Server
WAP DCN
http
Gatewa
Server
y
CSD Bearer
BSC RXCDR DCN
MSC/VLR
DCN Content
Server
BTS (Train
Timetable)
Rationale
It must be possible from the service framework to be able to construct the service
delivery path such that from any point in the path it is possible to drill sideways to the
next (east or west) service entities in the path.
Granularity dictated by service levels and need for diagnostic and root cause analysis
S3. Grouping and Classification - The service framework must be able to

support the grouping and classification of the quality measures that references
customer service level agreement (SLA) defined by contracts.
S4. Combination and Aggregation of Quality Parameters - The service

framework must be able to support the definition and monitoring of service metrics
that combines KPI and service statistics from multiple sources to infer the quality of
services and sub-services in order to prioritises problems. Top-level resource
components may be aggregated into combined KQI based on service dependencies
and hierarchical definition.
S5. Status Reference of Service Resources - The service framework must

provide a reference point of status for service resources that is to be maintained from
network and non-network sources.
S6. Shared User Views - It must be possible for different end users (in different
roles) to view and access information and must be possible to integrate to various

other OSS components (e.g., customer relationship management, billing,

provisioning, trouble ticketing etc).
S7. Identification of end-to-end service instances - The service framework

must be able to identify end-to-end service instances that can be viewed as particular
combinations of sub-services (or routes). These are legs of delivery whose quality is
managed in order to ensure the quality of the end-to-end service instances.
S8. Different End-to-End Service Delivery Perspectives - The service

framework must be able to reflect any sub-service component that may reflect end-to-
end interaction from customer perception or (e.g., from sending MMS to receiving
notification of successful/unsuccessful delivery); and/or of the service delivery path
transmitted across the network (e.g., download of content from a back-end WAP
gateway to the handheld device) that generates one (or more) performance records
off the service components.
S9. Faults Reference - The service framework must be able to reference Faults
within the network (i.e., technical problems) that trigger action to minimise or avert
impact on quality of services (both current and future). The reference to faults may
arise from a number of causes, such as configuration errors or unexpected capacity
bottlenecks, from equipment failures where faults relate to one or more combination
of service resources
S10. Customer Acceptance and Rollout - The service framework should be able
to support holding information of performance metrics and integrate with the end-to-
end customer acceptance testing of service elements that may impact go live to
production and rollout of service.
S11. Change Control Procedures - The service framework must be able to

provide reference point to track the progress of any changes to service resources that
may be managed through business process (manual or automated). For example,
where rollouts and upgrades impact operational elements or services, the relevant
configuration elements or sets would be executed via change control procedure
instigated by service operations for internal work order for service configuration and
activation.
S12. Comparative and Variation Monitoring - The service framework must be

able to support the pro-active monitoring and maintenance of testing, exception
conditions and unexpected changes to configuration that may be detected on an ad-
hoc basis and/or by periodic polling. This may be comparison with the expected
configuration where KPI have been set and affect SLAs. For example, the sampling
of a geographic region of service elements for viability of the launch of upgrade of
new service.
Resource Management
Resource Management is concerned with the more technical aspects in modelling,

defining and managing service resources involved in the service delivery chain. The
service framework is seen to underpin the common data structure to model the key

entities, attributes and interfaces in the service delivery architecture from evolving
technologies, GSM, 2.5, 3G etc. The identified requirements are:
R1. Creation of Service Resource Configuration Data between Sub Service

Elements - The service framework must be able to support the creation of sub-
services and/or dependencies where export/import of service configuration data are
created and needs to be shared across new sub service elements. This may be done
using automatic rules (e.g., radio access areas inferred from cells and hosting), or
manually (e.g., define and link application services and hosts). Dependencies might
also be defined in a logical design model and imported.
R2. Definition of Network Element Layer - The service framework must be able
to support the definition to network element layer that relates to the integration of the
service framework with element configuration managers. The view is that element
configuration manager bridges between logical configuration and physical
implementation. This may be achieved using a vendor-specific solution, a cross-
vendor solution (technology-specific or generic), or a cross-vendor solution driving
multiple vendor solutions. A cross-vendor solution might manage common
configuration across a subset of technologies.
R3. Service Alarm Reference - The service framework must be able to provide
reference point to service alarm analysis that uses dependencies to correlate quality
exceptions for services and sub-services with the results of technology-level alarm
analysis.
R4. Historical Service Data - The service framework must support the linkage of
historical service analysis providing flexible analysis of previous usage records for
various types of service, using different combinations and groupings of the type of
service the users/customers, and the elements involved.
R5. Consolidation of Common Information - The service framework must be

able to consolidate common information from multiple source components and make
it available to a number of other target service components involved in the physical
service delivery path. It must therefore be possible to relate and integrate any
common configuration by means of standard interface definition with a logical service
framework (e.g., entities and attribute definitions).
R6. Key Performance Indicator Reference - The service framework must be

able to hold information on key performance indicators off the network (i.e., the
technical quality of its services) in order for monitoring and measurement. For
example, these may be derived from different types of data source: element and
passive probe statistics, usage records, and real-time active probe measurements.
R7. Performance Monitoring – The service must be able to support and

reference data for operational monitoring and historical review, at the level of
individual elements, traffic patterns, or services. The purpose of these various
analyses is to support identification and diagnosis of faults, optimisation of
configuration, and upgrades and planning of capacity that affects service quality.

R8. Service Modelling of Service Sub Types - The service framework must be
able to support the definition of service and resources and/or sub-services that are of
different types. For example, at the highest level it should be possible to distinguish
application sub-services (content or information, media or media type) from the
transport sub-services (call or data session) that are used to access them, and also
used to connect with other users. Sub-services may be further broken down to lower
level sub-services, particularly if they are common across a number of higher level
services (e.g., email).
R9. User Defined Service Modelling – The service must be able to define the
level of granularity for monitoring purpose whether this is at high-level aggregate
service level or sub-service to manage the quality indicators as defined by the user.
For example, the lowest level sub-services would either have defined dependencies
on assets in common configuration (elements, circuits etc.), or be delivered by a 3rd
party (under an SLA) providing different view.
R10. Reference and Maintenance of Technical Quality - The service framework

must be able to support for each end-to-end service or sub-service, key technical
quality parameters using rules-based approach for measurement. For example, the
technical quality parameters of whether or not the service is available for use, and
whether its usability is degraded (according to various quality measure thresholds).
Both typical quality (averaged), and quality exceptions (individual or summarised)
may be considered. Different quality measures are appropriate for different services
or sub-services (e.g., delayed or incorrect call set-up, voice quality or jitter, application
response time).
Partner Management
A service framework needs to support the additional monitoring and control of service
resources used dependent on the multi partner service providers brought about the
additional complexity of product offerings. This will range from equipment vendors
(e.g., switches, handset devices etc) to application/content providers in the B2B
supply chain.
P1. SLA Management of Partners - The service framework must be able to

provide reference point to management of partners by SLA that can be defined using
key quality indicators for negotiating of internal/external service level agreement
(SLA).
P2. Multi B2B Parties Settlement - The service framework must be able to
provide a cross-reference point to revenue where product offering is dependent on
multiple B2B parties and revenue and profitability is dependent on revenue share,
multi-party settlement based on quality indicators and targets defined in SLA.
Tel 010 Requirement to B2B relationships
Identity and ownership of service components?
Support 3rd party settlement?

Support identification of financial liability in event of failure?
NOK-004 B-2-B support The service framework must not be limited by

organisational boundaries.
Rationale.
The service framework must support business-to-business relationships across

different companies.
Requirement to B2B relationships
Capture information to support business / investment decision making process
P3. 3rd Party service provider Reference - The service framework must be able
to provide a reference point to external 3rd Party service provider (e.g., bank/credit
agency, content provider) to allow for analysis of service components that make up
end-to-end service delivery chain for activation and provisioning and notification of 3rd
Party SLA breach.
P4. Internal SLA Management - The service framework must be able to provide
a reference point to performance monitoring of internal operational business units
involved in service delivery. For example, monitoring of network defined by different
class of service to end customer (e.g. Bronze, Silver, Gold) that is responsible for
maintaining bandwidth capability. Alternatively, where indirect inference of quality
customer care operations through monitoring of outage at customer call centre.
P5. Monitoring of 3rd Party Service Provider Delivery - The service framework
must be able to reference one or more end-to-end service instances as a complete
round trip interaction involving 3rd Party providers involved delivery of session as
experienced by a target customer. These end-to-end service instances may be
monitored or reviewed for particular groups of users (e.g., corporate customers,
premium customers), to check availability and quality against specific service levels,
as well as to analyse their usage patterns.
Misc requirements:
Identity and ownership of service components
Consider the re-use of existing components in context of new service
Support changes to service delivery components post launch.
Capability to manage the status of a component; planned, live etc.
Identify dependency and information flows between service components

Support drill up for impact analysis from service resource to impacted customers
Support relationships between customer, service, trouble ticket
Support RCA across multiple frameworks
Framework must support allow constraints and rules associated with a service and
resource.
Framework must support ability to monitor SLAs and the relationship between SLAs,
Customers and Services.

TMFC2198 GB924 - V1 (1) .0 - Me - 031004

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

TMFC2198 GB924 - V1 (1) .0 - Me - 031004

Uploaded by

Copyright:

Available Formats

Service Framework

Member Evaluation version 1.0 September, 2003

GB924 v1.0 TeleManagement Forum 2003

Direct inquiries to the TM Forum office:

89 Headquarters Plaza North – Suite 350

GB924 v1.0 TeleManagement Forum 2003

This document was prepared by the members of the TeleManagement Forum

GB924 v1.0 TeleManagement Forum 2003

Shahriar Shahriari, WatchMark

GB924 v1.0 TeleManagement Forum 2003

About this document

This document is an initial draft Guidebook. It provides information on the current

Document Life Cycle

Version Date Purpose

GB924 v1.0 TeleManagement Forum 2003

About TeleManagement Forum

TeleManagement Forum is an international consortium of communications service

GB924 v1.0 TeleManagement Forum 2003

GB924 v1.0 TeleManagement Forum 2003

Service Operator ..................................................................................................................................... 19

GB924 v1.0 TeleManagement Forum 2003

Figure 1. The scope of Guide Book related to the eTOM model 6

GB924 v1.0 TeleManagement Forum 2003

GB924 v1.0 TeleManagement Forum 2003

This document concentrates on describing the business problem in the service

Terms Used in this Document

Technology-neutral specification of an interface to a service; a Contract represents

Key Performance Indicators (KPIs)

Key Performance Indicators provide a measurement of a specific aspect of the

Key Quality Indicators (KQIs)

Provide a measurement of a specific aspect of the performance of the product,

(Logical) resource values set through operations functions

Resources (Physical or Logical)

Resources represent physical and non-physical components used to construct

GB924 v1.0 TeleManagement Forum 2003

A telecommunication service is a set of independent functions that are an integral part

Service resources and skills/capabilities of the processes

The implementation of the service in production

Service Level Agreement (SLA)

A formal negotiated agreement between two parties, sometimes called a Service

An SLA or Contract is a set of appropriate procedures and targets formally or

Management of Services to meet customer’s requirements. [ITIL]

Service Quality Management

GB924 v1.0 TeleManagement Forum 2003

A service topology is a pattern for composing a distributed application. Different types

A person or a machine delegated by a Customer to use the services and/or facilities

GB924 v1.0 TeleManagement Forum 2003

Business Problem Description

The framework is aimed at providing a ‘user friendly’ representation that ‘insulates’

GB924 v1.0 TeleManagement Forum 2003

Guide Book Scope and Context

Marketing and Offer Management Customer Relationship Management

Service Development & Management Service Management & Operations

Resource Development & Management Resource Management & Operations

Supply Chain Development & Management Supplier/Partner Relationship Management

© TeleManagement Forum October, 2001

Figure 1. The scope of Guide Book related to the eTOM model

GB924 v1.0 TeleManagement Forum 2003

Inter- process dependency:

New Functional Areas:

GB924 v1.0 TeleManagement Forum 2003

The figure below shows the service decomposition issue.