Sie sind auf Seite 1von 88

Service Problem Management

Business Agreement

TMF522
TM Forum Approved Version 1.5

May, 2011

TM Forum 2011

Service Problem Management Business Agreement

Notice
Copyright (C) 2011 TM Forum
Licensed under the Apache License, Version 2.0 (the "License");
You may not use this file except in compliance with the License.
You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless
required by applicable law or agreed to in writing, software distributed under the License is
distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND,
either express or implied. See the License for the specific language governing permissions and
limitations under the License.

TMF522, Version 1.5

TM Forum 2011

Page 2 of 88

Service Problem Management Business Agreement

Table of Contents
Notice ............................................................................................................................................................ 2
Table of Contents .......................................................................................................................................... 3
Requirements ................................................................................................................................................ 5
Use Cases ..................................................................................................................................................... 6
List of Figures ................................................................................................................................................ 7
Executive Summary ...................................................................................................................................... 9
1

Introduction .......................................................................................................................................... 10
1.1

Overview ....................................................................................................................................... 10

1.2

Document Structure ...................................................................................................................... 10

1.3

Terminology Used In This Document ........................................................................................... 11

Business Problem Description, Project Scope .................................................................................... 12


2.1

2.1.1

Relationship to TAM ................................................................................................................ 12

2.1.2

Relationship to eTOM ............................................................................................................. 13

2.2

Supported Business scenarios ..................................................................................................... 14

2.2.1

Reactive .................................................................................................................................. 14

2.2.2

Proactive ................................................................................................................................. 21

2.2.3

Predictive ................................................................................................................................. 27

2.3
3

Project Scope ............................................................................................................................... 12

Benefits ......................................................................................................................................... 32

Business Processes............................................................................................................................. 34
3.1

Business Requirements ................................................................................................................ 34

3.2

Category I: Static and Structural Requirements ........................................................................... 34

3.2.1
3.3

Service Problem ...................................................................................................................... 34

Category II: Normal Sequences, Dynamic Requirements ............................................................ 40

3.3.1

Service Problem Notification ................................................................................................... 40

3.3.2

Service Problem Control ......................................................................................................... 41

3.3.3

Service Problem Subscription ................................................................................................. 44

3.3.4

Service Problem Retrieval ....................................................................................................... 44

3.4

Category III: Abnormal or Exception Conditions, Dynamic Requirements ................................... 45

3.5

Category IV: Expectations and Non-Functional Requirements .................................................... 47

3.6

Category V: System Administration Requirements ...................................................................... 47

Use Cases ........................................................................................................................................... 48


4.1

Service Problem Notification ........................................................................................................ 48

TMF522, Version 1.5

TM Forum 2011

Page 3 of 88

Service Problem Management Business Agreement

4.2

Service Problem Control ............................................................................................................... 52

4.3

Service Problem Subscription ...................................................................................................... 73

4.4

Service Problem Retrieval ............................................................................................................ 75

Traceability Matrices ............................................................................................................................ 80


5.1

Use Cases Requirements Matrix ............................................................................................... 80

5.2

Requirements Use Cases Matrix ............................................................................................... 82

References ........................................................................................................................................... 85
6.1

References ................................................................................................................................... 85

6.2

IPR Releases and Patent Disclosure ........................................................................................... 85

Administrative Appendix ...................................................................................................................... 86


7.1

About this document ..................................................................................................................... 86

7.2

Use and Extension of a TM Forum Business Agreement ............................................................ 86

7.3

Document History ......................................................................................................................... 86

7.4

Company Contact Details ............................................................................................................. 87

7.5

Acknowledgments......................................................................................................................... 87

TMF522, Version 1.5

TM Forum 2011

Page 4 of 88

Service Problem Management Business Agreement

Requirements
R_TMF522_I_0001

34

R_TMF522_I_0002

34

R_TMF522_I_0003

34

R_TMF522_I_0004

35

R_TMF522_I_0005

36

R_TMF522_I_0006

36

R_TMF522_I_0007

38

R_TMF522_I_0008

39

R_TMF522_I_0009

39

R_TMF522_I_0010

39

R_TMF522_I_0011

39

R_TMF522_I_0012

39

R_TMF522_II_0013

40

R_TMF522_II_0014

40

R_TMF522_II_0015

40

R_TMF522_II_0016

41

R_TMF522_II_0017

41

R_TMF522_II_0018

41

R_TMF522_II_0019

41

R_TMF522_II_0020

41

R_TMF522_II_0021

41

R_TMF522_II_0022

41

R_TMF522_II_0023

41

R_TMF522_II_0024

42

R_TMF522_II_0025

42

R_TMF522_II_0026

42

R_TMF522_II_0027

43

R_TMF522_II_0028

43

R_TMF522_II_0029

44

R_TMF522_II_0030

44

R_TMF522_II_0031

44

R_TMF522_II_0032

44

TMF522, Version 1.5

TM Forum 2011

Page 5 of 88

Service Problem Management Business Agreement

Use Cases
UC_TMF522_0001

47

UC_TMF522_0002

48

UC_TMF522_0003

49

UC_TMF522_0004

50

UC_TMF522_0005

51

UC_TMF522_0006

53

UC_TMF522_0007

55

UC_TMF522_0008

57

UC_TMF522_0009

58

UC_TMF522_0010

60

UC_TMF522_0011

62

UC_TMF522_0012

63

UC_TMF522_0013

65

UC_TMF522_0014

67

UC_TMF522_0015

69

UC_TMF522_0016

71

UC_TMF522_0017

73

UC_TMF522_0018

74

UC_TMF522_0019

75

UC_TMF522_0020

76

UC_TMF522_0021

78

TMF522, Version 1.5

TM Forum 2011

Page 6 of 88

Service Problem Management Business Agreement

List of Figures
Figure 2-1. Telecom Application Map (TAM) .............................................................................................. 13
Figure 2-2. Hypothetical Problem Management OSSs ............................................................................... 17
Figure 2-3. Capacity and SLA Management ............................................................................................... 19
Figure 2-4. Proactive Detection of Potential Service Problems .................................................................. 22
Figure 2-5. Failed Network Resource Example .......................................................................................... 24
Figure 2-6 Customer report a service problem Example ............................................................................ 26
Figure 2-7. Network degradation trend detected Example ......................................................................... 28
Figure 2-8. Customer reports of a transient service problem Example ...................................................... 30
Figure 2-9. Customer trouble report leading to detection of network degradation trend ............................ 32
Figure 3-1. Service Problem Instance state transition diagram .................................................................. 43

TMF522, Version 1.5

TM Forum 2011

Page 7 of 88

Service Problem Management Business Agreement

List of Tables
Table 3-1. List of Reasons (probable causes) ............................................................................................ 37
Table 5-1. Use Cases Requirements Matrix ............................................................................................ 80
Table 5-2. Requirements - Use Cases Matrix ............................................................................................. 82

TMF522, Version 1.5

TM Forum 2011

Page 8 of 88

Service Problem Management Business Agreement

Executive Summary
This business agreement document provides requirements and use cases for service problem
management, i.e., the management of problems that cause one or more services to function at a level
below what was committed to the customer.
In terms of requirements, the concept of a service problem is defined (this is basically a static
requirement). This is followed by several dynamic requirements in the following areas:

service problem notifications

service problem control, i.e., the creation, modification and deletion of service problems

service problem subscription

service problem retrieval.

The requirements are followed by several use case that provide non-prescriptive flows in support of the
requirements. Each use case is traced back to one or more requirements. Further, requirement use
case traceability matrices are provided.
The document starts was several end-to-end service problem scenarios that cover a subset of the topic
of interest in this document. This is done to clearly set the context for the issue at hand (service problem
management) and to make clear what is and what is not in scope.

TMF522, Version 1.5

TM Forum 2011

Page 9 of 88

Service Problem Management Business Agreement

1 Introduction
1.1

Overview

The TM Forum has given much attention to the evolution of next generation networks and the business
and operational support systems needed to manage them. As a result, the NGOSS framework was
developed to provide a toolkit of industry-agreed specifications and guidelines that cover key business
and technical areas. NGOSS is reinforced by a set of unified open interfaces used between Operations
Systems (OSs) for the purpose of network and service management. Many of these interfaces have been
developed by individual groups such as OSS/J, mTOP and SLA management teams and may not be in
alignment.
Additionally, there are potential gaps or weaknesses for service problem management, especially for
newer, more advanced information and content services. To date, most service assurance activities have
focused on a set of network-facing processes aimed at determining and resolving network and service
issues and events. With the increased range of services now being offered and the increasingly
competitive market-driven environment, new demands are being placed on the service assurance
systems to deliver even higher levels of service to customers.
The TM Forum recognizes the service assurance platforms need to evolve at the same rate of speed as
the networks used to deliver services. The NGOSS Service Assurance team has been created to develop
interfaces at the service management level. The two main goals for the team are to:

1.2

provide a detailed service problem management interface for transport services, information
services and content services

define a methodology (in practice) and example of how to define NGOSS interfaces that
satisfy the needs of OSS/J and mTOP while following the SID model. In the past, we have
tended to work in silos and have then been left with the task of aligning SID, OSS/J and
mTOP specifications after the fact.

Document Structure

The following sections are contained in this document:

Section 1 is the introduction.

Section 2 defines the scope of the project and also provides business scenarios.

Section 3 covers the requirements.

The detailed use cases are in Section 4.

Traceability matrices between use cases and requirements can be found in Section 5.

References and any Intellectual Property Right (IPR) claims are listed in Section 6.

Contacts, acknowledgements and other administrative items can be found in Section 7.

TMF522, Version 1.5

TM Forum 2011

Page 10 of 88

Service Problem Management Business Agreement

1.3

Terminology Used In This


Document

The terminology used in Section 2.2 is based on separations used in the eTOM and TAM. However, it
must be emphasize that Section 2.2 covers example systems and neither the eTOM nor TAM define
systems but rather processes and applications, respectively.
The term service problem (the main focus of this document) is defined at the beginning of Section 3.2.1.

TMF522, Version 1.5

TM Forum 2011

Page 11 of 88

Service Problem Management Business Agreement

2 Business Problem Description, Project Scope


2.1

Project Scope

The scope of this project concerns requirements, use cases, information model and a detailed interface
specification for service assurance of transport, information and content services. The focus is on fault
management. Also, it is important to relate the fault management aspects to the closely related topics of
service trouble management and service level performance. It should be emphasized, however, that
trouble management and performance are out of scope.

2.1.1

Relationship to TAM

In terms of the TAM 3.0, the project fits the Service Problem Management area (see Figure 2-1). The
following items from the TAM Service Problem Management area are to be covered:

Customer Problem Resolution (this item needs to be considered further)

Correlation & Root Cause Analysis (as this impacts the interface to be defined)

Allocating priority (as indicated in a service problem)

Problem Reception (reception of service problems)

Problem Consolidation (of service problems)

Advising the Customer Relationship Management systems (via service problems)

Advising the Network Operations Center (via service problems)

Tracking progress (of service problems, e.g., acknowledgement/un-acknowledgement,


clearing, escalation)

Confirming when impact has been removed (via service problems)

Updating Configuration Management systems (via service problems)

Updating Inventory Management systems (via service problems)

Updating Billing systems (via service problems)

Note that the focus is on service problems and not on trouble tickets (as this item is out of scope for this
interface).

TMF522, Version 1.5

TM Forum 2011

Page 12 of 88

Service Problem Management Business Agreement

Figure 2-1. Telecom Application Map (TAM)

2.1.2

Relationship to eTOM

It is also instructive to note the coverage of this interface with respect to the eTOM processes in
GB921_D. It is important to emphasize that the eTOM defines processes and this document covers
interfaces. So, the explanation that follows will indicate which of the eTOM processes has interface
implications on the interface at hand.
In general, the area of interest in this document is the eTOM level 2 process known as Service Problem
Management (SPM). In terms of terminology, it should be noted that this document uses the term
Service Problem to refer to both the actual real world problem and the object that represents the
problem. The eTOM, however, uses Service Problem to reference the problem in the real world and
Service Trouble Report for the entity (i.e., the object instance) that represents the real world problem.
The terminology is further complicated by the fact that the eTOM does not seem to distinguish between
Trouble Tickets and Service Problems. However, the OSS/J Trouble Ticket API and the interface defined
in this document do make such a distinction (as do actual products). It is assumed for the purposes of this
discussion that the Service Trouble Report mentioned (but never defined) in the eTOM could be either
what is called a Service Problem in this document or a Trouble Ticket as defined in the OSS/J Trouble
Ticket API.
Interface implications for the various eTOM level 3 processes with Service Problem Management (SPM)
are as follows:

TMF522, Version 1.5

TM Forum 2011

Page 13 of 88

Service Problem Management Business Agreement

Create Service Trouble Report This seems to be an internal process that would not use the
SPM interface defined in this document. [Note: the implied coupling between the Create Service
Trouble Report and Report Service Problem processes appears to very tight. In fact, it seems that
the only way for this process to communicate with another is via the Report Service Problem
process.]

Diagnose Service Problem This process is a user of the SPM interface. In particular, this
process will be a subscriber to notifications related to service problems created by instances of
the Create Service Trouble Report process and forwarded by the Report Service Problem
process.

Correct & Resolve Service Problem This process is a user of the SPM interface. In particular,
this process will be a subscriber to notifications related to service problems created by instances
of the Create Service Trouble Report process.

Track & Manage Service Problem This process will use the SPM interface to report on status
changes to service problems, allow service problems to be updated (e.g., add a comment or
acknowledge a service problem) and to accept requests to retrieve service problems.

Report Service Problem This process will typically use the SPM interface to announce service
problems to other interested processes.

Close Service Trouble Report This process will use the SPM interface to indicate when a
service problem has been resolved and closed.

Survey & Analyze Service Problem This process appears to be out of scope for the SPM
interface.

2.2

Supported Business scenarios

The following scenarios cover the general area of service assurance. The intent is to use the scenarios to
identify gaps in the TM Forum coverage in the area of service assurance and to help define the scope of
the NGOSS Service Assurance project. To be clear, the intention is to focus on the area of Service
Problem Management and not the entirety of Service Assurance.
Once reviewed, updated and accepted by the team, the intention would be to
1. add the scenarios to the Business Scenarios section of the Business Agreements (BA) for this
project
2. derive some high-level use cases from the scenarios
3. define and detail use cases based on the agreed scope of the project (as noted the scenarios will
help determine the scope).
It should be emphasized that the OSS types in the scenarios that follow are just examples and are in no
way meant to be prescriptive. Clearly, other OSS configurations are possible

2.2.1 Reactive
2.2.1.1 Network resource fault leading to service interruptions
Name: Network resource fault leading to service interruptions
Summary: A network fault occurs, e.g., both the primary and protecting path for a high-speed link are
severed during a storm. The failure affects all services for a group of customers in a given area (i.e., no

TMF522, Version 1.5

TM Forum 2011

Page 14 of 88

Service Problem Management Business Agreement


service at all) and also prevents other customers (and non-customers for that matter) from reaching the
affected parties.
The Operations Support Systems (OSSs) used in the scenario are summarized in Figure 2-2.
1. A network fault occurs. For this example, assume that a SONET OC-48 link in the access
network fails and there is no protection, or there is protection but it fails also.
2. The link failure is detected by the NEs on either side of the link and the NEs report LOS to the
managing EMS(s). Just to make things more complicated, lets assume that different EMSs
manage the NEs, e.g., one NE may be an ADM from one supplier and the other NE may be a
DCS from another supplier.
3. Each EMS sends a LOS alarm (related to the end of the link it manages) to the same OSS which
we call the Resource Trouble Management (RTM) OSS.
4. The RTM OSS manages both ends of the link and is able to isolate the problem to the link (as
opposed to the end points of the link). Note that the EMSs would not be able to determine
whether the link failed or the end point (or supporting equipment) at the far end of the link failed.
5. The RTM OSS sends a link LOS alarm to a Service Problem Management (SPM) OSS.
[Alternately, the LOS alarm could be sent to an SQM OSS (not show in the diagram) that will
determine that there is a service violation and then send a service problem to the SPM OSS. The
SPM OSS determines that the origin of the problem is the LOS alarm and associates it to the
service problem. In any event, this is just an example and the intent is not to illustrate all possible
cases.] For the sake of speed, the problem may be sent before the RTM OSS requests that the
Resource Trouble Ticketing (RTT) OSS create an associated Trouble Ticketing (TT).

Based on the policy of the service provider, the resource alarm is acknowledged by a
user of the SPM OSS. The acknowledgement is propagated downward to the subtending
RTM OSS, EMSs and NEs (if needed).

The SPM OSS determines that access to all wire-line customer services is not possible
for all services that terminate in a given area.

(In Scope) The SPM OSS creates and sends one or more service problems to
the Customer Problem Resolution (CPR) OSS and other interested parties. Note
that the CPR OSS and not the SPM OSS determines the association between
the service problem(s) and the set of affected customers.

The CPR OSS will request that the Customer Trouble Ticketing (CTT) OSS
create one or more customer TTs.

The customer TT(s) should reference the associated service TT(s) but this
determination could be difficult unless (In Scope) the SPM OSS informs the CPR
OSS about the service TTs and the associated service problems.

The SPM OSS requests that the Service Trouble Ticketing (STT) OSS create one or
more service TTs. For each TT, references to one or more service problems, or perhaps
a root service problem are included.

6. The RTM OSS sends a resource TT creation request to the RTT OSS. References to one or
more resource alarms, or perhaps a root resource alarm are included.

The RTM OSS also sends a request to a dispatch OSS which schedules personnel and
resources (e.g., repair vehicles) to repair the problem (the schedule could indicate that
immediate attention is required). The dispatch information is appended to or referenced
from the resource TT.

TMF522, Version 1.5

TM Forum 2011

Page 15 of 88

Service Problem Management Business Agreement

The service TT(s) should reference the associated resource TT(s) but this determination
could be difficult unless the RTM OSS informs the SPM OSS about the resource TT and
the associated resource alarm.

7. Meanwhile, the customers are calling the service provider concerning the problem via their cell
phones.

Depending on the policies of the service provider, a customer TT may be created for
each customer that calls with a problem or (in the very least) the location of the
customer reporting a problem will be recorded as this is useful in determining the
scope of the network problem. (In Scope) Location isolation information would be
reported downward from the CPR OSS to the SPR OSS to the RTM OSS.

On the other hand, the CTT OSS may already have created a TT for the customer in
which case it is just a matter of making a note on the existing TT that the customer
called to report the problem at a given time.

In any event, the CTT OSS needs to associate the customer TTs with the underlying
service TTs, and the CPR OSS needs to associate the customer trouble reports with
the underlying service problems.

8. Repair personnel fix the severed link. The repair activity is recorded in the resource TT(s).
9. The NEs report that the alarms are cleared to the EMSs which in turn, report alarms clears to the
RTM OSS. The RTM OSS determines that the link has been fixed and sends one or more
problem clears to the SPM OSS. (In Scope) The SPM OSS sends one or more problem clears to
the CPR OSS and other interested OSSs.
10. The RTM, SPM and CPR OSSs report that the trouble has been cleared to the RTT, STT (In
Scope) and CTT OSSs, respectively. Depending on the policy of the service provider the TT
OSSs may close their respective TTs at this time or they may wait until a human user determines
the TT should be closed.
11. A record of the various alarms, problems and TTs may need to be kept for various reasons, e.g.,
laws or regulatory mandates, billing (possible discounts from customer bills) and customer
inquiries. (In Scope) In particular, retrieval of historical information concerning service problems
needs to be supported.
12. Although not common, clients of the alarm generating OSSs may get out of synchronization alarm
generating OSS regarding active alarms. Client-server alarm synchronization may also be
needed when a new OSS is inserted into a management environment. (In Scope) In particular,
the SPM OSS needs to offer the ability for its clients to request the set of active problems (along
with a filtering capability).

TMF522, Version 1.5

TM Forum 2011

Page 16 of 88

Service Problem Management Business Agreement

Customer
Problem
Resolution
(CPR) OSS

Customer
Trouble
Ticketing
(CTT) OSS

TT management (out
of scope)
Service
Problem
Management
(SPM) OSS

Service
Trouble
Ticketing
(STT) OSS
Service alarms (in
scope)

Resource
Trouble
Management
(RTM) OSS

EMS #1

EMS #2

Subnetwork #1

Resource
Trouble
Ticketing
(RTT) OSS

EMS #3

Subnetwork #3
Subnetwork #2

Management Interface
(out of scope)
Management Interface
(in scope)

Severed Link

Figure 2-2. Hypothetical Problem Management OSSs

2.2.1.2 Overbooking of a network resource that leads to service violations


Name: Overbooking of a network resource that leads to service violations

TMF522, Version 1.5

TM Forum 2011

Page 17 of 88

Service Problem Management Business Agreement


Summary: A network resource (e.g., an SDH vc-4-64c path between two locations) is overbooked. The
path is used to carry IP based services. However, the level of overbooking is now causing IP packets to
be discarded at a rate higher than is allowed by the SLA for some of the services being supported by the
vc-4-64c path. (Note that the IP packets would typically be carried by ATM or PPP/HDLC over SDH.)
The various OSSs in the following scenario are just examples. Clearly, other OSS configurations are
possible. The OSSs used in the scenario are summarized in Figure 2-3.
1. The IP Performance Management (IPM) OSS monitors IP performance at the ingress and egress
points of the SDH network. For example, if DiffServ is used, the IPM OSS would monitor various
DiffServ classes for performance (e.g., dropped packets per given time period).
2. The Service Level Agreement (SLA) Management (SLAM) OSS receives Performance
Management (PM) reports from the IPM OSS, derives service performance statistics from the
resource PM data, checks the service performance statistics against SLAs and determines if any
SLAs have been violated.
3. (Possibly In Scope) When an SLA is violated, the SLAM OSS will send an event to the CPR
OSS. Since the service is technically not working as promised, should a service problem be sent
to the CPR OSS? In addition to the possible service problem, the SLAM would also send a
Threshold Crossing Alert (TCA) to the CPR OSS (this would be out of scope).

The CPR OSS will start various activities, e.g., informing the customer, informing a
billing system so that a partial refund can be credited to the customer and requesting
the creation of a customer trouble ticket.

4. (Possibly In Scope) Similar to the previous step, the SLAM OSS will send an event to the
Service Capacity Management (SCM) OSS when the SLA is violated. Do we want to send both a
service problem and a TCA?

The SCM OSS will request that the Transport Capacity Management (TCM) OSS
increase transport capacity (mapping to the associated services is done by the SCM
OSS). If the TCM OSS does not have available capacity, it will need to prepare a
resource order.

5. Alternately or in addition, the IPM OSS could be designed and configured to request additional
transport capacity from the TCM OSS before SLAs are violated, perhaps leading to better
customer service and an over-engineered network.

TMF522, Version 1.5

TM Forum 2011

Page 18 of 88

Service Problem Management Business Agreement

Management Interface
(out of scope)

Customer Problem
Resolution (CPR) OSS

Management Interface
(possibly in scope)

Service Level Agreement


(SLA) Management
(SLAM) OSS

Service Capacity
Management (SCM)
OSS

IP Performance
Management (IPM) OSS

Transport Capacity
Management (TCM)
OSS

IP Network
SDH Network

Figure 2-3. Capacity and SLA Management

2.2.1.3 Customer(s) report of a service problem


Name: Customer(s) report of a service problem
Summary: A customer calls the service provider to report a problem with a given service. The service
provider will need to distinguish between several cases (two of which are considered here):

Case 1: the customer trouble report is associated with known network problems

Case 2: the customer trouble report is associated with a fault that is local to the customer.

For this scenario, we use the example OSSs and associated diagram in Figure 2-2.
1. A customer calls their service provider to report a problem with a service (e.g., IPTV). For the
sake of argument, assume that the customer has a very poor picture on most channels.
2. The service provider representative enters the report into the CTT OSS or perhaps some OSS
that flows to the CTT OSS.

TMF522, Version 1.5

TM Forum 2011

Page 19 of 88

Service Problem Management Business Agreement


3. The CTT OSS checks to see if an associated customer TT has already been created (possibly via
some automated procedure).

Case 1: If so, the CTT OSS alerts the service provider representative that a customer
TT has already been created and the problem is being addressed. (In Scope) Also,
the customer TT can be traced to a specific service problem (owned by the SPM
OSS).

Case 2: A customer TT has not yet been created. It should be emphasized that there
may in fact be a network failure which was not detected prior to customer complaint.
So, it is recommended to first test and analyze the problem and see if it is network
related or not. If the problem is determined to be network related, then a resource TT
should be created (a customer TT is also created). On the other hand, if no network
problems can be identified in relation to the customers problem, the CTT OSS will
create a work order to have someone visit the customers location (a customer TT is
also created in this case).

4. In either case, the service provider representative relays the information back to the customer.
5. In Case 2, if the problem is isolated to the customer location, a repair is made on site. If the
problem cannot be isolated to the customer location, this is recorded in the TT, and the CPR OSS
needs to initiate further investigation in the service providers network. For the sake of argument,
assume that the problem is eventually isolated in the service providers access network. Under
this assumption, the next steps are as follows:

(In Scope) A service problem will need to be created in the SPM OSS (perhaps this
will need to be done manually). The SPM OSS will send the service problem to the
STT OSS which creates a service TT. [Alternately, a service problem may not be
needed. For example, the CTT OSS could request the creation of a TT in the STT.
The STT operator would see that the TT does not related to a know problem and will
notify the SPM.]

(In Scope) The SPM OSS will send the service problem to the CPR OSS which
forwards the information to the CTT OSS. Since a related customer TT already exists
in the CTT OSS, it is just a matter of updating this TT with the information concerning
the service problem.

6. The SPM OSS sends a resource alarm to the RTM OSS which, in turn, requests that the CTT
OSS create a resource TT.
7. The RTM OSS comes to the knowledge that the root cause of the network problem has been
corrected and sends an alarm clear to the SPM OSS. (In Scope) The SPM OSS sends a problem
update to the CPR OSS and other interested OSSs. This doesnt seem to be a clear until the
service provider can verify with the customer that the problem has been corrected from the pointof-view of the customer.
8. The affected customer(s) will be contacted (coordinated by the CPR OSS or some customer
facing OSS) to make sure the customer also sees the problem as being corrected. (In Scope) If
the customer verifies that the problem has been corrected, the CPR OSS informs the SPM OSS
via a service problem clear.
9. Assuming the customer verifies that the problem has been corrected, the SPM and CPR OSSs
report that the trouble has been cleared to the STT (In Scope) and CTT OSSs, respectively. (The
RTM OSS should already have requested a clear of the resource TT since this doesnt depend on
verification from the customer.) Depending on the policy of the service provider the TT OSSs may
close their respective TTs at this time or they may wait until a human user determines the TT
should be closed. [Alternately, this process could be driven by TTs. For example, the customer
TT clear induces the service TT clear which, in turn, induces the service problem clear. Further,
the service TT clear induces the resource TT clear which induces the resource problem clear.]
TMF522, Version 1.5

TM Forum 2011

Page 20 of 88

Service Problem Management Business Agreement

2.2.2 Proactive
2.2.2.1 Detection and handing of a degraded network resource that could lead to service
violations
Name: Detection and handing of a degraded network resource that could lead to service violations
Summary: In this scenario, a resource level OSS detects potential problems that may eventually affect
services, e.g., a poor fiber splice or overbooking of a network resource.
The OSSs in this scenario are depicted in Figure 2-4.
Case 1 (Degraded Network Resource):
1. A network resource (e.g., a vc-4-64c SDH link) is operational but in a degraded capacity. For
example, perhaps a poor fiber splice was performed and now the count of Severely Errored
Framing Seconds (SEFS) is starting to rise.
2. The SDH Performance Management (SDH-PM) OSS detects the problem and sends a TCA to
the RTM OSS which also flows (via the RTM OSS) to the SQM OSS.
3. The RTM OSS creates a resource alarm and notifies the RTT which creates a resource TT.
4. The SQM OSS detects that this degradation does not directly impact the service, but is impacting
the service compliance and can lead to a violation if not fixed within the hour.
5. (In Scope) The SQM OSS sends a warning service problem to the SPR OSS. The SPR OSS
creates a service ticket in the STT OSS.
6. The STT OSS notifies the RTT OSS which associates this problem with the previous network TT.
7. The RTT OSS arranges for the problem to be repaired.
8. Subsequently, the problem is repaired and the resource TT is cleared.
9. The SDH-PM OSS detects that the problem has gone away and send a clear TCA to the RTM
OSS which also flows to the SQM OSS.
10. (In Scope) The SQM OSS sends, in turn, a clear service problem to the SPR OSS that notifies
the STT OSS to get the service TT closed.
Case 2 (Overbooking of a Network Resource):
1. A network resource (e.g., a vc-4-44c SDH link) is operational. However, the clients of the
resource, e.g., two IP routers at either end, have overbooked the resource. For the example at
hand, the result of this is the loss of IP packets.
2. The IPM OSS detects a loss of IP packets that cross a given threshold for a given interval. A TCA
is sent to the RTM OSS that creates a resource alarm and then requests that a resource TT be
created in the RTT OSS. The RTM OSS also sends the TCA (possibly modified) to the SQM
OSS.
3. The RTM addresses the problem and notifies the RTT.
4. The SQM OSS notes the TCA but at this point no SLAs have been violated.
5. At the resource level, the resources supporting the two IP routers are increased or traffic to the
two IP routers is diverted to another configuration that has spare capacity.
6. After the updates, the threshold is not exceeded for several intervals and the SQM OSS sends a
TCA clear to interested parties.

TMF522, Version 1.5

TM Forum 2011

Page 21 of 88

Service Problem Management Business Agreement


For Case 2, there does not appear to be any impact on the service level problem management interface.
So, Case 2 appears to be completely out of scope.

Service Problem Resolution


(SPR) OSS

TT management (out
of scope)

Service Trouble Ticketing


(STT) OSS

Service alarms (in


scope)

Service Quality
Management (SQM) OSS

Resource Trouble
Management (RTM) OSS

Resource Trouble Ticketing


(RTT) OSS

SDH Performance
Management (SDH-PM)
OSS

IP Performance
Management (IPM) OSS

IP Network
SDH Network

Management Interface
(In scope)

Management Interface
(out of scope)

Figure 2-4. Proactive Detection of Potential Service Problems

TMF522, Version 1.5

TM Forum 2011

Page 22 of 88

Service Problem Management Business Agreement

2.2.2.2 Detection and handling of a failed network resource that could lead to service violations
Name: Detection and handling of a failed network resource that could lead to service violations
Summary: In this scenario, a network resource (or other type of resource) has a failure that could lead to
service violations. For example, perhaps a protected resource (SDH link or a file server) fails but there is
an automatic switch-over capability to a hot backup. No services are affected, but now the resource may
not have a backup. So, repairs need to be made soon; otherwise, a second failure (to what was the
backup and now the primary resource) will affect services.
This scenario makes use of the OSSs in Figure 2-5.
1. Assume that a resource has failed and a protect switch was successfully made. The NE(s) will
report an alarm for the resource and also send a protection switch event to the EMS(s).
2. The EMS(s) will send both the resource alarm and protection switch event to the RTM OSS.
3. The RTM OSS will send both the resource alarm and protection switch event to SQM OSS.
4. RTM OSS notifies the RTT OSS which creates a resource TT to get the problem fixed.
5. The SQM OSS, however, determines that no services are affected at this point. So, propagation
of the alarm and protection switch could stop at this point. (Possibly In Scope) On the other
hand, SQM OSS determines that this resource has now no backup and that a subsequent failure
would impact the service. (In Scope) So it sends a warning service problem to the SPR OSS.
6. (In Scope) The SPR OSS detects that the service problem is due to a network alarm and makes
the association. Since no services have yet been impacted, it is not necessary to create a service
TT. The STT OSS notifies the RTT OSS which, in turn, associates this problem to the existing
resource TT.
7. Repair personnel are sent on site, fix the problem and update the resource TT.
8. The resource agent (e.g., the NE) sends a clear to the EMS which forwards it to the RTM OSS.
9. The RTM OSS notifies the SQM OSS which determines that things are back to normal.
10. (In Scope) SQM OSS sends a clear service problem to the SPR OSS.

TMF522, Version 1.5

TM Forum 2011

Page 23 of 88

Service Problem Management Business Agreement

Service Problem Resolution


(SPR) OSS

TT management (out
of scope)

Service Trouble Ticketing


(STT) OSS

Service alarms (in


scope)

Service Quality
Management (SQM) OSS

Resource Trouble
Management (RTM) OSS

EMS #1

EMS #2

Subnetwork #1

Resource Trouble Ticketing


(RTT) OSS

EMS #3

Subnetwork #3
Subnetwork #2

Management Interface
(out of scope)
Management Interface
(in scope)

Severed Link

Figure 2-5. Failed Network Resource Example

2.2.2.3 Customer(s) report of a service problem


Name: Customer(s) report of a service problem
Summary: In this scenario, a customer reports a problem with his/her service. After evaluation by the
service providers assurance OSSs and/or personnel, it is determined that the customer trouble report is
related to a previously undiscovered resource problem.
1. A customer calls their service provider to report a problem with a service (e.g., IPTV). For the
sake of argument, assume that the customer has a very poor picture on most channels.

TMF522, Version 1.5

TM Forum 2011

Page 24 of 88

Service Problem Management Business Agreement


2. The service provider representative enters the report into the CTT OSS.
3. The service provider representative tells the customer that the problem will be investigated but at
the present time there are no known network problems associated with the customers problem
report.
4. The CTT OSS notifies the SQM OSS.
5. The SQM OSS verifies that there is a problem with the service instance supporting the customer.
6. (In Scope) The SQM OSS requests the creation of a service problem in the SPR OSS.
7. (In Scope) The SPR requests the creation of a service TT in the STT which gets associated with
the customer TT.
8. (In Scope) The SPR operator investigates existing RTT alarms but does not (at this point) detect
any problems that might explain the service violation.
9. A second customer calls their service provider to report a problem with his service.
10. The service provider representative enters the report into the CTT OSS.
11. The service provider representative tells the customer that the problem will be investigated but at
the present time there are no known network problems associated with the customers problem
report.
12. The CTT OSS notifies the SQM OSS.
13. The SQM OSS verifies that there is a problem with the service instance supporting the customer.
14. (In Scope) As this is a different service instance (assume it is the same service type), the SQM
OSS requests the creation of a service problem in the SPR OSS.
15. The SPR OSS requests the creation of a service TT in the STT which gets associated with the
customer TT.
16. The SPR OSS investigates the problem and now finds that both customers are sharing the same
access switch.
17. The SPR OSS sends a request (as a maintenance or diagnosis command) to the RTM OSS to
ping this switch.
18. The RTM pings the switch and finds it is unreachable. It creates a resource alarm and notifies the
RTT which creates a resource TT.
19. (In Scope) The SQM OSS is notified and sends a service problem report to the SPR. This covers
the two services instances for the two customers that called to reports a problem, but also many
other affected service instances.
20. (In Scope) The SPR OSS relates this new service problem (from the SQM OSS) with the 2
service problems reported by the customers. It is determined that new service problem
supercedes the two existing service problems (which are deleted at this point). The SPR OSS
also associates the resource alarm to this new service problem.
21. Repair personnel are sent on site by the SPR OSS. They fix the problem and the resource TT is
updated accordingly.
22. The resource (i.e., access switch or the associated EMS) sends a clear to the RTM.
23. The RTM OSS notifies SQM OSS which determines that things are back to normal.
24. (In Scope) The SQM OSS sends a clear service problem to the SPR.
25. (In Scope) SPR OSS clears the service problems. The associated alarms are not automatically
acknowledged.

TMF522, Version 1.5

TM Forum 2011

Page 25 of 88

Service Problem Management Business Agreement


26. (In Scope) SPR notifies STT which closes the service TT and notifies the CTT.
27. The customer representative notifies the customers and gets feedback that the problem is fixed.
28. The customer representative notifies the CTT OSS which closes the customer TTs.

Service
Quality
Management
(SQM) OSS

TT management (out
of scope)

Service
Problem
Resolution
(SPR) OSS

Customer
Trouble
Ticketing
(CTT) OSS

Service
Trouble
Ticketing
(STT) OSS

Service alarms (in


scope)

Resource
Trouble
Management
(RTM) OSS

EMS #1

EMS #2

Resource
Trouble
Ticketing
(RTT) OSS

EMS #3

Management Interface
(out of scope)
Management Interface
(in scope)

NE #1

Failing switch

Figure 2-6 Customer report a service problem Example

TMF522, Version 1.5

TM Forum 2011

Page 26 of 88

Service Problem Management Business Agreement

2.2.3 Predictive
2.2.3.1 Adjustments to network/service environment based on anticipated problems
Name: Adjustments to network/service environment based on anticipated problems
Summary: Based on an anticipated event (e.g., a severe storm or an anticipated event of great interest),
the service provide determines that existing services could be impacted and takes action to addresses
the potential problem. Note that this is beyond proactive as there is really no specific problem to be
detected at this point.
1. A World Cup football (soccer) match is expected for next Saturday. The servers providing PPV
replays of the match are expected to see their traffic be increased ten-fold on Saturday evening
(during and after the match).
2. The Service Planning OSS notifies the Service Capacity Management OSS of the needed
bandwidth for the specified time.
3. The Service Capacity Management OSS computes the new links that needs to be assigned to
this service.
4. The Service Capacity Management OSS notifies the Transport Capacity Management (TCM)
OSS of the needed changes.
5. The TCM OSS makes the changes on Saturday morning.
6. The event goes on without any over capacity being detected. No resource alarm or performance
threshold is generated.
7. On Sunday evening, the Service Capacity Management OSS notifies the Transport Capacity
Management of the changes needed to return back to normal (or this might already have been
part of the original request, depending on the capacities of the TCM OSS)
This scenario appears to have no impact on the interface under consideration, i.e., service problem
management.

2.2.3.2 Network degradation trend detected


Name: Network degradation trend detected
Summary: The service provider via the assurance monitoring OSSs determines a trend is developing in
their network. Perhaps no thresholds have been crossed yet, but many links become busy at the same
time. Based on past experience, this may be the result of a computer virus that attempts to flood the
network with useless messages.
The traffic on a network link is growing. The Performance Mgt OSS detects that the trend is going up.
This might soon impact the service contract with the customer and could lead to a service violation.
1. The IP Performance Management (IPM) OSS monitors IP performance at the ingress and egress
points of the SDH network. For example, if DiffServ is used, the IPM OSS would monitor various
DiffServ classes for performance (e.g., dropped packets per given time period).
2. The IPM OSS detects that the traffic trend is growing even if no threshold has been crossed.
3. The IPM sends a warning (resource) alarm to the SQM OSS and the RTM OSS.
4. The SQM OSS receives the performance alarm and (In Scope) in turn issues a warning service
problem as the trend might impact services.
5. (In Scope) The SPR OSS, based on past experience, determines that this may be the result of a
computer virus that attempts to flood the network with useless messages.
TMF522, Version 1.5

TM Forum 2011

Page 27 of 88

Service Problem Management Business Agreement


6. The SPR OSS sends a request to the Network Configuration Management OSS to block this
traffic.
7. (In Scope) The SPR associates the network alarm in the RTM to this service problem so that the
network operator knows that the problem is being handled.
8. The NCM OSS sends the requests to the various access routers.
9. The IPM OSS detects that the traffic trend is no longer growing and sends a clear resource alarm
to the SQM OSS and RTM OSS.
10. (In Scope) The SQM OSS in turn issues a clear service problem to the SPR OSS.

Service Problem Resolution


(SPR) OSS

Management Interface
(out of scope)
Management Interface
(In scope)

Service Quality
Management (SQM) OSS
Resource Trouble
Management (RTM) OSS

Network Configuration
Management (NCM) OSS

IP Performance
Management (IPM) OSS

IP Network
SDH Network

Figure 2-7. Network degradation trend detected Example

TMF522, Version 1.5

TM Forum 2011

Page 28 of 88

Service Problem Management Business Agreement

2.2.3.3 Customer(s) report of a service problem transient problem


Name: Customer(s) report of a service problem transient problem
Summary: The service provider has received several trouble reports from customers but cannot isolate
the problem (perhaps it is a transient problem). However, the problem seems to becoming from a
particular area. Based on this information, the service provider is able to determine certain aspects of the
outside plant need to be inspected, and repair (testing) personnel need to be dispatched. Subsequently, it
is determined that Electro-Magnetic Interference (EMI) is causing the transient problem. The problem is
fixed by moving apart some equipment that should not have been collocated in the first place. (One might
argue that this is Proactive if not Reactive.)
1. A customer calls their service provider to report a transient problem with a service (e.g., IPTV).
For the sake of argument, assume that the customer has a very poor picture from time to time on
most channels.
2. The service provider representative enters the report into the CTT OSS.
3. As this is a new problem, the CTT OSS creates a TT. Since no network problems have been
identified in relation to the customers problem, the CTT OSS will create a work order to have
someone visit the customers location.
4. The service provider representative relays the information back to the customer.
5. The CTT OSS notifies the SQM OSS once the repair person confirms that the customer does, in
fact, have a service problem. At this point, the problem has not been isolated.
6. (In Scope) The SQM OSS creates a service problem in the SPR OSS.
7. The SPR creates a service TT in the STT that gets associated with the customer TT.
8. The SPR operator investigates RTT alarms but does not detect any problems that might explain
the service violation.
9. A second customer calls their service provider to report a problem with his service.
10. The service provider representative enters the report into the CTT OSS.
11. As this is a new problem, the CTT OSS creates a TT. Since no network problems have been
identified in relation to the customers problem, the CTT OSS will create a work order to have
someone visit the customers location.
12. The service provider representative relays the information back to the customer.
13. The CTT OSS notifies the SQM OSS once the repair person confirms that the customer does, in
fact, have a service problem. At this point, the problem has not been isolated.
14. (In Scope) As this is a different service, the SQM OSS creates a service problem in the SPR
OSS.
15. (In Scope) The SPR OSS creates a service TT in the STT which gets associated with the
customer TT.
16. (In Scope) The SPR OSS investigates the problem and finds that it is coming from the same
location. It notifies the STT. (Note: this type of investigation might also be done by the STT).
17. The STT OSS is able to determine certain aspects of the outside plant need to be inspected.
18. Repair (testing) personnel are dispatched. Subsequently, it is determined that Electro-Magnetic
Interference (EMI) is causing the transient problem. The problem is fixed by moving apart some
equipment that should not have been collocated in the first place. The service TT is updated.
19. The customer representative notifies the customer and get the feedback that the problem is fixed.

TMF522, Version 1.5

TM Forum 2011

Page 29 of 88

Service Problem Management Business Agreement


20. The customer representative notifies the CTT which closes the customer tickets.
21. Ticket closure is sent to the SQM OSS which (In Scope) in turn sends a clear service problem to
the SPR.

Customer
Trouble
Ticketing
(CTT) OSS

Service
Quality
Management
(SQM) OSS

TT management (out of scope)


Service
Problem
Management
(SPM) OSS

Service alarms (in scope)

Management Interface
(in scope)

Service
Trouble
Ticketing
(STT) OSS

Management Interface
(out of scope)

Figure 2-8. Customer reports of a transient service problem Example

2.2.3.4 Customer(s) report of a service problem network degradation trend


Name: Customer(s) report of a service problem network degradation trend
Summary: This is a variant of the previous use case. Customers are reporting a service problem. The
SPR OSS analyses the various reports and realizes that all these customers are sharing the same link. A
report is sent to RTM OSS which confirms that this link is operating correctly. A report is sent to the RPM
OSS that detects that the traffic on this link is growing and the link is close to being overbooked. The
customer problems are associated with this performance problem.
The OSSs in this scenario are shown in Figure 2-9.
1. A customer calls their service provider to report a problem with a service (e.g., IPTV). For the
sake of argument, assume that the customer has a very poor picture on most channels.
2. The service provider representative enters the report into the CTT OSS.
3. As this is a new problem, the CTT OSS creates a TT. Since no network problems have been
identified in relation to the customers problem, the CTT OSS will create a work order to have
someone visit the customers location.
4. The service provider representative relays the information back to the customer.
5. The CTT OSS notifies the SQM OSS.

TMF522, Version 1.5

TM Forum 2011

Page 30 of 88

Service Problem Management Business Agreement


6. (In Scope) The SQM OSS creates a service problem in the SPR OSS once the repair person
confirms that the customer does, in fact, have a service problem. At this point, the problem has
not been isolated.
7. The SPR creates a service TT in the STT which gets associated with the customer TT.
8. The SPR operator investigates RTT alarms but does not detect any problems that might explain
the service violation.
9. A second customer calls their service provider to report a problem with his service.
10. The service provider representative enters the report into the CTT OSS.
11. As this is a new problem, the CTT OSS creates a TT. Since no network problems have been
identified in relation to the customers problem, the CTT OSS will create a work order to have
someone visit the customers location.
12. The service provider representative relays the information back to the customer.
13. The CTT OSS notifies the SQM OSS.
14. (In Scope) As this is a different service, the SQM OSS creates a service problem in the SPR
OSS once the repair person confirms that the customer does, in fact, have a service problem.
15. The SPR OSS creates a service TT in the STT which gets associated with the customer TT.
16. The SPR OSS investigates the problem and finds that both customers are sharing the same link.
17. The SPR OSS sends a request (as a maintenance or diagnosis command) to the RPM OSS to
check the traffic on this link. Note: this scenario assumes that this link was not already monitored
in real time.
18. The RPM OSS detects that the link is close to being overbooked. It sends a performance warning
alarm (resource level) to the SQM OSS and the RTM OSS.
19. (In Scope) The SQM OSS is notified and sends 1 problem affecting 2 services to the SPR.
20. The RTM OSS notifies the RTT OSS which creates a resource TT.
21. (In Scope) The SPR OSS relates this service problem with the 2 service problems coming from
the customer TTs. The SPR OSS also associates the resource alarm to this new service problem.
22. Repair personnel are sent on site, fix the problem and update the resource TT.
23. The IPM OSS sends a clear performance alarm to the SQM OSS and the RTM OSS.
24. SQM OSS analyzes that things are back to normal.
25. (In Scope) SQM OSS sends a clear service problem to the SPR.
26. (In Scope) SPR OSS clears the service problems. Associated alarms are not automatically
acknowledged.
27. (In Scope) SPR notifies STT that closes the service ticket and notifies the CTT.
28. The customer representatives notify the customer and get the feedback that the problem is fixed.
29. The customer representatives notify the CTT that closes the customer tickets.

TMF522, Version 1.5

TM Forum 2011

Page 31 of 88

Service Problem Management Business Agreement

Service
Quality
Management
(SQM) OSS

TT management (out
of scope)

Service
Problem
Management
(SPM) OSS

Customer
Trouble
Ticketing
(CTT) OSS

Service
Trouble
Ticketing
(STT) OSS

Service alarms (in


scope)

Resource
Performance
Management
(RPM) OSS

Resource
Trouble
Management
(RTM) OSS

Resource
Trouble
Ticketing
(RTT) OSS

EMS #1

Management Interface
(out of scope)
Management Interface
(in scope)

Switch #1
NE #1

NE #1
Almost Overbooked
Link

Figure 2-9. Customer trouble report leading to detection of network degradation trend

2.3

Benefits

The following table summarizes the key elements of this specification and the associated benefits:

TMF522, Version 1.5

TM Forum 2011

Page 32 of 88

Service Problem Management Business Agreement

Key element

Benefit

Comprehensive set of service


assurance business scenarios

Common set of scenarios that can be


used to drive this and other work in the
area of service assurance. The
scenarios help scope the work in this
specification and help reduce overlaps
with other current or future work.

Service problem management


requirements and use cases

Can be used to service providers in


their RFP and RFIs
Used (internal to this project) to drive
the Information Agreement (IA) and
Interface Implementation Specification
(IIS) work.

SID extensions for service problem


management

Linkage to the comprehensive SID


model, allowing service providers to
build on their existing SID information
models in the area of service problem
management

Service problem management


interface

Can be used by OSS suppliers to


provide interoperable service problem
management products

TMF522, Version 1.5

TM Forum 2011

Page 33 of 88

Service Problem Management Business Agreement

3 Business Processes
3.1

Business Requirements

None identified

3.2

Category I: Static and


Structural Requirements

3.2.1

Service Problem

A Service Problem is an indication that a service or set of services is no longer functioning according to
the agreement with its client(s).
It is not similar to a resource alarm

It can consolidate information on multiple objects

It is not similar to a TT

It does not handle actions and resource assignment

R_TMF522_I_0001

Service Problem Identification


It shall be possible to uniquely identify a Service Problem over
the Interface.

Source

TMF522, Version 1.0

R_TMF522_I_0002

Types of Service Problems


There are 2 types of Service Problems:

Simple Service Problem, where only 1 service is


affected

Multi Service Problem, where more than 1 service is


affected

There should be the choice for a given implementation to


generate either simple or multi Service Problems or both,
depending on the number of services affected.
A simple Service Problem can become a multi one if additional
services become affected.
Source

TMF522, Version 1.0

R_TMF522_I_0003

Historical Service Problems

TMF522, Version 1.5

TM Forum 2011

Page 34 of 88

Service Problem Management Business Agreement

Service Problems can be active or historical. An historical


problem is one that is cleared and acknowledged. The
ActivityStatus (Active, historical) will track this status.
The Target OS can decide to remove historical problems based
on some internal criteria, like age.
Source

TMF522, Version 1.0

R_TMF522_I_0004

Service Problem Attributes


A Service Problem contains the following attributes:

Problem Identifier. Not modifiable and unique within the


namespace of a problem producing application (server).

Impact Importance is characterized by an Impact


Importance Factor: overall importance of the impact of all
the affected services, e.g. 0 (zero impact) to 100 (worst
impact). The Impact Importance is a calculated field which
is set by the OSS determining the impact. Settable.

Priority (1 to 10): an indication of how important it is for the


service provider to correct the Service Problem. The priority
can be changed by the human operator while the impact
importance can only be changed by the system which
determines the impact. Settable.

Description: free form text describing the Service Problem.


Settable.

First Alert is text that indicates what first alerted the


system to the problem. It is not the root cause of the
Service Problem. Settable. Examples:

Threshold crossing alert: Service component


causing the problem

Customer report: customer name (or TT id)


reporting the problem

Category: classifier for the problem. Settable. Structured


text/ enum
o

TMF522, Version 1.5

In the ATIS Service Outage document [ATISOUTAGE] , the What Category corresponds
to this attribute and the values can be used as
possible values.

Responsible Party person or organization responsible for


handling this problem. This is text or structured text and not
and association to a party object. The Who category from
the ATIS Service Outage document [ATIS-OUTAGE] can
be used for this attribute.

TM Forum 2011

Page 35 of 88

Service Problem Management Business Agreement

(optional) Service Problem Escalation Indicates if this


service problem has been escalated or not. Possible values
are 0 to 10. A value of zero means no escalation. The
meanings of values 1-10 are to be determined by the user
of the interface, but they show increasing levels of
escalation.

Comments.

An originatingSystem to indicate where the problem was


generated. Settable.

Time (Raised, Changed). Non settable

Root Cause information as defined in


requirement R_TMF522_I_0006

Impact scope as defined in requirement R_TMF522_I_0007

Clear status as defined in requirement R_TMF522_I_0008

Ack status as define in requirement R_TMF522_I_0009

Activity status as defined in requirement


Error! Reference source not found.

Tracking records for clearance and acknowledgement as


defined in requirement
R_TMF522_I_0010

Associated TTs as defined in


requirement R_TMF522_I_0011

Source

TMF522, Version 1.0

R_TMF522_I_0005

Vendor Extension
The interface should allow for vendor specific information to be
carried across, as an extension of the Service Problem.
VendorExtensions can be seen as an empty class that can be
extended by vendors.

Source

TMF522, Version 1.0

R_TMF522_I_0006

Root Cause
A Service Problem can have 1 or more root causes.

TMF522, Version 1.5

TM Forum 2011

Page 36 of 88

Service Problem Management Business Agreement

A problem includes:

a reason (required) as free text or optionally structured


text. It can be Unknown. The Why category of the
ATIS Service Outage document [ATIS-OUTAGE] can
be used to fill this value.

(optional) Underlying Alarms references to the


underlying alarms. Note: a resource RC alarm would be
an underlying alarm (also sometimes refer as a
symptom) for a service problem

(optional) Underlying Problems - references to the


underlying service problems. Only if this problem is
derived from other problems.

(optional) one or more RootCauseEntities which are the


Resource Entities of the RC alarm(s) if any (used only if
applicable).

(optional) Parent Problem. Identifies the problem of


which this problem is an underlying one.

All these fields should be settable with the possibility of the


target OSS raising an exception if they are only settable by the
target OSS.
Source

TMF522, Version 1.0

Table 3-1 shows some possible values for the reason parameter of the Service Problem. The list is not
prescriptive and implementers of this interface may chose to use other values if they wish.

Table 3-1. List of Reasons (probable causes)


Reasons

Source/Definition

Application subsystem failure

OSS/J QoS API (JSR-90)

Bandwidth reduction

OSS/J QoS API (JSR-90)

Communication subsystem failure

OSS/J QoS API (JSR-90)

Congestion

OSS/J QoS API (JSR-90)

Indeterminate

OSS/J QoS API (JSR-90)

Lost redundancy

OSS/J QoS API (JSR-90)

Performance degraded

OSS/J QoS API (JSR-90)

Resource at or nearing capacity

OSS/J QoS API (JSR-90)

Response time excessive

OSS/J QoS API (JSR-90)

System resources overload

OSS/J QoS API (JSR-90)

Threshold crossed

OSS/J QoS API (JSR-90)

Timeout expired

OSS/J QoS API (JSR-90)

Underlying resource unavailable

OSS/J QoS API (JSR-90)

Connection establishment error

ITU-T Rec. M.3100 and also 3GPP document TS 32.111-2 V4.5.0

TMF522, Version 1.5

TM Forum 2011

Page 37 of 88

Service Problem Management Business Agreement


(2002-12)
Delayed information

OSS/J Common API (JSR-144)

Denial of service

OSS/J Common API (JSR-144)

Maximum time interval error

TMF522
Maximum Time Interval Errors (MTIE) and Frequency errors may
also cause input signal faults when exceeding the set thresholds,
as set in nanoseconds.

Non redundant failure

TMF522
A non-redundant output module failed. This is caused by a bad
card being inserted into the system.

Out of hours activity

OSS/J Common API (JSR-144)

Out of service

OSS/J Common API (JSR-144)

Activation or provisioning failure

TMF522
Failure to activate or provision the service

Manual Operation

TMF522
Manual operator intervention was performed

Protecting resource failure

TMF522
Failure of a protecting resource, prime still functioning

Protection switch occurred

TMF522
Switch to protection resource due to a failure in prime

Customer experience degraded

TMF522
Customer experience a degradation in service or is likely to
experience such a degradation

Customer out of reach

TMF522
Customer could not be reached. Although the service is up and
running the network since that the customer is disconnected from
the service

Service degraded

TMF522
Degradation in service - general probable cause, use when the
specific error (such as performance degradation) is not known

R_TMF522_I_0007

Impact Scope
Impact Scope can be

List of affected services (optional)

Number of affected services (mandatory, but


value can be zero)

List of affected locations, as location objects


and not free text (optional)

List of affected entities (optional)

Patterns of impact (optional)

TMF522, Version 1.5

TM Forum 2011

e.g. other service characteristics

Page 38 of 88

Service Problem Management Business Agreement

Used when defining impact through


another pattern than the pre-defined
attributes above.

The field Patterns of impact needs to


be extensible.

Either the list of affected services or the list of affected locations


should at least be present. Both cannot be absent.
Impact can change over the life of the problem, so all impact
fields are settable.
The list and number of affected services can be null/empty.
There are the following use cases:

Creating a problem with only a location as


impact. Both list and number of affected
services are null/empty

The list of services is very long. In this case, the


list of affected services can be empty, but the
number would give the count of affected
services

Source

TMF522, Version 1.0

R_TMF522_I_0008

Clear Status
The Service Problem includes a Clear status (raised, cleared).
Clearance of the resource RC alarm does not imply clearance
of the problem.

Source

TMF522, Version 1.0

The clearance might come from the system which generated the problem or from a customer-facing
system (after validation by a customer).

R_TMF522_I_0009

Ack Status
The Service Problem includes an Ack status (unack, ack).
Acknowledgement of the problem does not imply
acknowledgement of the underlying problems or alarms.

Source

TMF522, Version 1.0

R_TMF522_I_0010

Tracking records
Timestamps of clearance and acknowledgements should be
kept as tracking records. The fields are:

TMF522, Version 1.5

timestamp, of the action

description, of the action, like ack, or clear,

user id, done the action,

TM Forum 2011

Page 39 of 88

Service Problem Management Business Agreement

system id, on which this action is done.

The tracking records should not be embedded in the problem to


allow retrieving the problem without the tracking records.
Source

TMF522, Version 1.0

R_TMF522_I_0011

Associated Trouble Tickets


Customer TT can be traced to a specific Service Problem.
Ids of associated TT information can also be kept in the
problem. This is settable and optional.

Source

TMF522, Version 1.0

R_TMF522_I_0012

Simple Service Problem


The simple Service Problem has:

Source

Only 1 affected service

No need for number of affected services

No need for patterns of impact, affected locations

a need for reason and RC information

a need for priority and importance

TMF522, Version 1.0

A simple Service Problem has almost the same information payload as a resource alarm. However, its
semantic is different from it and should not be mixed with it.
A service threshold crossing warning/ violation can be seen as an extension of the Service Problem.

3.3
3.3.1

Category II: Normal Sequences,


Dynamic Requirements
Service Problem Notification
R_TMF522_II_0013

Notification on Object Creation


The Interface shall support the sending of an Object Creation
notification when a Service Problem has been created.

Source

TMF522, Version 1.5

TMF522, Version 1.0

TM Forum 2011

Page 40 of 88

Service Problem Management Business Agreement

R_TMF522_II_0014

Notification on Object Update


The Interface shall support the sending of Attribute Value
Change Notification and/or State Change notification when a
Service Problem has been updated. The following modifications
shall be reportable:

addition of comments

acknowledgement or un-acknowledgement

Update of attributes.

Source

TMF522, Version 1.0

R_TMF522_II_0015

Notification on Clearance
The Interface shall support the sending of State Change
Notification when a Service Problem has been cleared.
Once a Service Problem is cleared, it no longer exists as an
active Service Problem. However, it may be converted to an
historical Service Problem.

Source

TMF522, Version 1.0

R_TMF522_II_0016

Notification on Deletion
The generation of an Object Deletion notification when an
historical Service Problem gets removed from the system is
optional.

Source

3.3.2

TMF522, Version 1.0

Service Problem Control


R_TMF522_II_0017

Create a Service Problem


The Interface shall allow one OSS to create one or more
Service Problem(s) on another OSS.

Source

TMF522, Version 1.0

R_TMF522_II_0018

Update a Service Problem


The interface shall allow one OSS to update a Service Problem
generated by another OSS. This is possible for all settable
attributes (as defined in R_TMF522_I_0004).

Source

TMF522, Version 1.0

R_TMF522_II_0019

Comment a Service Problem

TMF522, Version 1.5

TM Forum 2011

Page 41 of 88

Service Problem Management Business Agreement

The interface shall allow one OSS to add a comment to a


Service Problem generated by another OSS
Source

TMF522, Version 1.0

R_TMF522_II_0020

Change Correlation in Service Problem


The interface shall allow one OSS to request a change in the
underlying alarms and/or problems on a Service Problem from
another OSS. This covers adding a new correlation or removing
one.

Source

TMF522, Version 1.0

R_TMF522_II_0021

Clear a Service Problem


The Interface shall allow one OSS to clear a Service Problem
generated by another OSS.

Source

TMF522, Version 1.0

R_TMF522_II_0022

Unclear a Service Problem


The Interface shall allow one OSS to unclear a Service Problem
generated by another OSS.

Source

TMF522, Version 1.0

It should be noted that an OSS may not immediately delete a cleared Service Problem. In such cases
(i.e., when a cleared Service Problem has not yet been deleted), it may be possible to unclear the Service
Problem.

R_TMF522_II_0023

Acknowledge a Service Problem


The Interface shall allow one OSS to acknowledge a Service
Problem generated by another OSS.
Acknowledging a problem does not imply propagation of the
acknowledgement to underlying alarms or problems. This
behavior is implementation specific.

Source

TMF522, Version 1.0

R_TMF522_II_0024

Unacknowledge a Service Problem


The Interface shall allow one OSS to un-acknowledge a Service
Problem generated by another OSS.

Source

TMF522, Version 1.0

R_TMF522_II_0025

Delete a Service Problem

TMF522, Version 1.5

TM Forum 2011

Page 42 of 88

Service Problem Management Business Agreement

The Interface shall allow one OSS to delete historical Service


Problem(s) generated by another OS. Only historical Service
Problems can be deleted.
Source

TMF522, Version 1.0

R_TMF522_II_0026

Service Problem State Transition Diagram


An instance of the Service Problem entity must follow the state
transition diagram shown in the Figure 3-1.
Note: Any of the state transitions in the diagram can also
happen as the result of an internal decision of the OSS that
owns the Service Problem and in such cases, would not involve
an interface operation but could involve a subsequent transition
notification.

Source

TMF522, Version 1.0

create

create

acknowledge

: ServiceProblem
[Raised and unAcked]

: ServiceProblem
[Raised and Acked]
unAcknowledge

unClear

clear

unClear

clear

acknowledge

: ServiceProblem
[Cleared and unAcked]

: ServiceProblem
[Cleared and Acked]
unAcknowledge

delete

delete

Any of the state transitions in the diagram can also happen


as the result of an internal decision of the OSS that owns the
Service Problem and in such cases, would not involve an
interface operation but could involve a subsequent transition notification.

Figure 3-1. Service Problem Instance state transition diagram

TMF522, Version 1.5

TM Forum 2011

Page 43 of 88

Service Problem Management Business Agreement

3.3.3

Service Problem Subscription


R_TMF522_II_0027

Subscribe to Service Problems


The Interface shall allow an OSS to subscribe to the Service
Problems generated by other OSSs.

Source

TMF522, Version 1.0

R_TMF522_II_0028

Filter Service Problem Subscription


The Interface shall allow an OSS to apply a filter to its
subscription for Service Problems from another OSS. In
particular, Service Problems can be filtered based on any
Service Problem attribute.
If a particular characteristic is not populated, then Service
Problems for all possible values of that characteristic are
included.

Source

TMF522, Version 1.0

Only a single filter is allowed. To augment a filter, it will have to be deleted, edited and reapplied.

R_TMF522_II_0029

Unsubscribe to Service Problems


The Interface shall allow an OSS to unsubscribe from the
Service Problems generated by another OSS.

Source

3.3.4

TMF522, Version 1.0

Service Problem Retrieval


R_TMF522_II_0030

Retrieve Service Problems


The Interface shall support requests to retrieve active Service
Problems of a given OSS.
The request shall be able to filter on any Service Problem
attribute.
Filters shall support following retrieval criteria and their rational
combinations:

Source

TMF522, Version 1.5

Equality by using a pattern similar to the OSS/J


ByTemplates pattern

Inequality shall also be possible, i.e., value > x

String matching for string attributes

TMF522, Version 1.0

TM Forum 2011

Page 44 of 88

Service Problem Management Business Agreement

R_TMF522_II_0031

Retrieve Historical Service Problems


The Interface shall support requests to retrieve historical (i.e.,
cleared and ack) Service Problems of a given OSS. The
request shall be able to filter on any problem attribute.
Filters shall support following retrieval criteria and their rational
combinations:

Using a pattern similar to the OSS/J ByTemplates


pattern

Inequality shall also be possible.

String matching for string attributes

Source

TMF522, Version 1.0

R_TMF522_II_0032

Count Service Problems


The interface shall support requests to retrieve the count of
active problems of a given OSS. The request shall be able to
filter on any problem attribute.
Filters shall support following retrieval criteria and their rational
combinations:

Source

3.4

Using a pattern similar to the OSS/J ByTemplates


pattern

Inequality shall also be possible, i.e. value > x

String matching for string attributes

TMF522, Version 1.0

Category III: Abnormal or


Exception Conditions, Dynamic
Requirements

The following table identifies a list of exceptions that may be raised by a target OSS in response to a
requesting OSS. In the Description and Exceptions section of each Use Case the specific exceptions
that may be raised are identified. The target OSS can qualify each exception by indicating further details
about the exception in a free format string attached to the exception. This is specifically necessary if more
than one step in the description leads to the same exception.
The table 3.4.1 lists some exceptions defined in the mTOP framework doc (TMF518_FMW.doc, section 4).
The table 3.4.2 defines some exceptions which beyond the mTOP exceptions and may be used in this
doc.

Table 3.4.1. Use Case Exceptions (Raised by a target OSS)


TMF522, Version 1.5

TM Forum 2011

Page 45 of 88

Service Problem Management Business Agreement

ID

Name

General Description

Internal Error

The request has resulted in an OSS internal error.

Not Implemented

The entire request is not supported by the target OSS or the request with the
specified input parameters is not supported.

Invalid Input

The request contains an input parameter that is syntactically incorrect or identifies


an object of the wrong type or is out of range.

Entity Not Found

The specified object instance does not exist.

Unable To Comply

The target OSS cannot respond to the request.

Access Denied

The requesting OSS is not permitted to perform the request.

Not In Valid State

The state of the specified object is such that the target OSS cannot perform the
request.

Comm Loss

The target OSS (which is a top-level OSS) is unable to communicate with the
subordinate OSS and communication is required to complete the request.

Unable To Register

The target OSS is unable to register with Directory

10

Unable To Notify

The target OSS is unable to connect to the Notification Service

Table 3.4.2. Use Case Exceptions (Raised by a Notification Service)

ID

Name

General Description

Notification Service Exception

Base exception thrown by the notification service whenever it encounters a problem.

Invalid Selector

The publisher OSS or Subscriber OSS attempt to give a notification service provider
a message selector with invalid syntax.

Resource Allocation Fails

A notification service provider is unable to allocate the resources (such as for


connection) required by a publishing OSS or subscribe OSS.

Unable To Deliver

A notification service provider is unable to deliver the notifications to subscribe


OSSs.

TMF522, Version 1.5

TM Forum 2011

Page 46 of 88

Service Problem Management Business Agreement

3.5

Category IV: Expectations and


Non-Functional Requirements

3.6

Category V: System
Administration Requirements

TMF522, Version 1.5

TM Forum 2011

Page 47 of 88

Service Problem Management Business Agreement

4 Use Cases
For the following use cases, the Actor is an OSS. Also, the system(s) being acted upon is one or more
OSSs. According to the different contexts, the OSSs in the use cases play different roles. The following
roles are used in the use cases:
1. Requesting OSS
2. Target OSS (typically the client that handles a request)
3. Publishing OSS
4. Subscriber OSS

Please refer to mTOP framework BA doc (TMF518_FMW.doc) for detail description of these roles. Some
of the use cases (in this document) involve more specific roles (e.g., Service Problem-Owning OSS)
which are explained in the use cases that follow.

4.1

Service Problem Notification

Use Case Id

UC_TMF522_0001

Use Case Name

Send an object creation notification when a service problem has been


created

Summary

The report-owning OSS sends an object creation notification to the


subscriber OSSs

Actor(s)

report-owning OSS

Pre-Conditions

1. The OSSs involved in the use case have started (refer to the use
cases UC_TMF518_FMW_0001 and UC_TMF518_FMW_0002 in
TMF518_FMW.doc).
2. The subscriber OSSs have subscribed to receive object creation
notifications produced by the report-owning OSS (refer to the use
case UC_TMF522_0017).

Begins When

The report-owning OSS has created a Service Problem

Description

1. The report-owning OSS generates an object creation notification


from the new Service Problem and publishes the notification to the
notification service.
2. The subscriber OSSs receive the notification from the notification
service.

Ends When

In case of success:
The subscriber OSSs have received the notification in a predefined time.

TMF522, Version 1.5

TM Forum 2011

Page 48 of 88

Service Problem Management Business Agreement


In case of failure:
Some of the subscriber OSSs has not received the notification
in a pre-defined time.
Note that the definition of this pre-defined time is outside the scope
of this specification, i.e., it is an implementation issue.
Post-Conditions

In case of success:
The Service Problem information between report-owning OSS
and the subscriber OSSs is consistent.
In case of failure:
The subscriber OSS which has not received the notification is
not aware of the new Service Problem. Service problem
information between the report-owning OSS and the
subscriber OSS is not consistent.

Exceptions

1. In case the Notification Service is unavailable, the Unable To


Notify exception shall be raised and the target OSS stops trying to
publish the notification.
2. In case the notification delivery fails, the Unable To Deliver
exception shall be raised and the notification service stops
delivering the notification temporarily or permanently.

Traceability

R_TMF522_II_0013

With regard to UC_TMF522_0001, it is important to note that there are two different but related things,
i.e., the Service Problem and the associated notification. They are not necessarily equal. Typically, the
information in the notification is a superset of the information in the associated Service Problem. Also,
when active service problems are retrieved, it is in fact the Service Problem entities that are being
retrieved and not the associated notifications.

Use Case Id

UC_TMF522_0002

Use Case Name

Send an Attribute Value Change (AVC) notification or State Change


(SC) notification when a service problem has been updated

Summary

The report-owning OSS sends an AVC notification or SC to the


subscriber OSSs

Actor(s)

The report-owning OSS

Pre-Conditions

1. The OSSs involved in the use case have started (refer to use
cases UC_TMF518_FMW_0001 and UC_TMF518_FMW_0002
in TMF518_FMW).
2. The subscriber OSSs have subscribed to get AVC and SC
notifications produced by the report-owning OSS (refer to use
case UC_TMF522_0017).

Begins When

The report-owning OS has updated a service problem

Description

1. The report-owning OS generates notification(s) and publishes it to

TMF522, Version 1.5

TM Forum 2011

Page 49 of 88

Service Problem Management Business Agreement


the notification service.

Attribute Value Change notification for addition of comments

State Change notification for acknowledgement or


unacknowledgement of a service problem

Attribute Value Change notification for update to other Service


Problem attributes

2. The subscriber OSSs receive the notification from the notification


service.
Ends When

In case of success:
The subscriber OSSs have received the notification(s) in a predefined time.
In case of failure:
Some of the subscriber OSSs has not received the notification
in a pre-defined time.

Post-Conditions

In case of success:
Service Problem information between report-owning OSS and
the subscriber OSSs is consistent.
In case of failure:
The subscriber OSS which has not received the notification is
not aware of the Service Problem update. Service problem
information between the report-owning OSS and the subscriber
OSS is not consistent.

Exceptions

1. In case the Notification Service unavailable, the Unable To Notify


exception shall be raised and the target OSS stops trying to
publish the notification.
2. In case the notification delivery fails, the Unable To Deliver
exception shall be raised and the notification service stops trying to
deliver the notification temporarily or permanently.

Traceability

R_TMF522_II_0014

Use Case Id

UC_TMF522_0003

Use Case Name

Send a State Change notification when a service problem has been


cleared

Summary

The report-owning OSS notifies the subscriber OSSs that a related


(active) Service Problem in the report-owning OSS has been cleared.

Actor(s)

The report-owning OSS

TMF522, Version 1.5

TM Forum 2011

Page 50 of 88

Service Problem Management Business Agreement

Pre-Conditions

1. The OSSs involved in the use case have started (refer to use cases
UC_TMF518_FMW_0001 and UC_TMF518_FMW_0002 in
TMF518_FMW).
2. The subscriber OSSs have subscribed to get notifications produced
by the report-owning OSS (refer to use case UC_TMF522_0017)

Begins When

The report-owning OSS detects a Service Problem clear.

Description

1. The report-owning OSS generates a State Change notification and


delivers it to the notification service.
2. The subscriber OSSs receive the notification from the notification
service.

Ends When

In case of success:
The subscriber OSSs have received the notification in a predefined time.
In case of failure:
Some of the subscriber OSSs has not received the notification in
a pre-defined time.

Post-Conditions

In case of success:
The Service Problem information between report-owning OSS
and the subscriber OSSs is consistent.
In case of failure:
The subscriber OSS which has not received the notification is
not aware of the Service Problem clearance. Service problem
information between the report-owning OSS and the subscriber
OSS is not consistent.

Exceptions

1. In case the Notification Service unavailable, the Unable To Notify


exception shall be raised and the target OSS stops trying to publish
the notification.
2. In case the notification delivery fails, the Unable To Deliver
exception shall be raised and the notification service stops trying to
deliver the notification temporarily or permanently.

Traceability

R_TMF522_II_0015

Use Case Id

UC_TMF522_0004

Use Case Name

Send an Object Deletion notification when an historical Service


Problem has been removed (optional)

Summary

The report-owning OSS notifies the subscriber OSSs that an historical


Service Problem has been removed.

Actor(s)

The report-owning OSS

Pre-Conditions

1. The OSSs involved in the use case have started (refer to use

TMF522, Version 1.5

TM Forum 2011

Page 51 of 88

Service Problem Management Business Agreement


cases UC_TMF518_FMW_0001 and UC_TMF518_FMW_0002 in
TMF518_FMW).
2. The subscriber OSSs have subscribed to get the Object Deletion
notifications produced by the report-owning OSS (refer to use
case UC_TMF522_0017).
Begins When

The report-owning OSS detects a historical Service Problem removal.

Description

1. The report-owning OSS generates an Object Deletion notification


and delivers it to the notification service.
2. The subscriber OSSs receive the notification from the notification
service.
In case of success:

Ends When

The subscriber OSSs have received the notification in a predefined time.


In case of failure:
Some of the subscriber OSSs has not received the notification
in a pre-defined time.
Post-Conditions

In case of success:
The Service Problem information between report-owning OSS
and the subscriber OSSs is consistent.
In case of failure:
The subscriber OSS which has not received the notification is
not aware of the Service Problem removal, and Service
Problem information between the report-owning OSS and the
subscriber OSS is not consistent.

Exceptions

1. In case the Notification Service unavailable, the Unable To Notify


exception shall be raised and the target OSS stops trying to
publish the notification.
2. In case the notification delivery fails, the Unable To Deliver
exception shall be raised and the notification service stops trying to
deliver the notification temporarily or permanently.

Traceability

4.2

R_TMF522_I_0003, R_TMF522_II_0016

Service Problem Control


Use Case
Id

UC_TMF522_0005

Use Case
Name

Create a service problem

TMF522, Version 1.5

TM Forum 2011

Page 52 of 88

Service Problem Management Business Agreement

Summary

The requesting OSS forwards the problem creation request to the target OSS. The target OSS crea

Actor(s)

The requesting OSS

PreConditions

1. The OSSs involved in the use case have started (refer to use cases UC_TMF518_FMW_0001
2. The subscriber OSSs have subscribed to get the Object Creation notifications produced by the

Begins
When

The requesting OSS sends a request to the target OSS to create a new service problem

Description

1. The requesting OSS sends a request to the target OSS to create a new service problem.
2. The target OSS validates the request.
3. The target OSS creates a service problem.
Note: There are 2 types of Service Problems:

Simple Service Problem, where only 1 service is affected;

Multi-service Problems, where more than 1 service is affected.

There should a choice for a given implementation to generate either simple or multi-Service Problem

Note: In general, a Service Problem may contain the attributes which are specified in requirement R
R_TMF522_I_0001,
R_TMF522_I_0002,
R_TMF522_I_0005,
R_TMF522_I_0006,
R_TMF522_I_0007,
R_TMF522_I_0008,
R_TMF522_I_0009,
R_TMF522_I_0010,
R_TMF522_I_0011
R_TMF522_I_0012

4. The requesting OSS gets a direct response for the request which indicates that the new Service

5. The target OSS executes the use case UC_TMF522_0001, that is, to generate an Object Crea
6. All the subscribed OSSs receive the notification from the notification service.
Ends
When

In case of success:

The requesting OSS has gotten the direct response for the creation request and all the sub
In case of failure:
The requesting OSS has received an exception.

PostConditions

TMF522, Version 1.5

In case of success:

A new Service Problem is now known to the target OSS, and the Service Problem informat

TM Forum 2011

Page 53 of 88

Service Problem Management Business Agreement


In case of failure:

If the direct response failed, then the new Service Problem is not known to the target OSS a

If the direct response is successful, but the notification publishing and/or delivery fails, then
Exceptions

1. If the Target OSS does not support the request, a Not Implemented exception is raised, and the

2. If the syntax of the request is incorrect, an Invalid Input exception is raised and the Target OSS

3. If the Target OSS is unable to accomplish the operation, due to a lack of internal resources, an

4. Any other severe error in the Target OSS shall cause an Internal Error exception and the Targe
5. In case the Notification Service is unavailable, the Unable To Notify exception shall be raised.

6. In case the notification service encounters a problem and the delivery fails, the Unable To Deliv
Traceability

R_TMF522_I_0001, R_TMF522_I_0002, R_TMF522_I_0004, R_TMF522_I_0005, R_TMF522_I_0

Use Case Id

UC_TMF522_0006

Use Case Name

Update a service problem

Summary

The requesting OSS forwards the Service Problem update request to


the target OSS. The requesting OSS will be notified when the Service
Problem has been successfully updated.

Actor(s)

The requesting OSS

Pre-Conditions

1. The OSSs involved in the use case have started (refer to


UC_TMF518_FMW_0001 and UC_TMF518_FMW_0002 in
TMF518_FMW).
2. The subscriber OSSs have subscribed to get the AVC notifications
produced by the report-owning OSS (refer to use
case UC_TMF522_0017)

Begins When

The requesting OSS sends an update request to the target OSS

Description

1. The requesting OSS sends a request to update a Service Problem


that is owned by the target OSS. This is possible for all settable
attributes.
2. The target OSS updates the Service Problem according to the
request.
3. The requesting OSS gets a direct response to the request which
indicates that the Service Problem has been updated.
4. The target OSS executes the use case UC_TMF522_0002, that
is, to generate an AVC notification and delivers the notification to
the notification service.
5. All OSS that have subscribed to this notification receive it from the
notification service.

Ends When

In case of success:
The requesting OSS has gotten the direct response for the
update request and all the subscribed OSSs have received
the notification in a pre-defined time.

TMF522, Version 1.5

TM Forum 2011

Page 54 of 88

Service Problem Management Business Agreement


In case of failure:
The requesting OSS receives an exception.
Post-Conditions

In case of success:
The target OSS is now aware of the new attribute values for
the Service Problem. The Service Problem information in the
subscriber OSSs and the target OSS is in consistent.
In case of failure:
If the direct response failed, then the updated attribute values
of the Service Problem are not known to the target OSS and
no AVC notification will be sent out by the target OSS.
If the direct response is successful, but the notification
publishing and/or delivery fails, then the updated attributes of
the Service Problem will be known to the target OSS, but
some of the subscriber OSSs will not be aware of this update.

Exceptions

1. In case the operation is not implemented or supported by the


target OSS, the Not Implemented exception shall be raised and
the operation is not fulfilled.
2. In case the request is invalid (such as, request to update a nonsettable attribute), an Invalid Input exception shall be raised and
the operation is not fulfilled.
3. In case the authentication of the requesting OSS is not validated
by the target OSS, an Access Denied exception shall be raised
and the operation is not fulfilled.
4. If the target OSS is unable to accomplish the operation, due to a
lack of internal resources, an Unable To Comply exception is
raised and the operation is not fulfilled.
5. If the target OSS is unable to accomplish the operation, due to
any other internal error, an Internal Error exception is raised and
the operation is not fulfilled.
6. In case the Notification Service unavailable, the Unable To Notify
exception shall be raised.
7. In case the notification service encounters a problem and the
delivery fails, the Unable To Deliver exception shall be raised.

Traceability

R_TMF522_II_0018

Use Case Id

UC_TMF522_0007

Use Case Name

Change escalation level

Summary

The requesting OSS forwards the Service Problem escalation level


change request to the target OSS. The requesting OSS will be notified
when the escalation level of the Service Problem has been
successfully changed.
Note: The escalation level can be explicitly set through the interface or

TMF522, Version 1.5

TM Forum 2011

Page 55 of 88

Service Problem Management Business Agreement


an implicit done at the target OSS (e.g., via the user interface).
Actor(s)

The requesting OSS

Pre-Conditions

1. The OSSs involved in the use case have started (refer to


UC_TMF518_FMW_0001 and UC_TMF518_FMW_0002 in
TMF518_FMW).
2. The subscriber OSSs have subscribed to get the AVC notifications
produced by the report-owning OSS (refer to use
case UC_TMF522_0017)

Begins When

The requesting OSS sends a escalation level change request to the


target OSS

Description

1. The requesting OSS sends a request to set the escalation level of


a Service Problem in the target OSS or the target OSS decides to
change the escalation level of a service problem (e.g., at the
request of a user via the user interface of the target OSS).
2. The target OSS sets a value of the escalation level on the Service
Problem.
3. The target OSS gives the requesting OSS a direct response which
indicates that the escalation level has been changed.
4. The target OSS executes the use case UC_TMF522_0002, that
is, generates an AVC notification to all subscribed OSSs.
5. All subscribed OSSs have received the notification

Ends When

In case of success:
The requesting OSS has gotten the direct response for the
escalation level change request and all the subscribed OSSs
have received the associated notification in a pre-defined time.
In case of failure:
The requesting OSS receives an exception.

Post-Conditions

In case of success:
The Service Problem now has a new escalation level in the
target OSS.
The requesting OSS has gotten the direct response and the
subscriber OSSs are notified that the escalation of the Service
Problem has been successfully changed.
In case of failure:
If the direct response failed, then the escalation level of the
Service Problem has no change and no Attribute Value
Change notification will be sent by the target OSS.
If the direct response is successful, but the notification
publishing and/or delivery fails, then the escalation level of the
Service Problem has been changed, but some of the
subscriber OSSs will not be aware of this update.

Exceptions

TMF522, Version 1.5

1. In case the operation is implemented or supported by the target


OSS, the Not Implemented exception shall be raised and the
TM Forum 2011

Page 56 of 88

Service Problem Management Business Agreement


operation is not fulfilled.
2. In case the request is invalid (such as, the value of the escalation
level is out of the bound), an Invalid Input exception shall be
raised and the operation is not fulfilled.
3. In case the authentication of the requesting OSS is not validated
by the target OSS, an Access Denied exception shall be raised
and the operation is not fulfilled.
4. If the target OSS is unable to accomplish the operation, due to a
lack of internal resources, an Unable To Comply exception is
raised and the operation is not fulfilled.
5. If the target OSS is unable to accomplish the operation, due to
any other internal error, an Internal Error exception is raised and
the operation is not fulfilled.
6. In case the Notification Service unavailable, the Unable To Notify
exception shall be raised.
7. In case the notification service encounters a problem and the
delivery fails, the Unable To Deliver exception shall be raised.

Traceability

R_TMF522_I_0004

Use Case Id

UC_TMF522_0008

Use Case Name

Change priority of a service problem

Summary

The requesting OSS sends a Service Problem priority change request


to the target OSS. The requesting OSS will be notified when the
priority of the Service Problem has been successfully changed.

Actor(s)

The requesting OSS

Pre-Conditions

1. The OSSs involved in the use case have started (refer to


UC_TMF518_FMW_0001 and UC_TMF518_FMW_0002 in
TMF518_FMW).
2. The subscriber OSSs have subscribed to get the AVC notifications
produced by the report-owning OSS (refer to use
case UC_TMF522_0017)

Begins When

The requesting OSS sends a priority change request to the target


OSS

Description

1. The requesting OSS sends a request to change the priority of a


Service Problem in the target OSS.
2. The target OSS increases or decreases the priority of the Service
Problem to the value specified in the request.
3. (Side-effect) The target OSS may also change the value (which is
contained in the request) of the Service Problem Escalation Level
attribute of the Service Problem. This is to align with the change to
the priority.

TMF522, Version 1.5

TM Forum 2011

Page 57 of 88

Service Problem Management Business Agreement

4. The target OSS gives the requesting OSS a direct response which
indicates that the priority has been changed.
5. The target OSS executes the use case UC_TMF522_0002, that
is, generates an AVC notification to all subscribed OSSs.
6. All subscribed OSSs have received the notification.
Ends When

In case of success:
The requesting OSS has gotten the direct response for the
priority change request and all the subscribed OSSs have
received the notification in a pre-defined time.
In case of failure:
The requesting OSS receives an exception.

Post-Conditions

In case of success:
The Service Problem now has a new priority in the target
OSS.
The requesting OSS has gotten the direct response and the
subscriber OSSs are notified that the priority of the Service
Problem has been successfully changed.
In case of failure:
If the direct response failed, then the priority of the Service
Problem has not changed and will no update notification will
be sent by the target OSS.
If the direct response is successful, but the notification
publishing and/or delivery fails, then the priority of the Service
Problem will have changed, but some of the subscriber OSSs
will not aware of this update.

Exceptions

1. In case the operation is implemented or supported by the target


OSS, the Not Implemented exception shall be raised and the
operation is not fulfilled.
2. In case the request is invalid (such as, the value of the priority is
out of the bound), an Invalid Input exception shall be raised and
the operation is not fulfilled.
3. In case the authentication of the requesting OSS is not validated
by the target OSS, an Access Denied exception shall be raised
and the operation is not fulfilled.
4. If the target OSS is unable to accomplish the operation, due to a
lack of internal resources, an Unable To Comply exception is
raised and the operation is not fulfilled.
5. If the target OSS is unable to accomplish the operation, due to
any other internal error, an Internal Error exception is raised and
the operation is not fulfilled.
6. In case the Notification Service unavailable, the Unable To Notify
exception shall be raised.

TMF522, Version 1.5

TM Forum 2011

Page 58 of 88

Service Problem Management Business Agreement


7. In case the notification service encounters a problem and the
delivery fails, the Unable To Deliver exception shall be raised.
Traceability

R_TMF522_I_0004,R_TMF522_II_0014

Use Case Id

UC_TMF522_0009

Use Case Name

Add a comment to a service problem

Summary

The requesting OSS sends the Service Problem comment request to


the target OSS. The requesting OSS will be notified when the Service
Problem has been successfully commented.

Actor(s)

The requesting OSS

Pre-Conditions

1. The OSSs involved in the use case have started (refer to


UC_TMF518_FMW_0001 and UC_TMF518_FMW_0002 in
TMF518_FMW).
2. The subscriber OSSs have subscribed to get the AVC notifications
produced by the report-owning OSS (refer to use
case UC_TMF522_0017)

Begins When

The requesting OSS sends a comment request to the target OSS

Description

1. The requesting OSS sends a request to comment a Service


Problem in the target OSS.
2. The target OSS comments the Service Problem according to the
request.
3. The requesting OSS gets a direct response to the request which
indicates that the Service Problem has been commented, i.e., a
comment has been added to the Service Problem.
4. The target OSS executes the use case UC_TMF522_0002, that
is, to generate an AVC notification and delivers it to the notification
service.
5. All OSS that have subscribed to this notification receive it from the
notification service.

Ends When

In case of success:
The requesting OSS has gotten the direct response for the
comment addition request and all the subscribed OSSs have
received the notification.
In case of failure:
The requesting OSS receives an exception.

Post-Conditions

In case of success:
A comment has been added to the Service Problem in the
target OSS.
All subscriber OSSs are notified that the Service Problem has

TMF522, Version 1.5

TM Forum 2011

Page 59 of 88

Service Problem Management Business Agreement


been successfully commented.
In case of failure:
If the direct response failed, then the comments of the Service
Problem have not change and no update notification will be
sent by the target OSS.
If the direct response is successful, but the notification
publishing and/or delivery fails, then the Service Problem have
a new comment, but some of the subscriber OSSs will not
aware of this update.
Exceptions

1. In case the operation is not implemented or supported by the


target OSS, the Not Implemented exception shall be raised and
the operation will not be fulfilled.
2. In case the request is invalid, an Invalid Input exception shall be
raised and the operation will not be fulfilled.
3. In case the authentication of the requesting OSS is not validated
by the target OSS, an Access Denied exception shall be raised
and the operation will not be fulfilled.
4. If the target OSS is unable to accomplish the operation, due to a
lack of internal resources, an Unable To Comply exception is
raised and the operation will not be fulfilled.
5. If the target OSS is unable to accomplish the operation, due to
any other internal error, an Internal Error exception is raised and
the operation will not be fulfilled.
6. In case the Notification Service unavailable, the Unable To Notify
exception shall be raised.
7. In case the notification service encounters a problem and the
delivery fails, the Unable To Deliver exception shall be raised.

Traceability

R_TMF522_II_0019

Use Case Id

UC_TMF522_0010

Use Case Name

Add a new correlation or removing one.

Summary

The requesting OSS forwards the alarm correlation change request to


the target OSS. The requesting OSS will be notified when the
correlation of the Service Problem has been successfully changed.

Actor(s)

The requesting OSS

Pre-Conditions

1. The OSSs involved in the use case have started (refer to


UC_TMF518_FMW_0001 and UC_TMF518_FMW_0002 in
TMF518_FMW).
2. The subscriber OSSs have subscribed to get AVC notifications
produced by the report-owning OSS (refer to use
case UC_TMF522_0017)

TMF522, Version 1.5

TM Forum 2011

Page 60 of 88

Service Problem Management Business Agreement

Begins When

The requesting OSS sends a correlation change request to the target


OSS

Description

1. The requesting OSS sends a request to add a new correlation or


to remove one in the target OSS.
2. The target OSS adds a new correlation or removes one, as
requested.
3. The requesting OSS gets a direct response to the request which
indicates that the correlation of the Service Problem has been
changed.
4. The target OSS executes the use case UC_TMF522_0002 that is,
to generate AVC notification(s) and delivers to the notification
service.
5. All OSS that have subscribed to this notification receive it from the
notification service.

Ends When

In case of success:
The requesting OSS has gotten the direct response
concerning the change of correlation and all the subscribed
OSSs have received the notification.
In case of failure:
The requesting OSS receives an exception.

Post-Conditions

In case of success:
The Service Problem now has a new correlation (for addition a
new correlation) or no longer has an old correlation (for
removing an old correlation) in the target OSS.
The subscriber OSSs are notified that the correlation among
the service problems has been successfully changed.
In case of failure:
If the direct response failed, then the correlation of the Service
Problem has no change and will no update notification sent
out by the target OSS.
If the direct response is successful, but the notification
publishing and/or delivery fail, then the Service Problem has a
modified correlation collection, but some of the subscriber
OSSs will not aware of this update.

Exceptions

1. In case the operation is not implemented or supported by the


target OSS, the Not Implemented exception shall be raised and
the operation will not be fulfilled.
2. In case the request is invalid, an Invalid Input exception shall be
raised and the operation will not be fulfilled.
3. In case the authentication of the requesting OSS is not validated
by the target OSS, an Access Denied exception shall be raised
and the operation will not be fulfilled.

TMF522, Version 1.5

TM Forum 2011

Page 61 of 88

Service Problem Management Business Agreement


4. If the target OSS is unable to accomplish the operation, due to a
lack of internal resources, an Unable To Comply exception is
raised and the operation will not be fulfilled.
5. If the target OSS is unable to accomplish the operation, due to
any other internal error, an Internal Error exception is raised and
the operation will not be fulfilled.
6. In case the Notification Service unavailable, the Unable To Notify
exception shall be raised.
7. In case the notification service encounters a problem and the
delivery fails, the Unable To Deliver exception shall be raised.
Traceability

R_TMF522_II_0020

Use Case
Id

UC_TMF522_0011

Use Case
Name

Clear a service problem

Summary

The requesting OSS forwards the alarm clear request to the target OSS. The
requesting OSS will be notified when the alarm clear operation is successful.

Actor(s)

The requesting OSS

PreConditions

1. The OSSs involved in the use case have started (refer to


UC_TMF518_FMW_0001 and UC_TMF518_FMW_0002 in TMF518_FMW).
2. The subscriber OSSs have subscribed to get State Change notifications
produced by the report-owning OSS (refer to use case UC_TMF522_0017)
3. The Service Problem to be cleared has the raised status.

Begins
When

The requesting OSS sends a clear request to the target OSS

Description

1. The requesting OSS issues a request to clear a Service Problem in the target
OSS.
2. The target OSS clears the Service Problem according to the request. The
clear status of the Service Problem is updated to cleared.
3. Timestamps of the clear action should be kept as tracking records. The fields
of the tracking records are:

timestamp of the action


description of the action: Clear
the id of the user/system who done the action
system id on which this action is done

4. The requesting OSS gets a direct response to the request which indicates that
the Service Problem has been cleared.
5. The target OSS detects a Service Problem clear and executes use
case UC_TMF522_0003: generates a SC notification and delivers the

TMF522, Version 1.5

TM Forum 2011

Page 62 of 88

Service Problem Management Business Agreement


notification to the notification service.
6. All OSS that have subscribed to this notification receive it from the notification
service.
Ends
When

In case of success:
The requesting OSS has gotten the direct response for the clear request
and all the subscribed OSSs have received the notification.
In case of failure:
The requesting OSS receives an exception

PostConditions

In case of success:
The clear status of the Service Problem is cleared.
A tracking record about this action is created.
The subscriber OSSs are notified that the Service Problem has been
cleared.
In case of failure:
If the direct response failed, then the clearance status of the Service
Problem has no change and will no notification sent out by the target
OSS.
If the direct response is successful, but the notification publishing and/or
delivery fails, then the Service Problem holds new clearance status and
has a tracking record about this change, but some of the subscriber OSSs
is not aware of this change.

Exceptions

1. In case the operation is not implemented or supported by the target OSS, the
Not Implemented exception shall be raised and the operation will not be
fulfilled.
2. In case the request is invalid (such as the service alarm to be cleared does
not exist), an Invalid Input exception or Entity Not Found exception shall be
raised and the operation will not be fulfilled.
3. In case the authentication of the requesting OSS is not validated by the target
OSS, an Access Denied exception shall be raised and the operation will not
be fulfilled.
4. If the target OSS is unable to accomplish the operation, due to a lack of
internal resources, an Unable To Comply exception is raised and the Target
OSS stops serving the request.
5. If the target OSS is unable to accomplish the operation, due to any other
internal error, an Internal Error exception is raised and the Target OSS stops
serving the request.
6. If the target OSS is unable to accomplish the operation, due to the status of
the service alarm, then a Not In Valid State exception is raised and the target
OSS stops serving the request.
7. In case the Notification Service is unavailable, the Unable To Notify exception
shall be raised.

TMF522, Version 1.5

TM Forum 2011

Page 63 of 88

Service Problem Management Business Agreement


8. In case the notification service encounters a problem and the delivery fails,
the Unable To Deliver exception shall be raised.
Traceability

R_TMF522_I_0008, R_TMF522_I_0010, R_TMF522_II_0021,R_TMF522_II_0026

Use Case Id

UC_TMF522_0012

Use Case Name

Unclear a service problem

Summary

The requesting OSS forwards the alarm unclear request to the target
OSS. The requesting OSS will be notified when the alarm unclear
operation is successful.

Actor(s)

The requesting OSS

Pre-Conditions

1. The OSSs involved in the use case have started (refer to


UC_TMF518_FMW_0001 and UC_TMF518_FMW_0002 in
TMF518_FMW).
2. The subscriber OSSs have subscribed to get State Change
notifications produced by the report-owning OSS (refer to use
case UC_TMF522_0017)
3. The Service Problem to be un-cleared has cleared status.

Begins When

The requesting OSS sends an unclear request to the target OSS

Description

1. The requesting OSS issues a request to unclear a Service Problem


in the target OSS.
2. The target OSS unclear the Service Problem according to the
request. The clear status of the Service Problem is updated to
raised and the Service Problem became active.
3. Timestamps of the unclear action should be kept as tracking
records. The fields of the tracking records are:

timestamp of the action


description of the action: unclear
the id of the user who done the action
system id on which this action is done

4. The requesting OSS gets a direct response to the request which


indicates that the Service Problem has been un-cleared.
5. The target OSS detects a Service Problem unclear and executes
the use case UC_TMF522_0003: generates a SC notification and
delivers the notification to the notification service.
6. All OSS that have subscribed to this notification receive it from the
notification service.
Ends When

In case of success:
The requesting OSS has gotten the direct response for the unclearance request and all the subscribed OSSs have received
the notification.
In case of failure:

TMF522, Version 1.5

TM Forum 2011

Page 64 of 88

Service Problem Management Business Agreement


The requesting OSS receives an exception
Post-Conditions

In case of success:
The clear status of the Service Problem is raised.
.A tracking record about this action is created.
The subscriber OSSs are notified that the Service Problem has
been un-cleared.
In case of failure:
If the direct response failed, then the clearance status of the
Service Problem has no change and will no notification sent out
by the target OSS.
If the direct response is successful, but the notification
publishing and/or delivery fails, then the Service Problem holds
new clearance status and has a tracking record about this
change, but some of the subscriber OSSs is not aware of this
change.

Exceptions

1. In case the operation is not implemented or supported by the target


OSS, Not Implemented exception shall be raised and the operation
will not be fulfilled.
2. In case the request is invalid (such as the service alarm to be
cleared does not exist), an Invalid Input exception or Entity Not
Found exception shall be raised and the operation will not be
fulfilled.
3. In case the authentication of the requesting OSS is not validated by
the target OSS, an Access Denied exception shall be raised and
the operation will not be fulfilled.
4. If the target OSS is unable to accomplish the operation, due to a
lack of internal resources, an Unable To Comply exception is raised
and the Target OSS stops serving the request.
5. If the target OSS is unable to accomplish the operation, due to any
other internal error, an Internal Error exception is raised and the
Target OSS stops serving the request.
6. If the target OSS is unable to accomplish the operation, due to the
status of the service alarm, then a Not In Valid State exception is
raised and the target OSS stops serving the request.
7. In case the Notification Service unavailable, the Unable To Notify
exception shall be raised.
8. In case the notification service encounters a problem and the
delivery fails, the Unable To Deliver exception shall be raised.

Traceability

R_TMF522_I_0008,R_TMF522_I_0010,R_TMF522_II_0022,R_TMF52
2_II_0026

Use Case Id

UC_TMF522_0013

TMF522, Version 1.5

TM Forum 2011

Page 65 of 88

Service Problem Management Business Agreement

Use Case Name

Acknowledges a service problem

Summary

The requesting OSS forwards the alarm acknowledgment request to the


target OSS.
The requesting OSS will be notified when the alarm acknowledgment
operation is successful.

Actor(s)

The requesting OSS

Pre-Conditions

1. The OSSs involved in the use case have started (refer to


UC_TMF518_FMW_0001 and UC_TMF518_FMW_0002 in
TMF518_FMW).
2. The subscriber OSSs have subscribed to get State Change
notifications produced by the report-owning OSS (refer to use
case UC_TMF522_0017)
3. The Service Problem to be acknowledged has unacked status.

Begins When

The requesting OSS tries to acknowledge a Service Problem in the


target OSS

Description

1. The requesting OSS issues an Ack request to acknowledge a


Service Problem in the target OSS.
2. The target OSS acknowledges the Service Problem and the Service
Problem is updated as ack in the target OSS.
3. Timestamps of the acknowledgement action should be kept as
tracking records. The fields of the tracking records are:

timestamp of the action


description of the action: ack
the id of the user who done the action
system id on which this action is done

4. The requesting OSS gets a direct response to the request which


indicates that the Service Problem has been acknowledged.
5. The target OSS execute the use case UC_TMF522_0002:
generates a SC notification and delivers it to the notification service.
6. All OSS that have subscribed to this notification receive it from the
notification service.
Ends When

In case of success:
The requesting OSS has gotten the direct response for the
acknowledge request and all the subscribed OSSs have
received the notification.
In case of failure:
The requesting OSS receives an exception

Post-Conditions

In case of success:
The ack status of the Service Problem is ack in the target
OSS.

TMF522, Version 1.5

TM Forum 2011

Page 66 of 88

Service Problem Management Business Agreement


A tracking record about this action is created.
The subscriber OSSs are notified that the Service Problem has
been acknowledged in the target OSS.
In case of failure:
If the direct response failed, then the ack status of the Service
Problem has no change and will no update notification sent out
by the target OSS.
If the direct response is successful, but the notification
publishing and/or delivery fails, then the Service Problem holds
new ack status and has a tracking record about this change, but
some of the subscriber OSSs is not aware of this change.
Exceptions

1. In case the operation is not implemented or supported by the target


OSS, Not Implemented exception shall be raised and the operation
will not be fulfilled.
2. In case the request is invalid (such as the service alarm to be
acknowledged does not exist), an Invalid Input exception or Entity
Not Found exception shall be raised and the operation will not be
fulfilled.
3. In case the authentication of the requesting OSS is not validated by
the target OSS, an Access Denied exception shall be raised and
the operation will not be fulfilled.
4. If the target OSS is unable to accomplish the operation, due to a
lack of internal resources, an Unable To Comply exception is raised
and the Target OSS stops serving the request.
5. If the target OSS is unable to accomplish the operation, due to any
other internal error, an Internal Error exception is raised and the
Target OSS stops serving the request
6. If the target OSS is unable to accomplish the operation, due to the
status of the service alarm, then a Not In Valid State exception is
raised and the target OSS stops serving the request.
7. In case the Notification Service unavailable, the Unable To Notify
exception shall be raised.
8. In case the notification service encounters a problem and the
delivery fails, the Unable To Deliver exception shall be raised.

Traceability

R_TMF522_I_0009,R_TMF522_I_0010,R_TMF522_II_0023,R_TMF52
2_II_0026

Use Case
Id

UC_TMF522_0014

Use Case
Name

Un-acknowledges a service problem

Summary

The requesting OSS forwards the Service Problem un-acknowledge request to the
target OSS. The requesting OSS will be notified when the un-acknowledge

TMF522, Version 1.5

TM Forum 2011

Page 67 of 88

Service Problem Management Business Agreement


operation is successful.
Actor(s)

The requesting OSS

PreConditions

1. The OSSs involved in the use case have started (refer to


UC_TMF518_FMW_0001 and UC_TMF518_FMW_0002 in TMF518_FMW).
2. The subscriber OSSs have subscribed to get State Change notifications
produced by the report-owning OSS (refer to use case UC_TMF522_0017)
3. The Service Problem to be unacknowledged is acknowledged.

Begins
When

The requesting OSS tries to un-acknowledge a Service Problem in the target OSS

Description

1. The requesting OSS issues an UnAck request to un-acknowledge a Service


Problem in the target OSS.
2. The target OSS un-acknowledges the Service Problem and the Service
Problem is updated as unack in the target OSS.
3. Timestamps of the un-acknowledgement action should be kept as tracking
records. The fields of the tracking records are:

timestamp of the action,

description of the action: unack

the id of the user who done the action,

system id on which this action is done

4. The requesting OSS gets a direct response to the request which indicates that
the Service Problem has been un-acknowledged.
5. The target OSS execute the use case UC_TMF522_0002: generates a SC
notification and delivers the notification to the notification service.
6. All OSS that have subscribed to this notification receive it from the notification
service.
Ends
When

In case of success:
The requesting OSS has gotten the direct response for the unacknowledge request and all the subscribed OSSs have received the
notification.
In case of failure:
The requesting OSS receives an exception.

PostConditions

In case of success:
The ack status of the Service Problem is unack in the target OSS.
A tracking record about this action is placed somewhere.
The subscriber OSSs are notified that the Service Problem has been
unacknowledged.
In case of failure:
If the direct response failed, then the ack status of the Service Problem
has no change and will no notification sent out by the target OSS.

TMF522, Version 1.5

TM Forum 2011

Page 68 of 88

Service Problem Management Business Agreement


If the direct response is successful, but the notification publishing and/or
delivery fails, then the Service Problem holds new ack status and has a
tracking record about this change, but some of the subscriber OSSs is not
aware of this change.
Exceptions

1. In case the operation is not implemented or supported by the target OSS, Not
Implemented exception shall be raised and the operation will not be fulfilled.
2. In case the request is invalid (such as the service alarm to be unacknowledged does not exist), an Invalid Input exception or Entity Not Found
exception shall be raised and the operation will not be fulfilled.
3. In case the authentication of the requesting OSS is not validated by the target
OSS, an Access Denied exception shall be raised and the operation will not
be fulfilled.
4. If the target OSS is unable to accomplish the operation, due to a lack of
internal resources, an Unable To Comply exception is raised and the Target
OSS stops serving the request.
5. If the target OSS is unable to accomplish the operation, due to any other
internal error, an Internal Error exception is raised and the Target OSS stops
serving the request.
6. If the target OSS is unable to accomplish the operation, due to the status of
the service alarm, then a Not In Valid State exception is raised and the target
OSS stops serving the request.
7. In case the Notification Service unavailable, the Unable To Notify exception
shall be raised.
8. In case the notification service encounters a problem and the delivery fails,
the Unable To Deliver exception shall be raised.

Traceability

R_TMF522_I_0009, R_TMF522_I_0010, R_TMF522_II_0024,R_TMF522_II_0026

Use Case Id

UC_TMF522_0015

Use Case Name

Delete an historical service problem

Summary

The requesting OSS forwards an historical Service Problem delete


request to the target OSS.

Actor(s)

The requesting OSS

Pre-Conditions

1. The OSSs involved in the use case have started (refer to


UC_TMF518_FMW_0001 and UC_TMF518_FMW_0002 in
TMF518_FMW).

Begins When

The requesting OSS issues a request to delete an historical Service


Problem in the target OSS.

Description

1. The requesting OSS issues a request to delete an historical


Service Problem in the target OSS.
2. The target OSS removes the historical Service Problem from the
storage.

TMF522, Version 1.5

TM Forum 2011

Page 69 of 88

Service Problem Management Business Agreement

3. The requesting OSS gets a direct response to the request which


indicates that the Service Problem has been removed.
4. The target OSS execute the use case UC_TMF522_0004:
generates an Object Deletion notification and delivers it to the
notification service.
5. All OSS that have subscribed to this notification receive it from
the notification service.
Note:
According to R_TMF522_II_0016, the subscriber OSSs may not be
notified when the historical Service Problem has been successfully
deleted.
Ends When

In case of success:
The requesting OSS has gotten the direct response for the
deletion request and all the subscribed OSSs have received
the notification.
In case of failure:
The requesting OSS receives an exception

Post-Conditions

In case of success:
The historical Service Problem has been removed from the
storage in the target OSS.
In case of failure:
If the direct response failed, then the historical Service
Problem still kept by the target OSS and will no notification
sent out by the target OSS.
If the direct response is successful, but the notification
publishing and/or delivery fails, then the historical Service
Problem has been removed, but some of the subscriber
OSSs is not aware of this deletion.

Exceptions

1. In case the operation is not implemented or supported by the


target OSS, Not Implemented exception shall be raised and the
operation will not be fulfilled.
2. In case the request is invalid (such as the service alarm to be
deleted does not exist), an Invalid Input exception or Entity Not
Found exception shall be raised and the operation will not be
fulfilled.
3. In case the authentication of the requesting OSS is not validated
by the target OSS, an Access Denied exception shall be raised
and the operation will not be fulfilled.
4. If the target OSS is unable to accomplish the operation, due to a
lack of internal resources, an Unable To Comply exception is
raised and the Target OSS stops serving the request.
5. If the target OSS is unable to accomplish the operation, due to

TMF522, Version 1.5

TM Forum 2011

Page 70 of 88

Service Problem Management Business Agreement


any other internal error, an Internal Error exception is raised and
the Target OSS stops serving the request
6. If the target OSS is unable to accomplish the operation, due to
the status of the service alarm, then a Not In Valid State exception
is raised and the target OSS stops serving the request.
7. In case the Notification Service unavailable, the Unable To Notify
exception shall be raised.
8. In case the notification service encounters a problem and the
delivery fails, the Unable To Deliver exception shall be raised.
Traceability

R_TMF522_I_0003,R_TMF522_II_0025,R_TMF522_II_0026

Use Case
Id

UC_TMF522_0016

Use Case
Name

Create a parent service problem that either replaces or just references several
child service problems

Summary

The requesting OSS requests that the report-owning OSS create a new Service
Problem which includes all the affected services in a given set of existing Service
Problems

Actor(s)

The requesting OSS

PreConditions

1. The OSSs involved in the use case have started (refer to use cases
UC_TMF518_FMW_0001 and UC_TMF518_FMW_0002 in TMF518_FMW).
2. The subscriber OSSs have subscribed to get the Object Creation notifications
produced by the report-owning OSS (refer to use case UC_TMF522_0017).

Begins
When

The requesting OSS sends a request to the target OSS to create a new service
problem based on some existing Service Problems

Description

1. The requesting OSS sends a request to the target OSS to create a new
service problem based on some existing service problems (referred to as
subordinate service problems in this use case).
a. Optionally, the requesting OSS can reference the subordinate service
problems in the Underlying Problems field of the root cause attribute.
b. On the other hand, the requesting OSS can completely replace the
subordinate service problems with a new service problem and then
request deletion of the subordinate service problems.
2. The target OSS validates the request.
3. The target OSS creates a service problem which includes all the affected
services in the subordinate service problems. Some of the attributes of the
new service problem should be calculated based on the attributes of the
subordinate service problems.
4. At this point, the subordinate service problems can now be deleted (as noted
this is just one option). If the subordinate service problems are deleted, then
one or more object deletion notifications will be generated by the target OSS.
5. The requesting OSS gets a direct response for the request which indicates

TMF522, Version 1.5

TM Forum 2011

Page 71 of 88

Service Problem Management Business Agreement


that a new Service Problem has been created.
6. The target OSS executes the use case UC_TMF522_0001, that is, to
generate an Object Creation notification and send it to the notification service.
7. All the subscribed OSSs receive the notification from the notification service.
Ends
When

In case of success:
The requesting OSS has gotten the direct response for the request and all
the subscribed OSSs have received the notification in a pre-defined time.
In case of failure:
The requesting OSS has received an exception.

PostConditions

In case of success:
A new Service Problem is now known to the requesting OSS, and the
Service Problem information in the subscriber OSSs and the target OSS is
in consistent.
In case of failure:
If the direct response failed, then the new Service Problem is not known to
the requesting OSS and there will be no service problem creation
notification sent by the target OSS.
If the direct response is successful, but the notification publishing and/or
delivery fails, then the new Service Problem would be known to the target
OSS, but some of the subscriber OSSs will not be aware of this new
service problem.

Exceptions

1. If the Target OSS does not support the request, a Not Implemented exception
is raised, and the Target OSS will not fulfill the request.
2. If the syntax of the request is incorrect, an Invalid Input exception is raised
and the Target OSS will not fulfill the request.
3. If one of the specified child Service Problems does not exist, an Entity Not
Found exception is raised and the target OSS will not fulfill the request.
4. If the Target OSS is unable to accomplish the operation, due to a lack of
internal resources, an Unable To Comply exception is raised and the Target
OSS will not fulfill the request.
5. Any other severe error in the Target OSS shall cause an Internal Error
exception and the Target OSS will not fulfill the request.
6. In case the Notification Service is unavailable, the Unable To Notify exception
shall be raised.
7. In case the notification service encounters a problem and the delivery fails,
the Unable To Deliver exception shall be raised.

Traceability

TMF522, Version 1.5

R_TMF522_I_0002,R_TMF522_I_0006, R_TMF522_II_0013, R_TMF522_II_0017

TM Forum 2011

Page 72 of 88

Service Problem Management Business Agreement

4.3

Service Problem Subscription


Use Case Id

UC_TMF522_0017

Use Case Name

Subscribe to Service Problems

Summary

An OSS subscribes with the notification service to receive the service


problems generated by a publisher OSS, the subscription can have a
filter.

Actor(s)

The subscribing OSS

Pre-Conditions

The OSSs involved in the use case have started (refer to


UC_TMF518_FMW_0001 and UC_TMF518_FMW_0002 in
TMF518_FMW).

Begins When

The subscribing OSS sends a request to register itself at the


notification service for the Service Problem notifications offered by the
publisher OSS (or some subset of the notifications as restricted by the
specified filter)

Description

1. The subscribing OSS subscribes to the notification service with a


filter.
Note:
1) Only a single filter is allowed. To augment a filter, we will have
to delete, edit and reapply it.
2) The filter can based on the following characteristics:

Please refer to R_TMF522_II_0028

If a particular filter characteristic is not populated, then service


problems for all possible values of that characteristic are included.
2. The notification service receives the subscription request.
3. The notification service keeps the subscription and sends a
response to the subscriber OSS.
4. The subscribing OSS receives the subscription response.
Ends When

In case of success:
The subscribing OSS receives a positive response to its
connection request to the notification service.
In case of failure:
The subscribing OSS gets an error indication from the
notification service.

Post-Conditions

In case of success:
The specified filter is working and the subscribing OSS can
receive the Service Problem notifications published by the
publisher OSS.
In case of failure:
The subscribing OSS receives a negative response for

TMF522, Version 1.5

TM Forum 2011

Page 73 of 88

Service Problem Management Business Agreement


connection to the notification service, for the specific
subscription request, for the filter building or the request times
out. The result is that it (the Subscriber OSS) cannot receive
the Service Problem notifications published by the publisher
OSS.
Exceptions

1. In case the notification service is unavailable, the Notification


Service Exception shall be raised and the operation stops.
2. In case the filter is invalid, the Invalid Selector exception shall be
raised and the operation stops.

Traceability

R_TMF522_II_0027, R_TMF522_II_0028

Use Case Id

UC_TMF522_0018

Use Case Name

Un-subscribes to Service Problems

Summary

A subscribed OSS sends an unsubscribe request to the notification


service to unsubscribe from the Service Problem notifications
published by the publisher OSS

Actor(s)

The subscriber OSS

Pre-Conditions

1. The OSSs involved in the use case have started (refer to


UC_TMF518_FMW_0001 and UC_TMF518_FMW_0002 in
TMF518_FMW).
2. The subscriber OSSs had previously subscribed to get service
problems notifications produced by the publisher OSS (refer to
use case UC_TMF522_0017)

Begins When

The subscriber OSS sends a request (to the notification service) to


unsubscribe itself from the notifications about the service problems
offered by the publisher OSS.

Description

1. The subscriber OSS connects to the notification service and


sends an unsubscribe request to the notification service.
2. The notification service receives the unsubscribe request.
3. The notification service removes the subscription information and
notifies the subscriber OSS.
4. The subscriber OSS receives the unsubscribe response.

Ends When

In case of success:
The subscriber OSS receives a positive acknowledgement to
the unsubscribe request to the notification service.
In case of failure:
The notification service returns an error.

Post-Conditions

In case of success:
The subscriber OSS receives a positive acknowledgement to
the unsubscribe request and the subscription is removed. The
subscriber OSS will no longer receive the Service Problem
notifications published by the publisher OSS unless it re-

TMF522, Version 1.5

TM Forum 2011

Page 74 of 88

Service Problem Management Business Agreement


subscribes.
In case of failure:
The subscriber OSS receives a negative acknowledgement to
the unsubscribe request and the subscription remains intact.

4.4

Exceptions

1. In case of the notification service unavailable, the Notification


Service Exception shall be raised and the operation is not fulfilled.

Traceability

R_TMF522_II_0029

Service Problem Retrieval


Use Case Id

UC_TMF522_0019

Use Case Name

Retrieve active service problems

Summary

The requesting OSS retrieves all or some of the active service


problems from the target OSS. The request may be filtered. The target
OSS returns the service problems meeting the filters.

Actor(s)

The requesting OSS

Pre-Conditions

The OSSs involved in the use case have started (refer to


UC_TMF518_FMW_0001 and UC_TMF518_FMW_0002 in
TMF518_FMW).

Begins When

The requesting OSS sends a retrieval request to the target OSS to


retrieve active service problems. The request may be filtered.

Description

1. The requesting OSS sends an active Service Problem retrieval


request to the target OSS.

Note:
The request shall be able to filter on any Service Problem attributes
and It should at least support some typical queries, please refer
to R_TMF522_II_0030 for details.
2. The target OSS checks the request and associated filter for
validity.
3. The target OSS prepares the requested active Service Problems
list and returns them.
Note:

TMF522, Version 1.5

We may use the iterator pattern. In this pattern, the


first batch of active Service Problems is returned for
the first request. The requesting OSS then requested
the next batch of active Service Problems and so on
until all active Service Problems has been sent.

TM Forum 2011

Page 75 of 88

Service Problem Management Business Agreement

We can also return the active Service Problems in


single request.

4. The requesting OSS receives the response.


Ends When

In case of success:
The requesting OSS has retrieved the active service
problems.
In case of failure:
The requesting OSS receives an exception.

Post-Conditions

In case of success:
The requesting OSS has all the requested active service
problems information from the target OSS.
In case of failure:
The requesting OSS does not have the requested active
Service Problem information from the target OSS.

Exceptions

1. In case the operation is not implemented or supported by the


target OSS, the Not Implemented exception shall be raised and
the operation will not be fulfilled.
2. In case the request is invalid, an Invalid Input exception shall be
raised and the operation will not be fulfilled.
3. In case the authentication of the requesting OSS is not validated
by the target OSS, an Access Denied exception shall be raised
and the operation will not be fulfilled.
4. If the target OSS is unable to accomplish the operation, due to a
lack of internal resources, an Unable To Comply exception is
raised and the Target OSS stops serving the request.
5. If the target OSS is unable to accomplish the operation, due to
any other internal error, an Internal Error exception is raised and
the Target OSS stops serving the request

Traceability

R_TMF522_II_0030

Use Case Id

UC_TMF522_0020

Use Case Name

Retrieve the historical service problems

Summary

The requesting OSS retrieves historical service problems in the target


OSS. The request may be filtered. The target OSS returns the service
problems meeting the filters.

Actor(s)

The requesting OSS

Pre-Conditions

The OSSs involved in the use case have started (refer to


UC_TMF518_FMW_0001 and UC_TMF518_FMW_0002 in
TMF518_FMW).

TMF522, Version 1.5

TM Forum 2011

Page 76 of 88

Service Problem Management Business Agreement

Begins When

The requesting OSS sends a request to the target OSS to retrieve the
historical service problems

Description

1. The requesting OSS sends an historical service problems retrieval


request to the target OSS.

Note:
The request shall be able to filter on any problem attributes, and it
should at least support some typical queries. Please refer
to R_TMF522_II_0031 for details.

2. The target OSS checks the request and associated filter for
validity.
3. The target OSS prepares the requested historical service
problems list and returns them.
Note:

We may use the iterator pattern. In this pattern, the first


batch of historical service problems is returned for the first
request. The requesting OSS then requests the next
batch of historical service problems and so on until all of
them has been sent.

We can also return the historical service problems in


single request.

4. The requesting OSS receives the response.


Ends When

In case of success:
The requesting OSS has retrieved the historical service
problems.
In case of failure:

Post-Conditions

The requesting OSS receives an exception.


In case of success:
The requesting OSS has all the requested historical service
problem information from the target OSS.
In case of failure:
The requesting OSS has no or only part of the requested
historical Service Problem information from the target OSS.

Exceptions

1. In case the operation is not implemented or supported by the


target OSS, the Not Implemented exception shall be raised and
the operation will not be fulfilled.
2. In case the request is invalid, an Invalid Input exception shall be
raised and the operation will not be fulfilled.
3. In case the authentication of the requesting OSS is not validated
by the target OSS, an Access Denied exception shall be raised

TMF522, Version 1.5

TM Forum 2011

Page 77 of 88

Service Problem Management Business Agreement


and the operation will not be fulfilled.
4. If the target OSS is unable to accomplish the operation, due to a
lack of internal resources, an Unable To Comply exception is
raised and the Target OSS stops serving the request.
5. If the target OSS is unable to accomplish the operation, due to
any other internal error, an Internal Error exception is raised and
the Target OSS stops serving the request.
Traceability

R_TMF522_II_0031

Use Case Id

UC_TMF522_0021

Use Case Name

Count the active service problems

Summary

The requesting OSS requests the count of all the active service
problems meeting some filters from the target OSS. The target OSS
returns the count.

Actor(s)

The requesting OSS

Pre-Conditions

The OSSs involved in the use case have started (refer to


UC_TMF518_FMW_0001 and UC_TMF518_FMW_0002 in
TMF518_FMW).

Begins When

The requesting OSS sends a request to the target OSS to count the
number of active service problems.

Description

1. The requesting OSS sends an active service problems count


request to the target OSS.
Note:
The request shall be able to filter on any problem attributes and it
should at least support some typical queries. Please refer
to R_TMF522_II_0032 for details.
2. The target OSS checks the request.
3. The target OSS counts the active service problems and returns
the number.
Note:
This is only an estimate because as the requesting OSS is attempting
to make a count some service alarms could be cleared (and deleted)
and others newly created.
4. The requesting OSS receives the response.

Ends When

In case of success:
The requesting OSS has got the number of active service
problems meeting the specified filter(s).
In case of failure:

Post-Conditions

TMF522, Version 1.5

The requesting OSS receives an exception.


In case of success:

TM Forum 2011

Page 78 of 88

Service Problem Management Business Agreement


The requesting OSS has the number of the active service
problems meeting the specified filter(s) from the target OSS.
In case of failure:
The requesting OSS does not have the number of the active
service problems meeting the specified filter(s) from the target
OSS.
Exceptions

1. In case the operation is not implemented or supported by the


target OSS, a Not Implemented exception shall be raised and the
operation will not be fulfilled.
2. In case the request is invalid, an Invalid Input exception shall be
raised and the operation will not be fulfilled.
3. In case the authentication of the requesting OSS is not validated
by the target OSS, an Access Denied exception shall be raised
and the operation will not be fulfilled.
4. If the target OSS is unable to accomplish the operation, due to a
lack of internal resources, an Unable To Comply exception is
raised and the Target OSS stops serving the request.
5. If the target OSS is unable to accomplish the operation, due to
any other internal error, an Internal Error exception is raised and
the Target OSS stops serving the request.

Traceability

TMF522, Version 1.5

R_TMF522_II_0032

TM Forum 2011

Page 79 of 88

Service Problem Management Business Agreement

5 Traceability Matrices
5.1

Use Cases Requirements


Matrix
Table 5-1. Use Cases Requirements Matrix

Requirement Id

Use Case Name

Use Case Id

R_TMF522_I_0001

Create a service problem

UC_TMF522_0005

R_TMF522_I_0002

Create a parent service problem


that either replaces or just
references several child service
problems

UC_TMF522_0016
UC_TMF522_0005

Create a service problem


R_TMF522_I_0003

Delete an historical service


problem

UC_TMF522_0015
UC_TMF522_0004

Send an Object Deletion


notification when an historical
Service Problem has been
removed (optional)
R_TMF522_I_0004

Change priority of a service


problem
Change escalation level

UC_TMF522_0008
UC_TMF522_0007
UC_TMF522_0005

Create a service problem


R_TMF522_I_0005

Create a service problem

UC_TMF522_0005

R_TMF522_I_0006

Create a parent service problem


that either replaces or just
references several child service
problems

UC_TMF522_0016
UC_TMF522_0005

Create a service problem


R_TMF522_I_0007

Create a service problem

UC_TMF522_0005

R_TMF522_I_0008

Unclear a service problem

UC_TMF522_0012

Clear a service problem

UC_TMF522_0011

Create a service problem

UC_TMF522_0005

Un-acknowledges a service
problem

UC_TMF522_0014

R_TMF522_I_0009

Acknowledges a service problem

UC_TMF522_0013
UC_TMF522_0005

Create a service problem

TMF522, Version 1.5

TM Forum 2011

Page 80 of 88

Service Problem Management Business Agreement

R_TMF522_I_0010

Un-acknowledges a service
problem
Acknowledges a service problem
Unclear a service problem
Clear a service problem

UC_TMF522_0014
UC_TMF522_0013
UC_TMF522_0012
UC_TMF522_0011
UC_TMF522_0005

Create a service problem


R_TMF522_I_0011

Create a service problem

UC_TMF522_0005

R_TMF522_I_0012

Create a service problem

UC_TMF522_0005

R_TMF522_II_0013

Create a parent service problem


that either replaces or just
references several child service
problems

UC_TMF522_0016
UC_TMF522_0001

Send an object creation


notification when a service
problem has been created
R_TMF522_II_0014

Change priority of a service


problem

UC_TMF522_0008
UC_TMF522_0002

Send an Attribute Value Change


(AVC) notification or State
Change (SC) notification when a
service problem has been
updated
R_TMF522_II_0015

Send a State Change notification


when a service problem has
been cleared

UC_TMF522_0003

R_TMF522_II_0016

Send an Object Deletion


notification when an historical
Service Problem has been
removed (optional)

UC_TMF522_0004

R_TMF522_II_0017

Create a parent service problem


that either replaces or just
references several child service
problems

UC_TMF522_0016
UC_TMF522_0005

Create a service problem


R_TMF522_II_0018

Update a service problem

UC_TMF522_0006

R_TMF522_II_0019

Add a comment to a service


problem

UC_TMF522_0009

R_TMF522_II_0020

Add a new correlation or


removing one.

UC_TMF522_0010

R_TMF522_II_0021

Clear a service problem

UC_TMF522_0011

R_TMF522_II_0022

Unclear a service problem

UC_TMF522_0012

R_TMF522_II_0023

Acknowledges a service problem

UC_TMF522_0013

TMF522, Version 1.5

TM Forum 2011

Page 81 of 88

Service Problem Management Business Agreement

R_TMF522_II_0024

Un-acknowledges a service
problem

UC_TMF522_0014

R_TMF522_II_0025

Delete an historical service


problem

UC_TMF522_0015

R_TMF522_II_0026

Delete an historical service


problem

UC_TMF522_0015
UC_TMF522_0014

Un-acknowledges a service
problem

UC_TMF522_0013

Acknowledges a service problem

UC_TMF522_0012
UC_TMF522_0011

Unclear a service problem

UC_TMF522_0005

Clear a service problem


Create a service problem
R_TMF522_II_0027

Subscribe to Service Problems

UC_TMF522_0017

R_TMF522_II_0028

Subscribe to Service Problems

UC_TMF522_0017

R_TMF522_II_0029

Un-subscribes to Service
Problems

UC_TMF522_0018

R_TMF522_II_0030

Retrieve active service problems

UC_TMF522_0019

R_TMF522_II_0031

Retrieve the historical service


problems

UC_TMF522_0020

R_TMF522_II_0032

Count the active service


problems

UC_TMF522_0021

5.2

Requirements Use Cases


Matrix
Table 5-2. Requirements - Use Cases Matrix
Use Case Id

Use Case Name

Requirements

UC_TMF522_0001

Send an object creation notification


when a service problem has been
created

R_TMF522_II_0013

UC_TMF522_0002

Send an Attribute Value Change


(AVC) notification or State Change
(SC) notification when a service
problem has been updated

R_TMF522_II_0014

TMF522, Version 1.5

TM Forum 2011

Page 82 of 88

Service Problem Management Business Agreement

UC_TMF522_0003

Send a State Change notification


when a service problem has been
cleared

R_TMF522_II_0015

UC_TMF522_0004

Send an Object Deletion notification


when an historical Service Problem
has been removed (optional)

R_TMF522_I_0003, R_TMF522_II_00
16

UC_TMF522_0005

Create a service problem

R_TMF522_I_0001, R_TMF522_I_000
2, R_TMF522_I_0004, R_TMF522_I_0
005, R_TMF522_I_0006, R_TMF522_I
_0007, R_TMF522_I_0008, R_TMF52
2_I_0009, R_TMF522_I_0010, R_TMF
522_I_0011, R_TMF522_I_0012, R_T
MF522_II_0017,R_TMF522_II_0026

UC_TMF522_0006

Update a service problem

R_TMF522_II_0018

UC_TMF522_0007

Change escalation level

R_TMF522_I_0004

UC_TMF522_0008

Change priority of a service problem

R_TMF522_I_0004,R_TMF522_II_001
4

UC_TMF522_0009

Add a comment to a service problem

R_TMF522_II_0019

UC_TMF522_0010

Add a new correlation or removing


one.

R_TMF522_II_0020

UC_TMF522_0011

Clear a service problem

R_TMF522_I_0008, R_TMF522_I_001
0, R_TMF522_II_0021,R_TMF522_II_
0026

UC_TMF522_0012

Unclear a service problem

R_TMF522_I_0008,R_TMF522_I_001
0,R_TMF522_II_0022,R_TMF522_II_0
026

UC_TMF522_0013

Acknowledges a service problem

R_TMF522_I_0009,R_TMF522_I_001
0,R_TMF522_II_0023,R_TMF522_II_0
026

UC_TMF522_0014

Un-acknowledges a service problem

R_TMF522_I_0009, R_TMF522_I_001
0, R_TMF522_II_0024,R_TMF522_II_
0026

UC_TMF522_0015

Delete an historical service problem

R_TMF522_I_0003,R_TMF522_II_002
5,R_TMF522_II_0026

UC_TMF522_0016

Create a parent service problem that


either replaces or just references
several child service problems

R_TMF522_I_0002,R_TMF522_I_000
6, R_TMF522_II_0013, R_TMF522_II_
0017

UC_TMF522_0017

Subscribe to Service Problems

R_TMF522_II_0027, R_TMF522_II_00
28

UC_TMF522_0018

Un-subscribes to Service Problems

R_TMF522_II_0029

UC_TMF522_0019

Retrieve active service problems

R_TMF522_II_0030

UC_TMF522_0020

Retrieve the historical service


problems

R_TMF522_II_0031

TMF522, Version 1.5

TM Forum 2011

Page 83 of 88

Service Problem Management Business Agreement

UC_TMF522_0021

TMF522, Version 1.5

Count the active service problems

TM Forum 2011

R_TMF522_II_0032

Page 84 of 88

Service Problem Management Business Agreement

6 References
6.1

References

[ATIS-OUTAGE] ATIS Standard Outage Classification (ATIS-0100012.2007)

6.2

IPR Releases and Patent


Disclosure

There are no known patent claims concerning the material in this document. If any company has a patent
claim on this material, they should make the claim known to the TM Forum immediately.

TMF522, Version 1.5

TM Forum 2011

Page 85 of 88

Service Problem Management Business Agreement

7 Administrative Appendix
This Appendix provides additional background material about the TM Forum and this document.

7.1

About this document

This document has been generated from the SD0-3_mTOPTemplate_BA.dot Word template, which itself
is based on Version 6.0 of the TMF 402, BA Template.

7.2

Use and Extension of a TM


Forum Business Agreement

This document defines the business problem and requirement model for <<problem area>>. The
Business Agreement is used to gain consensus on the business requirements for exchanging information
among processes and systems in order to solve a specific business problem. The Business Agreement
should feed the development of Information Agreement(s), which is a technology-neutral model of one or
more interfaces. While the Business Agreement contains sufficient information to be a stand alone
document, it is better read together with the Information Agreement document TMF 612_SPM when the
Information Agreement is available. Reviewing the two documents together helps in gaining a full
understanding of how the technology neutral information model solution is defined for this requirement
model. An initial Business Agreement may only deal with a subset of the requirements. It is acceptable for
subsequent issues of the document to add additional requirements not addressed by earlier releases of
the BA. Business Agreements are the basis for requirement traceability for information models.
It is expected that this document will be used:

As the foundation for a TM Forum Information Agreement(s)

To facilitate requirement agreement between Service Providers and vendors

As input to a service Providers Request for Information / Request for Proposal (RFI/RFPRFX)

As input for vendors developing COTS products

As a source of requirements for other bodies working in this area

7.3

Document History
Version Number

Date Modified

Modified by:

Description of
changes

1.0

May 08

Stephen Fratini,
Marc Flauw and JinZhai Zhang

Internal team draft


many changes made
at this point

TMF522, Version 1.5

TM Forum 2011

Page 86 of 88

Service Problem Management Business Agreement

1.1

June 08

Stephen Fratini,
Marc Flauw and JinZhai Zhang

Updates based on
TM Forum internal
and public review

1.2

13 October 08

Stephen Fratini

Corrected several
cross references
Added list of
contributors
Populated Section
1.3 concerning
Terminology

7.4

1.3

25 March 2009

Marc Flauw

Add title to
requirements to align
to new template

1.4

18 November 2010

Alicja Kawecki

Minor cosmetic
format/style
corrections prior to
web posting and ME

1.5

16 May 2011

Alicja Kawecki

Updated to reflect
TM Forum Approved
status

Company Contact Details


Company

Team Member Representative

Telcordia Technologies

Stephen Fratini
sfratini@telcordia.com

7.5

Acknowledgments

This document was prepared by the members of the Resource and Service Assurance team of the TM
Forum Interface Program.
The editors of this document are as follows:

Stephen Fratini, Telcordia, sfratini@telcordia.com, co-editor

Marc Flauw, HP, marc.flauw@hp.com, co-editor

Jin-Zhai Zhang, HP, jinzhai.zhang@hp.com, co-editor

Additional input was provided by the following people:

John Wilmes, Progress Software

John Reilly, TM Forum

Amit Gal, TTI Telecom

TMF522, Version 1.5

TM Forum 2011

Page 87 of 88

Service Problem Management Business Agreement

Pavel Hardak, TTI Telecom

James Lyu, Chunghwa Telecom

Wudy Wu, Chunghwa Telecom

Chris Ramsden, Nortel

Nigel Davis, Nortel

Yong-Ping Tang, HP

TMF522, Version 1.5

TM Forum 2011

Page 88 of 88

Das könnte Ihnen auch gefallen