Frameworx 12 Implementation (Managed Service) Conformance Certification Report

(1)

Frameworx 12

Implementation (Managed Service)

Conformance Certification Report

Nokia Solutions & Networks

Service Management & MS

Operations Lifecycle Framework

(SMC and NOC) Version 2.0

February 2014

Version 1.0

(2)

List of Tables

Table 4.1 Level 2: 1.1.2.3 - Service Problem Management Conformance Scores ... 25

Table 4.2 Level 2: 1.1.2.4 - Service Quality Management Conformance Scores ... 41

Table 4.3 Level 2: 1.1.3.1 - RM&O Support & Readiness Conformance Scores ... 51

Table 4.4 Level 2: 1.1.3.2 - Resource Provisioning Conformance Scores ... 67

Table 4.5 Level 2: 1.1.3.3 - Resource Trouble Management Conformance Scores ... 84

Table 4.6 Level 2: 1.1.3.4 – Resource Performance Management Conformance Scores ... 102

Table 4.7 Level 2: 1.1.3.5 - Resource Data Collection & Distribution Conformance Scores ... 111

Table 4.8 Level 2: 1.2.3.2 - Resource Capability Delivery Conformance Scores ... 123

Table 6.1 – Business Process Framework: Detailed Conformance Results ... 128

List of Figures

Figure 2-1 SMC Operation Life Cycle Overview Diagram ... 7

Figure 2-2 Business Process Framework coverage ... 8

Figure 3-1 - Operations Level 2 process coverage for NSN’s Service Management & MS Operations Lifecycle Framework Assessment ... 11

Figure 3-2 - Level 3 process coverage for NSN’s Service Management & MS Operations Lifecycle Framework Assessment ... 12

Figure 3-3 - NSN Service Management & MS Operations Lifecycle Framework Footprint with Scope for eTOM Assessment ... 13

Figure 6-1 - TM Forum Business Process Framework: Conformance Scoring Rules ... 125

Figure 6-2 – Business Process Framework: Conformance Result Summary [1/2] ... 126

Figure 6-3 - Business Process Framework: Conformance Result Summary [2/2] ... 127

(5)

1 Introduction

1.1 Executive Summary

This document provides details of NSN’s self-assessment and TM Forum’s Conformance Assessment

of NSN Service Management & MS Operations Lifecycle Framework implementation, against the

following Frameworx 12 components:



Business Process Framework Version 12

The assessment included a review of:



The methodology approach to process modeling against the TM Forum’s Business Process

Framework Release 12 according to the specific processes submitted in scope for the

Assessment.

(6)

2 Product Functionality/Capability Overview

2.1 NSN Service Management & Managed Services Operations lifecycle

Framework – Overview

Service Management & MS Operations include managing the Service lifecycle and supporting

Customer lifecycle by focusing on the major components of service management layer and

Customer Experience Management (CEM) Operations through Service Management Center

(SMC) and Network Operation Center (NOC). In this managed services offering NSN covers the

entire lifecycle of mobile broadband services running on an operator’s multi-vendor,

heterogeneous networks, including service design, launch and service assurance. Intelligent

service models provide an integrated view of all services across the Evolved Packet Core (EPC),

transmission and radio networks significantly enhancing service quality and subscriber

experience.

The major focus from MS point of view is to deliver:

 Network Operations in local delivery model

 Network Operations through centralized delivery model

 Field Maintenance

 Network Performance Management

 Service Design ( Service Modeling and design engineering)

 Service Fulfillment (including Service inventory, Service provisioning and activation)

 Service Assurance (including Service Problem and Service Quality Management)

 Service Profitability Management

 Customer Experience Insights & Business Analytics Support

 Customer Care Insights and Proactive Support

 Marketing Insights and Support

 Governance across Customer, Service and Resource(Network and support functions)

layer

(7)

Figure 2-1 SMC Operation Life Cycle Overview Diagram

The NSN Process Framework Utilizes eTOM, ITIL and the experience gained by delivering more than

200 global Managed Services Projects using the best of the tools, resources as well as Centralized

operations though Global Delivery Centers.

Target of Process Framework

 Process framework allows MS Portfolio mapping

 Process framework are based on eTOM framework, best practices from ITIL and NSN

operations model

 Service delivery processes based on the framework follows 80/20* rule

 Service delivery processes are the basis for interaction between

• GNOC and local NOCs

• Customer Operations (CRM, Marketing) and Service Operations(SMC)

• Service Operations (SMC) and Network Operations (NOC)

• Service Operations and Support functions Operations

• Service Operations and Field Management

• Service Operations and Enterprise Management

• Service Operations and New Product Development

• NOCs and Hosting environments

• Service Organization and the Customer (Carrier)

 Process framework allows integration of existing Best Practices with minimal interruption

 Re-use existing developments within Nokia Solution and Networks

(8)

 Process framework shall be used as preferred reference for glossary, service scoping, …

 Unified “language” within MS and also towards to customer/partners

 Ease scoping workshops with customers in pre-sales / bid phase

Support for Level 3 processes within the 8 Level 2 Process Highlighted in Orange are mapped for this

Certification.

Figure 2-2 Business Process Framework coverage

This Service Management & MS Operations lifecycle framework is a key building block to help

Operators to transform their position in the value chain. Reshaping our customers related

telecom revenues, OPEX, CAPEX and other balance sheet elements will ensure long-term

competiveness, time-to-market and profitability for our customers.

The competitive advantages such as standardized processes & tools, new business models,

consultative sales and our best-in-class Operations Lifecycle helps us to achieve our vision to

become “The leading Transformation partner for Communication Service Providers”.

By applying the Service Management & MS Operations lifecycle framework blueprint to design and

run the Service Delivery Organizations for Managed Services contracts (Network Operations and

Customer Centric Service Operations through NOC and SMC) of Nokia Solution and Networks the

following benefits can be realized:

a. Assurance to Nokia Solution and Networks customers that it has a credible

model and a clear understanding of how to delivery Managed Services

b. Benefit from the best practices and innovations established across more than 200

Nokia Solution and Networks Managed Services contracts

c. Continuously improve through the learning resulting from global benchmarking

Managed Services Carrier Enterprise

Management

Operations

Ops Support & Readiness

Fulfillment Assurance Billing

Service Conf. & Activation SM&O Support

& Readiness Problem MgmtService Service Quality Mgmt Resource Trouble Mgmt Resource Perform. Mgmt

Resource Data Collection & Distribution Resource

Provisioning RM&O Support

& Readiness

Business

Continuity Mgmt SecurityMgmt AssetMgmt S/PRM Support

& Readiness S/P RequisitionMgmt Report.& MgmtS/P Problem S/P Perform.

Mgmt S/P Interface Mgmt

Strategy, Infrastructure & Product

Product Lifecycle Mgmt The image cannot be displayed. Your computer may not have enough memory to open the image, or the image may have been corrupted. Restart your computer, and then open the file again. If the red x still appears, you may have to delete the image and then insert it again. Infrastructure Lifecycle Mgmt The image cannot be displayed. Your computer may not have enough memory to open the image, or the image may have been corrupted. Restart your computer, and then open the file again. If the red x still appears, you may have to delete the image and then insert it again. Strategy & Commit

SC Capability

Delivery SC Develop.&Change Mgmt SC Strategy &Planning Res. Capability Delivery Serv. Capability Delivery Res. Strategy

& Planning Res. Develop.&Retirement Serv. Strategy

(9)

d. Minimize Customer’s ‘Demand Organization’ and hence its costs

e. Mitigate risks by relying on a well-structured Service Delivery Organization which

implements higher levels of a Process Maturity Model

f. Flexibility based on global as well as local deliveries to ensure the right approach for

the right customer and, for global players, to repeat it

g. Building MS capabilities towards service and customer centric operations

The Service Management & MS Operations lifecycle framework assessment was carried out against

the Business Process Framework Release 12.0.

(10)

3 Business Process Framework Assessment Overview

3.1 Mapping Technique Employed

Business Process Framework Level 3 descriptions are analyzed by looking for implied tasks. (This

is similar to how process decomposition can use Semantic Analysis). Each Business Process

Framework process is supported by descriptive text. In many cases, each process is aligned and

mapped to appropriate company documentation references solution, methodology or modeling

material.

The Business Process Framework Level 3 descriptions are analyzed by looking for implied tasks.

Color coded text as highlighted below is used as part of the process mapping whereby

highlighted text indicates the level of support for a Level 3 process implied task:



GREEN is used to highlight key words or key statements that are fully supported



YELLOW is used to highlight key words/key statements that are partially supported



GREY is used to highlight key words/key statements that are not supported



No highlighting is used for words/statements that are irrelevant, just for reference or

needed to complete the sentence.

Manual and Automated Support

It is important to determine whether the implied task is supported by manual steps, automated

steps, or a combination of both. In this document, “A”, “M”, or “AM” is used for each task to

indicate that the step or steps is/are automated (A), manual (M), or both (AM).

TM Forum Note 1: When process mappings are presented against Level 4 processes, the mappings

are provided against the text in the “Mandatory” field for the process. In the event of the Mandatory

field not being used, the process mappings are in that case provided against the Level 4

Brief/Extended descriptions.

TM Forum Note 2: Note that if a Level 3 process has not been decomposed to Level 4 processes in

the Business Process Framework, in such cases the process mapping support is provided against the

Level 4 process descriptions (Brief & Extended).

(11)

3.2 Business Process Framework Level 2 Process Scope

The following figures represent the Business Process Framework Level 2 processes that were

presented in scope for the assessment, and the textual callouts represent the components of NSN’s

Service Management & MS Operations Lifecycle Framework that were assessed and support the

corresponding Business Process Framework processes according to the results in Chapter

6

Frameworx Conformance.

Figure 3-1 - Operations Level 2 process coverage for NSN’s Service Management & MS Operations Lifecycle Framework Assessment

Managed Services

Carrier Enterprise Management

Operations

Ops Support & Readiness

Fulfillment Assurance Billing

Service Conf. & Activation SM&O Support

& Readiness Problem MgmtService

Service Quality Mgmt Resource Trouble Mgmt Resource Perform. Mgmt Resource Data Collection & Distribution Resource

Provisioning RM&O Support

& Readiness

Business

Continuity Mgmt SecurityMgmt AssetMgmt S/PRM Support

& Readiness S/P RequisitionMgmt Report.& MgmtS/P Problem S/P Perform.

Mgmt S/P Interface Mgmt

Strategy, Infrastructure & Product

Product Lifecycle Mgmt The image cannot be displayed. Your computer may not have enough memory to open the image, or the image may have been corrupted. Restart your computer, and then open the file again. If the red x still appears, you may have to delete the image and then insert it again. Infrastructure Lifecycle Mgmt The image cannot be displayed. Your computer may not have enough memory to open the image, or the image may have been corrupted. Restart your computer, and then open the file again. If the red x still appears, you may have to delete the image and then insert it again.

Strategy & Commit

SC Capability

Delivery SC Develop.&Change Mgmt SC Strategy &Planning Res. Capability Delivery Serv. Capability Delivery Res. Strategy

& Planning Res. Develop.&Retirement Serv. Strategy

& Planning ServRetirementDevelop.& Serv. & SpecificInsur. Rating

S/P Settlem. & Billing Mgmt Market Strategy

& Policy Product & Offer

Portfolio Plan.

Product & Offer Cap. Delivery

Marketing Cap. Delivery

Product & Offer Dev. & Retirem.

Sales Development

CRM Support

& Readiness Customer Interface Mgmt Order Handling Technology Scanning Research Mgmt

(12)

The following diagram identifies the number of Level 3 processes that were submitted for assessment, for each Level 2 process that was submitted in scope for the Assessment.

Figure 3-2 - Level 3 process coverage for NSN’s Service Management & MS Operations Lifecycle Framework Assessment

(13)

3.3 Product Scope

The diagram in Figure 3-3 represents NSN´s Service Management & MS Operations Lifecycle

Framework and how it is mapped to the Business Process Framework.

Figure 3-3 - NSN Service Management & MS Operations Lifecycle Framework Footprint with Scope for eTOM Assessment

(14)

4 Business Process Framework – Process Mapping Descriptions

This section provides the Process Mapping output from NSN’ Self-Assessment which was reviewed by

TM Forum Subject Matter Experts alongside supporting documentation for NSN´s Service

Management & MS Operations Lifecycle Framework.

4.1 Level 2: Service Problem Management (1.1.2.3)

eTOM Description

Service Problem Management processes are responsible for the management of problems associated with specific services. The objective of these processes is to respond immediately to reported service problems or failures in order to minimize their effects on customers, and to invoke the restoration of the service, or provide an alternate service as soon as possible.

Responsibilities of the Service Problem Management processes include, but are not limited to: · Detecting, analyzing, managing and reporting on service alarm event notifications;

· Initiating and managing service trouble reports; · Performing service problem localization analysis; · Correcting and resolving service problems;

· Reporting progress on service trouble reports to other processes;

· Assigning & tracking service problem testing and recovery activities; and · Managing service problem jeopardy conditions

Service Problem Management processes perform analysis, decide on the appropriate actions/responses and carry them out with the intent of restoring normal operation on specific services.

However these activities need to interact with the Problem Handling processes, as the latter have a view on customer impact. Service Problem Management processes are responsible for informing Problem Handling processes of any potential customer problems. Where the original report arose as a result of customer problems, the Service Problem Management processes may be coordinated by Problem Handling processes.

(15)

4.1.1 L3: Create Service Trouble Report

Brief Description

Create a new service trouble report.

Extended Description

The objective of the Create Service Trouble Report process is to create a new service trouble report. A new service trouble report may be created as a result of service alarm event notification analysis, and subsequent creation of new service alarm event records, undertaken by the Survey & Analyze Service Problem processes, or at the request of analysis undertaken by other processes in the CRM ( in particular a Customer Problem Report can generate one or more Service Trouble Reports), RM&O, SM&O or S/PRM layers which detect that some form of failure has occurred for which service restoration activity is required to restore normal operation. AM

Log Incident Ref1:Page32

Main activities: - Open TT form - Fill mandatory fields

- Copy all available information into the TT form - TT status is updated to "created"

If the service trouble report is created as a result of a notification or request from processes other than the Survey & Analyze Service Problem processes, the Create Service Trouble Report processes are responsible for converting the received information into a form suitable for the Service Problem Management processes, and for requested additional information if required.

These processes will make estimates of the time to restore service which will be included in the new service trouble report so that other processes can gain access to this information. AM

Log Incident Ref1:Page32

Ref 3: Page 6 Main activities:

- Open TT form - Fill mandatory fields

- Copy all available information into the TT form - TT status is updated to "created"

(16)

4.1.2 L3: Diagnose Service Problem

Identify the root cause of the specific service problem

The objective of the Diagnose Service Problem processes is to identify the root cause of the specific service problem. These processes are invoked by the Track & Manage Service Problem processes. The responsibilities of these processes include, but are not limited to:

· Verifying whether the service configuration matches the appropriate product features; · Performing diagnostics against the specific services;

· Running tests against the specific services;

· Starting and stopping audits against specific services; and · Scheduling routine testing of the specific services.

The Diagnose Service Problem processes will make the results of the root cause analysis available to other processes. The Diagnose Service Problem processes will update the open service trouble report, as required during the assessment, and when the root cause has been identified.

When the process is complete the Diagnose Service Problem processes will notify the Track & Manage Service Problem processes.AM

Discover Incident Ref1: Page 31

Ref 4: Page 4-9

This sub-process is reflecting the main activities of the ITIL Incident Investigation & Diagnosis process block.

Main activities:

- incident investigation

- check if root cause/solution is available in the Problem DB

(17)

4.1.3 L3: Correct & Resolve Service Problem

Restore the service to a normal operational state as efficiently as possible

The objective of the Correct & Resolve Service Problem processes is to restore the service to a normal operational state as efficiently as possible.

Based on the nature of the service failure leading to the associated service alarm event notification, automatic restoration procedures might be triggered. Manual restoration activity is assigned to the Correct & Resolve Service Problem processes from the Track & Manage Service Problem processes. Depending on the nature of the specific service failure, these processes may possibly re-assign services or re-configure service parameters.AM

Resolve Incident Ref1: Page35

Ref7: page 7-11 Description/Definition

This sub-process is reflecting the main activities of the ITIL Incident Resolution & Recovery process block.

Main activities:

- implementation of the incident resolution - testing of the implemented resolution

- when testing was successful TT status is updated to "resolved"

For large service failures requiring extensive re-assignment and/or re-configuration activity to restore normal operation, these processes will attempt to implement work-arounds to recover the specific service operation. In these circumstances, recovery of normal operation may require invocation of the Support Service Problem Management processes.AM

Create Known Error Record Ref1:Page38

Main activities:

- Description of the root cause - Description of the final solution

- Description of a work around, if needed

- Update of the Problem DB with these information

They will also report successful restoration of normal service operation, restoration through temporary work-arounds or an unsuccessful attempt at service restoration to Track & Manage Service Problem through updates to the associated service trouble report.AM

Resolve Problem Ref1: Page42

Main activities:

- Implementation of the problem resolution - testing of the implemented resolution

(18)

4.1.4 L3: Track & Manage Service Problem

Ensure that testing, repair and restoration activities are assigned, coordinated and tracked efficiently, and that escalation is invoked as required for any open service trouble reports in jeopardy

The purpose of the Track & Manage Service Problem processes is to ensure that testing, repair and restoration activities are assigned, coordinated and tracked efficiently, and that escalation is invoked as required for any open service trouble reports in jeopardy.

Responsibilities of these processes include, but are not limited to: · Initiating first-in testing using automated remote testing capabilities;

· Adding additional information to an open service trouble report based on the first-in testing; · Scheduling, assigning and coordinating repair and restoration activities;

· Generating the respective resource trouble report creation request(s) to Create Resource Trouble Report based on specific service trouble reports;

· Initiate any final testing to confirm clearance of the service problem; · Undertake necessary tracking of the execution progress;

· Modifying information in an existing service trouble report based on assignments; · Modifying the service trouble report status;

· Canceling a service trouble report when the specific problem was related to a false service alarm event; and

· Monitoring the jeopardy status of open service trouble reports, and escalating service trouble reports as necessary.AM

Track Incident Ref1:Page36

Description/Definition

Tracking of a incident is a permanent process. It starts with the creation of a TT and ends with the closing of a TT. The main focus of the tracking process is to ensure that the the resolution of a incident is running acc. to the agreed SLA's and KPI's. This process keep track of all the activities from logging an incident to closing incident and do the necessary modification in TT based on the updates from different activities. This also manages the co-ordination with internal and external parties where ever required.

Note that some specific resource components may be owned and managed by suppliers/partners. In these cases the Track & Manage Service Problem process is responsible for initiating requests, through S/P Problem Reporting & Management processes for restoration and recovery by the supplier/partner of the specific resource components.

These processes will co-ordinate all the actions necessary in order to guarantee that all tasks are finished at the appropriate time and in the appropriate sequence.AM

(19)

Track Problem Ref1: Page 42

Tracking of a problem is a permanent process. It starts with the creation of a TT and ends with the closing of a TT. The main focus of the tracking process is to ensure that the the resolution of a problem is running acc. to the agreed SLA's and KPI's.

The Track & Manage Service Problem processes are responsible for engaging external suppliers/partners in correction and recovery activities when:

· higher level expertise and/or higher level support is required to resolve the service problem, (which may be automatic in the case of highest priority service problems);

· the specific service has been purchased from an external supplier (as in an interconnect service); or · the specific service is delivered by an external partner.AM

Manage Incident Escalation Ref1: Page 33

Description/Definition

Escalation procedures has to be defined in the design phase of a service. An escalation can depend on:

- Incident priority - effected service

- effected amount of end customers etc.

This process also manages the notification to different stakeholder wherever needed

Where the engagement with an external supplier/partner is for purchased or delivered services, as the case may be, the tracking and management of the supplier/partner problem resolution activity is actually performed by the S/P Problem Reporting & Management processes, with the Track & Manage Service Problem processes relegated to an overall coordination role. The Track & Manage Service Problem processes will also inform the Close Service Problem processes by modifying the service trouble report status to cleared when the service problem has been resolved.AM

Manage Incident Escalation Ref6 : page 6-8

Tracking of a incident is a permanent process. It starts with the creation of a TT and ends with the closing of a TT. The main focus of the tracking process is to ensure that the the resolution of a incident is running acc. to the agreed SLA's and KPI's. This process keep track of all the activities from logging an incident to closing incident and do the necessary modification in TT based on the updates from different activities. This also manages the co-ordination with internal and external parties where ever required.

(20)

4.1.5 L3: Report Service Problem

Monitor the status of service trouble reports, provide notifications of any changes and provide management reports

The objective of the Report Service Problem processes is to monitor the status of service trouble reports, provide notifications of any changes and provide management reports.

These processes are responsible for continuously monitoring the status of service trouble reports and managing notifications to processes and other parties registered to receive notifications of any status changes, for example, Service Quality Management and Customer QoS/SLA Management processes. Notification lists are managed and maintained by the Support Service Problem Management processes. These processes record, analyze and assess the service trouble report status changes to provide

management reports and any specialized summaries of the efficiency and effectiveness of the overall Service Problem Management process. These specialized summaries could be specific reports required by specific audiences.

These processes will make the necessary reports about the problem that occurred, the root cause and the activities carried out for restoration.AM

Manage Incident Escalation Ref1: Page 33

Ref6 : page 6-8 Description/Definition

Escalation procedures has to be defined in the design phase of a service. An escalation can depend on:

- Incident priority - effected service

- effected amount of end customers etc.

(21)

4.1.6 L3: Close Service Trouble Report

Close a service trouble report when the service problem has been resolved

The objective of the Close Service Trouble Report processes is to close a service trouble report when the service problem has been resolved.

These processes monitor the status of all open service trouble reports, and recognize that a service trouble report is ready to be closed when the status is changed to cleared.AM

Ref5: Page 5 Description/Definition

Tracking of an incident is a permanent process. It starts with the creation of a TT and ends with the closing of a TT. The main focus of the tracking process is to ensure that the resolution of an incident is running acc. to the agreed SLA's and KPI's. This process keep track of all the activities from logging an incident to closing incident and do the necessary modification in TT based on the updates from different activities. This also manages the co-ordination with internal and external parties where ever required.

(22)

4.1.7 L3: Survey & Analyze Service Problem

Monitor service alarm event notifications and manage service alarm event records in real-time

The objective of the Survey & Analyze Service Problem processes is to monitor service alarm event notifications and manage service alarm event records in real-time.

Responsibilities of the Survey & Analyze Service Problem processes include, but are not limited to: · Detecting and collecting service alarm event notifications;

· Initiating and managing service alarm event records;

· Performing service alarm event notification localization analysis; · Correlating and filtering service alarm event records;

· Reporting service alarm event record status changes to other processes; · Managing service alarm event record jeopardy conditions.AM

Event Management (Ref 1: Page 29)

Description/Definition

An event can be defined as a measurable or identifiable occurrence which is relevant to the management of the infrastructures and consequently the provision of services. Events are typically messages or displays produced by services, configuration items or monitoring tools. An effective service operation is dependent upon the knowledge of the status of the infrastructures and any variances from the normal service operation. This can be

guaranteed by good monitoring and a system of controls which is provided on the basis of two tool types:

- Active monitoring tools, which interrogate key CIs to ascertain their availability - Passive monitoring tools, which detect and process alarm signals from configuration items.

A distinction is drawn between the following types of events in the service operation area: - Events which show that processing has been properly executed (information).

These can be completed status reports on a batch processing, registration of a user login or notification that an e-mail has been successfully sent.

- There are also events which flag errors or variances (warning) for example when a user logs on using an incorrect password or in the event of a CPU overload.

- There are also events which display an unusual system response but which is not yet a variance (exception).

Event Management is an extensively automated process which is audited on a regularly basis.

Service alarm event notification analysis encompasses the identification of the service alarm event in terms of reporting entity and nature of the service alarm event. It will then analyze the service alarm events based on a number of criteria and then suppress redundant, transient or implied service alarm events by means of filtering and correlation. It includes the notification of new service alarm event records, or status changes of previously reported service alarm event records, as well as abatement messages when service alarm event records have been cleared.

(23)

The analysis will correlate service alarm event notifications to planned outage notifications to remove false service alarm event notifications arising as a result of the planned outage activity.

These processes may determine that a service alarm event notification may represent a customer impacting condition. In these circumstances this process is responsible for indicating a potential customer problem to the Problem Handling processes. As a part of this indication this process is responsible for identifying the impacted deployed product instances associated with the service instances presenting alarm event notifications and passing this information to the Problem Handling processes.

Service alarm event record correlation and filtering encompasses the correlation of redundant, transient or implied service alarm event notifications with a specific “root cause” service alarm event notification and associated service alarm event record.

The Survey & Analyze Service Problem processes might trigger a well-defined action based on specific service alarm event notification information as well as the non-arrival of service alarm event

notification information after a specific time interval has elapsed.

These processes are also responsible for monitoring and triggering the appropriate action when a service alarm event record is not cleared within a pre-defined period of time.AM

Event Management (Ref 1: Page 29)

(Ref 2: Slide 24-27 Description/Definition