Beruflich Dokumente
Kultur Dokumente
Business Agreement
TMF522
TM Forum Approved Version 1.5
May, 2011
TM Forum 2011
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.
TM Forum 2011
Page 2 of 88
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
1.3
2.1.1
2.1.2
2.2
2.2.1
Reactive .................................................................................................................................. 14
2.2.2
Proactive ................................................................................................................................. 21
2.2.3
Predictive ................................................................................................................................. 27
2.3
3
Benefits ......................................................................................................................................... 32
Business Processes............................................................................................................................. 34
3.1
3.2
3.2.1
3.3
3.3.1
3.3.2
3.3.3
3.3.4
3.4
3.5
3.6
TM Forum 2011
Page 3 of 88
4.2
4.3
4.4
5.2
References ........................................................................................................................................... 85
6.1
References ................................................................................................................................... 85
6.2
7.2
7.3
7.4
7.5
Acknowledgments......................................................................................................................... 87
TM Forum 2011
Page 4 of 88
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
TM Forum 2011
Page 5 of 88
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
TM Forum 2011
Page 6 of 88
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
TM Forum 2011
Page 7 of 88
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
TM Forum 2011
Page 8 of 88
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 control, i.e., the creation, modification and deletion of service problems
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.
TM Forum 2011
Page 9 of 88
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
Section 2 defines the scope of the project and also provides business scenarios.
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.
TM Forum 2011
Page 10 of 88
1.3
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.
TM Forum 2011
Page 11 of 88
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:
Correlation & Root Cause Analysis (as this impacts the interface to be defined)
Note that the focus is on service problems and not on trouble tickets (as this item is out of scope for this
interface).
TM Forum 2011
Page 12 of 88
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:
TM Forum 2011
Page 13 of 88
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
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
TM Forum 2011
Page 14 of 88
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.
TM Forum 2011
Page 15 of 88
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).
TM Forum 2011
Page 16 of 88
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
TM Forum 2011
Page 17 of 88
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.
TM Forum 2011
Page 18 of 88
Management Interface
(out of scope)
Customer Problem
Resolution (CPR) OSS
Management Interface
(possibly in scope)
Service Capacity
Management (SCM)
OSS
IP Performance
Management (IPM) OSS
Transport Capacity
Management (TCM)
OSS
IP Network
SDH Network
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.
TM Forum 2011
Page 19 of 88
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
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.
TM Forum 2011
Page 21 of 88
TT management (out
of scope)
Service Quality
Management (SQM) OSS
Resource Trouble
Management (RTM) 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)
TM Forum 2011
Page 22 of 88
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.
TM Forum 2011
Page 23 of 88
TT management (out
of scope)
Service Quality
Management (SQM) OSS
Resource Trouble
Management (RTM) OSS
EMS #1
EMS #2
Subnetwork #1
EMS #3
Subnetwork #3
Subnetwork #2
Management Interface
(out of scope)
Management Interface
(in scope)
Severed Link
TM Forum 2011
Page 24 of 88
TM Forum 2011
Page 25 of 88
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
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
TM Forum 2011
Page 26 of 88
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.
TM Forum 2011
Page 27 of 88
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
TM Forum 2011
Page 28 of 88
TM Forum 2011
Page 29 of 88
Customer
Trouble
Ticketing
(CTT) OSS
Service
Quality
Management
(SQM) OSS
Management Interface
(in scope)
Service
Trouble
Ticketing
(STT) OSS
Management Interface
(out of scope)
TM Forum 2011
Page 30 of 88
TM Forum 2011
Page 31 of 88
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
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:
TM Forum 2011
Page 32 of 88
Key element
Benefit
TM Forum 2011
Page 33 of 88
3 Business Processes
3.1
Business Requirements
None identified
3.2
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 is not similar to a TT
R_TMF522_I_0001
Source
R_TMF522_I_0002
R_TMF522_I_0003
TM Forum 2011
Page 34 of 88
R_TMF522_I_0004
In the ATIS Service Outage document [ATISOUTAGE] , the What Category corresponds
to this attribute and the values can be used as
possible values.
TM Forum 2011
Page 35 of 88
Comments.
Source
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
R_TMF522_I_0006
Root Cause
A Service Problem can have 1 or more root causes.
TM Forum 2011
Page 36 of 88
A problem includes:
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.
Source/Definition
Bandwidth reduction
Congestion
Indeterminate
Lost redundancy
Performance degraded
Threshold crossed
Timeout expired
TM Forum 2011
Page 37 of 88
Denial of service
TMF522
Maximum Time Interval Errors (MTIE) and Frequency errors may
also cause input signal faults when exceeding the set thresholds,
as set in nanoseconds.
TMF522
A non-redundant output module failed. This is caused by a bad
card being inserted into the system.
Out of service
TMF522
Failure to activate or provision the service
Manual Operation
TMF522
Manual operator intervention was performed
TMF522
Failure of a protecting resource, prime still functioning
TMF522
Switch to protection resource due to a failure in prime
TMF522
Customer experience a degradation in service or is likely to
experience such a degradation
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
TM Forum 2011
Page 38 of 88
Source
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
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
R_TMF522_I_0010
Tracking records
Timestamps of clearance and acknowledgements should be
kept as tracking records. The fields are:
TM Forum 2011
Page 39 of 88
R_TMF522_I_0011
Source
R_TMF522_I_0012
Source
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
Source
TM Forum 2011
Page 40 of 88
R_TMF522_II_0014
addition of comments
acknowledgement or un-acknowledgement
Update of attributes.
Source
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
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
Source
R_TMF522_II_0018
Source
R_TMF522_II_0019
TM Forum 2011
Page 41 of 88
R_TMF522_II_0020
Source
R_TMF522_II_0021
Source
R_TMF522_II_0022
Source
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
Source
R_TMF522_II_0024
Source
R_TMF522_II_0025
TM Forum 2011
Page 42 of 88
R_TMF522_II_0026
Source
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
TM Forum 2011
Page 43 of 88
3.3.3
Source
R_TMF522_II_0028
Source
Only a single filter is allowed. To augment a filter, it will have to be deleted, edited and reapplied.
R_TMF522_II_0029
Source
3.3.4
Source
TM Forum 2011
Page 44 of 88
R_TMF522_II_0031
Source
R_TMF522_II_0032
Source
3.4
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.
TM Forum 2011
Page 45 of 88
ID
Name
General Description
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
Unable To Comply
Access Denied
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
10
Unable To Notify
ID
Name
General Description
Invalid Selector
The publisher OSS or Subscriber OSS attempt to give a notification service provider
a message selector with invalid syntax.
Unable To Deliver
TM Forum 2011
Page 46 of 88
3.5
3.6
Category V: System
Administration Requirements
TM Forum 2011
Page 47 of 88
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
Use Case Id
UC_TMF522_0001
Summary
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
Description
Ends When
In case of success:
The subscriber OSSs have received the notification in a predefined time.
TM Forum 2011
Page 48 of 88
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
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
Summary
Actor(s)
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
Description
TM Forum 2011
Page 49 of 88
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
Traceability
R_TMF522_II_0014
Use Case Id
UC_TMF522_0003
Summary
Actor(s)
TM Forum 2011
Page 50 of 88
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
Description
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
Traceability
R_TMF522_II_0015
Use Case Id
UC_TMF522_0004
Summary
Actor(s)
Pre-Conditions
1. The OSSs involved in the use case have started (refer to use
TM Forum 2011
Page 51 of 88
Description
Ends When
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
Traceability
4.2
R_TMF522_I_0003, R_TMF522_II_0016
UC_TMF522_0005
Use Case
Name
TM Forum 2011
Page 52 of 88
Summary
The requesting OSS forwards the problem creation request to the target OSS. The target OSS crea
Actor(s)
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:
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
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
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
Use Case Id
UC_TMF522_0006
Summary
Actor(s)
Pre-Conditions
Begins When
Description
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.
TM Forum 2011
Page 54 of 88
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
Traceability
R_TMF522_II_0018
Use Case Id
UC_TMF522_0007
Summary
TM Forum 2011
Page 55 of 88
Pre-Conditions
Begins When
Description
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
Page 56 of 88
Traceability
R_TMF522_I_0004
Use Case Id
UC_TMF522_0008
Summary
Actor(s)
Pre-Conditions
Begins When
Description
TM Forum 2011
Page 57 of 88
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
TM Forum 2011
Page 58 of 88
R_TMF522_I_0004,R_TMF522_II_0014
Use Case Id
UC_TMF522_0009
Summary
Actor(s)
Pre-Conditions
Begins When
Description
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
TM Forum 2011
Page 59 of 88
Traceability
R_TMF522_II_0019
Use Case Id
UC_TMF522_0010
Summary
Actor(s)
Pre-Conditions
TM Forum 2011
Page 60 of 88
Begins When
Description
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
TM Forum 2011
Page 61 of 88
R_TMF522_II_0020
Use Case
Id
UC_TMF522_0011
Use Case
Name
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)
PreConditions
Begins
When
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:
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
TM Forum 2011
Page 62 of 88
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.
TM Forum 2011
Page 63 of 88
Use Case Id
UC_TMF522_0012
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)
Pre-Conditions
Begins When
Description
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:
TM Forum 2011
Page 64 of 88
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
Traceability
R_TMF522_I_0008,R_TMF522_I_0010,R_TMF522_II_0022,R_TMF52
2_II_0026
Use Case Id
UC_TMF522_0013
TM Forum 2011
Page 65 of 88
Summary
Actor(s)
Pre-Conditions
Begins When
Description
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.
TM Forum 2011
Page 66 of 88
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
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
TM Forum 2011
Page 67 of 88
PreConditions
Begins
When
The requesting OSS tries to un-acknowledge a Service Problem in the target OSS
Description
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.
TM Forum 2011
Page 68 of 88
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
Use Case Id
UC_TMF522_0015
Summary
Actor(s)
Pre-Conditions
Begins When
Description
TM Forum 2011
Page 69 of 88
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
TM Forum 2011
Page 70 of 88
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)
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
TM Forum 2011
Page 71 of 88
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
TM Forum 2011
Page 72 of 88
4.3
UC_TMF522_0017
Summary
Actor(s)
Pre-Conditions
Begins When
Description
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
TM Forum 2011
Page 73 of 88
Traceability
R_TMF522_II_0027, R_TMF522_II_0028
Use Case Id
UC_TMF522_0018
Summary
Actor(s)
Pre-Conditions
Begins When
Description
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-
TM Forum 2011
Page 74 of 88
4.4
Exceptions
Traceability
R_TMF522_II_0029
UC_TMF522_0019
Summary
Actor(s)
Pre-Conditions
Begins When
Description
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:
TM Forum 2011
Page 75 of 88
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
Traceability
R_TMF522_II_0030
Use Case Id
UC_TMF522_0020
Summary
Actor(s)
Pre-Conditions
TM Forum 2011
Page 76 of 88
Begins When
The requesting OSS sends a request to the target OSS to retrieve the
historical service problems
Description
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:
In case of success:
The requesting OSS has retrieved the historical service
problems.
In case of failure:
Post-Conditions
Exceptions
TM Forum 2011
Page 77 of 88
R_TMF522_II_0031
Use Case Id
UC_TMF522_0021
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)
Pre-Conditions
Begins When
The requesting OSS sends a request to the target OSS to count the
number of active service problems.
Description
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
TM Forum 2011
Page 78 of 88
Traceability
R_TMF522_II_0032
TM Forum 2011
Page 79 of 88
5 Traceability Matrices
5.1
Requirement Id
Use Case Id
R_TMF522_I_0001
UC_TMF522_0005
R_TMF522_I_0002
UC_TMF522_0016
UC_TMF522_0005
UC_TMF522_0015
UC_TMF522_0004
UC_TMF522_0008
UC_TMF522_0007
UC_TMF522_0005
UC_TMF522_0005
R_TMF522_I_0006
UC_TMF522_0016
UC_TMF522_0005
UC_TMF522_0005
R_TMF522_I_0008
UC_TMF522_0012
UC_TMF522_0011
UC_TMF522_0005
Un-acknowledges a service
problem
UC_TMF522_0014
R_TMF522_I_0009
UC_TMF522_0013
UC_TMF522_0005
TM Forum 2011
Page 80 of 88
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
UC_TMF522_0005
R_TMF522_I_0012
UC_TMF522_0005
R_TMF522_II_0013
UC_TMF522_0016
UC_TMF522_0001
UC_TMF522_0008
UC_TMF522_0002
UC_TMF522_0003
R_TMF522_II_0016
UC_TMF522_0004
R_TMF522_II_0017
UC_TMF522_0016
UC_TMF522_0005
UC_TMF522_0006
R_TMF522_II_0019
UC_TMF522_0009
R_TMF522_II_0020
UC_TMF522_0010
R_TMF522_II_0021
UC_TMF522_0011
R_TMF522_II_0022
UC_TMF522_0012
R_TMF522_II_0023
UC_TMF522_0013
TM Forum 2011
Page 81 of 88
R_TMF522_II_0024
Un-acknowledges a service
problem
UC_TMF522_0014
R_TMF522_II_0025
UC_TMF522_0015
R_TMF522_II_0026
UC_TMF522_0015
UC_TMF522_0014
Un-acknowledges a service
problem
UC_TMF522_0013
UC_TMF522_0012
UC_TMF522_0011
UC_TMF522_0005
UC_TMF522_0017
R_TMF522_II_0028
UC_TMF522_0017
R_TMF522_II_0029
Un-subscribes to Service
Problems
UC_TMF522_0018
R_TMF522_II_0030
UC_TMF522_0019
R_TMF522_II_0031
UC_TMF522_0020
R_TMF522_II_0032
UC_TMF522_0021
5.2
Requirements
UC_TMF522_0001
R_TMF522_II_0013
UC_TMF522_0002
R_TMF522_II_0014
TM Forum 2011
Page 82 of 88
UC_TMF522_0003
R_TMF522_II_0015
UC_TMF522_0004
R_TMF522_I_0003, R_TMF522_II_00
16
UC_TMF522_0005
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
R_TMF522_II_0018
UC_TMF522_0007
R_TMF522_I_0004
UC_TMF522_0008
R_TMF522_I_0004,R_TMF522_II_001
4
UC_TMF522_0009
R_TMF522_II_0019
UC_TMF522_0010
R_TMF522_II_0020
UC_TMF522_0011
R_TMF522_I_0008, R_TMF522_I_001
0, R_TMF522_II_0021,R_TMF522_II_
0026
UC_TMF522_0012
R_TMF522_I_0008,R_TMF522_I_001
0,R_TMF522_II_0022,R_TMF522_II_0
026
UC_TMF522_0013
R_TMF522_I_0009,R_TMF522_I_001
0,R_TMF522_II_0023,R_TMF522_II_0
026
UC_TMF522_0014
R_TMF522_I_0009, R_TMF522_I_001
0, R_TMF522_II_0024,R_TMF522_II_
0026
UC_TMF522_0015
R_TMF522_I_0003,R_TMF522_II_002
5,R_TMF522_II_0026
UC_TMF522_0016
R_TMF522_I_0002,R_TMF522_I_000
6, R_TMF522_II_0013, R_TMF522_II_
0017
UC_TMF522_0017
R_TMF522_II_0027, R_TMF522_II_00
28
UC_TMF522_0018
R_TMF522_II_0029
UC_TMF522_0019
R_TMF522_II_0030
UC_TMF522_0020
R_TMF522_II_0031
TM Forum 2011
Page 83 of 88
UC_TMF522_0021
TM Forum 2011
R_TMF522_II_0032
Page 84 of 88
6 References
6.1
References
6.2
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.
TM Forum 2011
Page 85 of 88
7 Administrative Appendix
This Appendix provides additional background material about the TM Forum and this document.
7.1
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
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 input to a service Providers Request for Information / Request for Proposal (RFI/RFPRFX)
7.3
Document History
Version Number
Date Modified
Modified by:
Description of
changes
1.0
May 08
Stephen Fratini,
Marc Flauw and JinZhai Zhang
TM Forum 2011
Page 86 of 88
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
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:
TM Forum 2011
Page 87 of 88
Yong-Ping Tang, HP
TM Forum 2011
Page 88 of 88