Nokia Network Change Management Process_Ver 4.0A

Network Change Management Process

Author

Subhakanta Panda

Owner

Subhakanta Panda

Organization

Process & Tools-PMO, E2E Delivery India Region

Approver

Arvind Kumar

Document ID

D495740748

Document location

Share-net

22-04-2015 – D495740748 - 1 / 64

© Nokia Solutions and Networks 2014

Change History

Document history Date

Name

Versions

Contents of change

08.04.09

Vipin K. Sharma & Version 1.0 Vikas Kukreja

Release of First Version

13.04.09

Vikas Kukreja

Version 1.1

Updation of the document with creating CRs on OS3 tool

29.05.09

Vikas Kukreja

Version 1.2

Updation of the document with Additional approver of National NPO / Core teams

08.06.09

Vikas Kukreja

Version 1.3

Addition of WO numbering scheme, Directory structure for CR storage and description of Regulatory changes

10.07.09

SubhaKanta Panda

Version 1.4

Update of SLA for National teams, clarity on urgent CRFs and planned outage calendar

Version 1.5

Updation of the document for creating CRs on PT4 tool and modified approval process, new severiyt level added

Version 1.6

Change in approval matrix and severity defination. Some detailed responsibilities defined for originator and Executor in Responsibility Matrix

Version 1.7

Name of process changed from Change Management to Network Change Management. Status changes in PT4 Tool added in the process flow.

Version 1.8

Activities need to be updated in siteplus tool , some 3G activities, approval matrix for TTSL account, Contingency plan, Process review methodology are added.

Subhakanta 02.12.2010 Panda

Version 2.0

Complexity of process flow reduced by introducing the one pager flow.Process Structure changed to reduce complexity

04.7.2011

Subhakanta Panda

Version 2.1

12.06.2012

Subhakanta Panda

Version 2.1

SubhaKanta 10.03.2010 Panda SubhaKanta 18.07.2010 Panda Subhakanta 20.08.2010 Panda

02.11.2010

Subhakanta Panda

22-04-2015 – D495740748 - 2 / 64

Change in CR originator matrix Reviewed with stakeholders and no changes included


Updated approval matrix for VF added Few activities are added to the activity list. Pre-check list for originator/executor included

16.5.2013

Subhakanta Panda

Version 4.0

New features added in the PT4 tool: to select the tester, to provide the MO count of CR and the no. of site visits by engineer. Information to be given regarding OSS upgradation to central tools team Raising of CRs for physical changes through Site+ tool Lesson learned from six sigma project (how to reduce rejected CRs)

27.8.2014

Subhakanta Panda

Version 4.1

VF requirements included. Few CORE activities included

20.4.2015

Subhakanta Panda

Version 4.1A

Nokia logo incuded and document prepared as per new guidlines

DISCLAIMER: This document is purely for information purposes and makes no representation express or implied about the suitability of the information contained in this document for any purpose. All information and documents are provided without any warranty as to its contents, claims, analysis and are subject to change without notice. In no event shall NOKIA be liable for any direct, consequential, incidental, special or punitive damages arising out of the usage of the document.” This document shall not be shared with any third party. The furnishing of this document does not give you any license to these patents, trademarks, copyrights or other intellectual property nor grant you the right to reproduce this document, in whole or in part. . This material also contains confidential information, which may not be disclosed to others without the prior written consent of Nokia Solutions and Networks.

© 2015 Nokia Solutions & Networks. All rights reserved.

22-04-2015 – D495740748 - 3 / 64


Network Change Management Process Document Author

Subhakanta Panda

Program Manager Processes, E2E Delivery India Region

[email protected]

Document Contributor(s)

Lalit Sharma

National BSS Manager

[email protected]

Ronak Kazi

National Core Manager

[email protected]

Kalpesh Shah

National NPO Manager

[email protected]

Anand Pimparkar

National Transmission Manager

[email protected]

A.Kumar

National IP & Security Manager

[email protected]

Vikas Kukreja

Head - Process & Tools, [email protected] PMO, E2E Delivery India Region

Subhakanta Panda

Program Manager Processes, E2E Delivery India Region

Ajay Shukla

[email protected]

Subramonia Pillai MS Circles GNSC Document Owner

Subhakanta Panda

Document Release Arvind Kumar Authority

22-04-2015 – D495740748 - 4 / 64

[email protected]

Manager - NSS CM - GDC

[email protected]

& Program Manager - [email protected] Process & Tools, Delivery India Region PMO Head , Delivery India Region

[email protected]


TABLE OF CONTENTS 1

Introduction .......................................................................................................................... 7

1.1

Purpose .................................................................................................................................. 7

1.2

Scope...................................................................................................................................... 7

1.3

Key Interfaces ....................................................................................................................... 7

1.4

Process Change Control ...................................................................................................... 7

1.5

Process compliance and Audit............................................................................................ 7

1.6

eTOM Compliance ................................................................................................................ 7

1.7

Process Implementation ..................................................................................................... 8

2

Change Management Process flow .................................................................................... 8

3

Process Work Flow .............................................................................................................. 9

3.1

Work Flow ............................................................................................................................... 9

3.2

Process Overview ................................................................................................................. 10

4

Change Management Process Description ....................................................................... 11

4.1

Issue and Approve Change Request .................................................................................. 11

4.1.1

Reasons for Change Request ............................................................................................. 11

4.1.2

Change Request: Creation & Assignment ......................................................................... 11

4.1.3

Checklist for Originator during CR Creation ..................................................................... 13

4.1.4

Change Request Raised Through SitePlus Tool ............................................................... 13

4.1.5

Change Request Priority Definitions ................................................................................. 14

4.1.6

Change Request Severity level Definitions ....................................................................... 15

4.1.7

Change Request Severity Levels – BSS (for 2G) ............................................................... 16

4.1.8

Change request Severity Levels – Core ............................................................................. 21

4.1.9

Change request Severity Levels – Transmission .............................................................. 25

4.1.10

Change request Severity Levels – IN & VAS ...................................................................... 28

4.1.11

Change request Severity Levels – IP & Security ............................................................... 33

4.1.12

Network Change Request Severity Levels for 3G Activities ........................................... 33

4.1.13

Change Request: Acknowledgement & Analysis ............................................................. 34

4.1.14

Change Request Approval ................................................................................................... 35

22-04-2015 – D495740748 - 5 / 64


4.2

Change Request Track & Manage by PT4 Tool................................................................. 38

4.2.1

Change Request Workflow in PT4 Tool.............................................................................. 38

4.2.2

Approval Workflow in PT4 Tool (for approvers) ............................................................... 39

4.2.3

Checklist for Executor during CR Execution ..................................................................... 39

4.3

Change Request Scheduling & Implementation .............................................................. 40

4.3.1

Change Request Pending .................................................................................................... 42

4.3.2

Change Request Rejection .................................................................................................. 43

4.4

Test the Change Request .................................................................................................... 43

4.5

CM Process Reporting.......................................................................................................... 43

4.5.1

CM Planned outage activity report for manual process ............................................... 43

4.5.2

CM Daily Reporting for tool based process .................................................................... 44

4.5.3

CM Process KPI Reporting ................................................................................................... 46

4.6

Change Request Close ......................................................................................................... 47

4.7

Change Request Rollback .................................................................................................... 47

5

Change Management Responsibility Matrix ..................................................................... 48

5.1

SitePlus Tool should be updated for the below activities .............................................. 51

5.2

Contingency Plan .................................................................................................................. 51

6

Implementation with excel CR Form (in case tool is not operational for longtime) ... 52

SLA/OLA ................................................................................................................................................ 52 6.1

SLA/OLA of Originator, Approver and Executor .............................................................. 52

6.2

Change Requests SLA – BSS................................................................................................ 53

6.3

Change request SLA - Core ............................................................................................... 55

6.4

Change request SLA – Transmission ............................................................................... 56

6.5

Change request SLA – IN & VAS ........................................................................................ 57

7

Process Review .................................................................................................................... 62

7.1

Glossary ................................................................................................................................. 62

Circle and Customer ID ....................................................................................................................... 63 7.1.1

Circle ID .................................................................................................................................. 63

7.1.2

Customer IDs ........................................................................................................................ 64

22-04-2015 – D495740748 - 6 / 64


1 Introduction 1.1

Purpose

The purpose of this document is to understand Change Management Process which is a well-defined set of procedures for planning, managing and controlling “changes” to Telecommunications networks. The intention of the Change Management Process is to control the changes to the network so that a high level of service can be maintained. It will result in a higher level of network performance and customer satisfaction and also keep time spent in investigating perceived problems in the network to a minimum.

1.2

Scope

The process includes the following scope  Any change in the network configuration  Any change in the active network  Any change in Performance Reports



All major changes related to software upgrade needs to be captured and reported by GNOC

The process defines the process flow, notifications and approval methodology for Change Management activities so that all the concerned departments are kept informed in advance and an authorized change request implemented

1.3

Key Interfaces

A Change Request can be initiated as an outcome of any of the below listed processes:  Network Planning  Network Optimization  Performance Management  Fault Management  Field Maintenance  Technical Support  Customer/3rd party request

1.4

Process Change Control

The process will be changed only by the E2E Delivery India Region Process and Tools Team. All suggestions and feedback should be sent to the document author/owner.

1.5

Process compliance and Audit

Any deviation to this process compliance must be supported with written evidences from customer or/and circle head/OD/HOS for any exceptions during audit.

1.6

eTOM Compliance eTOM Business Process Map an industry-agreed integrated business process descriptions, created with today's customer-centric market in mind, used for mapping and analyzing operational processes. The eTOM model has been selected by NSN as a process standard and the processes are developed on the base of the comprehensive eTOM-Model which covers all business processes of a telecom

22-04-2015 – D495740748 - 7 / 64


th

operation. This Change Management Process document is prepared up to the 5 level of eTOM process model.

1.7

Process Implementation The Circle Head is responsible for the implementation of the process in the Circle.

2 Change Management Process flow Below process flow is 3rd level (sub-processes) of eTOM model

Network Change Management Process Level 3 Steps

Interface/Data

Resource Performance Management

Issue and Approve Change Requests

Resource Provisioning S/P problem reporting and management

Track and Manage CR

Resource Trouble Management Service Quality Management

Allocate and Install Resources

Configure and Activate Resources

Test Resources

Report CR

Close CR

End

The CR activities will follow the below mentioned routine

Role

Activity Initiate & Approve the CR

Originator/Approver Create the CR and provide the necessary

22-04-2015 – D495740748 - 8 / 64

Description


Role

Activity

Description information for the executor to execute the CR

CR executor

Ensure CR activities are assigned, managed and tracked efficiently.

Resource Allocation

CR executor/ Originator

Allocate specific resources required to support a specific CR.

Resource Installation

CR executor/ Originator

Install specific resources support a specific CR.

CR executor

Configure the specific resources allocated against a CR.

CR executor

Activate the specific resources allocated against a CR.

CR Originator & Executor

Test specific resources to ensure they are operating within normal parameters.

Track and Manage of the CR

Resource Configuration

Resource Activation

Resource Testing

required

to

3 Process Work Flow 3.1

Work Flow th

Below work flow is 4 level (detail activities map to role) of eTOM model:

22-04-2015 – D495740748 - 9 / 64


Network Change Management Process Yes

Yes

Initiate Change Request Through Site+ & PT4

Originator

Start Is the Change to be initiated through site plus ?

Change request Needed

Urgent CR & Approvers not Available/Emergency CR?

Select Executor And Add Groups/ Persons for Notification

Yes

Yes

Verify the Implementation & Testing

A

No

Approver

Acknowledge and analyze

Complete Information Provided in CR ? No

B

Impact Consequences Acceptable?

Perform Impact analysis

Yes

No

Approve Change request rejected

Yes

Contact Originator

No

No

Create Task Permission granted by AM Team for execution?

Support or On site assistance needed ?

Further Information Required?

Verify Change request

Executor

END

Customer Approval Yes

Schedule Configuration Change request

Yes

No

Wait for Permission

Perform Pre Test Implement change

Yes

Is Implementation Successful?

Yes

Arrange For Testing

No

3.2

Close the CR

Yes

Customer

Approval Through EMAIL/ SMS/PHONE

Update Site+/ Network database if Required

Performance Testing Successful

No

Perform Impact analysis

Add Approvers As per Matrix

No

Performance test required?

No

Create Task

Support or On site assistance needed ?

Initiate Change Request Through PT4

No

Yes

Create pre/post Test plan, Attach Fallback Plan, Data Sheet & MOP (if Applicable)

Post Test Successful?

No

Report & Close CR

Yes

Inform to AM Team

A B

Check & decide to Rollback

Rollback Successful ?

No

Escalate as Per Matrix

Fault Management Process

Process Overview

For the live network the change request (CR) can be initiated by the originator as defined and must be approved by component authority of the Circle. The network change executor can be the Circle CM team, GNSC Configuration Management team (GNSC CM Team) or both.

22-04-2015 – D495740748 - 10 / 64


4 Change Management Process Description 4.1

Issue and Approve Change Request

4.1.1 Reasons for Change Request Any change to the live network need to follow the Change Management process. Types of activities that need to follow CR process with different purposes is given below Reason

Description/Purpose

Unplanned Outage

SW / HW failure leading to loss of service or traffic

Planned outage

HW restarts , frequency retunes, etc

Maintenance and data collection

SW & HW maintenance

Network re-configuration

Parameter and configuration settings

Network expansion

Adding or removing HW

Performance Reporting

Change in the KPIs or algorithm for PM reporting

Fault Rectification*

Changes carried out during the fault rectification supported by a TT/WO for alarm clearance

* If any change is carried out during the Fault Rectification supported by a TT/WO for alarm clearance, the log of the change needs to be captured in the TT/WO.

Change Requests for Performance Reporting: For any change in the performance reporting a CR form will have to be filled up: • • • •

Change in formula of any KPI in a particular Report Addition of KPI in any report Creation of a new report or discontinuation of an existing report Change of schedule of any existing report

A clear description of the change has to be filled up in the CR form. The Change request for the Performance report has to be approved by the National Team. The executors of Change Requests for Performance Reporting will be GNSC’s PM Team. GNSC team will be allowed a sufficient time to complete the CR.

4.1.2 Change Request: Creation & Assignment The following table lists possible Originators and possible reasons:

Network Change Management Node expansions / Sector Addition / Configuration Changes / New Product Testing / 22-04-2015 – D495740748 - 11 / 64

CRF Originator NPO / Core Team


Frequency Planning Node expansions / Sector Addition / New Sites

Projects

HW maintenance (Corrective)

FLM / O&M

Core Software Upgrades

Core Team

BSS Software Upgrades

FLM / O&M Team

Configuration changes / Modifications on 3rd Party equipments / Customer's request

Respective functional owners as above

The Originator needs to fill in the Change Management Form in the PT4 tool providing all the necessary details, as per PT4 tool user manual available in sharenet. Insufficient details may lead to additional enquiries and may delay the work. The request should include but is not limited to the following: •

Customer Detail

•

Title of CR

•

CR Priority

•

CR Category

•

CR Type

•

CR Severity

•

Description of CR

•

Reason of the CR

•

Tester Group

•

MO count

Once the customer is selected in the CR module the Project tab will get activated After filling all other fields including CR data sheet attachment, the initiator has to click on the Project tab. In project tab, option "Integer Field 1" is for giving the input on how many MO types involved in the CR,for example if the CR is having BTS & TRX MOs, "Integer field 1" is to be selected as 2. Maximum up to 4 MO types can be included in the CR. Domain wise MO types already configured in the MO Type field. Initiator has to select the required type from the drop down menu. Values in the MO number field will reflect as numerical numbers after originator key in the value in the field & submit the CR.

22-04-2015 – D495740748 - 12 / 64


Before raising the CR for ZQ removal, Originator must go through the checklist to ensure that the project work has been completed.

Check List to raise CR for ZQ removal SL.NO

Activity

1

Site Installed

2

Punch Point Cleared

3

Pre-optimization done

status

Since obtaining approval for the CR is the responsibility of the originator, he / she need to assign the CR to himself / herself in PT4 tool during creation of CR:

4.1.3 Checklist for Originator during CR Creation

BSC Planned Activity Checklist

4.1.4 Change Request Raised Through SitePlus Tool Below find the list of activities part of physical changes for which the CR must be raised through SitePlus tool not in PT4 tool. Site related parameters: • Site name, BCF name, Site ID, Lat, Long, • Infra parameters: - for ex: antenna ht, shared/non shared, site owner, cabinet type, etc • RF parameters: - cell name, cell ID, antenna type, electrical and mechanical tilt, etc • It’s intended BSC (in case of re-homing) Link/trail related parameters: • Link ID • Capacity • Phase • Frequency • Tx power • Trail of site, etc. Core node details: • Name • Point code 22-04-2015 – D495740748 - 13 / 64


• Node owner • Capacity, etc

Procedure to Create the CR and update the tool • The initiator log in to the tool using his username and password

For single change:

• Initiator searches a site/link in Siteplus, then go to details. In details window click on the edit button. Provide the change value and save. • Provide the required value in Siteplus CR form then provide the approver name, executor nd name, 2 approver name and save that value in Siteplus. • Automatic email will go to approver and copy of email to initiator. • Approver can reply to that mail by mentioning Accept/Reject in first line of that mail or he can log in to the tool and approve/Reject the change request in the tool only. • The intimation of rejection of task will go to initiator through email. st nd • Once 1 approver approves the CR, an email will go to 2 approver (if any) to approve otherwise it will go to the executor to execute the task. nd nd • If 2 approver approves the change, mail will go to executor for execution of task but if 2 approver rejects the change a mail will only go to initiator to inform the initiator about the cancellation of task. • The executor or initiator can commit (equivalent to implemented in PT4 tool) the changes by log in to the tool or by replying to the email mentioning Done in first line of that email which they have received after the CR approval • The executor can cancel the task after the task is approved by approver but if initiator initiates the cancellation, it will take 24 hour to get cancelled in tool.

For Mass Changes:

• The initiator has to fill the required template (available in the Siteplus tool) with proper approvers, executor names and email ids. • Once the template is imported in Siteplus, email will go to the respective approvers for approval for each executor (for each executor approval will go to the approver) • Then the approval process goes on as mentioned in single change approval process.

4.1.5

Change Request Priority Definitions A request can have the following two priorities

Priority

Definition (is based on timelines for the process)

Urgent

Any CR of business critical nature which needs to be implemented immediately is classified as urgent CR. For example, any time pressing activity due to identification of some

22-04-2015 – D495740748 - 14 / 64


bug / situation to correct some alarm or some natural calamity / unplanned activity. All urgent change requests can be of any of the severity level. Regular

All non-urgent Change Requests are classified as regular requests, and can be of any of the severity levels

4.1.6 Change Request Severity level Definitions CRs have been classified into severity levels based on service impact and approvals required to execute CRs are based on this severity level.

Outage

Service Impacting (Outage Required)

Severity

Definition (is based on Impact on Service rather than pure outage)

Critical

All NPO related activities which will affect network performance on a larger scale, Frequency Plan Change, BSC Software upgrade etc. Any Planned Core work which causes complete outage of a node or one Particular Functionality, Expansion in live switch, Software upgrades, BSC Re-homing.

Major

All NPO related activities which will affect KPI at BSC/City/Towns level. I.e. Cell Level parameter change for more than 100 Cells or BSC Level parameter changes. Any Core Database change in the common database which requires outage like PLMN, Trigger, Barring, VLR /LAC timers & Frequency, changes in one of the Hardware unit.

Minor

All NPO activities which will have minor effect on network limited to less no. of cells. Signaling Rerouting If maintenance is urgently needed to prevent problems in the network. For example because of some end users complain MSC restart is required which will affect more end users

Emergency

Non Service Impacting (Outage Not Reqd.)

Major

All NPO related activities which are not service affecting but are KPI affecting on a wider scale >=50 cells due to the quantum of change being incorporated. Any Core Database change in the common database which do not require Outage like Attribute, Redundant hardware change

22-04-2015 – D495740748 - 15 / 64


Minor

All NPO activities which will have minor effect on network limited to < 50 cells. Creation of POI & AT, E1 / ATER Addition,

** All regulatory changes must be classified as Major / Critical.

4.1.7 Change Request Severity Levels – BSS (for 2G) Following is the classification of severity levels of common NPO activities–

Sl.No

CR Activity

Outage/Non outage

Severity

Non outage

Minor

1

New Sites Creation

2

BTS Sites Re-homing< 15 Sites

Outage

Minor

3

BTS Sites Re-homing>=15 Sites

Outage

Major

4

New Gb Definition

Non outage

Minor

5

Gb Capacity Modification

Non outage ( Non outage Voice Outage but Data Outage may be required)

Minor

6

Cascading Changes (Separate E1)

Outage

Minor

7

Timeslot shifting for the Metro Hub Implementation

Outage

Minor

8

Ext Alarms Definition

Non outage

Minor

9

TRX Addition/Deletion <100 Cells

Non outage (Outage Required in special cases)

Minor

10

TRX Addition/Deletion >= 100 Cells

Non outage(Outage Required in special cases)

Major

11

New Sites integration support

Non outage

Minor

12

TCSM Addition / A Interface definition / Pool Modification integration support

Non outage

Minor

13

TRX Addition - Field Support

Non outage (Outage Required in special cases)

Minor

14

External Alarm verification from the Field for new Sites

Non outage

Minor

22-04-2015 – D495740748 - 16 / 64


15

BSC Migration from one MSC to Other MSC

Outage

Critical

16

Coordination for Drive test

Non outage

Minor

17

Support to Extend the ET for the New Sites/TCSM/GB

Non outage

Minor

18

GENA Y/N Toggling < 100 Cells


Minor

19

GENA Y/N Toggling >= 100 Cells


Major

20

Frequency Plan implementation (New Plan Creation & Activation of the Existing Plan) <100Cells

Outage

Minor

21

Frequency Plan implementation (New Plan Creation & Activation of the Existing Plan) >=100 and <200 Cells

Outage

Major

22

Frequency Plan implementation (New Plan Creation & Activation of the Existing Plan) >=200 Cells

Outage

Critical

23

Neighbor Addition

Non outage

Minor

24

Neighbor Deletion < 2000 Neighbors

Non outage

Minor

25

Neighbor Deletion > 2000 Neighbors

Non outage

Major

26

RF Frequency Related Parameter Changes (Mal, Ho …etc) < 100 Cells

Outage

Minor

27

RF Frequency Related Parameter Changes (Mal, Ho …etc) >= 100 Cells

Outage

Major

28

Cell Level Parameter Change < 100 Cells

Outage (Voice/Data Outage Depends upon parameter to be changed)

Minor

29

Cell Level Parameter Change >=100 Cells

Outage (Voice/Data Outage Depends upon parameter to be

Major

22-04-2015 – D495740748 - 17 / 64


changed) 30

BCF Level Parameter Change

Outage

Major

31

BSC Level Parameter Change

Outage

Major

32

Cell level GPRS/EDGE definition < 200 Cells

Outage

Minor

33

Cell level GPRS/EDGE definition >=200 Cells

Outage

Major

34

Ultra <> Metro <> Talk site conversion

Outage

Minor

35

TCHF/TCHD implementation >100 Cells

Outage

Minor

36

Cabinet Expansion/Segmentation

Outage

Minor

37

Sector Addition/Deletion

Outage

Minor

38

Old Sites Deletion

Non outage

Minor

39

Site Naming Change ( ZZ && ZQ && ZL )

Non outage

Major

40

AMR implementation (from BSC to TCSM complete)

Outage

Minor

41

TCSM addition testing (One by one all PCM)

Non outage

Minor

42

BSC Measurements Activation

Non outage

Major

43

TCSM Features Modification(DTX ON)

Outage

Major

44

Command Output Logs as on when required

Non outage

Minor

45

New Feature Implementation affecting KPI indirectly

Outage (Voice/Data Outage Depends upon feature to be implemented)

Major

46

New Feature Implementation affecting KPI more than 100 cells directly

Outage (Voice/Data Outage Depends upon feature to be implemented)

Critical

47

Q1 Channel Definition for Monitoring the Flexi hopper from the NMS

Non outage

Minor

48

Supporting Logs for the Case raised by the Circle.

Non outage

Minor

22-04-2015 – D495740748 - 18 / 64


49

BSC Capacity Modification -BCSU removal – Deletion of all definitions attached to the BCSU

Outage

Critical

50

BSC Software Upgrade (New/First time Upgrade)

Outage

Major

51

BSC Software Upgrade (Routine/Already tested Upgrade)

Outage

Major

52

BTS software Upgrade (New/First time Upgrade)

Outage

Major

53

BTS software Upgrade (Routine/Already tested Upgrade)

Outage

Major

54

Antenna Down tilt

Non outage

Minor

55

Azimuth Change

Non outage

Minor

56

MSS pooling

Outage

Major

57

BSC- Migration to new SGSN

Outage

Major

58

BSC Expansion

Outage

Critical

59

BCSU addition

Outage

Critical

60

BSC Re-homing

Outage

Critical

61

PCU card deletion/ addition

Outage

Major

62

OSC Implementation

Outage

Minor

63

EDAP Augmentation/Reduction

Outage

Minor

64

Packet abis Implementation

Outage

Minor

65

ET Change

Outage

Minor

66

Flexi to Ultra Conversion

Outage

Minor

67

Abis Reconfiguration

Outage

Minor

68

TRX Creation & Unlocking

Non Outage

Minor

69

BCCH Shift

Outage

Minor

70

MAL Creation & BTS attach

Outage

Minor

71

CSDAP detach & attach

Outage

Minor

72

GTRX enabling/disabling

Outage

Minor

73

PCU load balancing

Outage

Major

22-04-2015 – D495740748 - 19 / 64


74

TRX Bit rate Change

Outage

Minor

75

BSC Dual homing

Outage

Critical

76

Static Route addition

Outage

Major

77

RTSL Change

Outage

Minor

78

PCU Card addition/Deletion

Outage

Critical

79

NSEI creation

Non Outage

Minor

80

BSC SPC Change

Outage

Critical

81

STMU Addition

Outage

Critical

82

NSEI Regrouping with BCSU Switchover

Outage

Major

83

Iu Interface creation

Outage

Critical

84

PR file activation

Outage

Major

85

NSAP Creation/Modification

Outage

Minor

86

License/Feature Activation

Non Outage

Minor

87

SLC Bit Rate Change

Outage

Major

88

ET Mode Change

Outage

Minor

89

ET Card Addition

Outage

Minor

90

ATER Addition

Non Outage

Minor

91

BCSU Load balancing

Outage

Major

92

Inter PCU Rerouting

Outage

Minor

93

Command Calander Creation

Non Outage

Minor

94

Site Deletion/Creation

Outage

Minor

95

4th Sector addition

Non Outage

Minor

96

Site Migration Loading

Non Outage

Minor

97

RNC Parameter changes

Non Outage

Minor

98

RNC Parameter changes

Outage/Non Outage

Minor

99

WBTS Parameter Change

Outage

Minor

100

WBTS License Activation/Retrieval

Non Outage

Minor

101

WBTS Migration

Outage

Minor

102

RNC Measurement activation/Deactivation

22-04-2015 – D495740748 - 20 / 64

Non Outage

Minor


103

BTS Deletion & addition

Non Outage

Minor

104

DSCP Parameter Change

Outage

Minor

105

Adjaceny Parameter changes

Non Outage

Minor

106

Site Deletion

Non Outage

Minor

107

BTS Name change

Non Outage

Minor

108

CBCH Creation

Non Outage

Minor

109

ADJ (S,I&G) creation & deletion

Non Outage

Minor

110

ADJ (S,I&G) parameter changes

Non Outage

Minor

111

WBTS Creation

Non Outage

Minor

112

PR file activation

Outage

Minor

4.1.8 Change request Severity Levels – Core Following is the classification of the severity levels of the common Core activities -

Sl.no

Core Activity

Outage/Non outage

Severity

1

CD Loading

Outage

Critical

2

BSC Re-homing

Outage

Critical

3

Service outage Hardware Maintenance

Outage

Critical

4

Version upgrade

Outage

Critical

5

New Service activation

Outage

Critical

6

Core node parameter Changes

Outage

Critical

7

Hardware expansion

Outage

Critical

8

Signaling rerouting

Outage

Major

9

New POIs addition

Non Outage

Minor

10

POI E1augmentation

Non Outage

Minor

11

New Node integration

Non Outage

Major

12

Traffic rerouting

Non Outage

Major

13

Redundant Node Hardware changes

Non Outage

Major

14

Alternate routing for Voice

Non Outage

Minor

15

Non Service impact hardware Changes

Non Outage

Minor

22-04-2015 – D495740748 - 21 / 64


16

Ater Addition

Non Outage

Minor

17

Inter MSC E1 Addition

Non Outage

Minor

18

Addition of signaling links

Non Outage

Minor

19

BTS site creation

Non Outage

Minor

20

New GT addition

Non Outage

Minor

21

Roaming configuration

Non Outage

Minor

22

Change in attribute analysis

Non Outage

Major

23

Barring table database change

Non Outage

Major

24

level opening

Non Outage

Minor

25

System specific parameter change

Can be Outage

Major

26

PLMN Parameter Change

Can be Outage

Major

27

Timer Change

Can be Outage

Major

28

VLR / LAC Parameter change

Can be Outage

Major

29

Trigger Database changes.

Can be Outage

Major

30

Any Urgent Change

Based on situation

Major

31

Transaction Log maintenance

Non Outage

Minor

32

Implementation of actions for network optimization

33

Roaming data audit

Non Outage

Minor

34

New BSC Creation

Non Outage

Major

35

User id Management ( creation based on request by scanned copy after getting reqd. approvals) & Audit

Non Outage

Minor

36

Traffic rerouting during outages

Outage

Major

37

CARE cases related to CM

Outage

Major

38

Periodic Dump for RA

Non Outage

Minor

39

SPC, CGR creation, Test Routing, Measurement , Live, BSC CGR creation

40

MSRN tree standardization

Non Outage

Major

41

MSRN tree standardization

Non Outage

Major

42

Routing Attr.

Non Outage

Major

22-04-2015 – D495740748 - 22 / 64

Based on situation

Non Outage

Major


43

Egos Attr.,

Non Outage

Major

44

CF tree standardization

Non Outage

Major

45

PoI tree standardization

Non Outage

Major

46

PoI tree shud be 100,800,400,200 - analysis to be fwd to tree 1029

Non Outage

Major

47

Inter msc tree 180,445,180 - tree2 , msrn ndest

Non Outage

Major

48

vas services - tree 180

Non Outage

Major

49

Pre analysis standardization

Non Outage

Major

50

CGR Standardization

Non Outage

Major

51

Rou/NDEST/NSDEST Standardization

Non Outage

Major

52

Analysis - Rou, Eos, Pre - Analysis, Extended Pre - Analysis, Barring, Call forwarding, Functional, Clear code, Trigger, Service set

Non Outage

Major

53

PLMN Audit

Non Outage

Major

54

Configuration dump maintenance

Non Outage

Minor

55

IMEI ( white list ) loading

Non Outage

Major

56

CDR related queries (High priority to be given )

Non Outage

Major

57

Clearance for accepting new node (after completion of successful acceptance testing by Circle)

Based on situation

Major

58

Dump request by planning

Non Outage

Minor

59

Co-ordination with nodes Managed by NSN

Non Outage

Minor

60

B number changes

Non Outage

Major

61

Alternate routing definition for Signaling

62

MSRN routing changes/new MSRN creation

63

BSC dual-homing

64

MSS multipoint integration with other MSS

65

MSS multipoint integration with Cluster SPC

66

UPD, UPDR analysis, creation, CORRECTION.

22-04-2015 – D495740748 - 23 / 64

Major Non Outage

Major

Outage

Critical

Non Outage

Critical

Outage

Critical

Non Outage

Major


67

Sip implementation

Non Outage

Major

68

New LAC/adjacent LAC creation/parameter changes.

Non Outage

Minor

SD IMPLEMENTATION

Based on situation

Based on situation

70

SIGU CKT shifting.

Based on situation

Major

71

VMGW change for CGR.

Based on situation

Major

72

ISU/SIGU change for VMGW

Based on situation

Major

73

License loading/new feature file activation

Non Outage

Minor

74

Annc loading/routing.

Non Outage

Major

75

Short code

Non Outage

Minor

76

USSD Creation

Non Outage

Minor

77

Patch implementation

Non Outage

Major

78

CLN correction

Non Outage

Minor

79

DSP allocation change

Based on situation

Major

80

E1 -mode change to CRC4 /DBLF

Partial Outage

Major

81

New VMGW creation

Non Outage

Minor

82

New SIGTRAN implementation

Non Outage

Major

83

New BICC implementation

Non Outage

Major

84

New Static route addition

Non Outage

Major

85

TMSI pooling changes.

Non Outage

Major

86

SIP/Sigu ckt redistribution.

Based on situation

Major

87

SCCP broadcast creation.

Non Outage

Major

88

M3UA PORT changes

Non Outage

Major

89

DBPARA patching in HLR

Non Outage

Critical

90

Traffic bifurcation

Non Outage

Major

91

IP configuration changes for node units

Based on situation

Major

92

Command calendar creation

Non Outage

Minor

93

PRI creation/configuration/deletion

Non Outage

Minor

94

Hand over definition/routing

Non Outage

Minor

69

22-04-2015 – D495740748 - 24 / 64


95

Link bit rate change

Outage

MAjor

96

O&M audit correction based on volume

Based on situation

Major

97

LAC based subscriber offloading

Non Outage

Major

98

Inter site ip Traffic migration

Non Outage

Major

99

HLR Parameter changes

Non outage

Major

100

PRFILE/ FIFILE Changes

Non outage

Major

101

CDR related parameter changes

Non outage

Critical

102

NCCP parameter Changes

Non outage

Major

103

SCTP parameter changes (VMGW/ASSOCIATION INDEX)

Can be outage

Major

104

CGR Parameter changes

Non outage

Major

105

M3UA Port Changes

Non outage

Major

106

BSSAP VER PARAMETER CHANGE

Non outage

Major

107

Integrity Key loading in HLR

Outage

Major

4.1.9 Change request Severity Levels – Transmission Following is the classification of the severity levels of the common Transmission activities -

Sl.no

Transmission Activity-Generic Activity

Outage/Non Outage

Severity

1

New Transport Hops [MW Radio or MUX] provisioning in creating a New and within the Operational Network

Non Outage

Minor

2

Capacity, configuration, set up and regular parameters setting changes in Transport nodes MW Radio and MUX w.r.t. planning docs.

Non Outage or Outage depending upon parameters

Major

3

Changes in NMS and DCN.

Non Outage

Minor

4

Installation related and physical in nature changes in Transport nodes - MW Radio and MUX w.r.t. planning docs.

Non Outage or Outage depending upon correction work

Major

5

User creation for Transmission NMS.

Non Outage

Minor

22-04-2015 – D495740748 - 25 / 64


6

Transport Circuit E1/Ethernet etc. E1 links design change within the Operational Network.

Outage

Critical

7

Management of back up for equipment configuration.

Non Outage

Critical

8

Synchronization parameters setting changes in Core Sync and Transport Network or node w.r.t. planning docs.

Non Outage

Critical

9

New Transport Circuit E1/Ethernet etc. links Provisioning in creating a New and within the Operational Network

Non Outage

Major

10


Outage

Critical

11

Swapping of the Transport hops.

Outage

Critical

12

Software, version Upgrade

Outage in Equipment, Non Outage in NMS

Major

13

Discarding old products.

Non Outage

Minor

14

MAP Creation - Netbuilder

Non - Outage

Minor

15

Service Creation - FPH(1200/800/200)

Non - Outage

Minor

16

Service Del/Creation - FPH(1200/800/200)

Outage

Major

17

FPR Migration(1200/800/200)

Outage

Major

18

Synch Configuration - FPH1200

Outage

Minor

19

Synch Configuration - FPH800

Outage

Minor

20

Synch Configuration - FM200

Outage

Minor

21

Mac Disabling

Non - Outage

Minor

22

STP Disabling in FPH UNI

Non - Outage

Minor

23

FPR 3G service CIR_EIR_CBS_EBS value Modification(Non Outage)

Non - Outage

Minor

24

Changing Queue Values, Changing 801.1p Priority values, ports

Non - Outage

Minor

25

Scheduling Algorithm

Non - Outage

Minor

26

STP Enabling in FPH NNI ports

Outage

Minor

27

FPR 3G service CIR_EIR_CBS_EBS value

Outage

Minor

22-04-2015 – D495740748 - 26 / 64


Modification(Outage) 28

Support - Site Migration

Outage

Major

29

SW Upgrade - FPR

Outage

Major

30

SW Upgrade - FPH1200

Outage

Major

31

SW Upgrade - FPH800

Outage

Major

32

SW Upgrade - FM200

Outage

Major

Product - NSN PDH 33

TRE SW Up-gradation

Outage

Major

34

CRC Enabling

Outage

Minor

35

Frequency Change

Outage

Major

36

ALCQ Enabling

Outage

Major

37

Sync Implementation

Outage

Minor

38

BW Up-gradation/Degradation

Outage

Major

39

E1 Creation(Metro hub/Flexi/Ultra)

Non - Outage

Minor

40

Label Change-Radio

Non - Outage

Minor

41

Label Change - Cross connections

Non - Outage

Minor

42

SNMP Enabling

Non - Outage

Minor

Product - 3rd Party ECI nodes-Generic Activity 43

NE/UME Upload

Non - Outage

Minor

44

NE/UME Deletion

Non - Outage

Major

45

Topology Creation

Non - Outage

Minor

ECI nodes-Trail Creation 46

E1/DS3 Creation(Abis, Ater, POI etc)

Non - Outage

Minor

47

Eos Trial

Non - Outage

Minor

48

VSI Creation

Non - Outage

Minor

49

VSI Modification

Outage

Major

ECI nodes-Topology Up-gradation 50

STM-1 to STM-4 Capacity

Outage

Major

51


Outage

Major

22-04-2015 – D495740748 - 27 / 64


52


Outage

Critical

ECI nodes-MOT(MPLS over Transport Port) 53

Trail Creation

Non - Outage

Minor

54

Tunnel Creation

Non - Outage

Minor

55

Service Creation

Non - Outage

Minor

ECI nodes-Other ECI activities 56

Slot Shifting

Outage

Major

57

Slot Up-gradation

Outage

Major

58

Trial Rerouting(Abis/Ater,etc)

Outage

Minor

59

BW Up-gradation fro Eos Trial

Outage

Major

60

Gb Link Migration

Outage

Critical

61

3G Site Migration to CEN

Outage

Minor

62

NE/UME Insertion

Outage

Major

63

NE/UME Removal

Outage

Major

64

RSTP Protection Configuration

Outage

Major

65

IP Change (Mux)

Non - Outage

Minor

66

Flex Trial clearance

Outage

Minor

67

Trail Deletion

Outage

Minor

68

NMS VLAN ID /Eth VPN ID Change

Non - Outage

Minor

69

MSP Creation

Non - Outage

Minor

70

Attribute Change(Customer ID/Mux/Trial/VSI Label)

Non - Outage

Minor

4.1.10 Change request Severity Levels – IN & VAS Following is the classification of the severity levels of the common IN/VAS activities -

Sl.n o

IN & VAS Activity

Outage/Non Outage

Severity

1

New Product Configuration

Non Outage

Minor/Major

2

Old Product Deletion

Non Outage

Minor

22-04-2015 – D495740748 - 28 / 64


3

New Level/Code Opening in Tariff Tool

Non Outage

Minor

4

New Level/Code Opening in Allowed list

Non Outage

Minor

5

Short Code Configuration

Non Outage

Minor

6

Tariff Changing in Existing Product

Non Outage

Minor/Major

7

New/ Modification in Recharge Definition

Non Outage

Minor/Major

8

Etop/ Euronet Grids Configuration

Non Outage

Minor/Major

9

Vouchers Creation/Activation/Purging

Non Outage

Minor/Major

Non Outage

Minor

10

Voucher state change from Pending to Enable

11

Retailer Margin configuration in ETOP

Non Outage

Minor

12

Periodic Rental Changes

Non Outage

Minor/Major

Promotional Messages Change on USSD/PCN/SMTP

Non Outage

Minor/Major

13 14

New PID/Series configuration on NMS

Non Outage

Minor/Major

15

New Promo Plan Configuration

Non Outage

Minor

16

Roaming Tariff Change

Non Outage

Minor

17

Bulk Commands for Promo Plan Offers

Non Outage

Minor/Major

Subscriber/ Promo plan Provisioning Monitoring

Non Outage

Minor/Major

18 19

Voucher State Change Process Monitoring

Non Outage

Minor/Major

System Backup & Restoration

Outage/Non Outage

Major/Critical

C7 Link Expansion & Configuration

Outage/Non Outage

Major/Critical

22

Subscriber Range Move/ Load Balancing

Outage

Major/Critical

23

SS7 Traffic shifting

Outage

Major/Critical

24

New Application Integration

Non Outage

Minor/Major

25

NBG: User agent baring

Non outage

Minor

26

NBG: System Backup

Non outage

Minor

27

NBG: Restore (if required)

Outage

Major/Critical

20 21

22-04-2015 – D495740748 - 29 / 64


Non Outage

28

NBG: User /Group/Access Rights / Password Creation, Modification & Deletion

29

NBG: Proxy feature configuration

Non outage

Minor

30

NBG: Optimization feature configuration

Non outage

Minor/Major

31

NBG: Push configuration

Non outage

Minor

32

NBG: Authentication configuration

Non outage

Minor

33

NBG: Authorization configuration

Non outage

Minor

34

NBG:LDAP interface configuration

Non outage

Minor

35

NBG:ICAP interface configuration

Non outage

Minor/Major

36

NBG: Radius support configuration

Non outage

Minor

37

NBG: Multipart support configuration

Non outage

Minor

38

NBG: Licensing configuration

Outage

Major/Critical

39

NBG: Logging configuration

Non outage

Minor

40

NBG: Monitoring configuration

Non outage

Minor

41

NBG: Profiling configuration

Non outage

Major

42

MMSC:MSIDDN Series Baring for white list / black list

Non outage

Major/Minor

43

MMSC: Change the profile is NPS server for Specific MSISDN depending on the request

Non outage

Major/Minor

44

MMSC: Application creation for push message

Non outage

Major/Minor

45

MMSC:CDR Backup

Non outage

Minor

46

MMSC:IACC configuration

Non outage

Minor/Major

47

MMSC: Inter MMS Series Definition

Non outage

Minor/Major

48

MMSC: New Operator Integration

Outage

Minor

49

MMSC: Mail gateway configuration

Non outage

Minor/Major

50

MMSC: Polling and Retry Configuration

Non outage

Minor

51

MMSC: Update Patch Installation

Non outage

Minor/Major

52

MMSC: User /Group/Access Rights / Password Creation, Modification & Deletion

22-04-2015 – D495740748 - 30 / 64

Minor

Minor Non outage © Nokia Solutions and Networks 2014

Outage

Critical

53

CMD: Workflow Switchover for prepaid and postpaid

Non Outage

Minor/Major

54

CMD: User/Group Password Modification/ Rights Modification

Non Outage

Minor/Major

55

CMD: Load Balancing of EC's for Prepaid and Postpaid

56

CMD: Changing RAM Size for EC's

Outage

Minor/Major

57

CMD: Addition of new External entities

Non Outage

Major

CMD:EC switchover in case of any outage for one server to another server

Outage

Critical

58 59

CMD: License Management

Outage

Critical

60

CMD: Data Call testing configuration

Non Outage

Minor/Major

Non Outage

Minor/Major

61

CMD: External/internal IP address Creation/ Deletion.

Outage

Minor/Major

62

SMSC:LA (Large Account) addition for new applications/CP for TPS & Session allowed.

63

SMSC: New series addition

Outage

Minor/Major

Outage

Minor/Major

64

SMSC: Inter SMSC configuration changes required to communicate with other SMSC(Within PLMN or other PLMN) SMSC: License addition on the base of subscriber base addition

Outage

Minor/Major

65

SMSC: Configure the TON/NPI parameters for MO/MT messages.

Outage

Minor/Major

66

SMSC: Whitelist/Blacklist of MSISDN on SMSC.

Non Outage

Minor/Major

67 68

SMSC: Short codes routing

Outage

Minor/Major

SGSN: Gb Link Creation / Deletion / Modification

Non Outage

Minor/Major

69 70

SGSN:PLM Creation / Deletion

Non Outage

Minor/Major

71

SGSN:GT Analysis

Non Outage

Minor/Major

72

SGSN:LAC Creation / Deletion

Non Outage

Minor/Major

73

SGSN:SCCP Routing Definition

Non Outage

Minor/Major

22-04-2015 – D495740748 - 31 / 64


74

SGSN: Backup

Non Outage

Minor

75

SGSN:SS7 Link set Creation/Deletion

Non Outage

Minor/Major

Non Outage

Minor/Major

76

SGSN: License Changes/ addition depend upon the request.

Non Outage

Minor

77

SGSN: Authentication Management for different level of user DNS:APN Configuration for national / International Operator

Non Outage

Minor/Major

78 79

DNS:LAC/RAC Entries

Non Outage

Minor/Major

80

DNS: Software Upgrade

Outage

Critical

81

DNS:APN resolution

Non Outage

Major

Non Outage

Minor

82

DNS: Authentication Managing for different level of user

83

Router: LAN Configuration.

Outage

Major

Router: Routing changes in case of any changes in the network.

Outage

Major

84 85

Router: SNMP configuration changes.

Outage

Minor/Major

86

Router: OSPF configuration changes.

Outage

Minor/Major

87

Router: Remote access Configuration

Outage

Minor

Non Outage

Minor

88

Router: Authentication Management for different level of user

89

Flexi-ISN: Addition of new IP pool

Non Outage

Minor/Major

Flexi-ISN: Addition of new APN configuration

Non Outage

Minor/Major

90

Outage

Minor/Major

91

Flexi-ISN: Creation / Modification / Deletion in existing service , Flows & Service class

Outage

Minor/Major

92

Flexi-ISN: Modification / Deletion for level of analysis ( L4/L7)

93

Flexi-ISN: Creation of new service provider

Outage

Minor/Major

94

Flexi-ISN: New Service Configuration

Outage

Minor/Major

Flexi-ISN: Modification / Deletion if there are any changes in the IP backbone network.

Outage

Minor/Major

95

22-04-2015 – D495740748 - 32 / 64


4.1.11 Change request Severity Levels – IP & Security Following are the classification of the severity levels of the common IP&Security activities -

Outage/Non Outage

Severity

Non Outage

Major

1

Sudden increase in latency from MWR at BTS(Edge router) to aggregation router (BSC)

Non Outage

Minor

2

Packet loss/drops from MWR at BTS(Edge router) to aggregation router (BSC)

Non Outage

Major

3

Sudden increase in latency from aggregation router ( at BSC) to PE router (at MSC)

Non Outage

Minor

4

Packet loss/drops from aggregation router ( at BSC) to PE router (at MSC) Latency increase in IP MPLS Core network PE to P, P to P

Non Outage

Minor

5

Packet loss/drops in IP MPLS Core network PE to P, P to P

Non Outage

Minor

6 7

IP Backbone network, topology changes

Outage

Critical

8

IP Routing, MPLS VRF changes

Outage

Major

9

Configure, Implementation of IP Access lists

Non Outage

Minor

Outage

Major

10

IP Network Elements failover/ redundancy testing incl. VRRP

Outage

Minor

11

VLAN, STP, SNMP, OSPF Configuration/ Modification

Outage

Major

12

Implementation of IP MPLS Network Security audit recommendations

13

Software Upgrade, patch/IOS implementation

Outage

Critical

l. No

IP & Security Activity

4.1.12 Network Change Request Severity Levels for 3G Activities Following are the classification of severity levels of the common 3G activities

Sr. No

Activity Name

Outage/Non Outage

Severity

1

3G Site creation

Non Outage

Minor

2

Re-homing of Sites

Outage

Major

22-04-2015 – D495740748 - 33 / 64


3

3G Parameter change

Outage

Major

4

LAC/CI changes

5

Enabling the HSDPA/HSUPA/HSPA

Outage

Major

6

Migration of Site from ATM to NATIVE IP

Outage

Major

7

Broad Band expansion of Sites

8

Frequency Retune(SC tune)

Outage

Critical

9

Transmission change(COCO Modification)

Outage

Major

10

3G Site Integration support

Non Outage

Minor

11

Licenses Up gradation

Non Outage

Minor

12

Software Up gradation

Outage

Critical

13

CMDB Updating (3G)

Non Outage

Minor

14

Maintenance Region Attachment

15

View creation in the TLUI

Non Outage

Minor

4.1.13 Change Request: Acknowledgement & Analysis After assigning CR to himself/herself, status in tool automatically changes the state of CR from “assigned” to “acknowledged “.Now the Originator needs to attach following additional information: •

Test Plan

•

Fall Back Plan

•

MOP (if required)

•

Any other information, if needed.

4.1.13.1 Test Plan Wherever applicable, Pre and Post test plan should be included for all planned pre and post testing scenarios. E.g. health checks before and after load of software, logs before the CD load, and logs after the CD load, backup of configuration before the CD load etc. For Minor CRs, the Pre- and Post Test plan may not be applicable, so the field can be filled as NA (Not Applicable).

4.1.13.2 Fall Back Plan Fall back plan must be created to secure system availability in case of a change request execution failure except for Minor CRs, the fall back plan may not be applicable, so the field can be filled as NA (Not Applicable). 22-04-2015 – D495740748 - 34 / 64


The fall back plan must ensure that the system can be rolled back in time for change request. Fall back procedure is included and fall back time separately specified

4.1.13.3 MOP Method of Procedure (MOP) should be attached in the CR wherever necessary

Originator needs to select Executors for the CR and if there are multiple executors, includes them in the additional modification field in the tool of CR which is just below the executor field. Then Originator needs to provide following information in the CR: •

Requested End Time

•

Planned Down Time

•

Execution Start Time

•

Execution End Time

Originator must provide enough time for execution window to avoid rejection of CR due to execution window expired. If no. of CRs more than certain limit, then executor may not implement all those CRs in the same maintenance window. CR status is now changed to “analyzed” and now the Originator can add the approvers or the predefined approvers can automatically added to it.

4.1.14 Change Request Approval Approval process follows sequence depending on severity of the CR – for minor CR one level of approval is required and for major and critical CRs 2nd level of approval is required as explained. The Approver upon receipt of a CR authorization request through mail and SMS, acknowledges it in the tool and the authorization request enters into the “Acknowledged” state. Prior to approving the CR, the approver needs to review the network impact and risks involved in the operation. The approver should Check Change Request for the following: •

Network change description

•

Network Elements involved

•

Reason for the CR

•

System/Service impact

•

Implementation time and duration

•

Test Plan

•

Method of Procedure

•

Fall-back procedure

•

Executor

•

Impact on work at hand

•

Cost of re-work/updating documents

22-04-2015 – D495740748 - 35 / 64


•

Materials made obsolete by the change

•

New or modified testing, if appropriate

•

Earliest implementation dates

•

Impact on other documentation, records etc.

•

Whether vendor agreement to the change is necessary

If the CR is acceptable to the approver then the CR is approved by the approver. The final responsibility for any discrepancy related to frequency plan will lie with the Circle Functional Head In case of CR (all types – critical, major, minor),, involving outage, Customer approval is also required, which is obtained by the originator through mail and the same can be attached in the CR in the tab additional information of the tool at the time of creation of CR along with other documents as Pre & Post test plans, Fall Back plan MOP

Originator has to add the customer as an approver in the tool same way as adding the other NSN internal approvers or if there is no access of tool to customer then circle SPOC has to take the customer approval through email and attach that to the tool.

Approver can reject the CR with providing the reason of rejection. In such cases the originator may create a new authorization request (to add approvers) for the CR if required. In case of emergencies, there is a provision of “Emergency Authorization” of CR in the tool. The originator can authorize the CR by self after getting verbal/ sms confirmation from the approvers. But in such cases intimation will go to all relevant level of approvers and it is the responsibility of the originator to regularize the authorization by attaching the email approval to the tool before closer of the CR. All Change Requests need to be duly approved by the competent authority at different levels depending on the severity of the change. It is the responsibility of the Change Request Originator to include the different levels of approvers in the CR accordingly. Level1- Functional Lead/ Function Manager Level 2- Cluster Head Level 3 – Customer

To obtain the required approvals for a CRF for Bharti-MS is as per below table:

Category

Severity

NSN

Customer

Team Lead / Function Manager

Circle Head

Service Impacting

Emergency

Approval

Approval

Approval

Service Impacting

Critical

Approval

Approval

Approval

22-04-2015 – D495740748 - 36 / 64


Service Impacting

Major

Approval

Approval

Approval

Service Impacting

Minor

Approval

_

Approval

Non Service Impacting

Major

Approval

_

Notification

Non Service Impacting

Minor

Approval

_

Notification

** For all regulatory changes customer approval should be taken irrespective of the change is service affecting or not.

Approval Matrix for VF account

Severity

Category

Team Lead

Manager

Circle Head

Customer

Emergency

Outage

No

Yes

Yes

Yes

Critical

Outage

Yes

Yes

Yes

Yes

Major

Outage

Yes

Yes

Yes

Yes

Minor

Outage

Yes

Yes

No

Yes

Major

Non outage

Yes

Yes

Yes

Yes

Minor

Non outage

Yes

No

No

Yes

The CR should be first approved by the Functional Lead/ Functional Manager. For critical/major CRs, the 2nd level approver is Circle Head. The notification of Critical/Major CRs should reach the Concerned Team once the CR is approved. The Final Nokia approved CR has to reach the customer for approval. Once the approval process is done the CR will move to the executors bucket (GNSC / Circle) for implementation. All regular changes reaching the executor after the cutoff time, which is 6:00 PM, will be tried with best effort, if the bandwidth permits.

If any of the approver are on vacation or are traveling, he / she must delegate their approval power to someone else by email. 22-04-2015 – D495740748 - 37 / 64


The non services impacting Minor CRs can be raised, approved and sent to executor at any time.

For Urgent/Emergency changes, the CRs can reach after the cut off timings. The approval for the urgent changes can be taken on SMS/email/call, but has to be regularized the next working day. The responsibility of getting the CR regularized in such cases lies with the CRF originator. But urgent CRs from one circle should not become a norm and so the number of such CRs will be tracked as a percentage of the regular change.

4.2

Change Request Track & Manage by PT4 Tool

4.2.1 Change Request Workflow in PT4 Tool

Originator

Approver will get notification to approve the CR i AR

Executor/ Originator

Originator

The back arrows indicate that it can be move back to previous state.

22-04-2015 – D495740748 - 38 / 64


4.2.2 Approval Workflow in PT4 Tool (for approvers)

Created Assigned Acknowledged

Reject

The status in the CR will remain as

Approved

The status in the CR will change to

4.2.3 Checklist for Executor during CR Execution

22-04-2015 – D495740748 - 39 / 64


BSC Planned Activity Checklist

4.3

Change Request Scheduling & Implementation

(Allocate & Install and Configure & Activate)

After authorization of the Change Request the executor receives intimation by SMS and email. Executor then changes CR status to “Scheduled” and then following information is required to be provided: Planned Disturbance Start Time Planned Disturbance End Time

In case Executor needs help of field level teams or third party, there is provision to create Task and assign to them. Task creation model is as under:

Started

Task Originator Created

Rejected

End

Assigned

Acknowledged

Pending

Task Executor Executed

Closed

Scheduled

Task Originator/ Executor

End

22-04-2015 – D495740748 - 40 / 64


For most of the Configuration issues, the GNSC CM team is the executor. GNSC (other executors) can validate if the CR can be technically implemented or not. If some other persons are also involved in the implementation, than the executor needs to plan the execution with concurrence of all other involve. For example, if the Software upgrade is being planned by the National Core Team / GNSC which requires local switch support, than the plan needs to be communicated to the local core Team and there availability confirmed. Any up gradation of OSS can hamper the proper working of the SAPRK tool so the information regarding the up gradation must go to the SPARK tools team so that they can upgrade the S/W in SPARK to avoid any issues. After task completion by the FLM/SDE or third party or by Executor himself Executor need to provide following information: •

Actual Disturbance Start Time

•

Actual Disturbance End Time

•

Real Impact on Qos (Quality of Service)

Now Status of CR can be changed to “Implemented”.  The process implementation is based on PT4 tool CM module.  For all the CRs which are to be implemented by the GNSC CM team/Circle team, the CR is assigned to GNSC CM team/Circle team for implementation while the CR is being created. The GNSC CM team/Circle team implements the CRs which are received after approval from the authorized person. 

GNSC CM/Circle team validates the change requests to see if the change can be implemented or not. The non-service impacting changes can be implemented in the network by the configuration management team during office hours. The service impacting changes (ex. network outages) are implemented during the network maintenance window only.



For all the CRs that need to be implemented by Circle teams (for example change in antenna, the change for Core activities) the CR is assigned to the Circle team while the CR is being created.



The planned outage report which contains all panned activities of change management and preventive maintenance will be available with GNSC Alarm Monitoring Team for suppression of the alarms during the planned outages.



GNSC CM team/ Circle CM team (Executors) needs to verify the CR before implementation. At the time of Verification, if the executor finds any wrong selection by the originator for category (Outage/Non-outage) or any other critical fields in the PT4 tool which has an impact on the network after implementation, it should be flagged as incorrect by the executor. Then in this case the executor should contact the originator to re-schedule the outage CR as this could have been done only in the maintenance window.



Instead of rejecting the CRs, executor should reassign the CR to the Originator for CRs whose execution time expired or more information needed from the originator so that it can be planned next day

22-04-2015 – D495740748 - 41 / 64




As operational implementation is not with the circle team, executor is responsible for the correct operational implementation of the change Request.



All network service affecting planned work is always to be scheduled for implementation between 00.00 and 06.00 am (considering time for eventual fallback). In case of deviations for specific reasons a joint agreement between the originator and approver should be decided keeping the network service availability in mind. BTS outages activity is to be done during normal working hours in case there is no 24 x 7 hours access to the site, or traffic is very less (limit to be decided). The approval for these outages in the day time should be taken from the customer. The BTS work must be planned cell-by-cell.





Working with antenna feeder’s antennas etc must be carried out in daylight for safety reasons hence the CR should consider suitable timeframes.

Below table illustrates the suggested planned works window, note that service impact planned work needs a shorter window if fall-back is needed.

Maintenance type

Preferred hours

Planned work, no Service impact (Severity minor and major)

Daily, All Day

Planned work, service impact (Severity minor)

Daily, 06:00

00:00

–

Planned Work , Service Impact (Severity Critical and Major)

Daily, 04:00

01:00

–

The maintenance window for planned outage BTS level activities has been extended till 07:00AM for VF operation only

Attached file illustrates the guidelines for execution timeline for Non-Outage CRs applicable for VF account only.

Guidelines for Non-Outage CR Exect

4.3.1 Change Request Pending The CR can put in “Pending” stage from the Authorize /planning / Implementation stage, for some specific reason. For example, if the customer wants to delay the implementation of a particular CR by 2 days, it can be 22-04-2015 – D495740748 - 42 / 64


put in Reject/Pending stage. If the resources are not available during planning stage, the CR can be put in the pending stage. If during the implementation stage for example, if some critical alarm comes on the network element, the CR can be put in the pending stage.

4.3.2 Change Request Rejection The CR can be rejected (withdrawn) by the executor due to any reason after it is authorized. For example, if the customer does not want to implement a particular CR, it can be put in rejected stage. If the resources will not be available for a long period of time, CR can be rejected. If there is a request from the originator to reject the CR

4.4

Test the Change Request

When CR implementation is finished the status in the PT4 tool will change from scheduled to implement. The tester group which is selected by the originator during creation of the CR will test the execution and if satisfied with the result, the respective tester group will change the status of the CR to “Tested” and closed.

* Verification (Testing after implementation) of the correct implementation is responsibility of the GNSC.

For example if there is a frequency change plan for 200 sites, then after implementation of the CR the executor has to take a dump and compare the changed frequencies with the CR raised by the originator

* If the change requires the field verification, then the final verification is the responsibility of the circle team. The requirement of field testing is supposed to be clarified in the method of Procedure (MOP) document for each activity (MOPs of all CR should exist)

4.5

CM Process Reporting

4.5.1 CM Planned outage activity report for manual process A Daily Schedule of the approved Change Requests must be circulated to all the responsible in NSN, Customer and other partners by GNSC. The template of the same is attached below:

Sr. NO. CRF No Circle 22-04-2015 – D495740748 - 43 / 64


Cluster Domain (Core/ BSS/ Tx etc) Network Node Severity Level (major /minor etc) Priority Outage/ Non-Outage File Name Planned Outage Date Planned Outage Timings Originator Originator Contact Phone Executor Executor Contact Phone Remarks

4.5.2 CM Daily Reporting for tool based process  GNSC will send a daily / weekly and monthly report on the total number of CRs to the circle and reports of major changes related to software upgrade needs to be stored for 10 years Continued…

Sr. #. CR No. CR Title Customer – Circle Site ID Domain (NSS/ BSS/ Tx. etc) Status Severity Level (major /minor etc) Priority(Urgent / Regular) Outage/ Non-Outage 22-04-2015 – D495740748 - 44 / 64


Originator Originator Contact Phone Acknowledged time Originator Assignee- User Originator Assignee- Profile Planned Execution Start time Planned Execution End time Planned down time Approver-1 Approver-1 Phone No. Approval time-1 Approver-2 Approver-2 Phone No. Approval time-2 Approver-3 Approver-3 Phone No. Approval time-3 Emergency Approver Name Emergency Approval Time Executor Name Executor Profile Executor Contact Phone Planned Disturbance Start time Planned Disturbance End time Execution Assignee- User Execution Assignee- Profile Actual Disturbance Start time Actual Disturbance End time Rejected by whom 22-04-2015 – D495740748 - 45 / 64


Rejected reason Rejected time Pending Reason Pending by whom Rollback by whom Rollback reason Rollback time Tested Time Close time

4.5.3 CM Process KPI Reporting Responsibility for adherence

KPI

Measurement Method

CR Authorized%

No. of CRs authorized during the reporting window / total CRs opened during the reporting window

CR Implemented%

No. of CRs Implemented during the reporting window / total authorized CRs opened during the reporting window

CM Manager/ GNSC COM Head

No. of CRs rejected during the reporting window / total CRs opened during the reporting window

= [# of CRs with status as rejected and rejected time CM Manager/ in reporting window] / [# GNSC COM CRs with created time in Head reporting window]

No. of CRs with pending status at close of reporting time/ total CRs authorized during the reporting window

= [# of CRs with status as pending at close of reporting window] / [# CRs with authorized time in reporting window]

CR Rejected %

Total CR Pending %

22-04-2015 – D495740748 - 46 / 64

Formula

Circle Head/Operation al Director



KPI

On Time %

Outage not exceeded %

Measurement Method

Formula

No. of CRs implemented before execution end time during the reporting window / total CRs planned to be implemented during the reporting window

= [# of CRs with implemented time in CM Manager/ reporting window and GNSC COM implementation time<= Head planned execution end time] / [# CRs with planned execution end time in reporting window]

No. of CRs for which actual outage is less than scheduled outage / total outage CRs planned to be implemented during the reporting window

= [# of outage CRs with (actual disturbance end time - start time) less than planned down time] / [# of outage CRs with planned execution end time in reporting window]


= [Sum of total time from status changed to implemented from scheduled during reporting CM Average time taken to window] / [# CRs Manager/GNS implement a CR during implemented during C COM Head the reporting window reporting window]

Mean time to Implement

4.6

Responsibility for adherence

Change Request Close

The CR originator/Executor after verification of the correct implementation “closes” the CR. Before closing the CR the originator must provide the no. of site visit for that particular CR.

4.7

Change Request Rollback

In case there is an issue in implementation of the CR, the roll back plan is implemented and the CR is put in the “Rollback stage”. The following is updated in the action logs in the CR: •

All actions taken are logged

•

Reason for abortion is stated (If applicable)

•

Reason for failure (If applicable)

22-04-2015 – D495740748 - 47 / 64


5 Change Management Responsibility Matrix The table below summarizes the functions and responsibilities within this process:

Function GNSC Management

Responsibility Change Receive approved(authorized) Network Change Request Forms (CRFs) by Mail/PT4 Tool Prepare planned outage calendar and distribute the same to circle for information and to GNSC AM/FM team for alarm suppression (for both Manual and PT4 CRs) Verify and Analyze the CRF. Verification includes the important aspect of the implementation that is the category of the CRF (outage / non-outage) and here the executor has to ensure the category of CR before execution. Schedule CRFs according to resource availability Analyze and assign numbers to CRFs Check for data Error/Non standard format/lack of Network Capacity and revert back to initiator Execute Non Outage CRFs during day time unless specified Assign CRFs requiring outage to Team at night shift Implement and confirm changes by testing, verification of the correct implementation is responsibility of the GNSC Close the loop by informing initiator, Fault Management & Performance Management and other concerned parties. Maintain record of Changes implemented.

CRF Originators

Use standard CRF/PT4 Tool for the Network Change Request Send correct data without any errors for the change Selects the approvers Selects the Executor and if there are multiple executors, includes them in the section of Affected Parties in the CRF /Additional Modification field in PT4 tool. Send authorized CRF to Executor to initiate change as per below schedule for various activities.

22-04-2015 – D495740748 - 48 / 64


Provide Pre- and Post Test Plan Provide Fall Back Plan Include MOP in the CRF for critical and Major changes Maintain the evidence of the approvals when using excel version of the CR form Update Site Plus Tool for the CRF having SitePlus Tool Control No. If the change requires the field verification, than the final verification is the responsibility of the circle team. Close the CRF in the tool when migrated to the CR tool Functional Head CRF Approver

Ensure correct format has been used for the Network Change Request Impact Analysis of the change Technical correction’s of the Network Change Request Insure the CRF form includes pre- and post test plan and fall back plan

Circle Head CRF Approver

Ensure correct process has been followed for the Change A particular change is required.

Circle Head for Report Sharing.

Hard copy signed off Self certification every month by confirming that all current network configuration are standard as agreed / approved by Bharti and software /patches & firmware’s are from latest release.

National NPO and Core Team

Publish Method of Procedures (MOP)

Circle CM SPOC

Resolving any conflict of CRs in the same technology area (example: Software upgrade of a BSC and re-home of sites on this BSC)

Provide Support for Fall Back plan if needed

Take Customer Approval for manual CRs Store all CRFs for future Audit for manual CRs Send NSN approved(authorized) CRs to GNSC CM Team before 3 PM of the day for preparation of outage calendar for manual CRs

22-04-2015 – D495740748 - 49 / 64


Send Customer approved(authorized) CRs to GNSC CM Team before 5 PM of the day for execution for manual CRs CM Activities projection for the circle once in 15 days by 1st and 16th of every month to GNSC CM Team (Site Integration/Rehoming/BSC Migration/Freq Plan Implementation/Site Conversion/GB Definition/TCSM Expansion/Modification and etc) The circle CM also publishes CM MIS report on weekly basis which includes all the CRs implemented for the circle, by GNSC CM Team or Circle implementers. No conflict of CRs across different technology domains ( example: software upgrade on a MSC and re-home of BSC on this MSC) SPOC also coordinates with GNSC CM SPOC for Planned Outage Calendar GNSC CM Team

Validates all CRs for technical viability before execution Compile the Planned outage calendar for each circle and send to circle SPOC for customer approval before 3.30pm for manual CRs Send daily report per circle for all the CRFs for the previous day No conflict of CRs in the same technology area (example: Software upgrade of a BSC and re-home of sites on this BSC) No conflict of CRs across different technology domains ( example: software upgrade on a MSC and re-home of BSC on this MSC) Resources are available in GNSC to take care of volume of the work for the night Compile the planned outage calendar per Circle and send it to the circle for information. He also sends the Planned Outage Calendar to FM team for Alarm Suppression. Send daily report per circle for all the CRs for the previous day in case of manual CRs

* The circle team is responsible for the impact that the particular change will bring in to the network after implementation of the CR raised by them. 22-04-2015 – D495740748 - 50 / 64


5.1

SitePlus Tool should be updated for the below activities

At the time of CR execution if any equipment needs to be changed in the system than the details of that equipment should be updated for inventory, so that this will reflect in the Inventory Dump.

Sl. no

CR Activity

Outage/Non outage

Severity

1

E1 provisioning and link design

Non outage

Minor

2

New Sites

Non outage

Minor

3

New Transmission media

Non outage

Major

4

New Core Node

Non outage

Major

5

CGR definitions creation or update

Non outage

Minor

6

Antenna Down tilt

Non outage

Minor

7

Azimuth Change

Non outage

Minor

5.2

Contingency Plan

Contingency Plan Breakdown Event S.N. OSS link to MSC / BSC PT4 GNSC link to OSS Server

1

2

Not Working

Working

Working

Circle BSS, Core and Transmission teams to take over urgent CR execution for their respective functions. Circle teams to give details Working of the CRs executed during link down time in excel format to GNSC and the same to be uploaded in PT4 for recording purpose

Working

Circle and GNSC both have to follow the Manual Excel CR form to execute urgent CRs. All Not incidents to be recorded in excel sheet and same Working to be uploaded in PT4 when it is up, details are mentioned below.

22-04-2015 – D495740748 - 51 / 64

Work Around


6 Implementation with excel CR Form (in case tool is not operational for longtime) The process implementation is based on the excel version of CR form. For all the CRs that needs to be implemented by the GNSC CM team, the GNSC CM team implements the changes to the network according to the Network Change Request Forms (CR’s) received with due approval. GNSC CM Team validates the Network Change Requests to see if the change can be implemented or not. The non-service impacting changes are implemented in the network by the configuration management team during any time of the day. Changes which required network outage are implemented during the network maintenance window. For all the CRs that need to be implemented by Circle Teams, for example CRs for Core etc., the information about the approved (authorized) CRs still need to be sent to GNSC CM team, so that it can be included in the planned outage report for that circle. This planned outage report is sent to the GNSC Alarm Monitoring Team by GNSC CM team for suppression of alarms during the planned outages. This planned outage report should also include the preventive maintenance activities if any.

SLA/OLA th

Below SLA/OLA is 5 level of eTOM model:

6.1

SLA/OLA of Originator, Approver and Executor

OLA for whom

OLA Definition

Originator- Creation to Assignment

Time for creation of a CR "Time of acknowledgement to time of assignment in Authorization Request" OLA= 8 hours Escalation: First email to self at 8 hours, Second to self and manager at 10 hours

Approver- 1st Authorization

Time for first authorization "Time since assigned to approver in Authorization Request to time when first approved / authorized" OLA= 24 hours Escalation: First email to self at 24 hours, Second to self and circle head at 48 hours

Approver- 2nd Authorization

Time for second authorization "Time since first approval to time when finally approved / authorized" OLA= 24 hours Escalation: First email to self at 24 hours, Second to self

22-04-2015 – D495740748 - 52 / 64


OLA for whom

OLA Definition at 48 hours

Executor- Approval to Implemented

Time for implementation "Time since authorized to time till implemented" OLA= Time since authorized to planned execution end time Escalation: First email to self at 100% of time lapse, Second to self and manager after 200% of time lapse

"Executor + Originator"Implemented to Tested

Time for testing "Time since implemented to time till tested" OLA = 14 hours Escalation: First email to originator and executor at 10.5 hrs, second at 14 hrs, third to originator and executor and their managers at 28 hours

"Originator"- Tested to Closed

Time for closing "Time since tested to time till closed" OLA = 24 hours Escalation: First email to self at 24 hours, Second to self at 48 hours

6.2

Change Requests SLA – BSS CM Activity

Turn-around time (All requests to reach Executor by 6 PM)

New Sites Creation

3 Days

BTS Sites Re-homing

2 Days

New GB Definition

2 Days

GB Capacity Modification

2 Days

Cascading Changes (Separate E1)

2 Days

Timeslot shifting for the Metro Hub Implementation

2 Days

Ext Alarms Definition

1 Day

TRX Addition/Deletion

1 Days

New Sites integration support

3 Hrs

22-04-2015 – D495740748 - 53 / 64


CM Activity


TCSM Addition / A Interface definition / Pool 2 Days Modification integration support TRX Addition - Field Support

3 Hrs

External Alarm verification from the Field for new 3 Hrs Sites BSC Migration from one MSC to Other MSC

4 Days

Coordination for Drive test

3 Hrs

Support to Extend the ET for the New Sites/TCSM/GB

3 Hrs

GENA Y/N Toggling

1 Day

Frequency Plan implementation >=200 cells (New 4 Days Plan Creation & Activation of the Existing Plan) Neighbors Addition/Deletion

1 Day

RF Para meter Chances (Mal,Ho …etc)

1 Day

Cell level GPRS/EDGE definition

1 Day

Ultra <> Metro <> Talk site conversion

2 Days

TCHF/TCHD implementation Cabinet Expansion/Segmentation

2 Days

Sector Addition/Deletion

2 Days

Old Sites Deletion

1 Day

Site Naming Change ( ZZ && ZQ && ZL )

1 Day

AMR implementation (from BSC to TCSM complete) TCSM addition testing (One by one all PCM)

3 Hrs

BSC Measurements Activation

3 Hrs

TCSM Features Modification(DTX ON)

1 Day

Command Output Logs as on when required

1 Day

New Feature Implementation like intelligent BTS Shut 2 Days Down 22-04-2015 – D495740748 - 54 / 64


CM Activity


Q1 Channel Definition for Monitoring the Flexi hopper 1 Day from the NMS Supporting Logs for the Case raised by the Circle. BSC Capacity Modification -BCSU removal Deletion of all definitions attached to the BCSU

1 Day – 2 Days

BSC Software Upgrade

Planned Event Window Time

BTS software Upgrade


Note: The above SLAs are from 1st to 23rd of every month and provided the work projection is given from the circle team by 1st and 16th of every month. If the request is sent for CM changes after the 23rd of the month, the request will be implemented on FIRST COME FIRST SERVE basis.

Note: Upon New sites integration/Sites Migration/Cabinet Expansion and CI changes the GNSC CM team will inform circle activity SPOC /FOPS team by phone to make necessary changes at the MSC end.

6.3

Change request SLA - Core CR Activity

Turn-around time ( All requests to reach Executor by 6 PM)

CD Loading

3 days

BSC Re-homing

2 days

Service outage Hardware Maintenance

3 days

Version upgrade


New Node integration

3 days

New Service activation

3 days

Core node parameter Changes

3 days

Hardware expansion

3 days

New POIs addition

3 days

22-04-2015 – D495740748 - 55 / 64


POI E1addition

2 days

Signaling rerouting

2 days

Traffic rerouting

2 days

Redundant Node Hardware changes

2 days

Hardware Expansion

2 days

Alternate routing for Voice

2 days

Non Service impact hardware Changes

1 Day

Ater Addition

1 Day

Inter MSC E1 Addition

1 Day

Addition of signaling links

1 Day

BTS site creation

1 Day

New GT addition

1 Day

Roaming configuration

1 Day

B number changes

1 Day

Backups

Maintenance Window Time

Alternate routing definition for Signaling

1 Day

6.4

Change request SLA – Transmission

CR Activity


New Transport Hops [MW Radio or MUX] provisioning in creating a New and within the Operational Network

2 Days

Capacity, configuration, set up and regular parameters setting changes in Transport nodes - MW Radio and MUX w.r.t. planning docs.

12 Hours

Changes in NMS and DCN.

1Day

Installation related and physical in nature changes in Transport nodes - MW Radio and MUX w.r.t. planning docs.

1Day

User creation for Transmission NMS.

12 Hours

22-04-2015 – D495740748 - 56 / 64



1Day

Management of back up for eqpt configuration.

1Day

Synchronization parameters setting changes in Core Sync and Transport Network or node w.r.t. planning docs.

1Day

New Transport Circuit E1/Ethernet etc. links Provisioning in creating a New and within the Operational Network

1Day


1Day

Swapping of the Transport hops.

1Day

Software, version Upgrade

1Day

Discarding old products.

1Day

6.5

Change request SLA – IN & VAS CR Activity

Turn-around time ( All requests to reach Executor by 6 PM) NSN IN

Comverse IN

Ericsson IN

New Product Configuration

48 Hrs

Minor 24 Hrs Major 48 Hrs


Old Product Deletion

24 Hrs

6 Hrs

48 Hrs

New Level/Code Opening in Tariff Tool

2 Hr

6 Hrs

4 Hrs

New Level/Code Opening in Allowed list

2 Hr

4 Hrs

Short Code Configuration

24 Hrs

8 Hrs

4 Hrs

Tariff Changing in Existing Product

24 Hrs


24 Hrs


3-4 Hrs

6 Hrs

15 Mins

30 Mins

New/ Modification in Recharge Definition

6 Hrs

Etop/Euronet Grids Configuration

6 Hrs

22-04-2015 – D495740748 - 57 / 64


Vouchers Creation/Activation/Purging

24 Hrs

Creation -2 Hrs (5 lakh Batch) approx. Activation - 24 Hrs (5 lakh Batch) approx. Purging - Depends upon the Qty. 2 Hrs

Voucher state change from Pending to Enable

1 Hr

NA

Retailer Margin configuration in ETOP

1 Hr

6 Hrs

30 Mins

Periodic Rental Changes

24 Hrs

4 Hrs

30 Mins

Promotional Messages Change on USSD/PCN/SMTP

2 Hr

3 Hrs

New PID/Series configuration on NMS

24 Hrs

NA

NA

New Promo Plan Configuration

24 Hrs

24 Hrs

24 Hrs

Roaming Tariff Change

48 Hrs

24 Hrs

4 Hrs

24 Hrs approx (5 lakh Batch)

8 Hrs

Subscriber/ Promo plan Provisioning Monitoring


4 Hrs

Voucher State Change Process Monitoring

24 Hrs approx (5 lakh Batch)

3-4 Hrs

3-4 Hrs

30 Mins

Bulk Commands for Promo Plan Offers

System Backup & Restoration

Automatic

Non Outage -45 Min Outage Restoration Depend on the System & Database Size

C7 Link Expansion & Configuration

24 Hrs

Non Outage - 1 week

2 Hrs

Critical - 6 Hrs Major - 24 Hrs

10 Hrs

Critical - 30 mins Major -1 Hr

Critical - 30 mins

Subscriber Range Move/ Load Balancing SS7 Traffic shifting

22-04-2015 – D495740748 - 58 / 64

2 Hrs

Non Outage - 2-10 Hrs Outage Restoration Depend on the System & Database Size


Major -1 Hr New Application Integration

Depends 1 week upon the new application

1-2 Days

NSN Products NBG:User agent baring

30 min

NBG: System Backup

30 min

NBG: Restore (if required)

1 hour/2 hour

NBG:User /Group/Access Rights / Password Creation, Modification & Deletion

NA

NBG: Proxy feature configuration

30 min

NBG: Optimization feature configuration

30 min

NBG: Push configuration

30 min

NBG: Authorization configuration

30 min

NBG:LDAP interface configuration

30 min

NBG:ICAP interface configuration

30 min

NBG: Radius support configuration

30 min

NBG: Multipart support configuration

30 min

NBG: Licensing configuration

1 hour/2 hour

NBG: Logging configuration

30 min

NBG: Monitoring configuration

30 min

NBG: Profiling configuration

30 min

MMSC:MSIDDN Series Baring for white list / black list

30 min

MMSC: Change the profile is NPS server for Specific MSISDN depending on the request

30 min

22-04-2015 – D495740748 - 59 / 64


MMSC: Application creation for push message

1 hrs

MMSC:CDR Backup

1 hour/2 hour

MMSC:IACC configuration

30 mins

MMSC: Inter MMS Series Definition

30 mins

MMSC: New Operator Integration

1 hour/2 hour

MMSC: Mail gateway configuration

30 mins

MMSC: Polling and Retry Configuration

30 mins

MMSC: Update Patch Installation

30 mins

MMSC: User /Group/Access Rights / Password Creation, Modification & Deletion

NA

CMD: Workflow Switchover for prepaid and postpaid

30 mins

CMD: User/Group Password Modification/ Rights Modification

NA

CMD: Load Balancing of EC's for Prepaid and Postpaid

1 hrs

CMD: Changing RAM Size for EC's

1.5 hrs.

CMD: Addition of new External entities

1 hrs.

CMD:EC switchover in case of any outage for one server to another server

2 hrs

CMD: License Management

2 hrs

CMD: Data Call testing configuration

1.5 hrs

CMD: External/internal IP address Creation/ Deletion.

1 hrs

SMSC: LA (Large Account) addition for new applications/CP for TPS & Session allowed.

1 hrs

SMSC: New series addition

30 mins

22-04-2015 – D495740748 - 60 / 64


SMSC: Inter SMSC configuration changes required to communicate with other SMSC(Within PLMN or other PLMN)

2 hrs

SMSC: License addition on the base of subscriber base addition

1 hrs

SMSC: Configure the TON/NPI parameters for MO/MT messages.

30 mins

SMSC: White list/Blacklist of MSISDN on SMSC.

30 mins

SMSC: Shortcodes routing

1 hrs

SGSN: Gb Link Creation / Deletion / Modification

1 hrs

SGSN:PLM Creation / Deletion

1hrs

SGSN:GT Analysis

1.5 hrs

SGSN:LAC Creation / Deletion

30 mins

SGSN:SCCP Routing Definition

1 hrs

SGSN: Backup

1 hrs

SGSN:SS7 Link set Creation/Deletion

1 hrs

SGSN: License Changes/ addition depend upon the request.

2 hrs

SGSN: Authentication Management for different level of user

NA

DNS:APN Configuration for national / International Operator

30 mins

DNS:LAC/RAC Entries

30 mins

DNS:Software Upgrade

Software dependent

DNS:APN resolution

15 mins

DNS: Authentication Management for different level of user

NA

Router: VLAN Configuration.

1 hr

Router: Routing changes in case of

2 hr

22-04-2015 – D495740748 - 61 / 64


any changes in the network. Router: SNMP configuration changes.

2 hr

Router: OSPF configuration changes.

2 hr

Router: Remote access Configuration

2 hr

Router: Authentication Management for different level of user

NA

Flexi-ISN: Addition of new IP pool

2 hr

Flexi-ISN: Addition of new APN configuration

2 hr

Flexi-ISN: Creation / Modification / Deletion in existing service , Flows & Service class

1 hr

Flexi-ISN: Modification / Deletion for level of analysis ( L4/L7)

30 mins

Flexi-ISN: Creation of new service provider

30 mins

Flexi-ISN: New Service Configuration

2 hrs

Flexi-ISN: Modification / Deletion if there are any changes in the IP backbone network.

2 hrs

7

Process Review Annually review of the process performance should take place involving, GDC, Customer Teams, Circle Operation Team and Process & Tools Team. Review of all KPIs and SLAs as defined in the process or as defined by Customer Teams from time to time should be a part of this review. Mode of review can be physical meeting, emails, WebEx or conference call.

7.1

Glossary The following acronyms, abbreviations and definitions are used in this document

Abbreviation

Meaning

NSN NBG GNSC

Nokia Siemens Networks Nokia Browsing Gateway Global Network Service Centre

22-04-2015 – D495740748 - 62 / 64


SLA PM OLA CRF DNS CMD TCSM

Service Level Agreement Performance Management Operational Level Agreement Change Request Form Domain Name Server Charge at once Mediate Transcoder Sub Multiplexer

Circle and Customer ID 7.1.1 Circle ID Circle

Circle ID

Delhi

DL

Haryana

HR

Punjab

PJ

Himachal Pradesh

HP

UP-E

UE

UP-W

UW

Karnataka

KA

R O Tamilnadu

TN

Kerala

KL

Andhra Pradesh

AP

Kolkata

KO

R o West Bengal

WB

Bihar & Jharkhand

BR

R o Maharashtra

MH

Odisha

OD

Gujarat

GJ

Rajasthan

RJ

Madhya Pradesh

MP

Chennai

CH

Mumbai

MU

Assam

AS

22-04-2015 – D495740748 - 63 / 64


Jammu & Kashmir

JK

North East

NE

7.1.2 Customer IDs Customer

Customer ID

Bharti

BH

Vodafone

VF(I)

Aircel

MX

22-04-2015 – D495740748 - 64 / 64

Remarks


Nokia Network Change Management Process_Ver 4.0A

Recommend Documents