NT9.1 SDH Network Takeover TL1 ED01

01 03/09/2010 Released M.Ierace Hu Xiaosong/S.Beretto

ED DATE CHANGE NOTE APPROVAL AUTHORITY ORIGINATOR

NT9.1 Management Domain Change Migration Guideline

NT9.1 -SDH Network Takeover For TL1 NEs

ED 01 Released

Optics 8DG 31501 AAAA TCZZA 1/31

©2010 Alcatel-Lucent - All rights reserved

3CK

0580

1 00

14 (

0311

) E

d.07

- A

4

NT9.1

Management Domain Change

Migration Guideline

SDH Network Takeover For TL1 NEs

ED 01 Released



TABLE OF CONTENTS

1 INTRODUCTION ........................................................................................................................................ 5

1.1 OVERVIEW ............................................................................................................................................. 5

1.2 REFERENCES........................................................................................................................................... 6

1.3 GLOSSARY AND ABBREVIATIONS ............................................................................................................ 6

2 SOFTWARE RELEASE AND NETWORK ASPECTS ............................................................................. 8

2.1 APPLICABLE SOFTWARE RELEASES......................................................................................................... 8

2.2 TESTED SOFTWARE RELEASES ................................................................................................................ 8

2.3 NETWORK ASPECTS ................................................................................................................................ 9

3 MIGRATION RESTRICTIONS ............................................................................................................... 10

3.1 TRAFFIC IMPACT................................................................................................................................... 10

3.2 EQUIPMENT RESTRICTION ..................................................................................................................... 10

3.3 TMN RESTRICTION ............................................................................................................................... 10

3.4 HARDWARE RESTRICTION..................................................................................................................... 11

3.5 NETWORK TOPOLOGY RESTRICTION ..................................................................................................... 11

3.6 NOT TESTED FEATURES ........................................................................................................................ 12

4 MIGRATION PROCESS GENERAL INFORMATION ......................................................................... 13

4.1 PRECONDITIONS ................................................................................................................................... 13

4.2 ORGANISATION..................................................................................................................................... 15

4.2.1 From organisation point of view ....................................................................................................... 15

4.3 APPROXIMATE MIGRATION TIME .......................................................................................................... 16

5 MIGRATION PROCEDURE .................................................................................................................... 17

5.1 PREPARATION SEVERAL WEEKS BEFORE................................................................................................ 17

5.2 PREPARATION JUST BEFORE THE MIGRATION......................................................................................... 17

5.3 UPLOAD PHYSICAL LAYER .................................................................................................................... 18

5.4 UPLOAD MULTIPLEX SECTION LAYER .................................................................................................. 21

ED 01 Released



5.5 UPLOAD COMPLETE SDH PATHS & TRAILS ............................................................................................ 23

5.6 NETWORK CHECKS ............................................................................................................................... 26

5.7 POST MIGRATION ACTIVITIES ............................................................................................................... 27

6 APPENDICES ............................................................................................................................................ 29

6.1 APPENDIX A : ROLLBACK PROCEDURE............................................................................................... 29

6.2 APPENDIX B : MISALIGNMENT ANALYSIS .......................................................................................... 31

ED 01 Released



DOCUMENT HISTORY

External

Edition

Edition Date Description of Change

01 2010-08-26 Released

1 02/09/2010 Delivery of the official migration Guideline.

The technical part has been originated by NI department

(Originator:Hu Xiaosong /).

The Product/Project management part has been updated by

S.Beretto (Product Manager).

ED 01 Released



1 INTRODUCTION

1.1 Overview

Audience This document describes a transformation process defined for the Alcatel-Lucent

Optics Network Release. The intended readers are:

• Alcatel-Lucent Product Managers

• Alcatel-Lucent Field Engineers

• Alcatel-Lucent employees who have to plan or to execute migration tasks.

• Alcatel-Lucent Project Managers

This document contains Alcatel-Lucent proprietary information and shall not be

released to customers without prior written confirmation Transformation Product

Manager.

Scope This document describes how to do SDH network takeover for Alcatel OND products on 1350OMS-SDH.

Feedbacks

mailing list

A feedbacks mailing list is available in order to improve this guideline.

In case of :

• errors

• misunderstandings

[email protected]

Conventions

and Notations

In this document, Shell commands are described using following conventions :

A string of characters in bold must be typed as written in this document.

One or more letters in angle brackets represent command parameter(s) which value(s) must be specified by the operator.

A string of characters in bold and Courier New represents a command line, see the following example :

...,alcatel> ./ cd /usr/Systems/<EML instance>/script

ED 01 Released



1.2 References

Installation and

Administration

1 1350 OMS EML 9.1 Administration Guide 8DG 41925 LAAA VOL3

2 1350 OMS SDH 9.1 Administration Guide 8DG 41925 LAAA VOL6

Operator's

Handbooks

3 1350 OMS EML 9.1 User Guide 8DG 41925 BAAA

4 1350 OMS SDH 9.1 User Guide Vol 1 Basic Management 8DG 41925 CAAA

VOL1

5 1350 OMS SDH 9.1 User Guide Vol 2 Enhanced Solutions 8DG 41925

CAAA VOL2

1.3 Glossary and Abbreviations

Terms and

Abbreviations

Below is given a list of terms and/or abbreviations used in this document.

AM Alarm Management

CM Config Manager

DCN Data Communication Network

DDTs Distributed Defect Tracking System

EHU Equipment Hardware Upgrade

MDC Management Domain Change

NE Network Element

NRU Network Release Upgrade

PM Performance Management

R&D Research and Development

RAM Random Access Memory

TEC Technical Expertise Center

TMN Transmission Management Network

ED 01 Released



TNO Topology Network Optimization

ED 01 Released



2 SOFTWARE RELEASE AND NETWORK ASPECTS

2.1 Applicable Software Releases

Scope This section provides information as to which products this migration procedure can be applied. Please consult the list below to find all the software releases to which it can be applied.

TMN

Software

Releases

NR9.2 1350 OMS-HPUX 9.1.1.14.6 or above

EML 9.1.1.40 P12, RP4, RP5 ... RP16 or above

SDH 9.1.1.41 P08, P10, P11, P12, P13, P14 or above

NE

Software

Releases

TSS320 3.2（3.21.60）or above

TSS160 3.2 （3.21.60）or above

Migration Tools No migration tools was used

2.2 Tested Software Releases

Scope The following software releases were used during the validation tests. Below is a list of all the Software releases to which this procedure was applied.

TMN & NE

Software

Releases

1350 OMS-HPUX 9.1.1.14.6

EML 9.1.1.40 P12, RP4, RP5 ... RP16

SDH 9.1.1.41 P08, P10, P11, P12, P13, P14

TSS320 3.2（3.21.60）

TSS160 3.2 （3.21.60）

ED 01 Released



Migration Tools No migration tools was used

2.3 Network Aspects

Scope The chapter below describes a part of the network aspects used for the validation of this migration procedure.

Network

Topologies

The Migration was tested in 2F-MS-SPRing, SNCP and MSP topology.

DCN During tests the TL1 NEs were directly connected to the IP+OSI Lan (no IP over OSI and no OSI over IP was configured).

Traffic The following traffic types were tested and monitored during the Migration:

SDH:

SDH AU4

ED 01 Released



3 MIGRATION RESTRICTIONS

3.1 Traffic Impact

Scope

No Traffic Impact

3.2 Equipment Restriction

Scope

3.3 TMN Restriction

Scope This section describes the restrictions on TMN during the migration.

General

Restrictions

No 4F-MSPring take over support .

No customized Alarm Severity Assignment Profile take over.

No threshold profiles take over.

No Performance Monitoring setting and data take over. The Path/Trail take-over feature does NOT include take-over of PM measures(this is according to requirements and specifications). Only 24h measures are automatically enabled, but just because this is SDH default behaviour (i.e. it does not depend on the fact that they are already enabled or not on the NE).

Network freeze During the migration process, the configuration containing all the NEs to migrate should be stopped. No implementation or de-implementation on paths passing through the NEs under migration has to be performed.

The only allowed operations should be:

ED 01 Released



• alarm and performance monitoring

• definition, allocation and de-allocation of paths

Important: no implementation or de-implementation on paths passing through the NEs under migration has to be performed.

3.4 Hardware Restriction

Scope

No Hardware Restriction

3.5 Network Topology Restriction

Scope

The take-over of Ethernet path (virtually concatenated or not) is not available.

It is not possible to obtain an X path if the main and the spare route are completely disjointed; in this case, two paths will be created.

There are particular configurations that the take-over process is not able to manage or it should be chosen how to manage them (e.g. because there are different possible choices).

In particular:

• 140Mb transport not-terminated on both sides are handled as paths (and not as trails)

• unidirectional paths with only two legs ending on two different nodes (or on a single virtual node) are treated as broadcast (and not as Y paths)

• SNCP paths/trails that have two branches ending on the same External-Network are automatically closed by the system on a single NAP (i.e. they are not treated as an Y path or trail)

• SNCP paths/trails not-terminated on both sides (even if terminated with bridge&switch connections on the real NEs), cannot be recognized as they are (i.e. as an X paths) and are thus uploaded as we separate paths

ED 01 Released



• paths terminated by two PDH ports are treated as PDH paths, even if they can also be of ATM type (ATM paths can have two, one or no ATM ports)

• concatenated path are created only if all physical connections the path is using have the correct concatenation configuration

Note : No traffic hits is expected during the transformation process.

3.6 Not Tested Features

Scope

Data traffic not test

ED 01 Released



4 MIGRATION PROCESS GENERAL INFORMATION

4.1 Preconditions

Scope Before migration begins, all preconditions listed below have to be checked for each involved network.

Note: This task has to be done by the migration project team as early as possible.

Read documents You must have a look to the list of documents put in section 1.2. It is your responsibility to decide what you need to read.

DCN The DCN requires the following items to be fulfilled :

• DCN must be designed according to the NR9.2 requirements

• OSI+IP connectivity between the 1350MS and all the NEs

• The DCN must have high availability and be stable

Remote access from Alcatel-Lucent to the customer premises should be configured to allow Alcatel units to logon in case of serious problems

Passwords The following passwords are needed during Migration:

• UNIX password for root user of 1350OMS

• MS-GUI password for at least one user with administrator-profile

Licences and Keys All needed licenses and keys are identified in the NR9.1 PL1 product documentation.

During the Migration no specific Licenses are needed.

Support Prepare a list of phone numbers of people who can help you in case of problems during migration. Don’t forget to inform those people about your planned migration, so they are prepared for your questions and can be contacted during the migration.

Network Backup Before migration starts, perform a data backup on customer network.

This backup could be used to recover from failure during migration (see Rollback procedure described in Appendix A).

Other-

precondition

All the NEs are to be reachable via DCN and supervised by EML

No provisioning at all is allowed at EML/CT level during the network takeover

Each step can be executed only if the previous one is completely successful.

ED 01 Released



Network Topology

plan

To plan(together with customer) the definitions in 1350OMS-SDH Network(s), sub-network, external networks, all the physical connections that related with External-Network.

Sub-network, external networks, all the physical connections that related with External-Network can’t takeover from 1350OMS-SDH.

ED 01 Released



4.2 Organisation

4.2.1 From organisation point of view

Planning The whole migration must be planned in detail, including following constraints :

• Human resource planning

• Access to customer sites

• Remote access for Alcatel-Lucent units in case of serious problems

• Preparation (see preconditions in section 4.1)

• Migration time (see § 4.3)

Manpower The amount of manpower needed depends on the network size and migration planning.

People performing the migration should have the following skills :

• Knowledge of the 1350 OMS 9.1.1 MNT-2 platform

• Knowledge of the equipment

Calamity and

Recovery

Procedures

Before the migration begins, establishment of procedures on calamity handling and how to recover the network, is considered wise (see sections 1 and 5).

ED 01 Released



4.3 Approximate Migration Time

Migration Time In order to be able to organise needed resources, the migration project leader can use approximate migration times given in table below about various actions and tasks to be done during the migration.

SDH Network Takeover

Action

Duration

Downtime of:

Supervision Traffic

Preparation several weeks before 1 day NO NO

Preparation just before the migration 4 hours NO NO

Take Over physical connetcions 15 min per NE NO NO

Take Over NPAs 15 min per NE NO NO

Take Over Path 10 min per NE NO NO

Times are given assuming involved field engineers are skilled and no unexpected troubles occur. Some extra time for troubleshooting and unexpected situations is usually required to be taken into account in the calculation of the total time of a migration.

Table 1 : Approximate time for NT9.1 - Management Domain Change-SDH Network Takeover For TL1 NEs

ED 01 Released



5 MIGRATION PROCEDURE

Introduction This chapter describes in details, sorted by main steps, the actions to be done during SDH Take Over. Last section focuses on post migration activities (e.g. Verify correctly working network).

Notes :

Preconditions listed in section 4.1 have to be checked before migration begins.

In case of serious problem during or just after migration, you can use procedure described in Appendix A.

5.1 Preparation several weeks before

Scope Before starting this procedure, certain preparations have to be done in order to ensure a successful migration. These preparations are described below.

Before starting the migration, perform a complete Network Backup of the involved SDH & EML Domain. This will assure that in case of a failure you are able to restore the backup and recover without traffic impact.

Perform the backup according to the system administration guide and check carefully backup log files to make sure the backup was successful.

5.2 Preparation just before the migration

Scope The activities described in this chapter should be done immediately before the migration.

Verify Start

Condition

Just before you start the migration, you must verify the network is stable and that you don't have any unexplainable alarms.

Do the following on the EML and/or SDH:

Verify EML and SDH are started and running the correct software.

Make sure that the EML and SDH are aligned with the Network Elements. If this is not the case, you must fix this first.

Check MIB

Alignment

(optional)

Optionally, a consistency Audit/Download on the Network Element to be migrated can be done. If this operation has been performed quite recently, it could be decided to skip this step; but it’s recommended to perform it. This operation allows to be sure that there were no misalignments before migration and allows to simplify the analysis of the misalignments after the migration.

ED 01 Released



Do the following steps :

• Perform: Search -> Physical -> Nodes from 1350OMS view.

• Select the NE to be migrated from the nodes list.

• Disable download, Execute: Actions -> SDH -> Configure Download -> Disable.

• Execute: Actions -> SDH -> Consistency Audit -> Mark Audit.

• Enable the download: Execute Actions -> SDH -> Configure Download -> Enable.

Minimize

Alarms

Before starting the migration you should try to minimize the number of alarms on the NEs to be migrated. Analyze carefully the current alarms, from EML and from SDH, raised on the NEs to be migrated and try to clear as much active alarms as possible. After the migration, you will be able to analyze which alarms are caused by the migration process and which alarms have already existed before the migration.

Important: Printout or take notes of the current alarm lists from EML and SDH managing the NEs to be migrated.

Network

freeze

From this point onwards no configuration has to be done on the affected part of the network. This must be clearly communicated to the customer! This restriction will remain until the migration is completed!

The only allowed operation should be:

• alarm and performance monitoring.

• definition, allocation and de-allocation of paths.

• creation of planned PM measurement.

Important: no implementation or de-implementation on paths passing through the NE under migration have to be performed.

5.3 Upload physical layer

Scope In this subchapter the users get all information on what has to be done to upload the physical layer into SDH. If the network’s size doesn’t fit with the maximum freezing time allowed by the customer the upload can be performed in several steps. Anyway it is not allowed to continue with the next chapter until the whole “physical” layer has been uploaded

Put NEs in

download

disable

Must put all involved NE as download disable. Otherwise, physical connection takeover will scratch the cross connections on NE.

1. Open the web portal of 1350OMS, Search->Physical->Nodes

2. Select one Network Element related to takeover action.

ED 01 Released



3. Change the configuration download state of the Network Element to Disabled.

4. Performing: Actions -> SDH -> Configure Download -> Disable.

5. Verify that the previous step was successful. ("Conf. Download Status.“ attribute of the Node is set to Disabled)

6. Repeat steps 2 to 4 for each Network Element related to takeover .

Note: NE download will not be enabled until finish 5.6 “Network checks” .

Upload and

implement

physical

connection

1. Select one Network Element related to takeover action.

2. Select Actions -> Physical -> Discover Physical Topology.

3. Select “Automatic Generation of Trace Identifier”.

4. As a result of the command, the sent value of J0 is generated for the selected port or for all the ports belong to the selected topology. Only if no value has already been set(The 1350OMS-SDH will not overwrite the NON-DEFAULT value). So, it’s recommended to check J0’s initial value on each SDH ports, and make sure

ED 01 Released



it’s empty or set by legal characters.

5. After “Automatic Generation of Trace Identifier” finished, click Back, select “Physical Connectivity from J0”, click Apply.

6. As a result of the command, the physical connections are automatically created for the selected port or for all the ports belong to the selected topology.

7. Implement all the discovered Physical Connections.

Repeat steps 2 to 7 for each Network Element related to takeover .

Note: Between step4 and step5 a break of at least 15 minutes should be done to ensure that everything will be correctly set, transported and synchronized.

Check/Creat

e the needed

connections

for TL1 NEs

and External

1. Check/Create all the needed External Networks in maps according to the network design or implementation;

2. List for each node’s appointed SDH ports (i.e. not yet involved in a physical connection; for each of this create the real physical connection towards the corresponding NE or the relevant external Networks (creating it if not existing)

ED 01 Released



Networks

Warning: For the physical connections with the external networks, must create and implement with the option ‘Preserve Au4 concatenation’ set to True (when relevant).

Upload NAPs

in SDH

From SDH, upload all the NEs’ NAPs:

1. Select one Node related to takeover action

2. Actions -> SDH -> Configuration -> Upload NAPs

5.4 Upload Multiplex Section Layer

Scope In this subchapter the users get all information on what has to be done to upload the MS layer into 1350OMS-SDH. If the network’s size does not fit with the maximum freezing time allowed by the customer the upload can be performed in several steps. Anyway it is not possible to continue with the next chapter until the whole “MS” layer has been uploaded.

Linear MSP

take over

This feature allows uploading of different kind of Linear Multiplex Section Protection scheme, as e.g. (1+1) and (m:n).

The MSP schemes are used to provide a protection for working channels set up between two NEs. Following preconditions are requested:

• The physical connections, which implement such scheme, should be already present in 1350OMS-SDH database. If one or more of these connections are not found, a message is sent to the User to suggest the calling of the “Upload Physical Connectivity” command before to re-start the ‘upload NPA’ command.

• The protection blocks characteristics should be consistent. If not, an error message is sent to the User.

Do these steps to upload linear MSP:

1. Select a topology (sub-network or network), and select Actions->SDH->Upload Protection Schema.

ED 01 Released



2. Select “Linear MSP” from NPA Type, click Apply.

When a consistent MSP scheme is found, a new NPA (including the involved NEs and the related physical connections) is created in 1350OMS-SDH database. Users can also set the ‘implement’ option with true.

• If ‘implement’ is True, after creating the discovered NPAs in 1350OMS-SDH database, these NPAs will be implemented too.

• If this option is False, the NPA can be manually implemented by the User later on.(recommended)

2f MS-SPRing

Take Over

Do these steps to upload 2f MS-SPRing:

1. Select a topology (sub-network or network), and select Actions->SDH->Upload Protection Schema.

ED 01 Released



2. Select “2f MS-SPring” from NPA Type, click Apply

When a consistent 2f MS-SPring scheme is found, a new NPA (including the involved NEs and the related physical connections) is created in 1350OMS-SDH database. Users can also set the ‘implement’ option with true.

5.5 Upload complete SDH paths & trails

Scope In this subchapter the users get all information on what has to be done to upload complete SDH paths & trails.

The feature allows the automatic creation (and the allocation, implementation and commissioning as well) of paths/trails starting from the actual configuration of the NEs.

Warning: The procedure takes over the complete network splitting this activity per

ED 01 Released



layers; only the previous step is successfully completed the next one can take place. (the complete network take over split per network partitioning is not considered reliable and effective, because trail/path take over cannot succeed if all the relevant supporting MS and physical resources have not been properly discovered).

Note: If the path/trail takeover operation – started from a big topology, e.g. sub-network does not find all the paths, repeat the operation starting from a more delimited object (node, physical connection, CTP or NAP).

The created path/trail has the following characteristics:

• the User label of the created path/trail is automatically calculated by the system

• the ASAP profiles of the involved TPs are not uploaded

• the info of the created path/trail are set according to the following:

² “path Type”, “path Rate” and “protection Type” according to the information retrieved from the NE

² “alarm Propagation Rule” is set to “when Implemented”

² “pdh Alarm Enabling Rule” and “sdh Alarm Enabling Rule” are set to “on Implementation”

² “pm Automatic” is set to true (the PM related to the created path/trail are started according to the 1350OMS-SDH rules)

² the other info are set to the 1350OMS-SDH default values

Select Nodes that related to takeover action.

Actions -> SDH -> Discover Connection

ED 01 Released



It tells you that takeover can be started on one or more of the following objects:

• NAP

• CAP

• CTP

• port

• physical connection

• link connection

• topology (node, 1st and 2nd level sub-network, network)

Note: We used node as take over objects and we recommend you to use it that way, you can find in this picture.

Note: If the path/trail takeover operation – started from a big topology, e.g. sub-network does not find all the paths, repeat the operation starting from a more delimited object (node, physical connection, CTP or NAP).

You can choose “Allocated/Implemented/commissioned” as Required configuration state to ask SDH to Allocated, Implemented or commissioned automatically, after the found paths are defined.

ED 01 Released



Click Apply, the path/trail involving the provided information is created (allocated, implemented and commissioned) inside the 1350OMS-SDH DB

Note: We select “Allocated” during take over test, and implement it manually after take over finished, you can find in this picture.

5.6 Network checks

Scope In this subchapter the users get all information on what has to be done to check that the network takeover was successful and a list of hints to solve possible problems

Content of

the chapter

Network checks guide you to performing double checks on 1350OMS-SDH DB consistency against network configuration; 1350OMS-SDH offers “Mark Audit” feature to do this.

Mark Audit capability can be applied on a-per-NE-basis (download disabled mode); the Audit report contains the list of NE misaligned resources.

1350OMS-SDH Users are also able to identify which of the misaligned resources can cause traffic impact in case 1350OMS-SDH downloads its own configuration (i.e. cross connection, paths trace…). So the operator can manually apply the proper actions at 1350OMS-SDH level before performing a forced download onto the NE.

Overview of activities:

• NE Synchronization (Optional)

• EML Alignment

• Check alignment

• Download enable

NE

Synchronizat

ion

(Optional)

It allows updating the ports attributes. Do the following steps :

1. Select Nodes that related to takeover action.

2. Perform: Actions -> SDH->Synchronize ->Synchronize NE

3. Wait until the Synchronization finished.

4. Repeat steps 1-3 for each NE.

Note: if you have many NE under the same EML you could also perform synchronization directly from the EML.

Check Now it is important to check the alignment between 1350OMS-SDH and the migrated

ED 01 Released



alignment NE. Do the following steps :

1. Select one of the migrated Network Elements on map. The Configuration Download status should already be "disabled".

2. Execute the command Actions-> SDH->Consistency Audit-> Mark Audit. This operation could take several minutes.

3. Wait until the Consistency finished.

4. Browse all misalignments by performing Search -> Node -> Not_Aligned TPs and Cross Connections

5. Analyse and understand all misalignment, if any. Refer to “ APPENDIX B : Misalignment Analysis “for more information about some kinds of possible misalignments. Important: you MUST NOT proceed until you have understood and clarified at least all the traffic affecting misalignment.

6. Repeat steps 2-5 for each NE.

Note: The following steps could be dangerous part of the migration because the 1350OMS-SDH database will be forced down to NE. Therefore if you have any REAL traffic-affecting misalignments on the NE you could have traffic failures.

Warning: Do not do perform the following steps unless you are sure that you do not

have any traffic affecting misalignments between 1350OMS-SDH and NEs!

Download

enable

Enable the download: Actions ->Node->Configure Download -> Enable. Note: this operation downloads only misaligned objects and therefore should be fast.

Verify that consistency download was successful and that no misalignments are still present.

5.7 Post Migration Activities

Introduction In this subchapter the users get all information on what has to be done correctly hand-hover the network to the customer.

Alarm

Synchroni-

zation

You may now synchronize alarms on 1350OMS-SDH:

1. Open the map of 1350OMS.

2. Browse one Network Element.

3. Select it and use the menu Actions ->Node-> Synchronize ->Synchronize Alarms.

4. Repeat step 2 and 4 for each NE.

Configure Because Alarm Severity Assignment Profile cannot be taken over, all needed ASAP

ED 01 Released



ASAP should be add manually.

PM

configuratio

ns

Start needed PM measurements manually

Backup After a major upgrade it is always wise to perform some backups. Perform the following backups from the 1350OMS-SDH and 1350OMS-EML:

• On 1350OMS-SDH: Network and PM domain

• On 1350OMS-EML: Network and PM domain

ED 01 Released



6 APPENDICES

6.1 APPENDIX A : Rollback Procedure

Overview The action list below defines the actions to perform network backup/restore

NMS backup Open backup SDH tool from web portal (in Data Management). Create and save a new job including all objects to be “saved” and launch the run command of the new created job.

NMS restore Open restore SDH tool from web portal (in Data Management). Select job that you backup before and restore it.

ED 01 Released



ED 01 Released



6.2 APPENDIX B : Misalignment Analysis

Overview This appendix could be useful if you have misalignments between the configuration in the 1350OMS Database and that of the OMSN. Once you have read this appendix, if you still have some traffic affecting misalignments that you do not understand, you should contact Alcatel-Lucent TEC before you enable the download!

How to Browse

Misaligned Objects

Do the following steps:

1. Start and Raise Up the 1350OMS Network Management GUI.

2. Select Search -> Physical -> Nodes to open the Nodes list.

3. Pull the scroll bar to the right and check the four items: Counter of not aligned objects, Counter of configuration mismatch objects, Counter of failed to align objects, Traffic Affected Not Aligned Counter.

4. If there is a counter of these items in the migrated node, select the node and search -> Node -> Not Aligned Tps and Cross Connection.

5. Then in the Not Aligned Tps and Cross Connection List check the objects.

6. Select one of the objects and right click -> Search -> Show Misalignment

In the next list four attributes (Misaligned Attributes, Error Type, Request Type, and Log Time) will be shown.

How to Deal with

Misaligned Objects

Gathering the information of the misalignment attributes you have to do the analysis for the different type before you enable the download. If you do not understand, you should contact Alcatel-lucent TEC for help.

END OF DOCUMENT

Documents

NT9.1 SDH Network Takeover TL1 ED01