Maintenance Guide (V100R001C00 02)

OptiX RTN 950 Radio Transmission System
V100R001C00
Maintenance Guide
Issue 02
Date 2009-06-30
HUAWEI TECHNOLOGIES CO., LTD.

Copyright © Huawei Technologies Co., Ltd. 2009. All rights reserved.
No part of this document may be reproduced or transmitted in any form or by any means without prior written
consent of Huawei Technologies Co., Ltd.
Trademarks and Permissions
and other Huawei trademarks are trademarks of Huawei Technologies Co., Ltd.
All other trademarks and trade names mentioned in this document are the property of their respective holders.
Notice
The purchased products, services and features are stipulated by the contract made between Huawei and the
customer. All or part of the products, services and features described in this document may not be within the
purchase scope or the usage scope. Unless otherwise specified in the contract, all statements, information,
and recommendations in this document are provided “AS IS” without warranties, guarantees or representations
of any kind, either express or implied.
The information in this document is subject to change without notice. Every effort has been made in the
preparation of this document to ensure accuracy of the contents, but the statements, information, and
recommendations in this document do not constitute a warranty of any kind, express or implied.
Huawei Technologies Co., Ltd.

Address: Huawei Industrial Base
Bantian, Longgang
Shenzhen 518129
People's Republic of China
Website: http://www.huawei.com
Email: support@huawei.com
Issue 02 (2009-06-30) Huawei Proprietary and Confidential i

Copyright © Huawei Technologies Co., Ltd.
Maintenance Guide About This Document
About This Document
Purpose
This document describes the following contents:
l Items, periods, and procedures of routine maintenance, which help you complete the routine
maintenance tasks so that long-term stable operation of the equipment can be ensured.
l Troubleshooting flow and typical methods for troubleshooting, which help you rectify
equipment faults in time.
l Alarms and performance events of the equipment, which provide reference information for
equipment maintenance and repair in terms of the generation principle, classification, and
troubleshooting method.
Related Versions
The following table lists the product versions related to this document.
Product Name Version
OptiX RTN 950 V100R001C00
OptiX iManager T2000 V200R007C03
Intended Audience
This document is intended for:
l System maintenance engineer
l Network monitoring engineer
l On-site maintenance engineer
Before reading this document, you need to know microwave communication basics.
Organization
This document is organized as follows:
Issue 02 (2009-06-30) Huawei Proprietary and Confidential iii

About This Document Maintenance Guide
Table 1 Introduction to each chapter

Chapter Main Content
1 Safety Precautions This chapter describes safety

symbols and operation regulations.
2 Routine maintenance This chapter describes items,

periods, and procedures of routine
maintenance.
3 Troubleshooting This chapter describes the

philosophy and flow of
troubleshooting.
4 Data Backup and Restoration This chapter describes methods for

backing up and restoring NM and
NE data.
5 Replacing Components This chapter describes procedures

for replacing boards and chassis.
6 Software Package Upgrade and Package Diffusion This chapter describes methods and
procedures for performing the
package loading and package
diffusion.
7 Remote Maintenance Guide This chapter describes methods and

procedures for enabling a remote
maintenance user and establishing
remote maintenance.
8 Task Set This chapter describes common

operations for troubleshooting.
9 Alarm This chapter describes how alarms

are generated, and how to classify
and handle the alarms.
10 Performance Event This chapter describes how

performance events are generated,
and how to classify and handle the
performance events.
A Glossary This chapter lists the glossary used

in this document.
B Acronyms and Abbreviations This chapter lists the acronyms and

abbreviations used in this
document.
iv Huawei Proprietary and Confidential Issue 02 (2009-06-30)

Maintenance Guide About This Document
Conventions
Symbol Conventions
The symbols that may be found in this document are defined as follows.
Symbol Description
Indicates a hazard with a high level of risk,

which if not avoided, will result in death or
serious injury.
Indicates a hazard with a medium or low level

of risk, which if not avoided, could result in
minor or moderate injury.
Indicates a potentially hazardous situation,

which if not avoided, could result in
equipment damage, data loss, performance
degradation, or unexpected results.
Indicates a tip that may help you solve a

problem or save time.
Provides additional information to emphasize

or supplement important points of the main
text.
General Conventions
The general conventions that may be found in this document are defined as follows.
Convention Description
Times New Roman Normal paragraphs are in Times New Roman.
Boldface Names of files, directories, folders, and users are in

boldface. For example, log in as user root.
Italic Book titles are in italics.

Courier New Examples of information displayed on the screen are in
Courier New.
GUI Conventions
The GUI conventions that may be found in this document are defined as follows.
Issue 02 (2009-06-30) Huawei Proprietary and Confidential v

About This Document Maintenance Guide
Convention Description
Boldface Buttons, menus, parameters, tabs, windows, and dialog titles are in
boldface. For example, click OK.
> Multi-level menus are in boldface and separated by the ">" signs. For
example, choose File > Create > Folder.
Mouse Operation
The mouse operations that may be found in this document are defined as follows.
Action Description
Click Select and release the primary mouse button without moving the pointer.
Double-click Press the primary mouse button twice continuously and quickly without
moving the pointer.
Drag Press and hold the primary mouse button and move the pointer to a certain
position.
Update History
Updates between document issues are cumulative. Therefore, the latest document issue contains
all updates made in previous issues.
Updates in Issue 02 (2009-06-30) Based on Product Version V100R001C00

This document is the second release of the V100R001C00 version.
Compared with the first release, this document contains the following updates:
l The database activation procedures are added to the data backup and restoration part.
l The list of alarms that need to be cleared before an upgrade by using the package loading
or package diffusion method is added to the package loading and package diffusion part.
l The NO_BD_SOFT and SYSPARA_CFDB_NOSAME alarms are deleted.
l The known bugs are fixed.
Updates in Issue 01 (2009-04-30) Based on Product Version V100R001C00

This document is the first release of the V100R001C00 version.
vi Huawei Proprietary and Confidential Issue 02 (2009-06-30)

Maintenance Guide Contents
Contents
About This Document...................................................................................................................iii

1 Safety Precautions......................................................................................................................1-1
1.1 Warning and Safety Symbols..........................................................................................................................1-2
1.2 Safety Precautions for Using the Equipment..................................................................................................1-3
1.2.1 Safety Symbols.......................................................................................................................................1-4
1.2.2 Electrical Safety.....................................................................................................................................1-4
1.2.3 Battery....................................................................................................................................................1-8
1.2.4 Microwave..............................................................................................................................................1-9
1.2.5 Laser and Fibers...................................................................................................................................1-10
1.2.6 High-Altitude Operations.....................................................................................................................1-10
1.2.7 Installing and Removing Boards..........................................................................................................1-11
1.2.8 Miscellaneous.......................................................................................................................................1-12
1.3 Precautions for Using the T2000...................................................................................................................1-12
2 Routine maintenance.................................................................................................................2-1
2.1 Routine Maintenance Items and Periods.........................................................................................................2-2
2.2 Guide and Record Table for Routine Maintenance in the NMS Center.........................................................2-3
2.2.1 Checking the Status of the NE and Boards............................................................................................2-4
2.2.2 Browsing Network-Wide Alarms...........................................................................................................2-5
2.2.3 Browsing Abnormal Events...................................................................................................................2-6
2.2.4 Browsing the Current Performance Events............................................................................................2-8
2.2.5 Browsing the Performance Events of the RMON Statistics Group.......................................................2-9
2.2.6 Checking the Optical Power.................................................................................................................2-11
2.2.7 Browsing the History Performance Events..........................................................................................2-13
2.2.8 Browsing the RMON History Performance Events.............................................................................2-14
2.2.9 Backing up the MO Data of the T2000................................................................................................2-16
2.2.10 Backing up the NE Database..............................................................................................................2-18
2.2.11 Testing the IF 1+1 Switching.............................................................................................................2-18
2.2.12 Maintenance Record Table.................................................................................................................2-19
2.3 Field Maintenance and Record Table for Outdoor Equipment.....................................................................2-20
2.3.1 Checking the ODU...............................................................................................................................2-21
2.3.2 Checking the Hybrid Coupler..............................................................................................................2-21
2.3.3 Checking the Antenna..........................................................................................................................2-22
Issue 02 (2009-06-30) Huawei Proprietary and Confidential vii

Contents Maintenance Guide
2.3.4 Checking IF Cables..............................................................................................................................2-22

2.3.5 Maintenance Record Table...................................................................................................................2-23
2.4 Guide and Record Table for Routine Maintenance of the Spare Parts.........................................................2-24
2.4.1 Testing the Spare Parts.........................................................................................................................2-24
2.4.2 Maintenance Record Table...................................................................................................................2-25
3 Troubleshooting.........................................................................................................................3-1
3.1 General Fault Handling Flow..........................................................................................................................3-3
3.2 Emergency Flow of Handling the Service Interruption Fault.........................................................................3-5
3.3 Troubleshooting Microwave Links.................................................................................................................3-7
3.4 CES Service Troubleshooting.......................................................................................................................3-15
3.5 Ethernet Service Troubleshooting.................................................................................................................3-18
3.6 Clock Troubleshooting..................................................................................................................................3-20
3.7 QoS Troubleshooting....................................................................................................................................3-22
3.8 Inband DCN Troubleshooting.......................................................................................................................3-25
3.9 LAG Troubleshooting...................................................................................................................................3-28
3.10 ML-PPP Troubleshooting...........................................................................................................................3-31
3.11 IMA Troubleshooting..................................................................................................................................3-33
3.12 FRR Troubleshooting..................................................................................................................................3-37
3.13 MPLS APS Troubleshooting.......................................................................................................................3-40
3.14 Information Collection and Information Record.........................................................................................3-42
3.15 Fault Notification and Technical Support...................................................................................................3-43
4 Data Backup and Restoration..................................................................................................4-1

4.1 Backing Up and Restoring the T2000 Data....................................................................................................4-2
4.1.1 Methods of Backing Up and Restoring the T2000 Data........................................................................4-2
4.1.2 Backing Up the T2000 MO Data...........................................................................................................4-7
4.1.3 Backing Up All Data in the T2000 Database.........................................................................................4-8
4.1.4 Backing Up the T2000 Network Configuration Data by Means of Scripts...........................................4-9
4.1.5 Restoring the MO Data of the T2000...................................................................................................4-10
4.1.6 Restoring All Data of the T2000 Databases.........................................................................................4-11
4.1.7 Restoring the T2000 Network Configuration Data by Means of Scripts.............................................4-12
4.2 Backing Up and Restoring the NE Data........................................................................................................4-13
4.2.1 Methods of Backing Up and Restoring NE Data.................................................................................4-13
4.2.2 Backing Up the NE Database to the System Control Board................................................................4-15
4.2.3 Backing Up the NE Database to the CF Card......................................................................................4-16
4.2.4 Backing Up the NE Database to a Local Server..................................................................................4-16
4.2.5 Restoring the NE Database from the System Control Board...............................................................4-18
4.2.6 Restoring the NE Database from the CF Card.....................................................................................4-18
4.2.7 Recovering the NE Database from a Local Server...............................................................................4-19
5 Replacing Components.............................................................................................................5-1
5.1 Replacing the CXPR with the 1+1 Protection.................................................................................................5-3
5.2 Replacing the CXPR Without the 1+1 Protection...........................................................................................5-4
viii Huawei Proprietary and Confidential Issue 02 (2009-06-30)

5.3 Replacing the Processing Boards....................................................................................................................5-5

5.4 Replacing the IFE2 Board...............................................................................................................................5-7
5.5 Replacing the FAN Board...............................................................................................................................5-8
5.6 Replacing the PIU Board.................................................................................................................................5-9
5.7 Replacing the AUXQ Board.........................................................................................................................5-10
5.8 Replacing the Chassis....................................................................................................................................5-11
5.9 Replacing the Pluggable Optical Module......................................................................................................5-13
5.10 Replacing the ODU.....................................................................................................................................5-14
5.10.1 Replacing the ODU with Waveguide Interface..................................................................................5-15
5.10.2 Replacing the ODU with Coaxial Interface.......................................................................................5-16
5.11 Replacing the IF Cable................................................................................................................................5-17
6 Software Package Upgrade and Package Diffusion............................................................6-1

6.1 Software Package Upgrade............................................................................................................................. 6-2
6.1.1 Definition and Feature............................................................................................................................6-2
6.1.2 State Model............................................................................................................................................ 6-2
6.1.3 Realization Scheme................................................................................................................................6-4
6.1.4 Creating a Package Upgrade Task..........................................................................................................6-5
6.2 Software Package Diffusion..........................................................................................................................6-13
6.2.1 Definition and Feature..........................................................................................................................6-13
6.2.2 State Model..........................................................................................................................................6-14
6.2.3 Realization Scheme..............................................................................................................................6-16
6.2.4 Creating a Package Diffusion Upgrade Task.......................................................................................6-16
7 Remote Maintenance Guide....................................................................................................7-1

7.1 Introduce..........................................................................................................................................................7-2
7.2 Enabling a Remote Maintenance User............................................................................................................7-2
7.3 Establishing Remote Maintenance..................................................................................................................7-3
8 Task Set........................................................................................................................................8-1
8.1 Querying T2000 Operation Logs.................................................................................................................... 8-4
8.2 Querying Current Alarms of a Board..............................................................................................................8-4
8.3 Querying the Board Information Report.........................................................................................................8-5
8.4 Checking the Optical Power............................................................................................................................8-6
8.5 Performing the LSP Ping Test.........................................................................................................................8-7
8.6 Performing the LSP Traceroute Test ..............................................................................................................8-8
8.7 Checking Data Consistency Between an NE and the T2000........................................................................8-10
8.8 Uploading the NE Configuration Data..........................................................................................................8-11
8.9 Configuring Port Loopback...........................................................................................................................8-12
8.10 Performing the MPLS Tunnel Protection Switching..................................................................................8-14
8.11 Performing the 1+1 Protection Switching for CXPR boards......................................................................8-15
8.12 Performing IF 1+1 Protection Switch.........................................................................................................8-16
8.13 Querying an IF 1+1 Protection Group.........................................................................................................8-17
8.14 Querying the Working State of AM............................................................................................................8-17
Issue 02 (2009-06-30) Huawei Proprietary and Confidential ix

8.15 Setting the State of an ODU Transmitter....................................................................................................8-18

8.16 Resetting Boards.........................................................................................................................................8-19
8.17 Testing the Transmitted Optical Power of the Optical Interface.................................................................8-20
8.18 Testing the Receive Optical Power of the Optical Interface.......................................................................8-22
8.19 Replacing Boards on Site............................................................................................................................8-24
8.20 Powering On the Equipment.......................................................................................................................8-30
8.21 Powering Off the Equipment.......................................................................................................................8-30
8.22 Querying and Setting the Working Mode of Ethernet Interface.................................................................8-31
8.23 Querying Protection Configuration.............................................................................................................8-32
8.24 Inspecting and Cleaning the Optical Fiber Connectors...............................................................................8-32
8.24.1 Overview............................................................................................................................................8-33
8.24.2 Protection of Optical Connectors.......................................................................................................8-34
8.24.3 Tools, Equipment and Materials........................................................................................................8-35
8.24.4 Inspecting Optical Connectors...........................................................................................................8-36
8.24.5 Cleaning Optical Fiber Connectors Using Cartridge Cleaners..........................................................8-39
8.24.6 Cleaning Optical Fiber Connectors Using Lens Tissue.....................................................................8-42
8.24.7 Cleaning Optical Modules Using Optical Cleaning Sticks................................................................8-45
9 Alarm............................................................................................................................................9-1
9.1 Basic Concepts Related to Alarms..................................................................................................................9-2
9.1.1 Alarm Reporting Flow...........................................................................................................................9-2
9.1.2 Alarm Correlation..................................................................................................................................9-3
9.1.3 Alarm Category......................................................................................................................................9-6
9.1.4 Alarm Severity.......................................................................................................................................9-7
9.1.5 Alarm Notification.................................................................................................................................9-8
9.2 Alarm List.......................................................................................................................................................9-8
9.2.1 SL91CXPR Board Alarm List................................................................................................................9-9
9.2.2 TND1EF8T Board Alarm List.............................................................................................................9-10
9.2.3 TND1EF8F Board Alarm List..............................................................................................................9-10
9.2.4 TND1EG2 Board Alarm List...............................................................................................................9-10
9.2.5 TND1ML1/TND1ML1A Board Alarm List........................................................................................9-11
9.2.6 TND1IFE2 Board Alarm List..............................................................................................................9-11
9.2.7 TND1AUXQ Board Alarm List...........................................................................................................9-12
9.2.8 TND1PIU Board Alarm List................................................................................................................9-12
9.2.9 TND1FAN Board Alarm List..............................................................................................................9-12
9.2.10 ODU Alarm List.................................................................................................................................9-12
9.3 Alarm Handling.............................................................................................................................................9-12
9.3.1 Alarm Handling Flow...........................................................................................................................9-17
9.3.2 AM_DOWNSHIFT..............................................................................................................................9-19
9.3.3 ALM_ALS...........................................................................................................................................9-21
9.3.4 ALM_E1RAI........................................................................................................................................9-21
9.3.5 ALM_IMA_LIF...................................................................................................................................9-22
9.3.6 ALM_IMA_LODS...............................................................................................................................9-24
x Huawei Proprietary and Confidential Issue 02 (2009-06-30)

9.3.7 ALM_IMA_RE_RX_UNUSABLE.....................................................................................................9-25
9.3.8 ALM_IMA_RE_TX_UNUSABLE.....................................................................................................9-26
9.3.9 ALM_IMA_RFI...................................................................................................................................9-28
9.3.10 BD_NOT_INSTALLED....................................................................................................................9-29
9.3.11 BD_STATUS.....................................................................................................................................9-30
9.3.12 BFD_DOWN......................................................................................................................................9-31
9.3.13 BUS_ERR..........................................................................................................................................9-33
9.3.14 CES_JTROVR_EXC.........................................................................................................................9-34
9.3.15 CES_JTRUDR_EXC.........................................................................................................................9-35
9.3.16 CES_LOSPKT_EXC.........................................................................................................................9-36
9.3.17 CES_MALPKT_EXC........................................................................................................................9-38
9.3.18 CES_MISORDERPKT_EXC............................................................................................................9-39
9.3.19 CES_STRAYPKT_EXC....................................................................................................................9-40
9.3.20 CFCARD_FAILED............................................................................................................................9-41
9.3.21 CFCARD_OFFLINE.........................................................................................................................9-42
9.3.22 CLK_NO_TRACE_MODE...............................................................................................................9-43
9.3.23 COMMUN_FAIL...............................................................................................................................9-45
9.3.24 CONFIG_NOSUPPORT....................................................................................................................9-47
9.3.25 DBMS_ERROR.................................................................................................................................9-48
9.3.26 DBMS_PROTECT_MODE...............................................................................................................9-50
9.3.27 DOWN_E1_AIS.................................................................................................................................9-51
9.3.28 ETH_APS_LOST...............................................................................................................................9-52
9.3.29 ETH_APS_PATH_MISMATCH.......................................................................................................9-53
9.3.30 ETH_APS_SWITCH_FAIL...............................................................................................................9-54
9.3.31 ETH_APS_TYPE_MISMATCH.......................................................................................................9-55
9.3.32 ETH_AUTO_LINK_DOWN.............................................................................................................9-56
9.3.33 ETH_LINK_DOWN..........................................................................................................................9-58
9.3.34 ETH_LOS...........................................................................................................................................9-59
9.3.35 EXT_SYNC_LOS..............................................................................................................................9-60
9.3.36 EXT_TIME_LOC..............................................................................................................................9-62
9.3.37 FAN_FAIL.........................................................................................................................................9-63
9.3.38 FLOW_OVER....................................................................................................................................9-64
9.3.39 GSP_ISIS_NB_AUTH_ERR.............................................................................................................9-65
9.3.40 GSP_RSVP_NB_AUTH_ERR..........................................................................................................9-66
9.3.41 GSP_RSVP_NB_DOWN...................................................................................................................9-68
9.3.42 GSP_TNNL_DOWN.........................................................................................................................9-69
9.3.43 HARD_BAD......................................................................................................................................9-70
9.3.44 IMA_GROUP_LE_DOWN...............................................................................................................9-74
9.3.45 IMA_GROUP_RE_DOWN...............................................................................................................9-75
9.3.46 IMAE1_DELAY................................................................................................................................9-76
9.3.47 IN_PWR_ABN...................................................................................................................................9-77
9.3.48 LAG_DOWN.....................................................................................................................................9-78
Issue 02 (2009-06-30) Huawei Proprietary and Confidential xi

9.3.49 LAG_MEMBER_DOWN..................................................................................................................9-79
9.3.50 LASER_MOD_ERR..........................................................................................................................9-81
9.3.51 LASER_SHUT...................................................................................................................................9-82
9.3.52 LFA....................................................................................................................................................9-83
9.3.53 IF_CABLE_OPEN.............................................................................................................................9-84
9.3.54 IF_INPWR_ABN...............................................................................................................................9-86
9.3.55 LMFA.................................................................................................................................................9-87
9.3.56 LOOP_ALM.......................................................................................................................................9-89
9.3.57 LSR_BCM_ALM...............................................................................................................................9-91
9.3.58 LSR_NO_FITED...............................................................................................................................9-92
9.3.59 LSR_WILL_DIE................................................................................................................................9-93
9.3.60 LTI......................................................................................................................................................9-94
9.3.61 MAC_FCS_EXC................................................................................................................................9-96
9.3.62 MP_DELAY.......................................................................................................................................9-97
9.3.63 MP_DOWN........................................................................................................................................9-98
9.3.64 MPLS_TUNNEL_BDI.....................................................................................................................9-100
9.3.65 MPLS_TUNNEL_Excess................................................................................................................9-101
9.3.66 MPLS_TUNNEL_FDI.....................................................................................................................9-102
9.3.67 MPLS_TUNNEL_LOCV.................................................................................................................9-103
9.3.68 MPLS_TUNNEL_MISMATCH......................................................................................................9-105
9.3.69 MPLS_TUNNEL_MISMERGE......................................................................................................9-106
9.3.70 MPLS_TUNNEL_SD......................................................................................................................9-107
9.3.71 MPLS_TUNNEL_SF.......................................................................................................................9-108
9.3.72 MPLS_TUNNEL_UNKNOWN......................................................................................................9-110
9.3.73 MW_BER_EXC...............................................................................................................................9-111
9.3.74 MW_BER_SD..................................................................................................................................9-112
9.3.75 MW_LIM.........................................................................................................................................9-113
9.3.76 MW_LOF.........................................................................................................................................9-114
9.3.77 MW_RDI..........................................................................................................................................9-115
9.3.78 MW_FECUNCOR...........................................................................................................................9-116
9.3.79 MSSW_DIFFERENT.......................................................................................................................9-117
9.3.80 NESF_LOST....................................................................................................................................9-119
9.3.81 NESTATE_INSTALL.....................................................................................................................9-120
9.3.82 OUT_PWR_ABN.............................................................................................................................9-121
9.3.83 PATCH_ACT_TIMEOUT...............................................................................................................9-122
9.3.84 PATCH_DEACT_TIMEOUT.........................................................................................................9-123
9.3.85 PATCH_ERR...................................................................................................................................9-124
9.3.86 PATCH_PKGERR...........................................................................................................................9-125
9.3.87 PATCHFILE_NOTEXIST...............................................................................................................9-126
9.3.88 POWER_ABNORMAL...................................................................................................................9-127
9.3.89 POWER_ALM.................................................................................................................................9-129
9.3.90 PPP_LCP_FAIL...............................................................................................................................9-130
xii Huawei Proprietary and Confidential Issue 02 (2009-06-30)

9.3.91 PPP_NCP_FAIL...............................................................................................................................9-131
9.3.92 PW_DOWN.....................................................................................................................................9-132
9.3.93 R_LOC.............................................................................................................................................9-133
9.3.94 RADIO_FADING_MARGIN_INSUFF..........................................................................................9-135
9.3.95 RADIO_RSL_LOW.........................................................................................................................9-137
9.3.96 RADIO_RSL_HIGH........................................................................................................................9-139
9.3.97 RADIO_TSL_LOW.........................................................................................................................9-140
9.3.98 RADIO_TSL_HIGH........................................................................................................................9-141
9.3.99 RADIO_MUTE................................................................................................................................9-142
9.3.100 RELAY_ALARM_CRITICAL......................................................................................................9-143
9.3.101 RELAY_ALARM_MAJOR...........................................................................................................9-144
9.3.102 RELAY_ALARM_MINOR...........................................................................................................9-145
9.3.103 RELAY_ALARM_IGNORE.........................................................................................................9-146
9.3.104 RPS_INDI......................................................................................................................................9-147
9.3.105 S1_SYN_CHANGE.......................................................................................................................9-149
9.3.106 SECU_ALM...................................................................................................................................9-150
9.3.107 SWDL_ACTIVATED_TIMEOUT................................................................................................9-151
9.3.108 SWDL_AUTOMATCH_INH........................................................................................................9-152
9.3.109 SWDL_COMMIT_FAIL...............................................................................................................9-153
9.3.110 SWDL_INPROCESS.....................................................................................................................9-154
9.3.111 SWDL_NEPKGCHECK................................................................................................................9-155
9.3.112 SWDL_PKG_NOBDSOFT...........................................................................................................9-156
9.3.113 SWDL_PKGVER_MM.................................................................................................................9-157
9.3.114 SWDL_ROLLBACK_FAIL..........................................................................................................9-158
9.3.115 SYN_BAD.....................................................................................................................................9-159
9.3.116 SYNC_C_LOS...............................................................................................................................9-160
9.3.117 SYNC_DISABLE..........................................................................................................................9-161
9.3.118 SYNC_F_M_SWITCH..................................................................................................................9-162
9.3.119 SYNC_FAIL..................................................................................................................................9-163
9.3.120 SYNC_LOCKOFF.........................................................................................................................9-164
9.3.121 SYSLOG_COMM_FAIL...............................................................................................................9-165
9.3.122 T_ALOS.........................................................................................................................................9-166
9.3.123 TEM_HA........................................................................................................................................9-168
9.3.124 TEM_LA........................................................................................................................................9-169
9.3.125 TEMP_ALARM.............................................................................................................................9-170
9.3.126 TEMP_OVER................................................................................................................................9-171
9.3.127 THUNDERALM............................................................................................................................9-172
9.3.128 TR_LOC.........................................................................................................................................9-173
9.3.129 UP_E1_AIS....................................................................................................................................9-175
9.3.130 VC_AIS..........................................................................................................................................9-176
9.3.131 VC_LOC........................................................................................................................................9-178
9.3.132 VC_RDI.........................................................................................................................................9-179
Issue 02 (2009-06-30) Huawei Proprietary and Confidential xiii

9.3.133 VOLT_LOS....................................................................................................................................9-181
9.3.134 VP_AIS..........................................................................................................................................9-183
9.3.135 VP_LOC.........................................................................................................................................9-184
9.3.136 VP_RDI..........................................................................................................................................9-186
9.3.137 WRG_BD_TYPE...........................................................................................................................9-188
10 Performance Event.................................................................................................................10-1
10.1 Basic Concepts Related to Performance Events..........................................................................................10-2
10.1.1 Performance Reporting Flow.............................................................................................................10-2
10.1.2 Performance Event Category............................................................................................................. 10-4
10.1.3 Performance Threshold......................................................................................................................10-5
10.2 Performance Event List...............................................................................................................................10-5
10.2.1 SL91CXPR Performance Event List..................................................................................................10-5
10.2.2 TND1EF8T Performance Event List..................................................................................................10-7
10.2.3 TND1EF8F Performance Event List..................................................................................................10-8
10.2.4 TND1EG2 Performance Event List................................................................................................... 10-9
10.2.5 TND1ML1/TND1ML1A Performance Event List..........................................................................10-10
10.2.6 TND1IFE2 Performance Event List.................................................................................................10-13
10.2.7 TND1AUXQ Performance Event List.............................................................................................10-15
10.2.8 TND1PIU Performance Event List..................................................................................................10-15
10.2.9 TND1FAN Performance Event List.................................................................................................10-15
10.2.10 ODU Performance Event List........................................................................................................10-16
10.3 Performance Event Handling....................................................................................................................10-17
10.3.1 ATM_CELL_AVAILABILITY.......................................................................................................10-17
10.3.2 ATMPW_LOSPKTS........................................................................................................................10-18
10.3.3 ATMPW_MISORDERPKTS...........................................................................................................10-19
10.3.4 CES_JTROVR.................................................................................................................................10-20
10.3.5 CES_JTRUDR.................................................................................................................................10-21
10.3.6 E1_LCV_SDH.................................................................................................................................10-22
10.3.7 E1_LES_SDH..................................................................................................................................10-23
10.3.8 E1_LSES_SDH................................................................................................................................10-24
10.3.9 MEMUSAGECUR...........................................................................................................................10-25
10.3.10 MEMUSAGEMAX........................................................................................................................10-25
10.3.11 MEMUSAGEMIN.........................................................................................................................10-26
10.3.12 ACMDOWNCNT and ACMUPCNT............................................................................................10-27
10.3.13 BDTMPMAX, BDTMPMIN, and BDTMPCUR..........................................................................10-27
10.3.14 RSLMAX, RSLMIN and RSLCUR...............................................................................................10-28
10.3.15 TSLMAX, TSLMIN, and TSLCUR..............................................................................................10-28
10.3.16 RLHTT, RLLTT, TLHTT, TLLTT................................................................................................10-29
10.3.17 IFBBE, IFES, IFSES, IFCSES, and IFUAS..................................................................................10-29
10.3.18 FEC_BEF_COR_ER, FEC_COR_BYTE_CNT, and FEC_UNCOR_BLOCK_CNT..................10-31
10.3.19 QPSKWS, QAMWS16, QAMWS32, QAMWS64, QAMWS128, and QAMWS256..................10-31
A Glossary.....................................................................................................................................A-1
xiv Huawei Proprietary and Confidential Issue 02 (2009-06-30)

B Acronyms and Abbreviations.................................................................................................B-1
Issue 02 (2009-06-30) Huawei Proprietary and Confidential xv

Maintenance Guide Figures
Figures
Figure 1-1 Wearing the ESD wrist strap..............................................................................................................1-7

Figure 3-1 General flow diagram for handling faults...........................................................................................3-3
Figure 3-2 Flow diagram for handling service interruption.................................................................................3-6
Figure 3-3 Flow of handling microwave link faults...........................................................................................3-11
Figure 3-4 Flowchart for troubleshooting CES service faults............................................................................3-16
Figure 3-5 Flowchart for troubleshooting Ethernet service faults......................................................................3-19
Figure 3-6 Flowchart for troubleshooting the QoS faults..................................................................................3-24
Figure 3-7 Flowchart for troubleshooting the inband DCN faults.....................................................................3-26
Figure 3-8 Troubleshooting Flowchart...............................................................................................................3-30
Figure 3-9 Flowchart for troubleshooting the ML-PPP faults...........................................................................3-32
Figure 3-10 Flowchart for troubleshooting the IMA faults................................................................................3-35
Figure 3-11 Flowchart for troubleshooting the FRR faults................................................................................3-38
Figure 3-12 Flowchart for troubleshooting the MPLS APS faults.....................................................................3-41
Figure 5-1 Inserting and removing the optical module......................................................................................5-14
Figure 6-1 State model of software package upgrade..........................................................................................6-3
Figure 6-2 Flow diagram for software package upgrade......................................................................................6-4
Figure 6-3 State model for package diffusion....................................................................................................6-15
Figure 7-1 Connection for remote maintenance...................................................................................................7-2
Figure 8-1 Connections for the test of the mean transmitted optical power at the optical interface..................8-21
Figure 8-2 Connections for the test of the receive optical power at the optical interface..................................8-23
Figure 8-3 Loosening screws with a screwdriver...............................................................................................8-25
Figure 8-4 Removing the board (1)....................................................................................................................8-26
Figure 8-5 Removing the board (2)....................................................................................................................8-27
Figure 8-6 Inserting the board (1)......................................................................................................................8-28
Figure 8-7 Inserting the board (2)......................................................................................................................8-29
Figure 8-8 Tightening screws with a screwdriver..............................................................................................8-29
Figure 8-9 Optical fiber connector.....................................................................................................................8-33
Figure 8-10 Protective caps recommended........................................................................................................8-34
Figure 8-11 Protective caps not recommended..................................................................................................8-35
Figure 8-12 CLETOP cassette cleaner...............................................................................................................8-36
Figure 8-13 Cleaning stick for the SC and FC optical interface (just for reference).........................................8-36
Figure 8-14 Cleaning stick for the LC optical interface ....................................................................................8-36
Figure 8-15 An intact fiber.................................................................................................................................8-37
Issue 02 (2009-06-30) Huawei Proprietary and Confidential xvii

Figures Maintenance Guide
Figure 8-16 Damaged or suspect fibers..............................................................................................................8-38

Figure 8-17 An intact fiber.................................................................................................................................8-38
Figure 8-18 Acceptable fibers with imperfections.............................................................................................8-39
Figure 8-19 Unacceptable fibers with imperfections.........................................................................................8-39
Figure 8-20 Using the CLETOP cassette cleaner...............................................................................................8-41
Figure 8-21 Dragging the fiber tip lightly on one cleaning area........................................................................8-41
Figure 8-22 Dragging the fiber tip lightly on the other cleaning area................................................................8-42
Figure 8-23 Cleaning the fiber tip with the lens tissue on the desk...................................................................8-44
Figure 8-24 Cleaning the fiber tip with the lens tissue on the hand...................................................................8-44
Figure 9-1 Alarm reporting flow diagram............................................................................................................9-3
Figure 9-2 Alarm correlation rules of the Ethernet services carried at the Ethernet port....................................9-5
Figure 9-3 Illustration of the alarm correlation analysis......................................................................................9-6
Figure 9-4 Flowchart for handling alarms..........................................................................................................9-17
Figure 10-1 Performance reporting flow............................................................................................................10-3
xviii Huawei Proprietary and Confidential Issue 02 (2009-06-30)

Maintenance Guide Tables
Tables
Table 1 Introduction to each chapter......................................................................................................................iv

Table 1-1 Warning and safety symbols................................................................................................................1-2
Table 1-2 Levels and meanings of the safety symbols.........................................................................................1-4
Table 2-1 Maintenance items and periods............................................................................................................2-2
Table 2-2 Maintenance Record Table.................................................................................................................2-23
Table 2-3 Maintenance Record Table.................................................................................................................2-25
Table 3-1 Troubleshooting for different services and functions..........................................................................3-4
Table 3-2 Alarm description.................................................................................................................................3-7
Table 3-3 Causes of microwave link faults..........................................................................................................3-9
Table 3-4 Flow description.................................................................................................................................3-12
Table 3-5 List of common symptoms of CES service faults..............................................................................3-15
Table 3-6 List of common symptoms of Ethernet service faults........................................................................3-18
Table 3-7 List of common symptoms of clock faults.........................................................................................3-21
Table 3-8 List of common symptoms of the QoS faults.....................................................................................3-23
Table 3-9 List of common symptoms of the LAG faults................................................................................... 3-29
Table 3-10 List of common symptoms of the ML-PPP faults............................................................................3-32
Table 3-11 List of common symptoms of the IMA faults..................................................................................3-34
Table 3-12 List of common symptoms of the MPLS APS faults.......................................................................3-40
Table 4-1 Script files supported by the T2000.....................................................................................................4-4
Table 4-2 Features and application scenarios of the three methods of maintaining data.....................................4-6
Table 4-3 Methods of backing up and restoring NE data and their application scenarios.................................4-14
Table 6-1 Alarms to be cleared before package upgrade.....................................................................................6-6
Table 6-2 Alarms to be cleared before package diffusion upgrade....................................................................6-17
Table 8-1 General procedure of inspecting and cleaning the optical fiber connectors...................................... 8-34
Table 9-1 Alarm severity......................................................................................................................................9-7
Table 10-1 SDH Performance Event List...........................................................................................................10-5
Table 10-2 RMON Performance Event..............................................................................................................10-6
Table 10-8 RMON Performance Event............................................................................................................10-10
Issue 02 (2009-06-30) Huawei Proprietary and Confidential xix

Tables Maintenance Guide
Table 10-9 SDH Performance Event List.........................................................................................................10-10

Table 10-10 RMON Performance Event..........................................................................................................10-11
Table 10-11 SDH Performance Events List.....................................................................................................10-13
Table 10-12 Microwave Performance Events List...........................................................................................10-14
Table 10-13 SDH Performance Event List.......................................................................................................10-15
Table 10-14 RMON Performance Event..........................................................................................................10-15
Table 10-15 SDH Performance Events List.....................................................................................................10-16
Table 10-16 Microwave Performance Events List...........................................................................................10-16
xx Huawei Proprietary and Confidential Issue 02 (2009-06-30)

Maintenance Guide 1 Safety Precautions
1 Safety Precautions
About This Chapter
This section describes the safety precautions that should be taken during operating and
maintaining the equipment or using T2000 NMS (Network Management System). The safety
precautions cover the safety rules related to the human beings and equipment. Adhere to these
safety rules to avoid injury to the human body and damage to the equipment.
1.1 Warning and Safety Symbols

Before using the equipment, carefully note the warning and safety symbols on the equipment.
Perform operations on the equipment according to the indications of these symbols. This section
describes the warning and safety symbols on the RTN equipment and the indications of these
symbols.
1.2 Safety Precautions for Using the Equipment
Before using the equipment, read the safety precautions carefully. During the operation of the
equipment, follow the safety precautions to ensure the safety of human beings and the equipment.
1.3 Precautions for Using the T2000
To use the T2000 correctly, you should be aware of the precautions for the running, setting, and
operation of the T2000.
Issue 02 (2009-06-30) Huawei Proprietary and Confidential 1-1

1 Safety Precautions Maintenance Guide
1.1 Warning and Safety Symbols

Before using the equipment, carefully note the warning and safety symbols on the equipment.
Perform operations on the equipment according to the indications of these symbols. This section
describes the warning and safety symbols on the RTN equipment and the indications of these
symbols.
Table 1-1 lists the warning and safety symbols on the equipment, and the indications of these
symbols.
Table 1-1 Warning and safety symbols

Symbol Indication
This symbol is for anti-static protection.

A notice with this symbol indicates that you should wear an
anti-static wrist strip or gloves when you touch a board.
Otherwise, damage might be caused to the board.
This symbol is for laser class.

CLASS 1
LASER A notice with this symbol indicates the class of the laser.
PRODUCT Avoid direct exposure to the laser beams launched from the
optical interface. Otherwise, damage might be caused to the
eye or skin.
This symbol is for chassis grounding.

A notice with this symbol indicates where the equipment is
grounded.
This symbol is a fan safety warning.

A notice with this symbol indicates that the fan leaves should
not be touched when the fan is rotating.
This symbol is for multi-channel power supply.

! A notice with this symbol indicates that the multiple channels
of power supply are available.
This symbol is for high temperature warning.

The board surface temperature may exceed 70°C when the
ambient temperature is higher than 55°C. In this case, you
need to wear protective gloves before touching the board.
! WARNING
This symbol is for operation warning.
-48V OUTPUT The ODU-PWR switch must be turned off before the IF cable
TURN OFF POWER BEFORE
DISCONNECTING IF CABLE is removed.
1-2 Huawei Proprietary and Confidential Issue 02 (2009-06-30)

1.2 Safety Precautions for Using the Equipment

Before using the equipment, read the safety precautions carefully. During the operation of the
equipment, follow the safety precautions to ensure the safety of human beings and the equipment.
CAUTION
l Before performing any operation on the equipment, read the operation instructions and
precautions carefully; during the operation, follow the equipment-specific precautions and
operation instructions provided by Huawei strictly to minimize the occurrence of accidents.
l When performing any operation on the equipment, follow the safety regulations of the local
areas. The safety precautions described in the manual are only supplements to the local safety
regulations.
l The texts introduced by the word "Caution", "Warning", or "Danger" in each manual do not
cover all the safety precautions that must be followed. They are only supplements to the
safety precautions for operations.
l The engineers that are responsible for installing and maintaining Huawei equipment must be
equipped with the general knowledge of safety operation. Therefore, they must have
completed relevant training to familiarize themselves with the proper operation methods and
safety precautions. In addition, they must possess relevant working certificates.
1.2.1 Safety Symbols

Safety symbols indicate the safety instructions that must be followed during the installation or
maintenance.
1.2.2 Electrical Safety
When installing or maintaining Huawei network equipment, follow relevant electrical safety
precautions to ensure the safety of human beings and the equipment.
1.2.3 Battery
When installing or maintaining the battery, follow relevant safety precautions for the battery to
ensure the safety of human beings and the equipment.
1.2.4 Microwave
When installing or maintaining microwave equipment, follow relevant safety precautions for
the microwave equipment to ensure the safety of human beings and the equipment.
1.2.5 Laser and Fibers
Clean the fiber connector correctly. To avoid injury caused by the laser beam to the human body,
replace and connect fibers safely.
1.2.6 High-Altitude Operations
When doing High-Altitude Operations, follow relevant safety precautions for High-Altitude
Operations to ensure the safety of human beings and the equipment.
1.2.7 Installing and Removing Boards
Removing the in-service board may result in service interruption. Thus, remove or insert a board
during off-peak hours.
1.2.8 Miscellaneous

When installing or maintaining Huawei network equipment, you also need to follow the safety
precautions for lifting heavy objects, operating sharp-cornered objects and binding signal cables
to ensure the safety of human beings and the equipment.
1.2.1 Safety Symbols

Safety symbols indicate the safety instructions that must be followed during the installation or
maintenance.
Table 1-2 lists the levels and meanings of the safety symbols.
Table 1-2 Levels and meanings of the safety symbols
Levels of the safety symbols Meaning
Indicates a hazard with a high level of risk

that, if not avoided, could result in death or
serious injury.
Indicates a hazard with a medium or low level

of risk that, if not avoided, could result in
minor or moderate injury to the human body.
Indicates a potentially hazardous situation

that, if not avoided, could cause equipment
damage, data loss, performance degradation,
or other unexpected results.
1.2.2 Electrical Safety

When installing or maintaining Huawei network equipment, follow relevant electrical safety
precautions to ensure the safety of human beings and the equipment.
High Voltage
DANGER
The high voltage power supply supplies power to the device so that it can operate. Direct or
indirect contact (through damp objects) with high voltage and AC mains supply may result in a
fatal accident.
l When installing the AC power supply facility, comply with the local safety regulations.
The personnel who install the AC facility must be qualified for performing high voltage
and AC operations.
l Do not wear articles that conduct electricity, such as watches, chains, bracelets and rings
when performing high voltage operations.
l Switch off the power supply immediately, if you find water in the rack or if the rack is
damp.

l Make sure that the device is kept away from water when being operated in a damp
environment.
WARNING
Non-standard and improper high voltage operations can result in fire and electric shock.
Therefore, you must abide by the local rules and regulations when bridging and wiring AC cables
through a certain area. The personnel who perform high voltage operations must be qualified
for performing high voltage and AC operations.
Power Cable
WARNING
Do not install or remove a live line. Transient contact between the core of the power cable and
the conductor may generate electric arc or spark, which can cause fire or injury to the eye.
l Before bringing the power cable into the power distribution frame (PDF), bind the bare
parts of the power cable with insulating tapes.
l Before installing or removing the power cable, turn off the power switch.
l Before connecting the power cable, make sure that the power cable and label conform to
the requirements of the actual installation.
Short Circuit
The short circuit makes the components fail to work normally and even causes damage to the
entire equipment. During the component replacement, avoid the short circuit that may occur
when you do not operate the tools or boards properly.
Use tools such as a screwdriver according to the regulations. Do not place any tools on the
honeycomb plate of the equipment.
CAUTION
Prevent any screws from falling into the equipment and causing short circuit.
Tools
WARNING
Use special tools when performing high voltage and AC operations.

Drilling Holes
WARNING
Do not drill on the rack without permission. Drilling on the racks does not conform to the related
requirements and may damage the wires and cables inside the rack. If the metal shavings from
the drilling enter the rack, it may result in short-circuit of the circuit boards. It may also damage
the Electromagnetic Compatibility (EMC) performance of the cabinet.
l Before drilling a hole on the rack, wear insulation gloves, and then remove the cables inside
the rack away.
l During the drilling, ensure that your eyes are completely protected. The hot metal shavings
may cause injury to your eyes.
l Ensure that the metal shavings do not enter the rack.
l Non-standard drilling may damage the electromagnetic shielding performance of the rack.
l After drilling, clean the metal shavings.
Thunderstorm
DANGER
High voltage and AC operations, or operations on a steel tower and a mast when there is a
thunderstorm are prohibited.
When there is a thunderstorm, the electromagnetic field generated in the thunderstorm area may
cause damage to electronic components. To prevent the device from being damaged by lightning,
use proper grounding.
Electrostatic Discharge
The electronic components on the board can be damaged by the electrostatic discharge. Thus,
when replacing the board, make sure that the equipment is properly grounded and take proper
measures to protect the components against electrostatic discharge. For example, wear the ESD
wrist strap during the operation.
CAUTION
The static electricity generated by the human body can damage the electrostatic sensitive
components on the circuit board, such as the large-scale integrated circuit (LIC).
Take the following measures to protect the components against electrostatic discharge:
l Make sure that the equipment is properly grounded according to the equipment grounding
requirement.

l Before touching the equipment, board or integrated circuit (IC) chip, you must wear the
ESD wrist strap to prevent the electrostatic discharge on the human body from damaging
the static-sensitive components, and ensure that the other end of the strap is properly
grounded. Figure 1-1 shows how to wear the ESD wrist strap.
Figure 1-1 Wearing the ESD wrist strap
CAUTION
Make sure that the metallic portion of the ESD wrist strap is in contact with the skin and
the other end of the ESD wrist strap is properly connected to the anti-static jack.
NOTE
If the ESD wrist strap is unavailable, wear antistatic gloves.

l When correctly wearing an ESD wrist strap, make sure that the resistance value of the ESD
wrist strap range from 0.75 Mohms to 10 Mohms. The validity period of the ESD wrist
strap is two years. When the resistance of the ESD wrist strap fails to meet the requirement,
you need replace the ESD wrist strap.
l Avoid touching the boards with clothing because this may generate static electricity that
cannot be defended by the ESD wrist strap.
l Use the antistatic pad when replacing the board. Wear the ESD wrist strap properly and
use antistatic tweezers or extraction tools to take, remove, or insert chips. Do not touch
chips, circuits, or pins with bare hands.
l Keep boards and other static-sensitive parts that are not installed in antistatic bags. Place
some desiccant inside the bag to keep the board dry.
l Place the boards or parts that are temporarily removed on the antistatic pad or other antistatic
materials. Do not use non-antistatic materials such as white foams, common plastic bags,
or paper bags to pack boards. Keep these materials away from boards.

l Wear an ESD wrist strap when operating the ports of boards because they are also static-
sensitive. Discharge the static electricity of cables and protective sleeves before connecting
them to the ports.
l Reserve some board package materials, such as vacuum forming box and antistatic bags in
the equipment room for future use.
1.2.3 Battery
When installing or maintaining the battery, follow relevant safety precautions for the battery to
ensure the safety of human beings and the equipment.
DANGER
Before handling the battery, read the safety precautions and the procedure for connecting the
batteries.
Electrolyte overflow can cause potential damage to the device. It can lead to the corrosion of
metal parts and circuit boards, and damage the device and cause short-circuit of the circuit boards.
General Operations
Before installing and maintaining the battery, pay attention to the following:
l Do not wear metallic articles, such as a watch, hand chain, bracelet and ring.
l Use special insulation tools.
l Use eye protection devices.
l Wear rubber gloves. Wear an apron in case of electrolyte overflow.
l Always keep the electrode upright when handling the battery. Do not place the battery
upside down or tilt it.
Short Circuit
CAUTION
Short-circuit in a battery may cause injury. Though the voltage of a battery is low, high transient
current generated by a short-circuit releases a large amount of power.
Keep metal objects that can cause battery short-circuit away from the batteries. If metal objects
have to be used, first disconnect the batteries in use and then perform any operations.

Harmful Gas
CAUTION
Do not use unsealed lead-acid battery, because the gas emitted from the battery may result in
inflammation or device corrosion. Place the battery horizontally and then fix it properly.
The battery in use may emit flammable gas. Therefore, store the battery in a place with good
ventilation, and take precautions against fire.
High Temperature
CAUTION
High temperature may result in distortion, damage and electrolyte overflow in the battery.
When the temperature of the battery exceeds 60°C, check whether there is acid overflow. If yes,
clean the acid immediately.
Acid Liquid
CAUTION
In the case of acid overflow, absorb and neutralize the liquid immediately.
When moving or replacing a leaky battery, observe the damage caused by the acid. When acid
spill is found, use the following materials to absorb and neutralize it.
l Sodium bicarbonate (baking soda): NaHCO3
l Sodium carbonate (pure alkali): Na2CO3
When using antacids, strictly follow the guide provided by the battery supplier.
1.2.4 Microwave
When installing or maintaining microwave equipment, follow relevant safety precautions for
the microwave equipment to ensure the safety of human beings and the equipment.
WARNING
Strong radio frequency can harm the human body.
When installing or maintaining an aerial on the tower or mast that is installed with multiple
aerials, switch off the transmitter in advance.

1.2.5 Laser and Fibers

Clean the fiber connector correctly. To avoid injury caused by the laser beam to the human body,
replace and connect fibers safely.
Laser
CAUTION
The laser beam launched by the optical interface board or by a fiber can cause damage to your
eyes! Do not stare into the fiber connector without wearing protective glasses during the
installation or maintenance of the fiber.
Cleaning Fiber Connectors

Clean fiber connectors with special cleaning tools and materials. The common tools and
materials used for cleaning fiber connectors are as follows:
l Special cleaning solvent (Isoamylol is preferred, propyl alcohol is the next, alcohol and
formalin is forbidden.)
l Non-woven lens tissue
l Special compressed gas
l Cotton stick (medical cotton or long fiber cotton)
l Special cleaning roll, used with cleaning solvent listed in the first item
l Special magnifier for optical connectors
For cleaning steps, refer to OptiX RTN 950 Radio Transmission System Maintenance Guide.
Replacing Fibers
When replacing a fiber, cap the fiber connector of the unused fiber with the protective cap.
Connecting Fibers
Take the following precautions when connecting fibers.
l If the optical power is excessively high, an optical attenuator should be used to protect the
optical interfaces from being damaged.
l When the fiber connector does not match the optical interface, use an adapter to connect
the connector to the optical interface. In addition, ensure that the optical power meets the
specification requirement of the optical interface after the adapter is used because the use
of an adapter introduces certain attenuation.
1.2.6 High-Altitude Operations

When doing High-Altitude Operations, follow relevant safety precautions for High-Altitude
Operations to ensure the safety of human beings and the equipment.

WARNING
When working at a height, prevent objects from falling down.
When working at a height, comply with the following requirements:
l Only trained personnel can work at a height.

l The operating machines and tools should be carried and handled safely to prevent them
from falling.
l Safety measures should be taken such as wearing a helmet and a safety belt.
l In cold areas, wear warm clothes before performing any high-altitude operation.
l Appliances used for lifting objects must be checked and ensured to be intact before
performing any high-altitude operation.
1.2.7 Installing and Removing Boards

Removing the in-service board may result in service interruption. Thus, remove or insert a board
during off-peak hours.
DANGER
Do not remove the power cable and the PIU board when the power is on.
For details on how to replace the PIU, see "Replace the PIU".
CAUTION
l Before installing or removing a board, wear an ESD glove or ESD wrist strap.
l Do not remove or install the IF board and the IF cable when the equipment is powered on.
l When holding a board, never touch the circuits, components, cable connectors, and cabling
trough on the board.
l Before inserting a board, make sure that the protective tube on the backplane has been taken
off.
l Before inserting a board, make sure that no fiber or cable is connected to the board.
l Insert a board gently to prevent bending of the pins on the backplane.
l Insert a board along the slide rail of each slot to prevent the components on the board from
touching each other and causing short circuit.
l The interval for removing and inserting a board should be longer than 10 seconds.
After a board is inserted into the equipment, it takes several minutes for the board to enter the
normal running state after the startup.

1.2.8 Miscellaneous
When installing or maintaining Huawei network equipment, you also need to follow the safety
precautions for lifting heavy objects, operating sharp-cornered objects and binding signal cables
to ensure the safety of human beings and the equipment.
lifting heavy objects
WARNING
Do not stand or walk under heavy objects when they are being lifted.
operating sharp-cornered objects
WARNING
When carrying the device, wear protection gloves to prevent injuries that can be caused by sharp
objects.
binding signal cables
CAUTION
Bundle the signal cables separately from the strong current cables or high voltage cables. The
space between two adjacent ties must be at least 30 mm.
1.3 Precautions for Using the T2000

To use the T2000 correctly, you should be aware of the precautions for the running, setting, and
operation of the T2000.
Precautions for the Running of the T2000

To ensure that the T2000 runs properly, be aware of the following precautions:
l To ensure that the working power of the T2000 server is stable, use the uninterrupted power
supply (UPS).
l Install the T2000 software in a file path that contains only English characters and numbers.
l A T2000 license file is an authorized file and must be kept confidential. Do not make any
change to the license file. Otherwise, the license becomes invalid.
l On the UNIX platform, use the t2000 user to log in to the operating system on which the
T2000 server is installed.

l On the Windows platform, use the user that is chosen during the T2000 installation, to log
in to the operating system. Do not change the login user of Windows.
Precautions for the Setting of the T2000

When you set a computer on which the T2000 server or client runs, be aware of the following
precautions:
l Do not modify the system time when the T2000 is running. Set the system time when you
install the T2000.
– If the system time of the server needs to be modified, log out of the T2000 server and
then modify the system time. After the modification, restart the T2000 server.
– If the system time of the client needs to be modified, log out of the T2000 client and
then modify the system time. After the modification, restart the T2000 client.
l Do not modify the name and IP address of the computer where the T2000 server is installed,
unless required. Otherwise, the communication among NEs may fail.
Precautions for the Operation of the T2000

When you operate the T2000, be aware of the following precautions:
l When the T2000 is running, ensure that the data is consistent between the T2000 and the
NE.
– When the data on an NE has been configured and the NE runs properly, use the upload
or synchronization function to keep the data consistent between the T2000 and the NE.
– When the NE data stored on the NE has errors and the NE data stored on the T2000 is
correct, use the download or restoration function to keep the data consistent between
the T2000 and the NE.
l To change the configuration data, abide by the following rules:
– Before you change the configuration data, upload the NE data to keep the NE data
consistent between the T2000 and the NE.
– Before you change the configuration data, back up the NE database and the T2000
database, so that the data can be restored in the case of an operation failure.
– After you change the configuration data, back up the NE database and the T2000
database, so that the data can be restored in the case of an NE anomaly.
l Before you set parameters, query the latest data from the NE.
l Be very careful before a dangerous operation is performed. Usually the T2000 presents a
prompt to remind of the danger before a dangerous operation is performed.
l Periodically back up the MO data to minimize the loss caused by system anomalies.
– Back up the MO data of the T2000 every month.
– When the service configuration data is changed, immediately back up the MO data of
the T2000.
l Periodically clear outdated backup data to ensure that there is sufficient disk space for new
backup data.
l For an T2000 system that has multiple clients, you are recommended to use only one client
for configuration, and to use the other clients for monitoring.

Maintenance Guide 2 Routine maintenance
2 Routine maintenance
About This Chapter
Routine maintenance includes the remote maintenance (on the T2000) and spare parts
maintenance. Check the current state of the equipment to determine the working condition of
the equipment in time and to prevent any problem from occurring; Check the spare parts to
ensure that the spare parts can replace faulty components that operate in the network when a
board is faulty.
2.1 Routine Maintenance Items and Periods

To ensure the stable and long-term running of the equipment, the equipment should be
periodically maintained. This section describes the routine maintenance items and maintenance
periods of the equipment according to different maintenance scenarios.
2.2 Guide and Record Table for Routine Maintenance in the NMS Center
To ensure the normal running of the equipment, check the running status of the equipment, back
up the data periodically by using the T2000 and record the maintenance results at the network
management center.
2.3 Field Maintenance and Record Table for Outdoor Equipment
To ensure the smooth operation of the ODU, you need to periodically check the ODU on site
and record the associated information.
2.4 Guide and Record Table for Routine Maintenance of the Spare Parts
To ensure that the spare parts of the equipment are normal, check the spare parts in the storehouse
regularly and record the check results.

2 Routine maintenance Maintenance Guide
2.1 Routine Maintenance Items and Periods

To ensure the stable and long-term running of the equipment, the equipment should be
periodically maintained. This section describes the routine maintenance items and maintenance
periods of the equipment according to different maintenance scenarios.
Table 2-1 lists the routine maintenance items and periods.
Table 2-1 Maintenance items and periods

Maintena Maintena Maintenance Item Maintenanc
nce nce Site e Period
Owner
T2000 NMS center Checking the status of the NE and boards Daily
operator
Browsing network-wide alarms Daily
Browsing abnormal events Daily
Browsing the current performance events Daily
Browsing the performance events of the Daily

RMON statistics group
Checking the optical power Daily
Browsing DCN Communication Status Daily
Browsing the running status of dynamic tunnel Daily
Browsing the PW working status Daily
Browsing the history performance events Monthly
Browsing the RMON history performance Monthly

events
Backing up the MO data of the T2000 Monthly
Backing up the NE database Monthly
Testing the IF 1+1 Switching Monthly
Maintenanc Installation Checking the ODU Half-yearly

e engineer site
Checking the Hybrid Coupler Half-yearly
Checking the Antenna Half-yearly
Checking IF Cables Half-yearly
Maintenanc Spare parts Testing the spare parts Half-yearly

e engineer center

2.2 Guide and Record Table for Routine Maintenance in the

NMS Center
To ensure the normal running of the equipment, check the running status of the equipment, back
up the data periodically by using the T2000 and record the maintenance results at the network
management center.
2.2.1 Checking the Status of the NE and Boards

Regularly check the status of the NE and boards on the NE. In this way, the anomalies can be
detected and then handled in time.
2.2.2 Browsing Network-Wide Alarms
Regularly browse alarms to detect and rectify faults in time.
2.2.3 Browsing Abnormal Events
Regularly browse performance events of an NE. In this way, you can determine the current
running status of the NE and avoid the faults that are likely to occur.
2.2.4 Browsing the Current Performance Events
Browse the current performance events periodically to check the current running state of the
equipment. In this way, potential faults can be eliminated in time.
2.2.5 Browsing the Performance Events of the RMON Statistics Group
Browse the performance events of the RMON statistics group periodically. this helps you to
learn the running status of the ports and links, and the quality of services (QoS).
2.2.6 Checking the Optical Power
If the mean transmitted power and the receive power of the optical interface is excessively low
or high, bit errors occur or the optical components may be damaged, and thus services are
affected. To prevent this problem from occurring, you should check the optical power regularly
of every optical interface of the optical interface board.
2.2.7 Browsing the History Performance Events
Browse the history performance events periodically to learn the long-term running state of the
2.2.8 Browsing the RMON History Performance Events
Browse the history RMON performance events periodically. This helps you to understand the
running status of the ports and channels, and the long-term quality of services.
2.2.9 Backing up the MO Data of the T2000
Periodically back up the T2000 MO data. When the T2000 data is lost, use the MO data to fast
restore the T2000 data.
2.2.10 Backing up the NE Database
To ensure that the NE data can be quickly restored after the database of the system control board
is lost or the power failure occurs to the equipment, you should back up the NE database
periodically.
2.2.11 Testing the IF 1+1 Switching
Periodically testing the IF 1+1 switching helps you to check whether the equipment can switch
over normally.
2.2.12 Maintenance Record Table
Maintenance record table is used to record the result of the maintenance operations.

2.2.1 Checking the Status of the NE and Boards

Regularly check the status of the NE and boards on the NE. In this way, the anomalies can be
detected and then handled in time.
Prerequisite
l The T2000 must be started in the NMS center.
l The NE must be configured and the NE configuration data must be uploaded to the T2000.
l You must be a T2000 user with the "NE Monitor" authority or higher.
Maintenance Period
Daily
Tools, Instruments and Materials

T2000
Operation Criteria
The NE icon and boards icon should be displayed in green on the T2000, and their working
status is normal.
Procedure
Step 1 Click the shortcut icon in the T2000 Main Topology to display the description of NE status.
Step 2 Check the NE status in the T2000 Main Topology. Normally, The NE icon should be displayed
in green and its working status is normal. If not, handle the problem with reference to
the following and the 3 Troubleshooting and 9 Alarm.
l If the NE icon is grey and is present above the NE icon, it indicates that the
communication between the T2000 and NE is interrupted.
l If the NE icon is red , it indicates that the highest severity level of the alarms generated
on the NE is critical.
l If the NE icon is orange , it indicates that the highest severity level of the alarms
generated on the NE is major.
l If the NE icon is yellow , it indicates that the highest severity level of the alarms
generated on the NE is minor.
l If the NE icon is slight-blue , it indicates that the highest severity level of the alarms
generated on the NE is warning.
l If is present above the NE icon, it indicates that the T2000 and the NE are inconsistent
with respect to the NE configuration data. In this case, refer to 8.8 Uploading the NE
Configuration Data.
Step 3 Double-click the NE icon. The NE status displayed in the upper left portion of the NE slot layout
should be "Running Status". If the NE status is "unknown", it indicates that the NE fails to

communicate with the T2000, or that the NE status cannot be detected because of a fault on the
equipment. Handle the problem with reference to 3 Troubleshooting and 9 Alarm.
Step 4 Click the shortcut icon in the NE slot layout to display the description of board status.
Step 5 Query the working state of the board. The board icon should be green . If the board icon
is of any other colors, take the following guidelines to handle the anomaly.
l If the board icon is slight-green , It indicates that the physical board is in position but
the logical board is not added on the T2000. Right-click the board, and choose Add
Board from the shortcut menu.
l If the board icon is blue , it indicates that the board is in the running state but not in
position. In this case, the physical board is not in position but the logical board is added on
the T2000. Check the board on site to ensure that the board is installed and the board is in
proper contact with the backplane.
l If the board icon is grey , it indicates that the board is in the installation state and is
running abnormally. In this case, check whether the configuration data of the board is correct
or whether the board becomes faulty.
l If is displayed in the lower right portion of the board icon, it indicates that the board is
in the protection state. If the original working board is in the protection state, troubleshoot
the board.
l If is displayed in the lower left portion of the board icon or is displayed in the upper
right portion of the board icon, it indicates that loopback is set to the board. Determine
whether to release the loopback on the board as required.
----End
2.2.2 Browsing Network-Wide Alarms

Regularly browse alarms to detect and rectify faults in time.
Prerequisite
l The NE must be configured and the NE configuration data must be uploaded to the T2000.
Maintenance Period
Daily
Tools, Equipment and Materials

T2000
Operation Criteria
Use the T2000 to query the network-wide alarms. No new alarms exist.
NOTE
New alarms are the alarms generated during the query intervals.

Procedure
Step 1 Click in the upper right portion of the Main Topology of the T2000 to display the
Current Alarms-[All Critical] interface. You can browse the current critical alarms.
NOTE
When the indicator is surrounded by a square frame , it indicates that there are critical alarms
to be acknowledged.
When the indicator is surrounded by a square frame and the square frame flashes, it indicates
that there are new critical alarms to be acknowledged.
The number in the middle of the indicator indicates the number of current network-wide uncleared critical
alarms. Keep the Current Alarms-[All Critical] interface open when alarms are monitored.
Step 2 Select the new cleared alarms and check the alarm causes. Check whether these alarms indicate
any probable faults by referring to 3 Troubleshooting and 9 Alarm.
Step 3 Select all the alarms and click Acknowledge. The cleared alarms disappear and are stored as
history alarms.
Step 4 Select the new uncleared alarms and then check the alarm causes. Handle the faults with
reference to 3 Troubleshooting and 9 Alarm.
Step 5 Click in the upper right portion of the Main Topology of the T2000 to browse the current
major alarm, and follow Step 2 to Step 4 to check and handle the new major alarms.
NOTE
When the indicator is surrounded by a square frame , it indicates that there are major alarms
to be acknowledged.
that there are new major alarms to be acknowledged.
The number in the middle of the indicator indicates the number of current network-wide uncleared major
alarms. Keep the Current Alarms-[All Major] interface open when alarms are monitored.
Step 6 Click in the upper right portion of the Main Topology of the T2000 to browse the current
minor alarm, and follow Step 2 to Step 4 to check and handle the new minor alarms.
NOTE
When the indicator is surrounded by a square frame , it indicates that there are minor alarms to
be acknowledged.
that there are new minor alarms to be acknowledged.
The number in the middle of the indicator indicates the number of current network-wide uncleared minor
alarms. Keep the Current Alarms-[All Minor] interface open when alarms are monitored.
----End
2.2.3 Browsing Abnormal Events

Regularly browse performance events of an NE. In this way, you can determine the current
running status of the NE and avoid the faults that are likely to occur.

Prerequisite
l The NE must be configured and the data must be uploaded to the T2000.
Maintenance Period
Daily

T2000
Operation Criteria
None
Procedure
Step 1 Choose Fault > Browse Event from the Main Menu of the T2000 to display the Events window
and filter dialog box.
NOTE
If you previously set the startup template for browsing performance events (set the filter conditions), the
Filter dialog box is not displayed. Instead, the performance events matching the startup template are directly
displayed. For details on how to create a startup template, refer to the OptiX iManager T2000 Online Help.
Step 2 Optional: Click Import in the lower left corner in the Basic Settings tab or Event Source tab
to import the event browse template previously set. For details on how to create an event browse
template by setting filter conditions, refer to the OptiX iManager T2000 Online Help.
NOTE
The default event browse template covers all abnormal performance events and all NEs.
Step 3 Set the filter conditions for browsing performance events in the Basic Settings tab of the
Filter dialog box.
1. Optional: Select the Event Name check box and click . In the displayed Select
Event dialog box, select the performance events to be browsed.
2. In the Basic Settings tab of the Filter dialog box, set Severity, Type, and Generated
Time for performance events.
3. Optional: Select the Remarks contain check box and enter the remarks made previously
for specific performance events in the text box behind the Remarks contain to filter the
performance events.
Step 4 In the Event Source tab of the Filter dialog box, select the NEs whose performance events are
to be browsed.
1. Set the mode for selecting NEs in the Select Mode group box.
2. Adopt either of the following modes to select NEs whose performance events are to be
browsed.
l Enter the key words of the NE name or NE type in the text box below Object name
(By object) or Type (By type). Fuzzy search is supported. During the search, separate

key words with spaces. Then, click Find. The matched NE names or NE types are
displayed in the Navigation Tree.
l Select the NE name or NE type in the Object Navigation Tree (By object) or Type
Navigation Tree (By type).
Step 5 Click OK. The matched performance events, if there is any, are displayed in the Events window.
Step 6 Handle these abnormal performance events according to experience and by referring to the 3
Troubleshooting and 9 Alarm.
Step 7 Optional: Click Print or Save As to output the performance event data.
----End
2.2.4 Browsing the Current Performance Events

Browse the current performance events periodically to check the current running state of the
Prerequisite
l The service must be configured.
l The performance monitoring function must be enabled. In addition, the performance
monitoring parameters must be set.
NOTE
For details on how to enable the performance monitoring function and how to set the monitoring
parameters, refer to the iManager T2000 Online Help.
l You must be a T2000 user with the "NE and network monitor" authority or higher.
Maintenance Period
Daily

T2000
Operation Criteria
For different objects, the checking criteria are listed as follows:
l For the port, no bit errors are generated or received.
l For the board, the working temperature, CPU utilization and memory utilization are normal.
l For the MPLS tunnel and Ethernet service, no packet loss or error occurs.
Procedure
Step 1 On the Main Topology, select and right-click the desired NE. In the shortcut menu, choose NE
Explorer to display the NE Explorer window.
Step 2 In the NE Explorer, select an NE, and then enter the browse performance interface of each object
in the following way.

Object Entry
Port/board Select the corresponding board, and then choose Performance >
Current Performance from the Function Tree.
MPLS Tunnel 1. Choose Configuration > MPLS Management > Unicast Tunnel
Management from the Function Tree.
2. Select one or multiple tunnels.
3. Right-click the tunnel to choose Browse Performance to display
the Performance Management window.
4. Select the Current Performance tab.
Ethernet service 1. Choose Configuration > Ethernet OAM Management >

Ethernet Service OAM Management from the Function Tree.
2. Click the Maintenance Association tab, and then select one or
multiple MEP points.
3. Right-click the MEP points to choose Browse Performance to
display the Performance Management window.
4. Select the Current Performance tab.
Step 3 Select a monitored Object and the Monitor Period for this object.
NOTE
l Choose whether to display the consecutive severe bit error seconds according to requirements.
l If the object to be viewed is a physical port, you can also set the related query parameters for Gauge
and Count as required.
Step 4 Click Query to query the data from the NE.

Step 5 Optional: Click Reset to reset the performance register of the queried performance event.
NOTE
After the performance register is reset, the current performance data of this type is cleared. Then, a new
performance monitoring period is started.
----End
2.2.5 Browsing the Performance Events of the RMON Statistics

Group
Browse the performance events of the RMON statistics group periodically. this helps you to
learn the running status of the ports and links, and the quality of services (QoS).
Prerequisite

NOTE
parameters, refer to the OptiX iManager T2000 Online Help.
Maintenance Period
Daily

T2000
Operation Criteria
No packet loss and error packets occur.
Procedure
Step 2 In the NE Explorer, select the NE, and then enter the browse performance interface of each
object in the following way.
Object Entry
RMON Performance from the Function Tree.
MPLS tunnel 1. Choose Configuration > MPLS Management > Unicast Tunnel
2. Select one or multiple tunnels. Right-click the tunnel to choose
Browse Performance to display the Performance Management
window.
PW 1. Choose Configuration > MPLS Management > PW

2. Select one or multiple PWs, and then right-click the PW to choose
window.
ATM service 1. Choose Configuration > ATM Service Management from the
Function Tree.
2. Select one or multiple ATM services, and then right-click the service
to choose Browse Performance to display the Performance
Management window.

Object Entry
CES service 1. Choose Configuration > CES Service Management from the
Function Tree.
2. Select one or multiple CES services, and then right-click the CES
service to choose Browse Performance to display the Performance
Management window.
Ethernet service 1. Choose Configuration > Ethernet Service Management from the
Function Tree, and then select an Ethernet service type.
2. Select one or more services, and then right-click the service to choose
window.
Step 3 Click the Statistics Group tab.

Step 4 Select the monitored objects and performance events and set Query Conditions and Display
Mode.
NOTE
l If a performance event does not support the display of the accumulated value, after you check the
Display Accumulated Value check box in Query Conditions, perform the statistics. A dialog box is
displayed, indicating that the performance event cannot display the accumulated value.
l When Display Mode is set to Graphics, the number of the selected performance events cannot exceed
10.
Step 5 Click Start to display the results.

NOTE
If performance statistics should be made again, click Resetting begins.
----End
2.2.6 Checking the Optical Power

If the mean transmitted power and the receive power of the optical interface is excessively low
or high, bit errors occur or the optical components may be damaged, and thus services are
affected. To prevent this problem from occurring, you should check the optical power regularly
of every optical interface of the optical interface board.
Prerequisite
NOTE
Maintenance Period
Daily


T2000
Operation Criteria
For the technical specifications of the mean transmitted optical power and receive optical power
of different optical interfaces, refer to Technical Specifications of Boards in the OptiX RTN
950 Radio Transmission System Product Description manual.
Procedure
Step 2 Select a board or interface board with the optical interface in the NE Explorer. Then, Choose
Performance > Current Performance from the Function Tree.
Step 3 In Performance Event Type, select transmitted Optical Power and receive Optical Power.
Then, click Query.
Step 4 Check whether the transmitted optical power and receive optical power are within the normal
range.
NOTE
The receive optical power must follow the standard: receiver sensitivity + 3 dBm < receive optical power (tested)
< overload threshold - 5 dBm.
Step 5 Optional: If the mean transmitted optical power is not within the normal range, handle the fault
with reference to the following.
1. Check and clean the fiber connector according to 8.24 Inspecting and Cleaning the
Optical Fiber Connectors.
2. Perform Step 2 - Step 4 to test the mean transmitted optical power of the optical interface
again, until the mean transmitted optical power obtained is within the normal range.
3. Restore the fiber connection at the tested optical interface.
Step 6 Optional: If the receive optical power is not within the normal range, handle the fault with
reference to the following.
l If the receive optical power is less than sensitivity + 3 dBm:
1. Check whether the fiber connector and the optical attenuator are clean.
2. If the fiber connector is not clean, clean it according to 8.24 Inspecting and Cleaning
the Optical Fiber Connectors.

3. If the fiber flange or the optical attenuator on the ODF side is not clean, replace the
fiber flange or the optical attenuator.
4. Perform Step 2 - Step 4 to test the receive optical power of the optical interface again,
until the receive optical power obtained is within the normal range.
l If the receive optical power is larger than overload threshold - 5 dBm
1. Check whether the optical attenuator is normal.
2. If the optical attenuator is normal, add an optical attenuator on the ODF side.
3. If the optical attenuator is not normal, replace the optical attenuator.
4. Perform Step 2 - Step 4 to test the receive optical power of the optical interface again,
until the receive optical power obtained is within the normal range.
Step 7 Repeat the previous steps to test the transmitted optical power and receive optical power at all
the other optical interfaces of the equipment one by one.
----End
2.2.7 Browsing the History Performance Events

Browse the history performance events periodically to learn the long-term running state of the
Prerequisite
NOTE
parameters, refer to the iManager T2000 Online Help.
Maintenance Period
Monthly

T2000
Operation Criteria
Determine the stability of service links by analyzing the collected history performance data.
Check the links working in an unstable state.

Procedure
Step 2 In the NE Explorer, select an NE, and then enter the browse performance interface of each object
in the following way.
Object Entry
Physical port/ Select the corresponding board, and then choose Performance >
board History Performance from the Function Tree.
2. Select one or multiple tunnels.
3. Right-click the tunnel to choose Browse Performance to display the
Performance Management window.
4. Select the History Performance tab.
Ethernet service 1. Choose Configuration > Ethernet OAM Management > Ethernet
Service OAM Management from the Function Tree.
2. Click the Maintenance Association tab, and then select one or
multiple MEP points.
3. Right-click the MEP points to choose Browse Performance to
display the Performance Management window.
4. Select the History Performance tab.
Step 3 Choose monitored Object and set the Monitor Period, From, To and Data Source.
NOTE
l If you view the history performance data from NE, you can set save to database by your need.
l If the object is physical port, you can also set the parameters of Gauge and Count.
Step 4 Click Query to display the results.
Step 5 Optional: Click Reset to reset the performance registers.

NOTE
After the resetting, the history performance data is deleted and a new performance monitoring period is
beginning.
----End
2.2.8 Browsing the RMON History Performance Events

Browse the history RMON performance events periodically. This helps you to understand the
running status of the ports and channels, and the long-term quality of services.

Prerequisite
NOTE
Maintenance Period
Monthly

T2000
Operation Criteria
Determine the long-term running quality of the service by analyzing and collecting the history
performance data. In the case of links with high loading for a long time, adjust the services. Take
some measures to prevent the high loading working state within a period. If the service link
works in an unstable state, clear the interference in time.
Procedure
Step 2 In the NE Explorer, select the NE, and then enter the browse performance interface of each
object in the following way.
Object Entry
RMON Performance from the Function Tree.
2. Select one or multiple tunnels. Right-click the tunnel to choose
window.
PW 1. Choose Configuration > MPLS Management > PW

2. Select one or multiple PWs, and then right-click the PW to choose
Browse Performance to display thePerformance Management
window.

Object Entry
ATM service 1. Choose Configuration > ATM Service Management from the
Function Tree.
2. Select one or multiple ATM services, and then right-click the service
to choose Browse Performance to display the Performance
Management window.
CES service 1. Choose Configuration > CES Service Management from the
Function Tree.
2. Select one or multiple CES services, and then right-click the CES
service to choose Browse Performance to display the Performance
Management window.
Ethernet service 1. Choose Configuration > Ethernet Service Management from the
Function Tree, and then select an Ethernet service type.
2. Select one or more services, and then right-click the service to choose
window.
Step 3 Click the History Group tab.

Step 4 Select the monitored objects and performance events and set From, To, History Table Type
and Display Mode.
NOTE
When Display Mode is set to Graphics, the number of the selected performance events cannot exceed 10.
Step 5 Click Query to display the results.
----End
2.2.9 Backing up the MO Data of the T2000

Periodically back up the T2000 MO data. When the T2000 data is lost, use the MO data to fast
restore the T2000 data.
Prerequisite
You must be a T2000 user with "NM Maintainer" authority or higher.
Context
The default directories where the database file should be backed up are as follows.
l On the UNIX platform, back up the MO data to /T2000/server/database/dbbackup.
l On the Windows platform, back up the MO data to \T2000\server\database\dbbackup.
NOTE
l The MO data backed up can not be restored on T2000 of different versions.

l Multiple modes of backing up the MO data are available. This section only describes the mode of
backing up the MO data to the local server. For other backup modes, refer to the OptiX iManager
T2000 Online Help.

Maintenance Period
Monthly

T2000
Operation Criteria
The system indicates that the backup operation is successful.
Procedure
l Back up the MO data on the T2000 client.
1. Choose System > Database > Database Backup from the Main Menu, and then the
Backup dialog box is displayed.
2. To set the backup directory on the server, click Backup. The T2000 backs up the
database immediately and a progress bar is displayed.
NOTE
The backup directory should be short and should not contain special characters, such as spaces,
punctuations or Chinese characters.
l Back up the MO data by using the database management tool.
1. Start Database Management Tool.

– On the Windows platform, open Windows Explorer. In the \T2000\server
\database directory, run T2000DM.exe. The T2000DM.exe window appears and
then immediately disappears, and the Database Management Tool window
displays.
– On the UNIX platform, right-click on the CDE desktop and then choose Tools >
Terminal to display a terminal window. In the /T2000/server/database directory,
run T2000DM.sh to display the Database Management Tool window.
2. In Database Server List on the left, select T2000DBServer.
3. In the displayed dialog box, enter the password of user sa.
NOTE
By default, the password of user sa is null.

4. Click Backup MO to display the Description dialog box.
5. Set the backup directory on the server, and enter the relevant description information.
Click Backup to display the Backup MO dialog box. In this case, the backup of the
MO data of the T2000 is started.
NOTE
l Customizing the backup directory of the data prevents the backup data from being affected
when you reinstall the system or format disk C. In this way, the maintainability of the
system is improved.
l The backup directory should be short and should not contain special characters, such as
spaces, punctuations or Chinese characters.

6. In the Backup MO dialog box, the progress of MO data backup is displayed. When
the backup is finished, click OK in the dialog box. Return to the database management
tool interface.
----End
2.2.10 Backing up the NE Database

To ensure that the NE data can be quickly restored after the database of the system control board
is lost or the power failure occurs to the equipment, you should back up the NE database
periodically.
Prerequisite
l You must be a T2000 user with "NE and network operator" authority or higher.
l You must log in to the NE as an NE user of the system level.
Maintenance Period
Monthly

T2000
Operation Criteria
The system indicates that the backup operation is successful.
Procedure
Step 1 Choose Configuration > Configuration Data Management from the Main Menu.
Step 2 In the Object Tree on the left, select one or more NEs and click .
Step 3 Select one or more NEs from Configuration Data Management List.
Step 4 Click Back Up NE Data, select Back Up Database To SCC or Manually Back Up Database
To SCC.
Step 5 Click OK in the Confirm dialog box, and then the system starts to back up the NE database.
Step 6 After the backup is complete, the Operation Result dialog box, which indicates that the backup
is successful, is displayed. Click Close.
----End
2.2.11 Testing the IF 1+1 Switching

Periodically testing the IF 1+1 switching helps you to check whether the equipment can switch
over normally.

Prerequisite
l The T2000 is in normal communication with the NE.
l The NE user has the authority of maintenance level or higher.
Tools, Instruments, and Materials

T2000
Precautions
l The IF 1+1 switching performed manually is a HSB switching. During the 1+1 protection
switching (< 200 ms), protection services are interrupted. Hence, you are recommended to
carry out 1+1 protection switching when the traffic is light.
l Before you perform the switching, ensure that the standby equipment is working properly.
If the switching fails, contact Huawei engineers for further assistance.
Procedure
Step 1 Select an NE from the NE Explorer, and choose Configuration > Microwave Link
Configuration from the Function Tree.
Step 2 Select the IF 1+1 Protection tab.
Step 3 In Protection Group, select the protection group that is to be switched over.
Step 4 In Slot Mapping Relation, right-click the IF board, and choose Manual Switch to
Protection from the shortcut menu.
Step 5 Click OK to begin the protection switching.
Step 6 Click Query to check the protection switching status.
After the switching is complete, the Switching Status of Device of the working board should
be Manual Switching.
Step 7 After the equipment runs properly for a period, query the current alarms and performance events.
There should be no new alarms or performance events.
Step 8 Repeat Step 1 to Step 3.
Step 9 In Slot Mapping Relation, right-click the IF board, and choose Clear from the shortcut menu.
Step 10 Click OK to restore the protection switching.
Step 11 Click Query to check the protection switching status.
The Switching Status of Device of the working board should be Normal.
Step 12 After the equipment runs properly for some time, query the current alarms and performance
events.
There should be no new alarms or performance events.
----End


Maintenance Record Table

Maintenance date：
Maintenance Item Maintenance Status Remarks Maintainer
Checking the status of the NE and the
□Normal □Abnormal
boards
Browsing the network-wide alarms □Normal □Abnormal
Browsing Abnormal Events □Normal □Abnormal
Checking the optical power □Normal □Abnormal
Browsing DCN communication status □Normal □Abnormal
Browsing the current performance □Normal □Abnormal
Browsing the performance of the
RMON statistics group
Browsing the running status of
dynamic tunnel
Browsing the PW working status □Normal □Abnormal
Browsing the history performance □Normal □Abnormal
Browsing the RMON history
performance
Backing up the MO data of the T2000 □Normal □Abnormal
Backing up the NE database □Normal □Abnormal
Testing the IF 1+1 Switching □Normal □Abnormal
Problems and their solution:
Pending problems:
Verification:
2.3 Field Maintenance and Record Table for Outdoor

Equipment
To ensure the smooth operation of the ODU, you need to periodically check the ODU on site
and record the associated information.
2.3.1 Checking the ODU

Periodically checking the ODU helps you to find faults and hidden troubles of the ODU in a
timely manner.

2.3.2 Checking the Hybrid Coupler

Periodically checking a hybrid coupler helps you to find faults and hidden troubles of the coupler
in time.
2.3.3 Checking the Antenna
Periodically checking an antenna helps you to find faults and hidden troubles of the antenna in
a timely manner.
2.3.4 Checking IF Cables
Periodically checking the IF cables helps you to find faults and hidden troubles of the cables in
a timely manner.
2.3.1 Checking the ODU

Periodically checking the ODU helps you to find faults and hidden troubles of the ODU in a
timely manner.
Prerequisite
None.

None.
Procedure
Step 1 Ensure that the ODU is located within the protected area of the lightning arrester.
For plain areas, the lightning arrester protects the area that is located within an angle of 45° under
it. For mountainous areas and the areas where lightning frequently occurs, the lightning arrester
protects the area that is located within an angle of 30° under it.
Step 2 Ensure that the ODU is properly fixed on the antenna.
Step 3 Ensure that the ODU is not damaged.
Step 4 Ensure that the interface between the ODU and the antenna is waterproof.
Step 5 Ensure that the protection grounding cable of the ODU is firmly and reliably grounded.
----End
2.3.2 Checking the Hybrid Coupler

Periodically checking a hybrid coupler helps you to find faults and hidden troubles of the coupler
in time.
Prerequisite
None.

None.

Procedure
Step 1 Ensure that the coupler is located within the protected area of the lightning arrester.
Step 2 Ensure that the coupler is reliably fixed on the antenna.
Step 3 Ensure that the coupler is not damaged.
Step 4 Ensure that the interface between the coupler and the antenna is waterproof.
Step 5 Ensure that the interface between the coupler and the ODU is waterproof.
----End
2.3.3 Checking the Antenna

Periodically checking an antenna helps you to find faults and hidden troubles of the antenna in
a timely manner.
Prerequisite
None.

None.
Procedure
Step 1 Ensure that the antenna is located within the protected area of the lightning arrester.
Step 2 Ensure that the antenna is reliably fixed on the mast.
Step 3 Ensure that the antenna radome is not damaged.
Step 4 Ensure that there is no accumulated water in the antenna.
Step 5 Check whether the fastening bolts on the antenna are loose. Check whether the antenna slants
from the original position. Ensure that the azimuth angle and the elevation angle of the antenna
meet the design requirements.
Step 6 In the case of split mounting, ensure that the installation parts (ODU adapter, antenna adapter,
and flexible waveguide) are installed firmly, and that the connectors are fastened.
Step 7 Check and ensure that the interface of the feed boom is properly sealed and waterproof.
----End
2.3.4 Checking IF Cables

Periodically checking the IF cables helps you to find faults and hidden troubles of the cables in
a timely manner.

Prerequisite
None.

None.
Procedure
Step 1 Check the appearance of cables.
l There should be no bent or twisted cable.
l There should be no bare copper wire.
l The bending radius of the cable should be greater than 30 cm.
Step 2 Check the cable connectors.

l The cable connector should be reliably connected to the ODU.
l The cable connector should be waterproof.
Step 3 Check the grounding of the cables.

l The grounding clip should be waterproof.
l The grounding cable should be routed from top downwards. The angle between the grounding
cable and the IF cable should not be more than 15 degrees.
----End

Table 2-2 Maintenance Record Table

Maintenance Maintenance Maintenance Remarks Maintainer
Item Status Period
Checking the □Normal □ Half a year

ODU Abnormal

Hybrid Coupler Abnormal

Antenna Abnormal
Checking IF □Normal □ Half a year

Cables Abnormal
Pending problems:
Verification:

2.4 Guide and Record Table for Routine Maintenance of the

Spare Parts
To ensure that the spare parts of the equipment are normal, check the spare parts in the storehouse
regularly and record the check results.
2.4.1 Testing the Spare Parts

Check the status and versions of the spare parts regularly. This ensures that the spare parts can
replace the faulty boards in the existing network at any time and thus improves the maintenance
efficiency.
Maintenance record table is used to record the result of maintenance operations.
2.4.1 Testing the Spare Parts

Check the status and versions of the spare parts regularly. This ensures that the spare parts can
replace the faulty boards in the existing network at any time and thus improves the maintenance
efficiency.
Prerequisite
l Important boards must be available in the spare parts center.
l Spare NEs must be available in the spare parts center for testing the spare parts.
Maintenance Period
Half-yearly

T2000
Operation Criteria
In terms of the BIOS version, software version, and the FPGA version, the spare parts should
be consistent with or compatible with the boards of the same type running on the network.
NOTE
A portion of the boards of different printed circuit board (PCB) versions are mutually compatible. If the
PCB versions of the spare parts are different from those of the running boards, consult local Huawei
technical support engineers.
Procedure
Step 1 Log in to the T2000 client. Choose Report > Board Information Report from the Main Menu.
Step 2 Click on the left to refresh the Navigation Tree. Then, select the NE and boards for query
and click .

Step 3 Click Query. A dialog box is displayed to indicate that the operation is successful.
Step 4 Click Close. The status and version information of each board of the NE is displayed in the
interface.
Step 5 Record the BIOS version, software version, PCB version and logic version of the spare part.
Step 6 Check whether the version of the spare part is consistent with that of the board of the same type
running in the network. If inconsistent, consult local Huawei technical support engineers for
handling.
----End
Reference Information
Follow the listed principles to maintain the spare parts.
l Principle for check of spare parts:

– Check the version and quality of spare parts periodically.
– The version of spare part must be consistent with the version of the same type of board
running in the network in terms of software, BIOS, PCB and logic.
– When the network is to be upgraded, provide the parts in time and upgrade the version
of the running parts.
l Principle for storage of parts:
– The spare parts must be stored in line with regulations and be kept for exclusive use.
– The spare parts must be stored in anti-static bags and no friction should be caused among
them. These bags with parts inside should be kept in special anti-static cupboard and
away from sundries.
– Wear an anti-static glove to touch the spare parts.
– The inbound/outbound information must be recorded and timely refreshed. Hence, the
parts can be supplemented accordingly.

Maintenance record table is used to record the result of maintenance operations.
Table 2-3 Maintenance Record Table
Maintenance Item Maintenance Remarks Maintainer

Status
Testing the Spare □Normal □

Parts Abnormal
Pending problems:
Verification:

Maintenance Guide 3 Troubleshooting
3 Troubleshooting
About This Chapter
This chapter describes the thought and process of troubleshooting equipment faults with respect
to the common flow, emergency flow, information collection, and fault notification.
3.1 General Fault Handling Flow
Adherence to the general fault handling flow helps you to rectify the system faults in time.
3.2 Emergency Flow of Handling the Service Interruption Fault
If any fault causes service interruption, follow the general fault handling flow and also take other
emergency measures, such as backup trails, to reduce the service interruption time to the
minimum.
3.3 Troubleshooting Microwave Links
When an NE reports MW_LOF or MW_FECUNCOR due to failure or performance degrade of
a microwave link, there is a microwave link fault.
3.4 CES Service Troubleshooting
This section describes how to troubleshoot interruption or bit errors of the CES service in terms
of the symptoms, impact on the system, possible causes, tools required for troubleshooting,
troubleshooting procedure, and precautions that should be taken during the troubleshooting.
3.5 Ethernet Service Troubleshooting
This section describes how to troubleshoot Ethernet service interruption or packet loss in terms
3.6 Clock Troubleshooting
This section describes how to troubleshoot loss of the clock source and degrade of clock signals
in terms of the symptoms, impact on the system, possible causes, tools required for
troubleshooting, troubleshooting procedure, and precautions that should be taken during the
troubleshooting.
3.7 QoS Troubleshooting
This section describes the QoS faults in terms of the symptoms, impact on the system, possible
causes, tools required for troubleshooting, troubleshooting procedure, and precautions that
should be taken during the troubleshooting.
3.8 Inband DCN Troubleshooting

3 Troubleshooting Maintenance Guide
This section describes the inband DCN faults in terms of the symptoms, impact on the system,
possible causes, tools required for troubleshooting, troubleshooting procedure, and precautions
that should be taken during the troubleshooting.
3.9 LAG Troubleshooting
This section describes the LAG faults in terms of the symptoms, impact on the system, possible
3.10 ML-PPP Troubleshooting
This section describes the ML-PPP faults such as service interruption, packet loss, or bit error
troubleshooting.
3.11 IMA Troubleshooting
This section describes the IMA faults in terms of the symptoms, impact on the system, possible
3.12 FRR Troubleshooting
This section describes the FRR faults in terms of the symptoms, impact on the system, possible
3.13 MPLS APS Troubleshooting
This section describes the MPLS APS faults in terms of the symptoms, impact on the system,
3.14 Information Collection and Information Record
Collect information and record the information in a timely manner for locating and rectifying
the fault quickly.
3.15 Fault Notification and Technical Support
During troubleshooting, you can inform Huawei of the faults and apply for technical support, if
necessary.

3.1 General Fault Handling Flow

Adherence to the general fault handling flow helps you to rectify the system faults in time.
Flow Diagram
Figure 3-1 shows the general flow diagram for handling faults.
Figure 3-1 General flow diagram for handling faults
Start
Observe and record

fault phenomenon
External Yes
Other handling flow
anomalies?
No
Find cause and locate

fault
Rectify fault
No Contact Huawei for

Fault rectified?
technical support
Yes
Write fault Find solution together

handling report and rectify fault
End
Description of the Fault Handling Flow

Observe and record fault phenomena
Observe the fault phenomena and record them. Record the details of the fault, especially the
time when the fault occurs, and the operations performed before and after the fault in details.

You can also save the important data such as the alarm and performance event information stored
on the T2000.
Handle external anomalies
Check whether the fault lies in external anomalies concerning the power supply, fiber, ambience
in the equipment room (temperature, for example), and terminal equipment. If yes, handle the
anomalies immediately.
Make experience-based judgment and theory-based analysis
According to the information on the fault phenomena and other fault-related information,
analyze the probable causes based on the experience and related theories.
Rectify faults
According to the probable causes, make a plan to confirm each probable cause, find out the most
likely cause, and rectify the fault. For details, refer to Table 3-1.
Table 3-1 Troubleshooting for different services and functions
S Type of trouble Contents

N
1 Microwave Links Refer to 3.3 Troubleshooting Microwave Links.
2 CES service Refer to 3.4 CES Service Troubleshooting.
3 Ethernet service Refer to 3.5 Ethernet Service Troubleshooting.
4 Clock Refer to 3.6 Clock Troubleshooting.
5 QoS Refer to 3.7 QoS Troubleshooting.
6 Inband DCN Refer to 3.8 Inband DCN Troubleshooting.
7 LAG Refer to 3.9 LAG Troubleshooting.
8 ML-PPP Refer to 3.10 ML-PPP Troubleshooting.
9 IMA Refer to 3.11 IMA Troubleshooting.
10 FRR Refer to 3.12 FRR Troubleshooting.
11 MPLS APS Refer to 3.13 MPLS APS Troubleshooting.
NOTE
Confirm the probable causes one by one.
Check whether the fault is rectified
After confirming a cause, analyze the result to check whether the fault is rectified and whether
any new fault occurs.
l If the fault persists, contact Huawei technical support engineers.

l If the fault is rectified, prepare the fault handling report.

l If new faults occur, refer to the fault handling flow and try to rectify them.
Contact Huawei engineers for co-work
If you fail to rectify the fault, contact Huawei technical support engineers and co-work with
them to find a solution. For contact information, see 3.15 Fault Notification and Technical
Support.
If remote maintenance is required, refer to 7 Remote Maintenance Guide and work with
Huawei engineers for remote access.
Write the fault handling report
After rectifying a fault, record the work done for handling the fault in a timely manner. When
summarizing the working experience, provide reference information for handling similar faults.
The report should contain the following key information:

l Description of the fault phenomenon and collected fault-related information
l Probable causes of the fault
l Plan and confirmation result for each probable cause
l List of involved equipment and instruments used for confirming the probable causes
l Experience of confirming probable causes
l Others such as the references used during the process
3.2 Emergency Flow of Handling the Service Interruption

Fault
If any fault causes service interruption, follow the general fault handling flow and also take other
emergency measures, such as backup trails, to reduce the service interruption time to the
minimum.
CAUTION
Take the following precautions when handling the service interruption fault or any other
emergency according to the emergency flow:
l Restore services as soon as possible. If backup channels are available, switch services to
the backup channels.
l Observe the fault phenomenon, find the cause, and rectify the fault.
l When you cannot handle the fault, contact Huawei for technical support and work with
Huawei to handle the fault and to minimize the service interruption duration.
l Properly make a record when handling a fault and save the original data.
Flow Diagram
Figure 3-2 shows the flow diagram for handling service interruption.

Figure 3-2 Flow diagram for handling service interruption
Start
T2000
Yes Perform reverse operation

Any mis-operation?
to restore service
No
Any Yes Reset/re-insert/replace

equipment alarm on
board
NE?
No
Perform
Any signal Yes inloop on opposite No Reset/re-insert/replace
loss alarm? port and recheck board of the opposite NE
alarm
Yes
Handle anomaly of
No
interconnected equipment
Yes Any line Yes Handle fiber cut/board

Any line alarm? alarm on adjacent
fault/power supply problem
NE?
No
Any No Change service route or

protection switching
use standby route
configured?
No
Yes
Reset/re-insert
Check fiber and use
faulty board, disable
standby route
protection protocol
Yes Change port loopback

Any loopback?
configuration
No
Any Yes Change service

service configuration
configuration
error
No
Fault ratified?
No
Yes
Contact Huawei for

End
technical support

Description of the Emergency Handling Flow

Check for misoperations
Check whether any misoperations are performed before the fault occurs, such as addition or
deletion of services or boards, and configuration change. In the case of any misoperation, perform
the reverse operation to restore the services.
Check alarms
When the services are interrupted, check for any of the alarms listed in Table 3-2 and rectify
the fault indicated by the alarm accordingly.
Table 3-2 Alarm description
Alarm Type Alarm Name Indication
Equipment alarm HARD_BAD The board hardware becomes

faulty.
Signal loss alarm ETH_LOS A link breaks.

The network interface has no
signals (PHY-layer
detection).
The board has no signal
input.
EXT_SYNC_LOS The system detects loss of the

external clock source traced
by the equipment.
Line alarm PW_DOWN A PW service connection is

interrupted.
NOTE
The alarms listed in Table 3-2 may cause service interruption. Therefore, take priority to handle these
alarms. For details on other alarms reported on the T2000, see 9.3 Alarm Handling.
Check loopback
Check whether any loopback is set along the service route.
Check service configuration
Check the service configuration section by section along the route.
3.3 Troubleshooting Microwave Links

When an NE reports MW_LOF or MW_FECUNCOR due to failure or performance degrade of
a microwave link, there is a microwave link fault.

Context
The key to locating a microwave link fault is to check whether the transmit power and the receive
power are abnormal, and to check whether there is an external interference.
In the following two cases, the transmit power is abnormal. The first case is that the transmit
power exceeds the range that the ODU supports. The second case is that the difference between
the transmit power and the set value is more than 2 dB when the ATPC is disabled. The relevant
alarms and performance events are as follows:
l RADIO_TSL_HIGH
l RADIO_TSL_LOW
l TSL_CUR
l TSL_MAX
l TSL_MIN
NOTE
For a detailed description of the range of the transmit power, refer to the OptiX RTN 950 Radio Transmission
System Product Description.
In the following two cases, the RSL is abnormal. The one case is that the receive power is lower
than the ideal value (Ideal value = Planned value - 3 dB). The second case is that the receive
power is lower than the receiver sensitivity or higher than the free space receive power due to
fading. The relevant alarms and performance events are as follows:
l RADIO_RSL_HIGH
l RADIO_RSL_LOW
l RSL_CUR
l RSL_MAX
l RSL_MIN
NOTE
For a microwave link on which the AM function is enabled, the receiver sensitivity refers to the receiver
sensitivity that guarantees the capacity.
For a detailed description of the receiver sensitivity, refer to the OptiX RTN 950 Radio Transmission System
Product Description.
Generally, external interference is classified into co-channel interference and adjacent channel
interference.
l Co-channel interference is crosstalk from two different radio transmitters reusing the same
frequency channel. Therefore, the entire spectrum may be impaired.
l Adjacent channel interference is signal impairment to one frequency due to presence of
another signal on a nearby frequency. Therefore, a part of the spectrum is impaired.
Because interference is closely related to the frequency in use, the transmission over a microwave
link may be faulty in one direction only.

Fault Causes
Table 3-3 Causes of microwave link faults

Fault Common Fault Causes
The transmit power is abnormal. The ODU is faulty.
The receive power is always lower than the l The antenna direction is not properly
ideal value. adjusted.
l The antennas have different polarization
directions.
l There is a mountain or obstacle in the
transmit direction.
l The antenna is faulty or the antenna and the
ODU are connected abnormally. For
example, the waveguide interface on the
ODU is wet, or the flexible waveguide is
loose.
l The ODU is faulty.
The receive power is abnormal due to slow There is an external interference.

up-fading.
The receive power is abnormal due to slow The fading margin is not sufficient.
down-fading.
The receive power is abnormal due to fast The multipath fading is fast.
fading.
The receive power is always normal, but the There is external interference.
microwave link becomes faulty occasionally.
NOTE
Depending on the received level, there is up fading and down fading.

l Up fading
The received level is higher than the value after free space fading. The difference can be 10-odd decibels.
l Down fading
The received level is lower than the value after free space fading. The difference can be tens of decibels.
Depending on the fading time, there is fast fading and slow fading.
l Fast fading
The fading duration time ranges from several milliseconds to tens of seconds.
l Slow fading
The fading duration time ranges from tens of seconds to several hours.
Because slow down fading and fast fading are imposed by the propagation paths, the microwave link may be
faulty in both directions.

Fault Locating Methods

1. Check whether the ODU is mute, powered off, or looped back. Check whether the data
configuration is correct.
2. Check whether the ODU and the IF board are faulty.
3. If the transmit power is abnormal, replace the ODU.
4. If the receive power is abnormal, check out the possible causes based on the fading type.
5. If the receive power is always normal, but the microwave link becomes faulty occasionally.
Check whether there is interference before you proceed.
6. If the transmit/receive power is normal, perform loopback operations.

Fault Locating Procedures
Figure 3-3 Flow of handling microwave link faults
Start
1 Yes
Is there a wrong
Cancel the operation
operation?
No
2 Is there an ODU or IF Yes

Handle the alarm
board related fault?
No
3
No
Normal transmit power? Handle the fault
Yes
4
The receive power Yes
always lower than the Handle the fault
ideal value?
No
5
Abnormal receive Yes
power caused by slow up- Handle the fault
fading?
No
6
power caused by slow Handle the fault
down-fading?
No
7
power caused by fast Handle the fault
fading?
No
8
Microwave link Yes
fault in one Handle the fault
direction?
No
9
No
Perform loopback operations Go to the next step Is the fault cleared?
Yes
End

Table 3-4 Flow description

Note Description
① Handle Check the following points:

incorrect l Check whether the ODU is powered off.
operations.
l Check whether the ODU is muted.
l Check whether the IF board is looped back.
l Check whether the data configuration at the transmit end is the same as the
data configuration at the receive end.
l Check whether the data configuration matches the type of the ODU and
the hybrid coupler.
② Handle Pay special attention to:

equipment l HARD_BAD
faults.
l TEMP_ALARM
l IF_INPWR_ABN
l RADIO_MUTE
l RADIO_TSL_HIGH
l RADIO_TSL_LOW
l RADIO_RSL_HIGH
l IF_CABLE_OPEN
③ Handle Replace the ODU.

theanomaly
of transmit
power.

Note Description
④ Handle Follow the steps below:

the anomaly 1. If the RSL decreases dramatically and does not recover, check the
that the installation of the antenna. Check whether the azimuth angle of the antenna
receive meets the requirement.
power is
smaller than 2. If the RSL difference between the main and standby ODUs on one end of
the ideal a 1+1 HSB microwave link exceeds the range 0 to 9 dB (for the unbalanced
value. hybrid coupler) or the range 0 to 5 dB (for the balanced hybrid coupler),
determine the faulty part by replacing the ODU or hybrid coupler.
3. If the RSL difference between the receive and transmit ends exceeds 10
dB, determine the faulty ODU by replacing the ODU.
4. Check the antenna direction. Check whether the received signal is from the
main lobe.
If the antenna direction does not meet the requirement, adjust the antenna
in a wide range.
5. Check whether the setting of the polarization direction of the antenna is
correct. Adjust wrong polarization direction.
6. Determine the faulty part by replacing the ODU or hybrid coupler.
7. Check whether the antenna gain at both the transmit and receive sides meets
the indexes. Replace unqualified antennas.
8. Check whether there is a mountain or obstacle in the transmit direction.
⑤ Handle Follow the steps below:

the up slow 1. Check whether there is co-channel interference.
fading fault.
1. Mute the opposite ODU.
2. Check the RSL at the local end. If the RSL exceeds –90 dBm, you can
infer that there is co-channel interference that may impair the long-term
availability and performance of the system.
2. Use a spectrum analyzer to analyze the interference source.
3. Contact the spectrum management department to clear the interference
spectrum or change plans to reduce the interference.
⑥ Handle Contact the network planning department to make the following changes:
the down l Increase the installation height of the antenna.
slow fading
fault. l Reduce the transmission distance.
l Increase the antenna gain.
l Increase the transmit power.

Note Description
⑦ Handle Contact the network planning department to make the following changes:
the fast l Adjust the position of the antenna to block the reflected wave or make the
fading fault. reflection point fall on the ground that has a small reflection coefficient,
thus reducing the multipath fading.
l Adjust the RF configuration to make the links in the 1+1 SD configuration.
l For the links in the 1+1 SD configuration, adjust the height difference
between two antennas to make the receive power of one antenna much
stronger than that of another.
l Increase the fading margin.
⑧ Handle The handling procedure is as follows:

the 1. Check whether there is co-channel interference.
interference
fault. 1. Mute the opposite ODU.
2. Check the RSL at the local end. If the RSL exceeds –90 dBm, you can
infer that there is co-channel interference that may impair the long-term
availability and performance of the system.
2. Check whether there is adjacent channel interference.
1. Mute the opposite ODU.
2. Adjust the microwave working mode at the local end and use the
minimum channel spacing.
3. Decrease the received frequency at the local end by a half of the channel
spacing.
4. Test and record the RSL.
5. Increase the received frequency at the local end, with a step length of
0.5 MHz or 1 MHz, and record the RSL accordingly until the received
frequency is equal to the original received frequency plus a half of the
channel spacing.
6. Compare the recorded RSLs, and check whether the RSL in a certain
spectrum is abnormal if the received frequency is within the permitted
range.
3. Use a spectrum analyzer to analyze the interference source.
4. Contact the spectrum management department to clear the interference
spectrum or change plans to reduce the interference.
⑨ Use the Follow the steps below:

loopback 1. Perform the inloop on the IF port.
method to
locate a fault. If the fault is not cleared after the loopback, replace the IF board.
2. Check whether the cable connector is made in accordance with
specifications. If not, make the connector again. For details, refer to
Quickly Installation Guide.
3. Check whether the IF cable is soggy, broken or pressed. If yes, replace the
IF cable.
4. Replace the ODU.
If the fault is cleared after the replacement, the original ODU is faulty.

Experience and Summary

l During the hop commissioning, you must well adjust the antenna direction. Hence, the
dormant problems for future maintenance can be avoided.
l You should periodically collect, analyze the change of the transmit power and receive
power, and eliminate the dormant problems in a timely manner.
3.4 CES Service Troubleshooting

This section describes how to troubleshoot interruption or bit errors of the CES service in terms
Symptoms
The symptoms of a CES service fault may be as follows. See Table 3-5. Clear up all the reported
alarms and the fault is rectified.
Table 3-5 List of common symptoms of CES service faults
Symptom Alarm Reported Board
The CES service is HARD_BAD, CXPR, ML1 or ML1A

interrupted. TEMP_OVER, or
BUS_ERR
COMMUN_FAIL CXPR
T_ALOS ML1 or ML1A
UP_E1_AIS or ML1 or ML1A

DOWN_E1_AIS
MPLS_TUNNEL_LOCV CXPR
PW_DOWN
The CES service has bit HARD_BAD, CXPR, ML1 or ML1A

errors and the TEMP_OVER, or
communication is degraded. BUS_ERR
SYNC_C_LOS or LTI CXPR
CES_LOSPKT_EXC, ML1 or ML1A

CES_MISORDERPKT_EX
C, CES_MALPKT_EXC,
CES_STRAYPKT_EXC,
CES_JTRUDR_EXC, or
CES_JTROVR_EXC

Troubleshooting Flowchart
Figure 3-4 shows the flowchart for troubleshooting CES service faults.
Figure 3-4 Flowchart for troubleshooting CES service faults

Start
Whether Board is faulty or inter-

HARD_BAD, TEMP_OVER,
Yes Reset/re-insert/replace
board communication
BUS_ERR, or COMMUN_FAIL board
alarm exists? fails
No
Whether
T_ALOS, UP_E1AIS, Yes Loop to locate the No Modify/replace the
Signals are lost
or DN_E1AIS alarm faulty physical path faulty physical path
exists?
No
Whether
MPLS_TUNNEL_LOCV Yes Tunnel or PW which Rectify fault of No Rectify fault of
or PW_DOWN alarm carries service is faulty physical link opposite equipment
exists?
No
Whether Yes No Reset/re-insert/replace

Synchronous
SYNC_C_LOS or LTI Rectify clock fault
clock is lost cross-connect board
alarm exists?
No
Whether
Yes Lost packets, Check cable and No
CES_LOSPKT_EXC, Modify network
CES_JTRUDR_EXC
errored packets, or jitter connections, and
crosses threshold configuration
alarm exists? handle problems
No Whether fault
is rectified?
Yes
Contact Huawei technical

End
support engineers
Impact on the System

The CES service in the network has bit errors or is interrupted. As a result, the communication
is degraded or interrupted. If the CES service fault is caused by the CXPR board, other services
accessed by the equipment may also be affected.
Possible Causes
As shown in the troubleshooting flowchart, a CES service fault may be due to the following
causes:
l Cause 1: The board has a hardware fault or excessively high temperature, or the inter-board
communication fails. As a result, the board does not work normally.
l Cause 2: The signals are lost or degraded.
l Cause 3: The tunnel or PW that carries the CES service is interrupted.

l Cause 4: The priority of the synchronous clock source or the synchronous clock source
itself is lost.
l Cause 5: The number of lost packets or erorred packets, or the jitter buffer of the CES
service over the PW crosses the threshold.

T2000, optical power meter, and SDH analyzer or BER tester
Precautions
DANGER
Avoid direct eye exposure to laser beams launched from optical interfaces or fiber connectors.
Otherwise, the laser beams launched from the optical interfaces or fiber connectors may damage
the eyes.
Procedure
1. Query the current alarms of the system to check for the HARD_BAD, TEMP_OVER,
COMMUN_FAIL, or BUS_ERR alarm and determine which board reports the alarm.
For details, refer to 8.2 Querying Current Alarms of a Board.
2. Handle the HARD_BAD, TEMP_OVER, COMMUN_FAIL, or BUS_ERR alarm.
l Cause 2: The signals are lost or degraded.
1. Check for the T_ALOS, UP_E1_AIS, or DOWN_E1_AIS alarm of the system and
handle the T_ALOS, UP_E1_AIS, or DOWN_E1_AIS alarm.
2. Check for the LASER_MOD_ERR, LSR_WILL_DIE, IN_PWR_ABN, TEM_HA,
or LSR_BCM_ALM alarm of the system and handle the LASER_MOD_ERR,
LSR_WILL_DIE, IN_PWR_ABN, TEM_HA, or LSR_BCM_ALM alarm.
l Cause 3: The tunnel or PW that carries the CES service is interrupted.
1. Check for the MPLS_TUNNEL_LOCV alarm of the system and handle the
MPLS_TUNNEL_LOCV alarm.
2. Check for the PW_DOWN alarm of the system and handle the PW_DOWN alarm.
l Cause 4: The priority of the synchronous clock source or the synchronous clock source
itself is lost.
1. Check whether the SYNC_C_LOS or LTI alarm exits.
2. If yes, handle the SYNC_C_LOS or LTI alarm.
l Cause 5: The number of lost packets or erorred packets, or the jitter buffer of the CES
service over the PW crosses the threshold.
1. Check whether the CES_LOSPKT_EXC or CES_MISORDERPKT_EXC alarm
exits. If yes, handle the CES_LOSPKT_EXC or CES_MISORDERPKT_EXC
alarm.

2. Check whether the CES_STRAYPKT_EXC or CES_MALPKT_EXC alarm exits. If

yes, handle the CES_STRAYPKT_EXC or CES_MALPKT_EXC alarm.
3. Check whether the CES_JTRUDR_EXC or CES_JTROVR_EXC alarm exits. If yes,
handle the CES_JTRUDR_EXC or CES_JTROVR_EXC alarm.
----End
3.5 Ethernet Service Troubleshooting

This section describes how to troubleshoot Ethernet service interruption or packet loss in terms
Symptoms
The symptoms of Ethernet service faults may be as follows. See Table 3-6. Clear up all the
reported alarms and the fault is rectified.
Table 3-6 List of common symptoms of Ethernet service faults

The Ethernet service is HARD_BAD, CXPR, AUXQ, EF8T, EF8F

interrupted. TEMP_OVER, or or EG2
BUS_ERR
COMMUN_FAIL CXPR
ETH_LOS, AUXQ, EF8T, EF8F or EG2

ETH_LINK_DOWN,
ETH_AUTO_LINK_DOW
N, LOOP_ALM, or
MAC_FCS_EXC
LASER_SHUT or EF8F or EG2

LSR_WILL_DIE
The Ethernet service loses HARD_BAD, CXPR, AUXQ, EF8T, EF8F

packets or has erorred TEMP_OVER, or or EG2
packets. BUS_ERR
LSR_WILL_DIE EF8F or EG2
MAC_FCS_EXC or AUXQ, EF8T, EF8F or EG2

FLOW_OVER
Figure 3-5 shows the flowchart for troubleshooting Ethernet service faults.

Figure 3-5 Flowchart for troubleshooting Ethernet service faults

Start
Whether
HARD_BAD, TEMP_OVER,
Yes Board is faulty or inter- Reset/re-insert/replace
BUS_ERR, or COMMUN_FAIL board communication fails board
alarm exists?
No
Whether
Check fiber, optical
ETH_LOS or Yes Signals are
module, and network cable,
MAC_FCS_EXC alarm lost or degraded
and handle problems
exists?
No
Whether Yes Modify port configuration, No

Reset/re-insert/
ETH_LINK_DOWN alarm Port negotiation fails including port attributes
and working mode replace board
exists?
No
Whether Yes Modify port loopback

LOOP_ALM alarm Port loopback is set
configuration
exists?
No
Whether Yes
Service configuration Modify service
FLOW_OVER alarm
is incorrect configuration
exists?
No Whether fault
is rectified?
Yes

End
support engineers

The Ethernet service in the network is interrupted, loses packets, or has erorred packets. If the
fault is caused by the CXPR board, other services accessed by the equipment may also be
affected.
Possible Causes
As shown in the troubleshooting flowchart, an Ethernet service fault may be due to the following
causes:
l Cause 2: The signals on the receive side of the Ethernet interface are lost.
l Cause 3: The Ethernet port is misconnected and the port negotiation fails.
l Cause 4: Loopback is configured for the port.
l Cause 5: The configured traffic limit is excessively low at the port and configurations of
the source and sink ports are inconsistent.


T2000, optical power meter
Precautions
DANGER
Avoid direct eye exposure to laser beams launched from optical interfaces or fiber connectors.
Otherwise, the laser beams launched from the optical interfaces or fiber connectors may damage
the eyes.
Procedure
1. Query the current alarms of the system to check for the HARD_BAD, TEMP_OVER,
COMMUN_FAIL, or BUS_ERR alarm and the board that reports the alarm. For
details, refer to 8.2 Querying Current Alarms of a Board.
2. Clear the HARD_BAD, TEMP_OVER, COMMUN_FAIL, or BUS_ERR alarm.
l Cause 2: The signals on the receive side of the Ethernet interface are lost.
1. Check for the ETH_LOS or ETH_AUTO_LINK_DOWN alarm of the system and
clear the ETH_LOS or ETH_AUTO_LINK_DOWN alarm.
2. Check for the LASER_SHUT or LSR_WILL_DIE alarm of the system and clear the
LASER_SHUT or LSR_WILL_DIE alarm.
3. Check for the IN_PWR_ABN or OUT_PWR_ABN alarm of the system and clear the
IN_PWR_ABN or OUT_PWR_ABN alarm.
4. Check for the MAC_FCS_EXC alarm of the system and clear the
MAC_FCS_EXC alarm.
l Cause 3: The Ethernet port is misconnected and the port negotiation fails.
1. Check for the ETH_LINK_DOWN alarm of the system and clear the
ETH_LINK_DOWN alarm.
l Cause 4: Loopback is configured for the port.
1. Check for the LOOP_ALM alarm of the system and clear the LOOP_ALM alarm.
l Cause 5: The configured traffic limit is excessively low at the port and configurations of
the source and sink ports are inconsistent.
1. Check for the FLOW_OVER alarm of the system and clear the FLOW_OVER alarm.
l If any problems occur during the troubleshooting, contact Huawei engineers. For the
contact information, see 3.15 Fault Notification and Technical Support.
----End
3.6 Clock Troubleshooting

This section describes how to troubleshoot loss of the clock source and degrade of clock signals

troubleshooting.
Symptoms
The symptoms of clock faults may be as follows. See Table 3-7. Clear up all the reported alarms
and the fault is rectified.
Table 3-7 List of common symptoms of clock faults

The service has bit errors. SYNC_C_LOS, LTI, CXPR, AUXQ, EF8F, EF8T,
S1_SYN_CHANGE, EG2, ML1, or ML1A
SYN_BAD,
EXT_SYNC_LOS, or
CLK_NO_TRACE_MODE
EXT_TIME_LOC CXPR

Loss or quality degrade of a clock source in the network affects the service that traces this clock
source, causes pointer justification, and increases the BER.
Possible Causes
A clock fault may be due to the following causes:
l Cause 1: The priority of the synchronous clock source on the service board is absent from
the priority table.
l Cause 2: The synchronous clock source is lost and the clock of the NE works abnormally.
l Cause 3: The clock source is switched in the SSM mode and thus the clock source traced
by the NE is also switched.
l Cause 4: The signals of the synchronous clock source are degraded.
l Cause 5: The external clock source is lost.
l Cause 6: The clock does not work in the tracing mode.
l Cause 7: The external time source is lost.

T2000, frequency meter, ANT20

Precautions
WARNING
If no active and standby CXPR board that are working normally can be used for protection,
cold-reset of CXPR board may completely interrupt the services.
Procedure
l Cause 1: The priority of the synchronous clock source on the service board is absent from
the priority table.
1. Check for the SYNC_C_LOS alarm of the system. For details, refer to 8.2 Querying
Current Alarms of a Board.
2. If the SYNC_C_LOS alarm occurs, clear the SYNC_C_LOS alarm.
l Cause 2: The synchronous clock source is lost and the clock of the NE works abnormally.
1. Check for the LTI alarm of the system and clear the LTI alarm.
l Cause 3: The clock source is switched in the SSM mode and thus the clock source traced
by the NE is also switched.
1. Check for the S1_SYN_CHANGE alarm of the system and clear the
S1_SYN_CHANGE alarm.
l Cause 4: The signals of the synchronous clock source are degraded.
1. Check for the SYN_BAD alarm of the system and clear the SYN_BAD alarm.
l Cause 5: The external clock source is lost.
1. Check for the EXT_SYNC_LOS alarm of the system and clear the
EXT_SYNC_LOS alarm.
l Cause 6: The clock does not work in the tracing mode.
1. Check for the CLK_NO_TRACE_MODE alarm of the system and clear the
CLK_NO_TRACE_MODE alarm.
l Cause 7: The external time source is lost.
1. Check for the EXT_TIME_LOC alarm of the system and clear the
EXT_TIME_LOC alarm.
----End
3.7 QoS Troubleshooting

This section describes the QoS faults in terms of the symptoms, impact on the system, possible
Prerequisite
The connection of services configured with the QoS policy must be normal.

Symptoms
The symptoms of the QoS faults may be as follows:
l The service is configured with bandwidth, but the actual traffic exceeds the limit. Hence,
the traffic is large, and a congestion occurs.
l Different services preempt bandwidth of each other. The packets of the service are lost or
bit errors occur in the service whose bandwidth is preempted.
l A service of a lower priority preempts the bandwidth of a service of a higher priority. In
this case, the packets of the service are lost or bit errors occur in the service of a higher
priority.
Generally, in the case of the QoS faults, the system reports the alarms listed in Table 3-8. If the
alarms reported by the equipment are cleared, the faults are rectified.
Table 3-8 List of common symptoms of the QoS faults

The traffic is large, and a FLOW_OVER AUXQ, EF8T, EF8F, or EG2

congestion occurs.
The service bandwidth is CES_LOSPKT_EXC ML1, or ML1A

preempted, and the packets
of the service are lost or bit CES_JTROVR_EXC
errors occur. CES_JTRUDR_EXC
Figure 3-6 shows the flowchart for troubleshooting the QoS faults.

Figure 3-6 Flowchart for troubleshooting the QoS faults
Start
Check The traffic crosses

Yes Check No
whether the alarms the threshold or the Reconfigure the port
whether the Qos policy
listed in the preceding service bandwidth is policy or PW policy
is configured
table exist insufficient
Yes
Check
No
whether the Qos policy Reconfigure the
for the service is service parameters
correct
Yes
Check
Yes Increase the
whether the bandwidth
configured bandwidth
of the tunnel or PW can
for the tunnel or PW
be increased
No
Check
Yes
whether the hardware Clear the hardware
alarms exist on the alarms
board
No Whether fault
is rectified?
Yes
Contact Huawei
End
technical engineers

If the service processing capability of the board is restricted, part of the services may not be
processed, and the packets of the service are lost or bit errors occur.
Possible Causes
As shown in the troubleshooting flowchart, the QoS faults may be due to the following causes:
l Cause 1: The NE is not configured with the QoS policy.

l Cause 2: During the service configuration, an incorrect QoS policy is selected.
l Cause 3: The bandwidth configured in the tunnel or PW is small.
l Cause 4: The board is faulty, and the configuration data is not delivered to the board.

T2000 and BER tester

Procedure
l Cause 1: The NE is not configured with the QoS policy.
1. Check whether the NE is configured with the related QoS policy such as the WRED
policy, WFQ scheduling policy, port policy, CAR policy, V-UNI Ingress policy, or
ATM policy.
2. If the NE is not configured with the related QoS policy, configure the missing QoS
policy. For details, see QoS-Related Operation Tasks in the Feature Description
manual.
l Cause 2: During the service configuration, an incorrect QoS policy is selected.
1. Check whether the QoS policy that is currently configured is applicable. If it is not
applicable, configure a new policy. For details, see the Configuration Guide manual.
l Cause 3: The bandwidth configured in the tunnel or PW is small.
1. Check whether the bandwidth that is currently configured in the tunnel or PW meets
the requirement for the traffic. If the configured bandwidth is excessively small,
reconfigure the bandwidth. For details, see the Configuration Guide manual.
l Cause 4: The board is faulty, and the configuration data is not delivered to the board.
1. Check whether a hardware alarm such as HARD_BAD exists in the system. If the
alarm exists, clear the HARD_BAD alarm.
2. Check whether the laser alarm such as LSR_WILL_DIE exists in the system. If the
alarm exists, clear the LSR_WILL_DIE alarm.
----End
3.8 Inband DCN Troubleshooting

This section describes the inband DCN faults in terms of the symptoms, impact on the system,
Prerequisite
You must ensure that each board on the NE is of the mapping version by checking the engineering
document.
Symptoms
The symptoms of the inband DCN faults may be as follows:
l The communication between the T2000 and the NE is interrupted. The NE icon on the
T2000 is grey, and the NE is unreachable to the T2000.
l The operations on the T2000 are not responded. If the response interruption time lasts for
more than two minutes, the communication between the T2000 and the NE is interrupted.
l When you query certain information on the T2000, the query result contains incomplete
information.

Figure 3-7 shows the flowchart for troubleshooting the inband DCN faults.
Figure 3-7 Flowchart for troubleshooting the inband DCN faults

Start
Whether
Whether Yes The communication Yes Reconnect the
the physical
the NE icon turns between the T2000 and network cable or
connection is
grey the NE is interrupted optical fiber
interrupted
No
Whether Yes Enable

the DCN port is
the DCN port
disabled
No
No Handle the alarms

Whether Yes related to the optical
the receive signals
power, fibers, and
are lost
cables
No
Whether Yes
the board is Replace the board
faulty
Whether
Yes The bandwidth Increase the bandwidth
the T2000 query
configured for the DCN configured for the inband
information is
tunnel is too small DCN tunnel
lost
No
Whether
Yes Wait until the reset
the T2000 operation The system control
of the system control
command is not board is restting
board is complete
responded
No
Whether fault
is rectified
Yes
End
engineers

l When the NE fails to communicate with the T2000, other NEs that communicate with the
T2000 through this NE become unreachable to the T2000, if they cannot be connected to
the T2000 in other manners. The other NEs are not affected.
l If the physical channel that carries the inband DCN is faulty, the other services carried in
this physical channel are affected.
Possible Causes
As shown in the troubleshooting flowchart, the inband DCN faults may be due to the following
causes:

l Cause 1: The physical connection between the faulty NE and the T2000 is interrupted.
l Cause 2: The inband DCN port of the faulty NE is not enabled.
l Cause 3: The received signals of the faulty NE are lost, or the received optical power is
excessively low, and thus the DCN packets cannot be extracted.
l Cause 4: The board is faulty.
l Cause 5: The bandwidth configured for the inband DCN channel is excessively small.
l Cause 6: The board on the faulty NE is being reset or the active/standby switching of boards
is performed, and thus the inband DCN packets cannot be responded.

T2000
Precautions
CAUTION
Before locating the faults, you should check whether each board on the NE is of the mapping
version. If a board is not of the mapping version, replace the board in time.
NOTE
When handling the inband DCN faults, perform the following operations:
l If the NE communication is interrupted, you should handle the faults of the gateway NE, and then
handle the faults of the non-gateway NEs.
l If the NE communication is not interrupted, handle the faults of the non-gateway NEs first, and then
handle the faults of the gateway NE. Hence, the non-gateway NEs are prevented from being unreachable
to the T2000.
Procedure
l Cause 1: The physical connection between the faulty NE and the T2000 is interrupted.
1. Check whether the network cables or fibers of the faulty NE are disconnected from
the ports. If the network cables or fibers are disconnected from the ports, insert the
network cables or fibers again.
l Cause 2: The inband DCN port of the faulty NE is not enabled.
1. Check whether the ports, which support the DCN function by default, are connected
with the fibers or cables. If not, change the present port to a port whose DCN function
is enabled by default. Availability provides the information about the ports of OptiX
RTN 950 whose DCN function is enabled by default.
2. Check whether the ports at the two ends of the link are enabled. If not, enable the
inband DCN port. For details, see Enabling the Port DCN in the Feature
Description manual.
l Cause 3: The received signals of the faulty NE are lost, or the received optical power is
excessively low, and thus the DCN packets cannot be extracted.

1. Check whether the ETH_LOS, or IN_PWR_ABN alarm exists on the board

configured with the inband DCN channel. For details, see 8.2 Querying Current
Alarms of a Board. Clear these alarms.
1. Check whether the HARD_BAD alarm exists on the board configured with the inband
DCN channel.
2. If the alarm exists, replace the board that reports the alarm. For details, see 5 Replacing
Components.
l Cause 5: The bandwidth configured for the inband DCN channel is excessively small.
1. When the number of services configured on the port exceeds a certain number, part
of the query information may be lost. In this case, you should properly increase the
bandwidth configured for the inband DCN channel. For details, see Setting the VLAN
ID and Bandwidth Used by an Inband DCN in the Feature Description manual.
l Cause 6: The board on the faulty NE is being reset or the active/standby switching is
performed, the inband DCN packets cannot be responded.
1. Observe whether the PROG indicator on the system control board is blinking in green.
If the indicator is blinking in green, it indicates that the system control board is in the
reset state. After the PROG indicator is always on in green, the reset of the system
control board is complete and the DCN connection is automatically recovered.
NOTE
If the active/standby switching occurs on the system control board, a warm reset is performed
on Active Board.
2. If the DCN response does not recover, check whether the protection switching occurs
on other boards. If other boards are switched, the inband DCN packets are in the
rerouting state. For details, see 8.23 Querying Protection Configuration.
3. If the protection switching occurs on the boards, after the DCN rerouting is complete,
the response is automatically recovered.
----End
3.9 LAG Troubleshooting

This section describes the LAG faults in terms of the symptoms, impact on the system, possible
Symptoms
The symptoms of the LAG faults may be as follows. See Table 3-9. If the alarms reported by
the equipment are cleared, the faults are rectified.

Table 3-9 List of common symptoms of the LAG faults

The LAG is invalid, all the LAG_DOWN CXPR

member ports cannot be used,
and the services are
interrupted.
The member ports in the LAG_MEMBER_DOWN CXPR

LAG cannot be used, and the
packet of the service are lost. LOOP_ALM AUXQ, EF8T, EF8F, or EG2
ETH_LOS
ETH_LINK_DOWN
Figure 3-8 shows the flowchart for troubleshooting the LAG faults.

Figure 3-8 Troubleshooting Flowchart

Start
Whether Yes Whether Yes

The link aggregation
the service is the LAG_DOWN
group is invalid
interrupted alarm exists
No
Whether Yes Whether the Yes The link aggregation

the packet loss occurs LAG_MEMBER_DOWN group member port
in the service alarm exists is invalid
Whether
Yes Modify the LAG
LAG configurations
configurations at the
at the two ends are
two ends of the NE
incorrect
No
Whether
Yes Modify the working
the working mode
mode of the port to
of the port is
full-duplex
half-duplex
No
Whether the Yes Release the port

Loopback-related
loopback status
alarm exists
No
Whether Rectify the port

the ETH_LOS or Yes connection fault,
ETH_LINK_DOWN and clear the
alarm exists related alarms
No
Whether fault
is rectified
Yes
End
engineers

l If the LAG is invalid, the service carried by the LAG is interrupted, but the services carried
by other channels are not affected.
l If the members in the LAG are invalid, in the load sharing mode, consistent packet loss
may occur because of insufficient bandwidth. If the LAG is in the non-load sharing mode,
the switching occurs in the link and the packets of the service are lost for a short time.
Possible Causes
As shown in the troubleshooting flowchart, the LAG faults may be due to the following causes:
l Cause 1: The NEs at the two ends of the LAG are incorrectly configured.
l Cause 2: The working mode of the member ports in the LAG is set to half-duplex.

l Cause 3: The loopback is configured on the member ports in the LAG.

l Cause 4: The connection of the member ports in the LAG are improperly connected or
disconnected.

T2000
Procedure
l Cause 1: The NEs at the two ends of the LAG are incorrectly configured.
1. 8.2 Querying Current Alarms of a Board, and check whether the LAG_DOWN or
LAG_MEMBER_DOWN alarm exists.
2. Check whether the configurations of the NEs at the two ends of the LAG are consistent.
If the configurations are inconsistent, modify the configuration as the same, and then
check whether the alarm is cleared. For details, see Creating an LAG in the Feature
Description manual.
l Cause 2: The working mode of the member ports in the LAG is set to half-duplex.
1. Check whether the working mode of each member port in the LAG is set to half-
duplex. If the working mode is set to half-duplex, modify the working mode of the
port to full-duplex. For details, see 8.22 Querying and Setting the Working Mode
of Ethernet Interface.
l Cause 3: The loopback is configured on the member ports in the LAG.
1. Check whether the LOOP_ALM alarm exists on each member port in the LAG group.
If yes, reconfigure the loopback status of the port to clear the LOOP_ALM alarm.
For details, see 8.9 Configuring Port Loopback.
l Cause 4: The connection of the member ports in the LAG are improperly connected or
disconnected.
1. Check whether the ETH_LOS or ETH_LINK_DOWN alarm exists on each member
port in the LAG.
2. If the alarm exists, clear the ETH_LOS or ETH_LINK_DOWN alarm.
----End
3.10 ML-PPP Troubleshooting

This section describes the ML-PPP faults such as service interruption, packet loss, or bit error
troubleshooting.
Symptoms
The symptoms of the ML-PPP faults may be as follows. See Table 3-10. If the alarms reported
by the equipment are cleared, the faults are rectified.

Table 3-10 List of common symptoms of the ML-PPP faults

The MP group is invalid, and MP_DOWN ML1, or ML1A

the service is interrupted.
The MP group member is PPP_LCP_FAIL or ML1, or ML1A

invalid, and the packets of the PPP_NCP_FAIL
service are lost.
T_ALOS
The MP group member is MP_DELAY ML1, or ML1A

delayed, and the packets of
the service are lost.
Figure 3-9 shows the flowchart for troubleshooting the ML-PPP faults.
Figure 3-9 Flowchart for troubleshooting the ML-PPP faults

Start
Modify the
Whether Yes Whether Yes No
The MP group is configuration of the Replace the cable
the service is the MP_DOWN alarm
invalid MP group, or restart or board
interrupted exists
the ML-PPP protocol
No
Whether The configurations at Modify the

Yes
the PPP_LCP_FAIL the two ends of the configuration of the
or PPP_NCP_FAIL MP group member MP group member
alarm exists are inconsistent port
No
No
Whether Yes No
The signals at the Check and then
the T_ALOS alarm Replace the board
interface are lost rectify the cable fault
exists
No
Whether The delay of the MP Increase the

Yes Whether Yes
the packet loss group member maximum reserved No Replace the cable
the MP_DELAY alarm
occurs in the exceeds the bandwidth for the MP or board
exists
service threshold group
No Whether fault
is rectified
Yes

End
engineers

l If the MP group is invalid, the carried service is interrupted, but the services carried by
other channels are not affected.

l If the MP group member is invalid, the bandwidth of this MP group is decreased, and thus
the packets of the service may lost.
Possible Causes
As shown in the troubleshooting flowchart, the ML-PPP fault may be due to the following causes:
l Cause 1: The MP group is invalid.
l Cause 2: The negotiation of the protocols at the two ends of the MP group member fails.
l Cause 3: The received signals of the MP group member port are lost.
l Cause 4: The MP group member delay exceeds the threshold.

T2000
Procedure
l Cause 1: The MP group is invalid.
1. 8.2 Querying Current Alarms of a Board, and check whether the MP_DOWN alarm
exists.
2. If yes, clear the MP_DOWN alarm.
l Cause 2: The negotiation of the protocols at the two ends of the MP group member fails.
1. Check whether the PPP_LCP_FAIL or PPP_NCP_FAIL alarm exists in any member
of the MP group.
2. If yes, modify the configurations at the two ends of the MP group member to clear the
PPP_LCP_FAIL or PPP_NCP_FAIL alarm.
l Cause 3: The received signals of the MP group member port are lost.
1. Check whether the T_ALOS alarm exists in any member of the MP group.
2. If yes, clear the T_ALOS alarm.
l Cause 4: The MP group member delay exceeds the threshold.
1. Check whether the MP_DELAY alarm exists in the MP group.
2. If yes, clear the MP_DELAY alarm.
----End
3.11 IMA Troubleshooting

This section describes the IMA faults in terms of the symptoms, impact on the system, possible
Symptoms
Table 3-11 lists the symptoms of the IMA faults. If the alarms reported by the equipment are
cleared, the faults are rectified.

Table 3-11 List of common symptoms of the IMA faults

The IMA group is invalid, IMA_GROUP_LE_DOWN ML1, or ML1A

and the service is interrupted.
IMA_GROUP_RE_DOWN
One IMA group member link ALM_IMA_LIF ML1, or ML1A

is invalid, and the service on
the faulty link is shared by ALM_IMA_RFI
other member links. The ALM_IMA_LODS
IMA port is congested, and
the packets of the service are ALM_IMA_RE_RX_UNUS
lost. ABLE
ALM_IMA_RE_TX_UNUS
ABLE
Figure 3-10 shows the flowchart for troubleshooting the IMA faults.

Figure 3-10 Flowchart for troubleshooting the IMA faults

Start
Whether
Whether
IMA_GROUP_LE_ Yes Yes Enable the IMA
The IMA group is the IMA protocols at
DOWN or IMA_GROUP_RE protocol at the two
invalid the two ends are
_DOWN alarm ends
disabled
exists
No
No
whether Modify the

Whether
ALM_IMA_LIF, ALM Yes The IMA group Yes configurations at the
the negotiation of the
_IMA_LODS, or ALM_IMA_ member link is two ends to the same,
two ends of the IMA
RE_RX_UNUSABLE invalid and enable the IMA
group fails
alarm exists protocol again
No
Whether the
Yes Modify the
interface attribute is
configuration of the
incorrectly
interface attribute
configured
No
Whether Yes
the hardware Clear the hardware
alarm exists on the alarm
board
No
Whether
Yes
the service alarm Clear the service
exists in the alarm on the IMA link
IMA link
No Whether fault
is rectified
Yes

End
engineers

l If the IMA group is invalid, the carried service is interrupted, but the services carried by
other channels are not affected.
l If an IMA member link is invalid, the service is shared by the other member links. When
the number of valid links of an IMA group is smaller than the minimum number of activated
links configured for the IMA group, the IMA group is invalid.
Possible Causes
As shown in the troubleshooting flowchart, the IMA faults may be due to the following causes:
l Cause 1: The protocols at the two ends of the IMA group are not enabled.
l Cause 2: The negotiation of the two ends of the IMA group fail.
l Cause 3: The interface attribute of the IMA member link is incorrectly configured.

l Cause 4: Hardware faults exist on the board, and the IMA group members are invalid.
l Cause 5: Other service alarms exist in the IMA link.

T2000
Procedure
l Cause 1: The protocols at the two ends of the IMA group are not enabled.
1. 8.2 Querying Current Alarms of a Board, and check whether the
IMA_GROUP_LE_DOWN or IMA_GROUP_RE_DOWN alarm exists.
2. Enable the protocol status at the two ends of the IMA group again. For details, see
Configuring Attributes of an ATM IMA Group in the Feature Description manual.
3. Check whether the ALM_IMA_LIF, ALM_IMA_RFI,
ALM_IMA_RE_RX_UNUSABLE, ALM_IMA_RE_TX_UNUSABLE, or
ALM_IMA_LODS alarm exists in the IMA group member link. If the alarm exists,
the IMA member links are invalid. In this case, clear the ALM_IMA_LIF,
ALM_IMA_RFI, ALM_IMA_RE_RX_UNUSABLE,
ALM_IMA_RE_TX_UNUSABLE, or ALM_IMA_LODS alarm.
l Cause 2: The negotiation of the two ends of the IMA group fail.
1. Check whether the configurations at the two ends of the IMA group are consistent. If
the configurations are inconsistent, reconfigure the parameters for the IMA group, and
enable the IMA protocol. For details, see Configuring Attributes of an ATM IMA
Group in the Feature Description manual.
l Cause 3: The interface attribute of the IMA member link is incorrectly configured.
1. Check whether the interface attribute of the IMA group is correctly configured. If the
interface attribute of the IMA group is incorrectly configured, reconfigure the attribute
of each interface, and enable the IMA protocol again. For details, see Configuring
ATM Interface Attributes in the Feature Description manual.
l Cause 4: Hardware faults exist on the board, and the IMA group members are invalid.
1. Check whether a hardware alarm such as HARD_BAD, COMMUN_FAIL, or
TEMP_OVER exists in the system. If the alarm exists, clear the HARD_BAD,
COMMUN_FAIL, or TEMP_OVER alarm.
2. Check whether the laser alarm such as IN_PWR_ABN, LSR_BCM_ALM, or
TEM_HA exists in the system. If the alarm exists, clear the IN_PWR_ABN,
LSR_BCM_ALM, or TEM_HA alarm.
l Cause 5: Other service alarms exist in the IMA link.
1. Check whether the T_ALOS alarm exists in the system. If the alarm exists, clear the
T_ALOS alarm.
----End

3.12 FRR Troubleshooting

This section describes the FRR faults in terms of the symptoms, impact on the system, possible
Symptoms
The symptoms of the FRR faults may be as follows:
l The FRR switching fails, and the service is interrupted.
l The FRR switching time or overall restoration time exceeds 50 ms, jitter occurs in the
service.
l After the FRR switching is performed, the bandwidth configured for the bypass tunnel is
smaller than the bandwidth configured for the protected tunnel. Hence, part of the packets
of the service are lost or bit errors occur.
Figure 3-11 shows the flowchart for troubleshooting the FRR faults.

Figure 3-11 Flowchart for troubleshooting the FRR faults
Start
Whether Yes Whether Yes

The FRR switching Adjust the service to
the service is other normal usable
fails the normal tunnel
interrupted tunnels exist
No
Whether the Yes Configure the FRR

protected tunnel is not
protection for the
configured with FRR
protected tunnel
protection
No
Whether Yes Modify the

the bypass tunnel configuration
is incorrectly parameters for the
configured bypass tunnel
No
No
Whether
Yes
the hardware Rectify the board
fault exists on the fault
board
No
Whether
Yes Rectify the
the inter-board
inter-board
communication
communication fault
is faulty
Whether Yes The FRR switching time

Increase the configured
the jitter or bit error exceeds the threshold or
FRR bandwidth or create a
occurs in the the bandwidth for the
new Bypass Tunnel
service bypass tunnel is small
No Whether fault
is rectified
Yes
End
engineers

When the FRR switching is invalid, the service cannot be protected. In this case, if the protected
tunnel is faulty, the service is interrupted.
Possible Causes
As shown in the troubleshooting flowchart, the FRR faults may be due to the following causes:
l Cause 1: The protected tunnel is not configured with the FRR protection.
l Cause 2: The FRR switching cannot be performed, because the bypass tunnel is incorrectly
configured.

l Cause 3: The board is faulty, and thus the FRR switching command cannot be delivered,
or errors occur when the FRR switching command is responded.
l Cause 4: The inter-board communication is faulty, and thus the board cannot receive the
switching command issued by the system control board.
l Cause 5: In the FRR protection group, the bandwidth configured in the tunnel is small, and
thus the transmission time of the FRR command times out or part of the packets are
discarded when the link is congested.

T2000
Precautions
When the service is interrupted in the case of the FRR failure, you should switch the service to
a normal tunnel. After making sure that the service is restored, you can locate and then rectify
the faults.
Procedure
l Cause 1: The protected tunnel is not configured with the FRR protection.
1. Check whether the protected tunnel is configured with the FRR protection. If the
protected tunnel is not configured with the FRR protection, you should reconfigure
the FRR protection. For details, see Creating the FRR Protection for MPLS Tunnels
in the Configuration Guide manual.
l Cause 2: The FRR switching cannot be performed, because the bypass tunnel is incorrectly
configured.
1. Check whether the configured parameters for the bypass tunnel are correct. If the
parameters are incorrect, you should reconfigure the parameters for the bypass tunnel.
For details, see Creating the FRR Protection for MPLS Tunnels in the Configuration
Guide manual.
l Cause 3: The board is faulty, and thus the FRR switching command cannot be delivered,
or errors occur when the FRR switching command is responded.
1. Check whether a hardware alarm such as HARD_BAD exists on the board. If the
alarm exists, clear the HARD_BAD alarm, and then check whether the service is
restored.
l Cause 4: The inter-board communication is faulty, and thus the board cannot receive the
switching command issued by the system control board.
1. Check whether the COMMUN_FAIL alarm exists on the board. If the alarm exists,
you should clear the COMMUN_FAIL alarm, and then check whether the service is
restored.
l Cause 5: In the FRR protection group, the bandwidth configured in the tunnel is smaller,
and thus the transmission time of the FRR command times out or part of the packets are
discarded when the link is congested.
1. Properly increase the configured FRR bandwidth or create a new Bypass Tunnel. For
details, see Creating the FRR Protection for MPLS Tunnels in the Configuration
Guide manual.

----End
3.13 MPLS APS Troubleshooting

This section describes the MPLS APS faults in terms of the symptoms, impact on the system,
Symptoms
Table 3-12 lists the symptoms of the MPLS APS faults. If the alarms reported by the equipment
are cleared, the faults are rectified.
Table 3-12 List of common symptoms of the MPLS APS faults

The APS protection group is ETH_APS_PATH_MISMA CXPR

incorrectly configured, or the TCH
APS frame cannot be
received. In this case, the ETH_APS_LOST
protection fails. ETH_APS_SWITCH_FAIL
ETH_APS_TYPE_MISMA
TCH
When the working tunnel or MPLS_TUNNEL_LOCV

bypass tunnel is faulty, the
switching fails. MPLS_TUNNEL_MISMER
GE
MPLS_TUNNEL_MISMA
TCH
MPLS_TUNNEL_Excess
MPLS_TUNNEL_SD
MPLS_TUNNEL_SF
MPLS_TUNNEL_UNKNO
WN
Figure 3-12 shows the flowchart for troubleshooting the MPLS APS faults.

Figure 3-12 Flowchart for troubleshooting the MPLS APS faults

Start
Modify the
Whether The working and Whether the
Yes Yes configurations, and
ETH_APS_PATH_ protection trails of configurations of the two
make sure that the
MISMATCH alarm the APS are ends on the T2000 are
working and protection
exists inconsistent inconsistent
trails are consistent
No
Whether
the fibers or cables Yes Reconnect the fibers
No
are incorrectly or cables
connected
Modify the
Whether the
Whether Yes The APS frame of No configurations, and
configurations of the two
ETH_APS_LOST the bypass tunnel is make sure that the
ends on the T2000 are
alarm exists lost working and protection
consistent
trails are consistent
Yes
Whether Activate the protocol

No
the protocol status of status at the two
the protection group is ends of the
activated protection group
Yes
Whether
Yes
the hardware alarm Rectify the board
such as HARD_BAD hardware fault
exists
No
Whether Yes Rectify the

the clock alarm such as
clock fault
TR_LOC exists
No
Whether
Yes
the tunnel-level alarm Rectify the fault of
exists in the bypass the bypass tunnel
tunnel
No
Whether fault
is rectified
Yes
Contact Huawei engineers End

When the APS protection group is invalid, the service cannot be protected. If the protected tunnel
is faulty, the service is interrupted.
Possible Causes
As shown in the troubleshooting flowchart, the MPLS APS faults may be due to the following
causes:
l Cause 1: The configurations at the two ends of the APS protection group are inconsistent.
l Cause 2: The protocols at the two ends of the APS protection group are in the inactive state.
l Cause 3: The optical fibers or cables are incorrectly connected.

l Cause 4: A hardware alarm exists on the board where the bypass tunnel resides, and thus
the APS frame cannot be transmitted.
l Cause 5: The clock alarms exist in the system.
l Cause 6: The working tunnel or bypass tunnel is faulty.

T2000
Procedure
l Cause 1: The configurations at the two ends of the APS protection group are inconsistent.
1. 8.2 Querying Current Alarms of a Board, and check whether alarms such as
ETH_APS_PATH_MISMATCH or ETH_APS_TYPE_MISMATCH exists.
2. If yes, clear the ETH_APS_PATH_MISMATCH or
ETH_APS_TYPE_MISMATCH alarm.
l Cause 2: The protocols at the two ends of the APS protection group are in the inactive state.
1. Check whether the ETH_APS_LOST or ETH_APS_SWITCH_FAIL alarm exists in
the APS protection group.
2. If yes, clear the ETH_APS_LOST or ETH_APS_SWITCH_FAIL alarm.
l Cause 3: The optical fibers or cables are incorrectly connected.
1. Check whether the optical fibers or cables are correctly connected.
2. If not, correct the fiber or cable connection.
l Cause 4: A hardware alarm exists on the board where the bypass tunnel resides, and thus
the APS frame cannot be transmitted.
1. Check whether a hardware alarm such as the HARD_BAD, COMMUN_FAIL, or
BUS_ERR exists on the board where the APS bypass tunnel resides. If the alarm exists,
clear the HARD_BAD, COMMUN_FAIL, or BUS_ERR alarm, and then check
whether the switching can be normally performed in the APS protection group.
l Cause 5: The clock alarms exist in the system.
1. Check whether the clock alarm such as TR_LOC, SYNC_C_LOS, or LTI exists in
the system.
2. If yes, clear the TR_LOC, SYNC_C_LOS, or LTI alarm, and then check whether
the switching can be normally performed in the APS protection group.
l Cause 6: The bypass tunnel is faulty.
1. Check whether any tunnel-level alarms listed in Table 3-12 exist in the working tunnel
or bypass tunnel. If an alarm exist, it indicates that the protection capability of the very
tunnel fails. In this case, clear the alarm, and then check whether the switching can be
normally performed in the APS protection group.
----End
3.14 Information Collection and Information Record

Collect information and record the information in a timely manner for locating and rectifying
the fault quickly.

When handling a fault, the maintenance personnel should record the fault phenomena, alarms,
performance events, and detailed handling process. The recorded information is helpful for
accurately locating the fault, and handling the fault accordingly. In this way, the faults cannot
persist in the network and lead to further problems in the operation stability of the network.
3.15 Fault Notification and Technical Support

During troubleshooting, you can inform Huawei of the faults and apply for technical support, if
necessary.
Contact Huawei Customer Service Center and notify the fault in the case of any difficulty in
locating or solving a problem.
Huawei Technologies Co., Ltd.
Address: Huawei Industrial Base Bantian, Longgang, Shenzhen, People's Republic of China
Zip code: 518129
Website: http://www.huawei.com/
Huawei Customer Service Center 24-hour hot line: 400-830-2118, 86-755-28560000
Huawei Customer Service Center fax: 86-755-28560111
Huawei Customer Service Center e-mail address: support@huawei.com
In the case of any serious accident on equipment, contact Huawei by phone or fax for technical
support.
If any replaced equipment component is returned to Huawei for repair, apply for a spare
component according to the service contract.
NOTE
The latest technical documents are available on the support website, which may help to analyze and solve
problems.
Website: http://support.huawei.com/

Maintenance Guide 4 Data Backup and Restoration
4 Data Backup and Restoration
About This Chapter
You can back up the T2000 data and the NE data in time so that the data can be quickly restored
after it is damaged and the data security can be ensured. This chapter describes several methods
to back up and restore data. You can select these methods as needed.
4.1 Backing Up and Restoring the T2000 Data
Back up the T2000 data in time for quick data restoration when the T2000 data is damaged.
4.2 Backing Up and Restoring the NE Data
To ensure security of the NE data, back up and restore the NE data in a timely manner.

4 Data Backup and Restoration Maintenance Guide
4.1 Backing Up and Restoring the T2000 Data

Back up the T2000 data in time for quick data restoration when the T2000 data is damaged.
4.1.1 Methods of Backing Up and Restoring the T2000 Data
To maintain the data stored on the T2000, you can back up and restore the managed object (MO)
data, all data in the databases, or script-based network configuration data.
4.1.2 Backing Up the T2000 MO Data
When the system becomes faulty, you can quickly restore the system data from the backed up
MO data. This section describes how to back up the MO data of the T2000.
4.1.3 Backing Up All Data in the T2000 Database
This section describes how to use the database management tool to immediately back up the
T2000 database to the local server, and thus to quickly restore the data when the database is
faulty.
4.1.4 Backing Up the T2000 Network Configuration Data by Means of Scripts
Before upgrading the T2000, export the data stored in the T2000 databases and save the data as
a script file.
4.1.5 Restoring the MO Data of the T2000
This section describes how to restore the MO data of the T2000.
4.1.6 Restoring All Data of the T2000 Databases
This section describes how to restore the data stored in the T2000 databases backed up before
by using the database management tool.
4.1.7 Restoring the T2000 Network Configuration Data by Means of Scripts
When upgrade of the T2000 software is complete, restore the network configuration data from
the backup script files.
4.1.1 Methods of Backing Up and Restoring the T2000 Data

To maintain the data stored on the T2000, you can back up and restore the managed object (MO)
data, all data in the databases, or script-based network configuration data.
Backing Up and Restoring the T2000 MO Data

To back up the T2000 MO data, directly duplicate every database table in the MO structure of
the T2000 databases to an OS file by using the scripts compiled by Huawei. The data for backup
is the same for the MO backup and database backup, and covers the customization on the T2000,
network-layer trail, NE configuration, alarms and performance events. Backup of the T2000
MO data only involves the data listed in tables instead of the table structure, storage process,
trigger, user name, and authority.
NOTE
Backup of the T2000 MO data excludes the following data:

l Data not stored on NEs, that is, data not uploaded
l User preferences of the system

Backing up and Restoring All Data in the T2000 Databases

The T2000, when initially installed, automatically creates five databases, that is, the T2000
databases.
l T2000DB, which stores the core data of the server, including all MO data and static data.
This database can be accessed using the Ems Server process.
l iMapAlarmDB, which stores alarm data, including data about current and history alarms.
This database can be accessed using the Ems Server process.
l iMapTopoDB, which stores topology data in the T2000 client. This database can be
accessed using the Topo Server process.
l iMapLogDB, which stores operation logs.
l iMapSecurityDB, which stores security data. This database can be accessed using the
Security Server process.
To back up the T2000 databases is to save these five databases as OS files. The data for backup
covers customization on the T2000, network-layer trail, NE configuration, alarms, and
performance events. In addition, the complete database structure, tables in the databases (system
table and user table), table structure, and storage process are also backed up.
NOTE
Backup of the T2000 databases excludes the following data:

l Data not stored on NEs, that is, data not uploaded
l User preferences of the system
Backing Up and Restoring Script-Based T2000 Network Configuration Data

Export the data stored in the database as script files. Export or import the script files to back up
or restore the T2000 network configuration data. The script files are basic data for script import
and export. When the T2000 is upgraded, importing and exporting scripts is one way to achieve
smooth upgrade of the configuration data. Table 4-1 lists the types of script files supported by
the T2000 and data contained in each script file.

Table 4-1 Script files supported by the T2000

Script File File Naming Data Importable/
Type Rule Exportable or
Not
Networkwide None Is a collection of script files, Yes

configuration file which include the T2000
naming file, NE configuration
file, NE list file, and network-
layer information file. When
you export the network
configuration file, these script
files are all exported. To
import the networkwide
configuration file is to import
the NE configuration file and
T2000 naming file in sequence
according to the NEs
contained in the NE list file,
and then to import the
network-layer information
file.
NE port naming NEPort_extended Contains the naming Yes

file ID-basic ID_NE information of ports on the NE.
name.txt
NE configuration NEData_extende Is similar to the configuration Yes

file d ID-basic ID_NE information for the command
name.txt lines and contains all the data
used for setup and normal
operation of an NE. The data
covers the NE attributes,
service configuration, clock
attributes, board parameters,
protection attributes, board
version information, and board
manufacturing information.
NE list file NWNeList_NM Contains information about Yes

name.txt the NEs, T2000 version,
chassis, and physical IP
addresses. The T2000 naming
file and NE configuration file
are imported or exported in
sequence for NEs listed in this
file.

Script File File Naming Data Importable/

Type Rule Exportable or
Not
NMS computer NMInfo_NM Contains the configuration Exportable, but

information file name.txt information of the T2000 not importable
server, including the hardware
information, such as the OS
name and version, OS patch
version, physical memory,
CPU quantity and main
frequency, computer name, IP
address, database name and
version.
Service NWScvcData_N Contains data scripts for the Exportable, but

configuration file M name.txt system to provide transport not importable
services. This file covers the
NE attributes, slot layout,
board protection, protection
relation, service configuration,
protection subnet, and circuit
configuration.
Network-layer NWCfg_NM Contains network-layer Yes

information file name.txt configuration information,
covering the fiber/cable
connections, protection
subnets, and circuit
configuration.
Network None Contains the configuration Yes

simulation information about network
planning simulation planning.
information file
Comparison Among the Three Methods of Maintaining the T2000 Data

The features of the three methods of maintaining the T2000 data decide the application scenarios.
Table 4-2 lists the comparison among the three methods.

Table 4-2 Features and application scenarios of the three methods of maintaining data
Method Backup Feature Application Specific

Scenario Operation
Backing l Back up all data in the T2000 This method is For details, see 4.1.2
up and database as an MO file. The preferred for backing Backing Up the
restoring data is in the .txt format. You up and restoring data T2000 MO Data and
the T2000 can read the data file only if between the T2000 4.1.5 Restoring the
MO data you are familiar with the data systems of the same MO Data of the
structure of the T2000. version. The backup T2000.
l All data is backed up. MO files are version-
specific and are not
l This method features high interchangeable.
processing speed and small
size of the backup file.
Backing l Back up the structure and This method requires For details, see 4.1.3
up and contents of the T2000 the storage medium Backing Up All
restoring databases. The data is in of large capacity. Data in the T2000
all data in binary. Tapes are Database and 4.1.6
the T2000 l All data is backed up. recommended for Restoring All Data
databases regular backup. of the T2000
l This method features high Databases.
processing speed and large
size of the backup file.
Backing l Export the configuration The T2000 of a later For details, see 4.1.4
up and data of the T2000 as a text version is compatible Backing Up the
restoring file, which stores data and is with the scripts for T2000 Network
script- easy to read. the T2000 of an Configuration Data
based l Not all data is backed up. The earlier version. by Means of
T2000 data backed up only covers Hence, this method Scripts and 4.1.7
network the general configuration, is generally adopted Restoring the
configurati port naming rule, and for upgrade of the T2000 Network
on data network customization. T2000. Also, this Configuration Data
method is applicable by Means of
l This method features high to back up and Scripts.
processing speed and small restore the general
size of the backup file. configuration data of
an NE, or to restore
the network
customization data.
NOTE
You can specify a remote server for restoring the T2000 databases. For specific operations, see the OptiX
iManager T2000 Operation Guide for RTN for RTN NE Management.
Suggestion
l When you finish installing the T2000 for the first time, back up the T2000 databases. One-
time backup is necessary if the databases are not expanded. If sufficient capacity (10G or

more idle capacity) is available on the hard disk, back up the T2000 databases by quarter.
Regularly back up the databases in the case of sufficient capacity on the hard disk.
l Back up the MO data of the T2000 during routine maintenance. Whenever service
configuration data changes, back up the MO data immediately. You can also set up a
scheduled task to back up the MO data on a monthly basis.
l To release capacity of the hard disk, clear the data previously backed up, after a new backup.
l To restore the T2000 MO data and all data in the T2000 databases, first shut down the
T2000 server.
4.1.2 Backing Up the T2000 MO Data

When the system becomes faulty, you can quickly restore the system data from the backed up
MO data. This section describes how to back up the MO data of the T2000.
Prerequisite
l The T2000 user must log in and display the Main Topology interface.
l You must be a T2000 user with "NM administrator" authority or higher.
Background Information
The default directories where the database file is backed up are as follows.
l On the UNIX platform, the MO data is backed up to /T2000/server/database/
dbbackup.
l On the Windows platform, the MO data is backed up to \T2000\server\database
\dbbackup.
Precautions
The method of restoring the system data from the backed up MO data is not applicable to upgrade
of the T2000. In the case of upgrade of the T2000, import and export scripts to store the system
data.
Procedure
Step 1 Start the Database Management Tool.
NOTE
l On the UNIX platform, right-click on the common desktop environment (CDE) and then choose
Tools > Terminal to display a terminal window. In the /T2000/server/database directory, run
"T2000DM.sh" to display the Database Management Tool window.
l On the Windows platform, open Windows Explorer. In the \T2000\server\database directory, run
"T2000DM.exe". The T2000DM.exe window appears and then immediately disappears, and the
Database Management Tool window displays.
Step 2 In Database Server List on the left, select T2000DBServer.

Step 3 In the displayed dialog box, enter the password of user sa.
NOTE
Step 4 Click Backup MO to display the Description dialog box.

Step 5 Set the backup directory on the server, and enter the relevant description information. Click
Backup to display the Back Up MO dialog box. In this case, the backup of the MO data of the
T2000 is started.
NOTE
l If the customized directory of data backup is not disk C, you can avoid the effect on the backup data
when you reinstall the system or format disk C, so that the maintainability of the system is improved.
l The backup directory should be short and should not contain special characters, such as spaces,
punctuation, and Chinese characters.
Step 6 Click OK in the dialog box. Return to the Database Management Tool window.
----End
4.1.3 Backing Up All Data in the T2000 Database

This section describes how to use the database management tool to immediately back up the
T2000 database to the local server, and thus to quickly restore the data when the database is
faulty.
Prerequisite
l On the UNIX platform, the current user must be a root user, and the Sybase database must
be started.
l On the Windows platform, the current user must have the administrator authority of the
operating system. The MS SQL server database must be started.
Procedure
Step 1 Start the Database Management Tool.
l On the UNIX platform, right-click the common desktop environment (CDE) and choose
Tools > Terminal to display a terminal window. In the /T2000/server/database directory,
run "T2000DM.sh" to display the Database Management Tool window.
l On the Windows platform, open Windows Explorer. In the \T2000\server\database
directory, run "T2000DM.exe". The T2000DM.exe window appears and then immediately
disappears, and the Database Management Tool window displays.
Step 2 In the Database Server List on the left, select T2000DBServer.
Step 3 In the dialog box displayed, enter the password of user sa.
NOTE
Step 4 Click Backup Database to display the Description dialog box.
Step 5 Enter the path and a description of the database backup.

NOTE
l By customizing the backup directory of the data, you can prevent the impact on the backup data when
you re-install the system or format disk C, thus improving the maintainability of the system.
l Ensure that the backup directory is short and contains no space, punctuation, or Chinese character.
Step 6 Click Backup to back up the T2000 database.

Step 7 When the backup is complete, click OK in the displayed indication dialog box and return to the
database management tool interface.
----End
4.1.4 Backing Up the T2000 Network Configuration Data by Means

of Scripts
Before upgrading the T2000, export the data stored in the T2000 databases and save the data as
a script file.
Prerequisite
l Before exporting the script file, check the consistency of the configuration data to ensure
data consistency between the T2000 and the NEs. For specific operations, see 8.7 Checking
Data Consistency Between an NE and the T2000.
Procedure
Step 1 Choose System > Import/Export Script File from the Main Menu and the Import/Export
Script File window is displayed.
Step 2 Select the file format, click Export and then select the script file type in Script File Type.
NOTE
l For types of exported script files, see Table 4-1 in 4.1.1 Methods of Backing Up and Restoring the
T2000 Data.
l To export a script containing networkwide configuration data, select Networkwide Configuration
File. The files exported to the specified directory are as follows:
l Networkwide Configuration File "NGCfg_NM name.txt"
l NE List File "NWNeList_NM name.txt"
l NE Port Naming File "NEPort_extended ID-basic ID_NE name.txt"
l NE Configuration File "NEData_extended ID-basic ID_NE name.txt"
Step 3 Select the NE for which you want to export script files from the Export NE List on the left.
NOTE
Specify the NEs for exporting NE Configuration File, NE List File, NE Port Naming File, and
Networkwide Configuration File.
Step 4 Click Create File Directory to create a directory to save the exported script files.
Step 5 Input the name of the newly created directory and click OK. The newly created directory will
be displayed automatically in the Operation Directory List area.

NOTE
The script files are saved on the T2000 server. For the Windows platform, the script files are backed up to
\T2000\server\script. For the UNIX platform, the script files are backed up to /T2000/server/script. For
both cases, the user can create sub-folders further.
Step 6 Select a directory and click Apply.

Step 7 Click OK in the displayed Confirm dialog box. A progress bar appears, indicating the progress
of exporting script files.
----End
4.1.5 Restoring the MO Data of the T2000

This section describes how to restore the MO data of the T2000.
Prerequisite
l The T2000 MO data must be backed up.
l The T2000 server must be shut down.
l On the UNIX platform, the current user must be root, and the Sybase database must be
started.
l On the Windows platform, the current user must have the authority of administrator of the
l The T2000 database must be initialized. The software of the T2000 server must be started
up and then shut down.
Context
CAUTION
In the case of the MO data to be restored, the T2000 versions must be consistent.
NOTE
The default directories where the database file should be backed up are as follows.
l On the UNIX platform, back up the MO data to /T2000/server/database/dbbackup.
l On the Windows platform, if the T2000 server is installed in disk C, back up the MO data to C:
\T2000\server\database\dbbackup.
Procedure
Step 1 Start Database Management Tool.
l On the UNIX platform, right-click on the common desktop environment (CDE) and then
choose Tools > Terminal to display a terminal window. In the /T2000/server/database
directory, run "T2000DM.sh".
directory, run "T2000DM.exe".

NOTE
Step 4 Click Restore MO to display the Select MO dialog box.
Step 5 Specify the directory where the MO data to be restored should be saved. Click Restore and click
Yes in the displayed Confirm dialog box to restore the MO data of the T2000.
Step 6 When the restoration is complete, click OK in the Restore MO dialog box and return to the
database management tool interface.
----End
4.1.6 Restoring All Data of the T2000 Databases

This section describes how to restore the data stored in the T2000 databases backed up before
by using the database management tool.
Prerequisite
l The T2000 MO data must be backed up.
l The T2000 server must be shut down.
l On the UNIX platform, the current user must be root, and the Sybase database must be
started.
l On the Windows platform, the current user must have the authority of administrator of the
Context
CAUTION
In the case of the data restoration, the T2000 versions must be consistent.
Procedure
Step 1 Start The Database Management Tool.
l On the UNIX platform, right-click on the common desktop environment (CDE) and then
choose Tools > Terminal to display a terminal window. In the /T2000/server/database
directory, run "T2000DM.sh".
directory, run "T2000DM.exe".
NOTE

Step 4 Click Restore Database to specify the directory where the database file is backed up.
Step 5 Click Restore and click Yes in the displayed Confirm dialog box to restore the database data
of the T2000.
Step 6 When the restoration is complete, click OK in the Restore Database dialog box and return to
the Database Management Tool interface.
----End
4.1.7 Restoring the T2000 Network Configuration Data by Means of

Scripts
When upgrade of the T2000 software is complete, restore the network configuration data from
the backup script files.
Prerequisite
l You must have the license for the T2000 script import.
Precautions
CAUTION
Before importing the script file, back up the T2000 database or the T2000 MO data. Then,
initialize the T2000 database. Finally, import the networkwide configuration script file. If
importing the script files fails, restore the data from the backup database or MO data.
Procedure
Step 1 Choose System > Import/Export Script File from the Main Menu.
Step 2 Select the file format, click Import and then select the script file type in Script File Type.
NOTE
Service Actualization Script and NM Computer Information File cannot be imported.
Step 3 In Operation Directory List, select the directory where the script file for importing is located.
Step 4 Select the script file to be imported from Import File List.
Step 5 Click Apply. The system prompts twice that importing the script files causes data inconsistency
between the T2000 and NE.

NOTE
When the script files are imported, deliver the configuration data from the T2000 to the NE for data
consistency. For specific operations, see Downloading NE Configuration Data.
Step 6 Click OK. A progress bar appears, indicating the progress of importing script files.
NOTE
The script files are saved on the T2000 server. For the Windows platform, the script files are backed up to
\T2000\server\script. For the UNIX platform, the script files are backed up to /T2000/server/script. For
both cases, the user can create sub-folders further.
----End
4.2 Backing Up and Restoring the NE Data

To ensure security of the NE data, back up and restore the NE data in a timely manner.
4.2.1 Methods of Backing Up and Restoring NE Data
Save important NE data during routine maintenance. In this way, if the system control board of
the NE loses data or the equipment is powered off, the NE data can be restored for normal
operation of the NE. This section describes certain methods of backing up and restoring NE data.
Select a proper method as required.
4.2.2 Backing Up the NE Database to the System Control Board
During routine maintenance, back up the NE database for restoring data when the system control
board loses data or the equipment power-off is unexpectable. To back up the NE database to the
system control board is to back up the NE data to the flash of the system control board. When
the NE restarts after a power failure, the system control board automatically reads the
configuration data from the flash and delivers the configuration data to other boards.
4.2.3 Backing Up the NE Database to the CF Card
board loses data or the equipment power-off is unexpectable. You can back up the NE database
to the CF card.
4.2.4 Backing Up the NE Database to a Local Server
To improve the security of the NE database and prevent the loss of the database files due to an
NE fault, you need to back up the NE database. Periodic backup of the database files is
recommended. You can back up the database files to NMS server or NMS client.
4.2.5 Restoring the NE Database from the System Control Board
If the database file is lost due to NE maintenance or an NE fault, you can restore the NE database
from the backup database file on the system control board.
4.2.6 Restoring the NE Database from the CF Card
When the database file is lost due to NE maintenance or an NE fault, you can restore the NE
database from the backup database file on the CF card of the system control board.
4.2.7 Recovering the NE Database from a Local Server
If the database file is lost due to NE maintenance or an NE fault, you can recover the NE database
4.2.1 Methods of Backing Up and Restoring NE Data

Save important NE data during routine maintenance. In this way, if the system control board of
the NE loses data or the equipment is powered off, the NE data can be restored for normal

operation of the NE. This section describes certain methods of backing up and restoring NE data.
Select a proper method as required.
Comparison Among the Methods of Backing Up and Restoring NE Data

In the case of backup and restoration, the NE data can be saved on the system control board, CF
card, or local server. The methods of backing up and restoring NE data are specific to where the
NE data is saved. For details, see Table 4-3.
Table 4-3 Methods of backing up and restoring NE data and their application scenarios
Backup and Application Scenario Specific Operation
Restoration Method
Back up NE data to or This method is applicable to the For details, see 4.2.2 Backing
restore NE data from system control board not Up the NE Database to the
the system control configured with any CF card. System Control Board and
board. l Back up NE data in the DRDB 4.2.5 Restoring the NE
to the flash of the system Database from the System
control board. Control Board.
l To restore NE data, the
system resets (warm) the
system control board, reads
the configuration data stored
in flash, and delivers the
configuration data to other
boards.
Back up NE data to or This method is applicable to the For details, see 4.2.3 Backing
restore NE data from system control board configured Up the NE Database to the CF
the CF card. with a CF card. Card and 4.2.6 Restoring the
l Back up the NE data in the NE Database from the CF
DRDB to the CF card. Card.
l To restore the NE database,
copy the NE database from
the CF card to the flash of the
system control board. After
reset (warm), the system
control board reads
configuration data in the flash
and delivers the configuration
data to other boards.
Back up NE Back up NE configuration data For details, see Backing Up the

configuration data to to the computer where the T2000 NE Configuration Data to a
or restore NE server or client is installed. Local Server and 4.2.7
configuration data Recovering the NE Database
from the local server. from a Local Server.

NOTE
You can also specify a remote server for restoring the NE databases. For specific operations, see the OptiX
iManager T2000 Operation Guide for RTN NE Management.
NE Database
NE configuration data is stored in the NE databases on the system control board. The types of
NE databases are as follows:
l Memory database (MDB): The data in this database varies with the configuration
information, and is lost when the system control board is reset or powered off.
l Dynamic random database (DRDB): This database automatically stores data that is verified.
l Flash database (FDB): FDB is divided into FDB0 and FDB1. The data in FDB is copied
from DRDB and can be stored permanently.
The NE configuration data, when delivered, is first stored in MDB. Then, the data is verified. If
the data passes the verification, the system control board automatically copies data from MDB
to DRDB and delivers the generated configuration data to other boards. Data needs to be copied
from DRDB to FDB, which then backs up DRDB.
When the NE restarts upon a power failure, the system control board checks for configuration
data in DRDB. In the case of any configuration data in DRDB, the system control board restores
data from DRDB; in the case any damage to the configuration data in DRDB, the system control
board restores data from FDB0 and FDB1.
NE Configuration Data
The NE configuration data refers to the information in DRDB of the NE, such as the board
configuration, clock configuration, and protection relations of the NE. The NE configuration
data is the instruction file of the NE and the key for the NE to normally operate in the entire
network.
NE Database Package
The NE database package indicates a collection of all database files on an NE. A file list defines
and manages those files in the package.
The NE database package contains the same data as the NE configuration data. The data is called
differently for different NE releases. In the case of an NE of release 5.00.06 or later, you can
back up and restore the NE database package.
4.2.2 Backing Up the NE Database to the System Control Board

board loses data or the equipment power-off is unexpectable. To back up the NE database to the
system control board is to back up the NE data to the flash of the system control board. When
the NE restarts after a power failure, the system control board automatically reads the
configuration data from the flash and delivers the configuration data to other boards.
Prerequisite
l You must log in to the NE as an NE user of the system level.
l You must be a T2000 user with "NE and Network Operator" authority or higher.

Procedure
Step 1 Choose Configuration > Configuration Data Management from the Main Menu. The
Configuration Data Management window is displayed.
Step 2 In the Object Tree on the left, select an NE and click .
Step 4 Choose Back Up NE Data > Back Up Database To SCC. Click OK in the displayed
Confirm to start the backup.
Step 5 Click Close in the displayed Operation Result dialog box to complete the operation.
----End
4.2.3 Backing Up the NE Database to the CF Card

board loses data or the equipment power-off is unexpectable. You can back up the NE database
to the CF card.
Prerequisite
l You must log in to the NE as an NE user with "System Level" authority.
l You must be an NM user with "NE and Network Operator" authority or higher.
l The system control board is configured with a CF card.
Procedure
Step 2 Select an NE from the Object Tree, and then click .
Step 4 Click Back Up NE Data > Manually back up database to CF Card . Click OK to start the
backup.
Step 5 In the displayed Operation Result dialog box, click Close.
----End
4.2.4 Backing Up the NE Database to a Local Server

To improve the security of the NE database and prevent the loss of the database files due to an
NE fault, you need to back up the NE database. Periodic backup of the database files is
recommended. You can back up the database files to NMS server or NMS client.
Prerequisite
l You must be a T2000 user with "NE and Network Maintainer" authority or higher.

l The NE must be created on the T2000.

l The computer where the T2000 is installed must be able to normally communicate with the
NE.
l The FTP/HFCP/SFTP server is configured and the FTP/HFCP/SFTP service is started.
Context
l Backup operation can be performed on multiple devices of the same device type.
l On selecting the device type in the device tree, all the devices and the device type versions
related to the device type is displayed in the Device View table.
l The files are backed up from the server can be viewed in the Backup Information tab.
Procedure
Step 1 Choose Data Center > Device Operation from the Main Menu to open the Device
Operation tab. The device types are displayed in the device tree on the left.
Step 2 Select and right-click the device(s) that you want to backup in the right Device View table, and
click Backup.
NOTE
The Backup Information tab is unavailable when multiple devices are selected.
Step 3 In the displayed Backup dialog box, select backup to NMS Server or NMS Client.
l If the NMS Server is selected, the database file is stored on the NMS server.
l If the NMS Client is selected, the database file is stored on the NMS client and you need to
click to select the location where the device data have to be backed up.
Step 4 Click Start and the backup processing information is displayed in the Device View area.
----End
Result
The selected NE's database is successfully backed up.

4.2.5 Restoring the NE Database from the System Control Board

If the database file is lost due to NE maintenance or an NE fault, you can restore the NE database
Prerequisite
l You must log in to the NE as an NE user with "system level" authority.
l The NE Database must be backed up to the system control board.
Procedure
Step 1 Double-click an NE on the Main Topology to display the Running Status slot layout.
Step 2 Right-click a board and select Warm Reset.
Step 3 In the displayed dialog box, click OK to finish restoring the NE database.
----End
4.2.6 Restoring the NE Database from the CF Card

When the database file is lost due to NE maintenance or an NE fault, you can restore the NE
database from the backup database file on the CF card of the system control board.
Prerequisite
l You must log in to the NE as an NE user with "system level" authority.
l The system control board must be configured with a CF card and the NE database must be
backed up to the CF card.
Procedure
Step 2 Select an NE from the Object Tree, and then click .

Step 4 Click Restore NE Database. The Confirm dialog box is displayed, indicating that restoring the
NE database may interrupt services.
Step 5 Click OK to start restoring the NE database.
Step 6 Click Close.
----End
Postrequisite
When the restoration is complete, the database on the CF card is restored to the memory of the
system control board, but not delivered to other boards. To restore the configuration data of the

boards, perform warm reset on the system control board and then on other boards. During reset
of other boards, the system control board delivers the configuration data to the boards again.
4.2.7 Recovering the NE Database from a Local Server

If the database file is lost due to NE maintenance or an NE fault, you can recover the NE database
Prerequisite
l The NE must be created on the T2000.
l The computer where the T2000 is installed must be able to normally communicate with the
NE.
l The database package for recovering is available. Only the data backed up when the NE is
in the running state can be restored to the NE.
l The FTP/HFCP/SFTP server is configured and the FTP/HFCP/SFTP service is started.
Context
l You cannot perform the Recover operation for devices of different device types.
l On selecting the device type in the device tree, all the device information related to the
device type is displayed in the Device View table.
Precautions
CAUTION
Before recovering the NE database file to the NE, make sure that the database file for restoration
is correct; otherwise, services are interrupted.
Procedure
Step 1 Choose Data Center > Device Operation from the Main Menu to open the Device
Operation tab. The device types are displayed in the device tree on the left.
Step 2 Select and right-click the device(s) that you want to backup in the right Device View area, and
click Recover to open the Recover dialog box.

Step 3 Select the file to be recovered from the File Name drop-down list. If the file is not listed, click
Browse to display the Select File dialog box.
Step 4 Select the file from NMS Server or NMS Client to recover.
l If the NMS Server is selected, select the file to be recovered from the NMS Server. The
selected file path is displayed in the Select File dialog.
l If the NMS Client is selected, click to select the file to be recovered from the NMS
Client. The selected file path is displayed in the following Selected File dialog.

Step 5 Click OK. The selected file path from the NMS Server or NMS Client is displayed in the File
Name drop-down list.
Step 6 Click Start and click Yes in the displayed Operation Confirmation dialog box. The processing
information is displayed in the Device View area.
NOTE
When the restoration is complete, the following information will be displayed in the Device View area.
Step 7 Right-click the device icon and click Activation Database to activate the database file which
is just restored.

----End
Result
The selected NE's database is successfully recovered.

Maintenance Guide 5 Replacing Components
5 Replacing Components
About This Chapter
Component replacement refers to the replacement of a board or component for purpose of

maintaining or expanding capacity for the equipment. This operation, though done on the
equipment site, requires support from the T2000.
5.1 Replacing the CXPR with the 1+1 Protection
When the CXPR becomes faulty or during capacity expansion, the board needs to be replaced.
This section describes replacement of the CXPR with the 1+1 protection in terms of prerequisite,
impact on system, precautions, tools, and operation procedure.
5.2 Replacing the CXPR Without the 1+1 Protection
This section describes replacement of the CXPR not configured with the 1+1 protection in terms
of prerequisite, impact on system, precautions, tools, and operation procedure.
5.3 Replacing the Processing Boards
The processing boards include the EF8T, EF8F, EG2, ML1, and ML1A. When a processing
board becomes faulty or capacity expansion is required, the board needs to be replaced. This
section describes replacement of a processing board in terms of prerequisite, impact on system,
precautions, tools, and operation procedure.
5.4 Replacing the IFE2 Board
When the IFE2 board becomes faulty or capacity expansion is required, the IFE2 board needs
to be replaced. This topic describes the replacement of the IFE2 board in terms of prerequisite,
5.5 Replacing the FAN Board
When the FAN board becomes faulty or during capacity expansion, the FAN board needs to be
replaced. This section describes replacement of the FAN board in terms of prerequisite, impact
on system, precautions, tools, and operation procedure.
5.6 Replacing the PIU Board
When the PIU board becomes faulty or during capacity expansion, the PIU board needs to be
replaced. This section describes replacement of the PIU board in terms of prerequisite, impact
5.7 Replacing the AUXQ Board

5 Replacing Components Maintenance Guide
When an AUXQ board becomes faulty or capacity expansion is required, the AUXQ board needs
to be replaced. This section describes replacement of the AUXQ board in terms of prerequisite,
5.8 Replacing the Chassis
The entire case-shaped equipment needs to be replaced when the backplane of chassis becomes
faulty, or the equipment is severely damaged by external force. This section describes
replacement of the chassis in terms of prerequisite, impact on system, precautions, tools, and
operation procedure.
5.9 Replacing the Pluggable Optical Module
This section provides information on how to replace the pluggable optical module. When the
optical module becomes faulty, it needs to be replaced in time. So, the optical interface can work
normally.
5.10 Replacing the ODU
The method of replacing the ODU with the waveguide interface is different from the method of
replacing the ODU with the coaxial interface.
5.11 Replacing the IF Cable
This topic describes how to replace an IF cable.

5.1 Replacing the CXPR with the 1+1 Protection

This section describes replacement of the CXPR with the 1+1 protection in terms of prerequisite,
Prerequisite
l The 1+1 board protection group must be available.
l The standby CXPR board is in service and works normally.
Impact on System
If the CXPR is configured with the 1+1 protection, replacing the faulty CXPR board does not
affect services when the switching is normally performed.
Precautions
Before replacing the CXPR, read Safety Precautions for Using the Equipment.
CAUTION
When replacing a board, make sure that the board is not connected to any cables. The cable
connectors must be properly enveloped to avoid short circuit.

Anti-static bag, ESD wrist strap, T2000, crosshead screwdriver
Procedure
Step 1 Make sure that the spare board is the same as the board to be replaced with respect to the name,
model, and parameters.
Step 2 Query the current alarms of the board. When the replacement is complete, you can check whether
the original alarms are cleared and no new alarms are generated. For details, see 8.2 Querying
Current Alarms of a Board.
Step 3 Query whether the 1+1 protection switching occurs on the board. For details, see 8.23 Querying
Protection Configuration.
l If the slot and the board name of the faulty board is displayed in Active Board, it indicates
that the protection switching does not occur. Go to Step 4.
l If the slot and the board name of the faulty board is not displayed in Active Board, it
indicates that the 1+1 protection switching is complete. Go to Step 5.
Step 4 On the T2000, perform the 1+1 protection switching for the faulty CXPR board. For details, see
8.11 Performing the 1+1 Protection Switching for CXPR boards.

Step 5 Ask the on-site maintenance personnel to remove the faulty CXPR board. For specific
operations, see 8.19 Replacing Boards on Site.
NOTE
l When the replacement is complete, the PROG indicator on the newly inserted CXPR board flashes
green, indicating that the board software is being loaded. This process will take about 5 minutes.
l CXPR will restore the original configuration data from the active board after the board software is
successfully loaded. This process will take about 5 minutes.
Step 6 Optional: On the T2000, cancel the board 1+1 protection switching. For details, see 8.11
Performing the 1+1 Protection Switching for CXPR boards.
NOTE
If the recovery of the board working/protection state is faulty, the working and protection boards may be
in the backup state. In this case, wait for at least 5 min, and then perform the recovery operation.
Step 7 Check whether the fault is rectified.

1. Check indicators of the newly inserted CXPR board. If any indicator flashes abnormally,
remove and then insert the board, or replace the board. For more details on the indicators
of boards, see the OptiX RTN 950 Radio Transmission System IDU Hardware
Description..
2. Query the board alarms. Make sure that the alarms generated by the original faulty board
are cleared.
----End
5.2 Replacing the CXPR Without the 1+1 Protection

This section describes replacement of the CXPR not configured with the 1+1 protection in terms
of prerequisite, impact on system, precautions, tools, and operation procedure.
Prerequisite
Impact on System
Replacing the CXPR interrupts services for about 15 minutes.
Precautions
Before replacing the CXPR, read Safety Precautions for Using the Equipment.
CAUTION
When replacing a board, make sure that the board is not connected to any cables. The cable
connectors must be properly enveloped to avoid short circuit.


Procedure
Step 2 Query and record the current alarms of the CXPR. When the replacement is complete, you can
check whether the original alarms are cleared and no new alarms are generated. For specific
operations, see 8.2 Querying Current Alarms of a Board.
Step 3 Query and record the current NE user. When the board replacement is complete, restore data
about the login NE user.
1. Right-click the target NE and choose NE Explorer. The NE Explorer window is displayed.
2. Choose Security > NE Login Management from the Function Tree on the left.
3. Check the NE Login Management Table on the right, and record the current login NE
user.
Step 4 Back up the NE database to the CF card. When the replacement is complete, you can restore the
NE database in time. For details, refer to 4.2.3 Backing Up the NE Database to the CF
Card.
Step 5 Ask the on-site maintenance personnel to draw out the CXPR board, move the CF card to the
spare CXPR board, and insert the spare CXPR board into the chassis. For specific operations,
refer to 8.19 Replacing Boards on Site and the OptiX RTN 950 Radio Transmission System
IDU Quick Installation Guide manual.
Step 6 Press and hold the CF RCV button of the CXPR board for 5 seconds to restore the NE database
from the CF card.
NOTE
l In the process of restoring NE database, the PROG indicator on the CXPR flashes green.
l When the STAT and PROG indicators on the CXPR stay green without flashing, it indicates that the
NE database is completely restored and the board is working normally. In this case, you can perform
operations on the T2000. Otherwise, re-insert the CXPR or replace it with another spare CXPR if
necessary.
l The process of restoring NE database will take about 5 minutes.
Step 7 Use the NE user which is recorded in the step 3 and log in the T2000.
Step 8 Check whether the original alarms are cleared and no alarms are generated. If yes, it indicates
that the board replacement is successful.
----End
5.3 Replacing the Processing Boards

The processing boards include the EF8T, EF8F, EG2, ML1, and ML1A. When a processing
board becomes faulty or capacity expansion is required, the board needs to be replaced. This
section describes replacement of a processing board in terms of prerequisite, impact on system,
precautions, tools, and operation procedure.

Prerequisite
Impact on System
Replacing a processing board interrupts the service on the board for about 3 - 5 minutes.
Precautions
Before replacing a processing board, read Safety Precautions for Using the Equipment.
DANGER
Avoid direct eye exposure to the laser beam launched from the optical interface board or from
inside the fiber, for the laser beam may cause permanent damage to the eyes.
WARNING
l When replacing a processing board, make sure that the board is not connected to any fiber
jumpers or cables.
l The optical interface and the fiber jumper connector must be clean. Seal the jumper connector
in protection cap.
l The cable connectors must be properly sealed to prevent short circuit.
Tools, Meters, and Materials

Procedure
Step 2 Query and record the current alarms of the processing board. When the replacement is complete,
you can check whether the original alarms are cleared and no new alarms are generated. For
specific operations, see 8.2 Querying Current Alarms of a Board.
Step 3 Ask the on-site maintenance personnel to remove the faulty processing board. For specific
NOTE
All the processing boards support hot plugging. When the board replacement is complete, the new
processing board is in the process of initialization and sets up service connections automatically. This
process will take each board about one minute.
Step 4 Check indicators of the newly inserted processing board. If any indicator flashes abnormally,
remove and then insert the board, or replace the board the second time. For more details on the

indicators of boards, see the OptiX RTN 950 Radio Transmission System IDU Hardware
Description..
----End
5.4 Replacing the IFE2 Board

When the IFE2 board becomes faulty or capacity expansion is required, the IFE2 board needs
to be replaced. This topic describes the replacement of the IFE2 board in terms of prerequisite,
Prerequisite
l The location of the board to be replaced must be specified.
l The service protection and protection channels of the board to be replaced must be specified.
l A spare board must be prepared, and the version and type of the spare board must be the
same as those of the board to be replaced.
Impact on System
l On the equipment without 1+1 IF protection, the replacement of the IF board causes service
interruption.
l On the equipment with 1+1 IF protection, the replacement of the current protection IF board
does not affect the service. The replacement of the currently working IF board, however,
causes transient service interruption during the protection switching.
Precautions
Before you replace the IFE2 board, be sure to turn off the ODU-PWR switch on the IFE2 board.

l ESD wrist strap
l Screwdriver
l T2000
Procedure
Step 1 Query the current alarms of the IFE2 board by referring to Querying the Current Alarms of
a Board, and record the alarms.
Step 2 Optional: If the microwave service is provided with 1+1 protection, be sure to switch the service
to the protection IF board.
1. Perform the task described in Querying the Working State of the IF 1+1 Protection
Group.
2. If the board to be replaced acts as the working board instead of the protection board and
the protection channel is in the normal or SD state, performed forced switching.

Step 3 Turn off the ODU-PWR switch on the IF board to be replaced.
Step 4 Replace the IFE2 board by referring to Replacing Boards On Site.
Step 5 After the board starts to work, observe the indicators on the board.
The STAT indicator should be lit green.
Step 6 Turn on the ODU-PWR switch on the IF board.
Step 7 Repeat Step 1.

There should be no new alarms.
Step 8 Optional: If you have performed forced switching earlier between the radio links, release the
switching through the T2000.
----End
5.5 Replacing the FAN Board

When the FAN board becomes faulty or during capacity expansion, the FAN board needs to be
replaced. This section describes replacement of the FAN board in terms of prerequisite, impact
Prerequisite
Impact on System
If the FAN becomes faulty, replace it in a timely manner; otherwise, the equipment may become
faulty because of poor heat dissipation.
Precautions
Before replacing the FAN board, read Safety Precautions for Using the Equipment.
WARNING
When the FAN board is removed, do not touch the rotating fan leaves.

Anti-static bag, ESD wrist strap, T2000
Procedure

Step 2 Query and record the current alarms of the FAN board. When the replacement is complete, you
can check whether the original alarms are cleared and no new alarms are generated. For specific
Step 3 Ask the on-site maintenance personnel to remove the faulty FAN board. For specific operations,
see 8.19 Replacing Boards on Site.
Step 4 Verify that the FAN board is successfully replaced.

1. When the board replacement is complete, check whether the FAN indicator on the new
board stays on and green. If not, re-insert the FAN board or replace it with another spare
FAN board if necessary.
2. Query alarms of the board. Make sure that the original alarms of the FAN board are cleared
and no new alarms are generated.
----End
5.6 Replacing the PIU Board

When the PIU board becomes faulty or during capacity expansion, the PIU board needs to be
replaced. This section describes replacement of the PIU board in terms of prerequisite, impact
Prerequisite
Impact on System
If the PIU boards are of 1+1 hot backup, replacing one PIU board does not affect the services.
Precautions
WARNING
When replacing the PIU board, turn off the switch on the power supply device connected to the
PIU board and then remove all cables connected to the PIU board.

Anti-static bag, ESD wrist strap, T2000
Procedure

Step 2 Query and record the current alarms of the system. When the replacement is complete, you can
Step 3 Ask the on-site maintenance personnel to turn off the switch on the power supply device
connected to the PIU board. For specific operations, see 8.21 Powering Off the Equipment.
CAUTION
Turn off the correct switch that corresponds to the PIU board to be replacement.
Step 4 Remove the power connectors of the faulty PIU board. Then, replace the faulty PIU board. For
specific operations, see 8.19 Replacing Boards on Site.
Step 5 Power on the new PIU board. For specific operations, see 8.20 Powering On the Equipment.
Step 6 Verify that the PIU board is successfully replaced.
1. Observe the indicators of all boards after the chassis is replaced. If any indicator flashes
abnormally, re-insert the PIU board or replace it with another spare one if necessary. For
more details on the indicators of boards, see the OptiX RTN 950 Radio Transmission System
IDU Hardware Description.
2. Query alarms of the system. Make sure that the original alarms are cleared and no new
alarms are generated.
----End
5.7 Replacing the AUXQ Board

When an AUXQ board becomes faulty or capacity expansion is required, the AUXQ board needs
to be replaced. This section describes replacement of the AUXQ board in terms of prerequisite,
Prerequisite
Impact on System
Replacing the AUXQ board interrupts the service on the AUXQ board for about 3 minutes.
Precautions
Before replacing the AUXQ board, read Safety Precautions for Using the Equipment.
WARNING
When replacing a board, make sure that the board is not connected to any cable. The cable
connectors must be properly sealed to prevent short circuit.


Procedure
Step 2 Query and record the current alarms of the AUXQ board. When the replacement is complete,
you can check whether the original alarms are cleared and no new alarms are generated. For
specific operations, see 8.2 Querying Current Alarms of a Board.
Step 3 Ask the on-site maintenance personnel to remove the faulty AUXQ board. For specific
NOTE
The AUXQ board support hot plugging. When the board replacement is complete, the new AUXQ board
is in the process of initialization and sets up service connections automatically. This process will take about
one minute.
Step 4 Check the STAT, SRV and LINK indicators stay on and green. If not, re-insert the AUXQ board
or replace it with another spare AUXQ board if necessary.
----End
5.8 Replacing the Chassis

The entire case-shaped equipment needs to be replaced when the backplane of chassis becomes
faulty, or the equipment is severely damaged by external force. This section describes
replacement of the chassis in terms of prerequisite, impact on system, precautions, tools, and
operation procedure.
Prerequisite
Impact on System
Replacing the chassis interrupts services for about 30 minutes, because the equipment has to be
powered off during the replacement.
Precautions
Before replacing the chassis, read Safety Precautions for Using the Equipment.

DANGER
Avoid direct eye exposure to the laser beam launched from the optical interface board or from
inside the fiber, for the laser beam may cause permanent damage to the eyes.
WARNING
l When replacing a processing board, make sure that the board is not connected to any fiber
jumpers or cables.
l The optical interface and the fiber jumper connector must be clean. Seal the jumper connector
in protection cap.

Procedure
Step 1 Make sure that the spare chassis is the same as the chassis to be replaced with respect to the
name, model, and appearance.
Step 2 Query and record the current alarms of the system. When the replacement is complete, you can
Step 3 Record every board's present slot, and the fiber or cable connections of interfaces on the boards.
When the chassis replacement is complete, recover the fiber or cable connections.
Step 4 Ask the on-site maintenance personnel to power off the equipment. For specific operations, see
8.21 Powering Off the Equipment.
Step 5 Remove the power connectors, all fibers and cables connected to the chassis. Then, remove all
boards. For specific operations, see 8.19 Replacing Boards on Site.
Step 6 Remove the mounting ears on the chassis and then take down the chassis. (Skip this step if the
chassis is installed on the desk.)
WARNING
Hold the bottom of the chassis when you remove the mounting ears. Otherwise, the chassis may
drop, causing hurt to human bodies or damage to other equipment.
Step 7 Remove the PGND cable and mounting ears, and install them onto the spare chassis. Install the
spare chassis to the previous position. Then, recover all board, and the fiber or cable connections

according to Step 3. For specific operations, see OptiX RTN 950 Radio Transmission System
IDU Quick Installation Guide.
Step 8 Powering on the equipment. For specific operations, see 8.20 Powering On the Equipment.
Step 9 Verify that the chassis is successfully replaced.

1. Observe the indicators of all boards after the chassis is replaced. If any indicator flashes
abnormally, re-insert boards, or replace the chassis if necessary. For indications on
indicators of boards, see OptiX RTN 950 Radio Transmission System IDU Hardware
Description.
2. Query alarms of the system. Make sure that the original alarms are cleared and no new
alarms are generated.
----End
5.9 Replacing the Pluggable Optical Module

This section provides information on how to replace the pluggable optical module. When the
optical module becomes faulty, it needs to be replaced in time. So, the optical interface can work
normally.
Prerequisite
Context
For the optical modules used on the OptiX RTN 950, see the OptiX RTN 950 Radio Transmission
System IDU Hardware Description.
Impact on System
Replacement of the optical module causes service interruption.

Anti-static bag, T2000
Precautions
CAUTION
Before replacing the pluggable optical module, 8.4 Checking the Optical Power and make sure
that the input optical power is within the normal range to avoid exceeding the overload point
which can damage the optical module.

Procedure
Step 1 A spare part is required. The model and parameters of the spare part must be the same as those
of the optical module to be replaced.
Step 2 Query and record the current alarms on the NE. For details, refer to 8.2 Querying Current
Alarms of a Board.
Step 3 Check the optical power and make sure that the input optical power is within the normal range
to avoid exceeding the overload point which can damage the optical module. For details, refer
to 8.4 Checking the Optical Power.
Step 4 Inform the on-site maintenance engineer and replace the optical module.
NOTE
l Before you remove an optical module, remove the fiber jumpers that connect to it.
l There should be no fiber jumper connecting to the interfaces when you insert an optical module.
Figure 5-1 Inserting and removing the optical module
1
optical port
2 safety latch spare part
Removing optical module: Inserting optical module:

1. Pull out the fiber connectors first. 1. Insert the spare part into port.
2. Pull safety latch to pull out the optical 2. Push the optical module slowly to the bottom
module from the optical port. until hearing a pop voice.
3. Cover the port with cover. 3. Insert the fiber connectors as before.
NOTE
When you insert the spare optical module, avoid excessive force; otherwise, the interface circuit might be
damaged.
Step 5 Check the indicators of the board where the new optical module resides. If the indicator gives
abnormal indication, you need to reinsert the optical module, or replace the optical module again.
For more details on the indicators of boards, see the OptiX RTN 950 Radio Transmission System
IDU Hardware Description..
Step 6 Query board alarms and make sure that the original alarms are cleared and no new alarms are
generated. Check whether the module is online, and whether the input/output optical power and
the performance of the module are normal.
----End
5.10 Replacing the ODU

The method of replacing the ODU with the waveguide interface is different from the method of
replacing the ODU with the coaxial interface.
5.10.1 Replacing the ODU with Waveguide Interface

In the OptiX RTN 950 system, all the ODUs have waveguide interfaces except the ODUs that
operate in the 6 GHz band.
5.10.2 Replacing the ODU with Coaxial Interface
In the OptiX RTN 950 system, only the ODUs that operate in the 6 GHz band uses coaxial
interfaces.
5.10.1 Replacing the ODU with Waveguide Interface

In the OptiX RTN 950 system, all the ODUs have waveguide interfaces except the ODUs that
operate in the 6 GHz band.
Prerequisite
l The positions of the ODU to be replaced and the position of the IF board that is connected
to the ODU must be specified.
l Spare ODU must be available on site, and the spare part must be the same as those to be
replaced in version and type
Precautions
Before you replace an ODU installed on the coupler, power off the ODU to be replaced, but do
not power off or mute the other ODU. Otherwise, the services may be affected. The interface of
the coupler ejects little RF radiation, and thus meets the safety standards for microwave radiation.
Before you replace an ODU, turn off the ODU power switch on the IF board.
Impact on System
Replacing an ODU that is not provided with protection interrupts the service.

l Torque spanner
l T2000
l Silicon
l Waterproof adhesive tape
Procedure
Step 1 Query and record the current alarms of the ODU.
Step 2 Turn off the ODU-PWR switch on the panel of the IF board.
Step 3 Disconnect the IF cable and grounding cable of the ODU.
Step 4 Loosen the four latches of the ODU and disconnect the ODU from the antenna or the hybrid
coupler.
Step 5 Make sure the type of the spare ODU is the same with the type of the ODU to be replaced.
Step 6 Install the ODU.
1. Remove the protective cap on the antenna interface of the ODU. Apply an appropriate
amount of lubricant to the gasket of the feeder on the antenna, coupler, or ODU adapter.

CAUTION
Do not dispense the lubricant on the front panel of the feeder. Otherwise, it may affect the
signal transmission.
2. Keep the direction indicated by the polarization arrow on the ODU consistent with the
polarization direction of the antenna or hybrid coupler. (In the case of vertical polarization,
keep the polarization arrow vertical. In the case of horizontal polarization, keep the
polarization arrow horizontal). Slowly fit the antenna interface of the ODU into the feeder
until the four latches on the ODU engage with the hooks on the antenna.
3. Lock the four latches in a diagonal order.
Step 7 Connect the grounding cable and IF cable to the ODU.
Step 8 Perform waterproof processing for the IF interface of the ODU.
Step 9 Turn on the ODU-PWR switch on the panel of the IF board.
Step 10 When the ODU is working, observe the indicators of the IF board: ODU and LINK.
The indicators ODU and LINK should be on in green.
Step 11 Query the current alarms of the ODU.

----End
5.10.2 Replacing the ODU with Coaxial Interface

In the OptiX RTN 950 system, only the ODUs that operate in the 6 GHz band uses coaxial
interfaces.
Prerequisite
l The position of the ODU to be replaced and the position of the IF board that is connected
to the ODU must be specified.
l Spare ODU must be available on site, and the spare part must be the same as those to be
replaced in version and type
Impact on System
Replacing an ODU that is not provided with protection interrupts the service.
Precautions
Before you replace an ODU installed on the coupler, power off the ODU to be replaced, but do
not power off or mute the other ODU. Otherwise, the services may be affected. The interface of
the coupler ejects little RF radiation, and thus meets the safety standards for microwave radiation.

l Torque spanner
l T2000

l Silicon
Procedure
Step 1 Query and record the current alarms of the ODU.
Step 2 Turn off the ODU-PWR switch on the panel of the IF board.
Step 3 Disconnect the IF cable and grounding cable of the ODU.
Step 4 Remove the old ODU from the pole.
Step 5 Make sure the type of the spare ODU is the same with the type of the ODU to be replaced.
Step 6 Mount the new ODU to the pole.
Step 7 Connect the grounding cable and IF cable to the ODU.
Step 8 Perform waterproof processing for the IF interface of the ODU.
Step 9 Turn on the ODU-PWR switch on the panel of the IF board.
Step 10 When the ODU is working, observe the indicators of the IF board: ODU and LINK.
The indicators ODU and LINK should be on in green.
Step 11 Query the current alarms of the ODU.
----End
5.11 Replacing the IF Cable

This topic describes how to replace an IF cable.
Prerequisite
l The impact of replacing an IF cable must be specified.
l The position of the IF cable to be replaced and the position of the IF board that is connected
to the IF jumper must be specified.
Impact on System
Replacing the IF cable interrupts the services.
Precautions
Before you replace the IF cable, be sure to turn off the ODU-PWR switch on the IF board.

l Ejector lever
l Electro-technical knife
l File

l Installation parts and accessories of the type-N connector

l IF cable
Procedure
Step 1 Query and record the current alarms of the IDU.
Step 2 Turn off the ODU-PWR switch on the front panel of the IF board.
Step 3 Disconnect the IF cable from the IF jumper and from the ODU.
Step 4 Use a multimeter to test whether the IF cable conducts electricity well, and check whether you
need to make a new IF connector or to replace the IF cable with a new one.
If... Then...
You need to make a new IF connector Refer to Quick Installation Guide and make a
new IF connector.
You need to replace the IF cable with a new Replace the IF cable with a new one.
one
Step 5 Connect the IF cable to the IF jumper and to the ODU.

Step 6 Use waterproof adhesive tapes to waterproof the connectors at both ends of the IF cable.
Step 7 Turn on the ODU-PWR switch on the front panel of the IF board.
Step 8 After the ODU starts to work, observe the ODU and LINK indicators on the IF board.
The ODU indicator and LINK indicator should be on in green.
Step 9 Query the current alarms of the IDU.
----End

Maintenance Guide 6 Software Package Upgrade and Package Diffusion
6 Software Package Upgrade and Package

Diffusion
About This Chapter
In the case of software package upgrade and package diffusion, the NE-level software of the
entire network is upgraded, activated and managed in a centralized manner. The software
package upgrade and package diffusion help simplify upgrade and maintenance operations and
improve the efficiency of upgrade and maintenance.
Context
Please download and consult the OptiX RTN 910&950 Upgrade Guide from Huawei Technical
Support website (http://support.huawei.com/). You can directly apply for a user ID and a
password. Log in to the website by entering the user ID and password, and then click
Software to search for the required manual.
6.1 Software Package Upgrade
In the case of the NE software upgrade, you can perform the software package upgrade to
upgrade, activate, and manage the NE software in a centralized manner, and thus to simplify the
operations to upgrade the NE software.
6.2 Software Package Diffusion
The software package diffusion function provides an upgrade and maintenance method that
features higher efficiency and simpler operation for the networkwide upgrade.

6 Software Package Upgrade and Package Diffusion Maintenance Guide
6.1 Software Package Upgrade

In the case of the NE software upgrade, you can perform the software package upgrade to
upgrade, activate, and manage the NE software in a centralized manner, and thus to simplify the
operations to upgrade the NE software.
6.1.1 Definition and Feature
In the case of software package upgrade, the NE-level software is upgraded, activated and
managed in a centralized manner. With the help of the software package upgrade, the process
of upgrading software of an NE is simplified and the availability of upgrade operations is
improved. In addition, the system checks whether the board software versions match, and
updates the unmatched board software versions automatically.
6.1.2 State Model
This section describes the state model of software package upgrade.
6.1.3 Realization Scheme
This section describes the flow for implementing the software package upgrade.
6.1.4 Creating a Package Upgrade Task
This section describes the operations for upgrading the software package in details.

In the case of software package upgrade, the NE-level software is upgraded, activated and
managed in a centralized manner. With the help of the software package upgrade, the process
of upgrading software of an NE is simplified and the availability of upgrade operations is
improved. In addition, the system checks whether the board software versions match, and
updates the unmatched board software versions automatically.
Software package upgrade has the following features:
l The object of software package upgrade is the NE. A uniform interface is available to load
the software.
l The complete software package is stored on the CF card of the CXPR for upgrading the
entire NE. The NE software files are stored on the target directory, and the board software
files are buffered on the CF card. Hence, after a board is newly housed, the board software
is automatically updated. If any board software file is lost, the CXPR restores the file.
l An NE can be automatically managed. The software of a newly housed board is
automatically updated if the software does not match the software in the software package
for the NE.
l Software package upgrade is an incremental upgrade process in which only the new files
are updated.
Software package upgrade applies to the following scenarios:
l Upgrade of NE software
l Replacement of the CXPR board
6.1.2 State Model

This section describes the state model of software package upgrade.
Figure 6-1 shows the state model of software package upgrade.

Figure 6-1 State model of software package upgrade
Start
The NE is in the normal state

before the upgrade
Rollback
Whether copying the No

software succeeds
Yes
The software is copied
Whether dispensing No
the software succeeds
Yes
The software is dispensed
Whether activating No
the software succeeds
Yes
The software is activated
No
Whether committing Handle the trouble
the software succeeds and re-upgrade
Yes
The software is committed and
the NE returns the normal state
End
The state model of software package upgrade is described as follows:
l Before the software package upgrade, the software should be in the normal state.
l After the files are copied, the software state changes from the normal state to the file copy
ending state. In this way, the software package is downloaded. For details on the
implementation, see Step 1 and Step 2 in 6.1.3 Realization Scheme.

l After the software is delivered, the software state changes from the file copy ending state
to the software delivery ending state. In this way, the software package is dispensed. For
details on the implementation, see Step 3 and Step 4 in 6.1.3 Realization Scheme.
l After the software is activated, the software state changes from the software delivery ending
state to the active state. In this way, the NE is activated. For details on the implementation,
see Step 5, Step 6, and Step 7 in 6.1.3 Realization Scheme.
l After the software state changes from the active state to the normal state, the software is
submitted. For details on the implementation, see Step 8 and Step 9 in 6.1.3 Realization
Scheme.
l If any problem occurs before the software package is submitted or after the operation for
each state is completed, perform the rollback operation to revert software to the normal
state. In this way, the software package is rolled back.
NOTE
The rollback operation means that all the board software files on the entire NE are restored to the original
state if any problem occurs. The rollback operation cannot be performed after the software package is
submitted. After the rollback operation is performed, the NE is in the to-be-steady state. In this case, you
cannot load the software package. Instead, you need to wait for some time to perform other operations until
the system becomes steady.
If you want to stop the upgrade of the software when delivery of the software is in process, you can manually
perform rollback.

This section describes the flow for implementing the software package upgrade.
Context
Figure 6-2 shows the flow for upgrading a software package.
Figure 6-2 Flow diagram for software package upgrade

T2000
1
1+1 protection
Software switching
package server
Software system
of the working 3
2
CXPR board
5
6
Software system of the
protection CXPR board
4
1+1 protection
6 8 9 switching
7
单板 8 Software system of the
Board
单板software working CXPR board
system 9

NOTE
Numbers 1~9 in Figure 6-2 indicate the steps in the main flow of upgrading the software package.
Precautions
NOTE
During software package upgrade, services maybe interrupted. The upgrade time depends on the number
of NEs and boards. Normally, upgrading a software package for an NE takes five to ten minutes.
Procedure
Step 1 Start the package upgrade procedure on the T2000.
Step 2 The sub-system of the software on the system control board downloads the new software package
from the software package server.
Step 3 The standby system control board then updates its software package to keep consistent with the
active system control board. (If only one system control board is configured, skip this step.)
Step 4 The active system control board then loads the new software onto the boards that support the
software package upgrade and require updated software.
Step 5 Activate the standby system control board. (If only one system control board is configured, skip
this step.)
Step 6 Switching the active CXPR to the standby CXPR. (If only one system control board is
configured, skip this step.)
Step 7 Activate all the boards.
Step 8 The standby CXPR and other boards are then required to replace the software stored in the
backup area with the software stored in the working area.
NOTE
The working area and backup area refer to the areas where the software package is stored on the board.
Step 9 The software backup is complete and the result is reported.
----End
6.1.4 Creating a Package Upgrade Task

This section describes the operations for upgrading the software package in details.
Prerequisite
l You must be a T2000 user with "NE and network operator" authority or higher and enter
the Main Topology.
l Make sure that the active and standby CXPR boards are of the same type, and NE software
versions are consistent. Otherwise, the database cannot be synchronized and services are
delivered abnormally during the package upgrade. As a result, the package upgrade may
be rolled back. For details, see 8.3 Querying the Board Information Report.
l Make sure that the protection switching can be performed normally for boards configured
with 1+1 protection switching.

l If an NE is configured with only one CXPR board, a cold reset on the CXPR board may
result in an automatic cold reset of all the service boards. As a result, services are
interrupted. Thus, prepare a spare board during the upgrade.
l Before upgrading the software package, perform "Precheck" to check the NE health. Load
the software package if all the items pass the check.
l You would better clear all the alarms of the NE, but the alarms in Table 6-1 must be cleared,
because the alarms may cause service interruption or rollback of the package upgrade. The
alarms that cannot be cleared may affect the services during switching or reset. It is
recommended to request Huawei technical support engineers to confirm the impact.
Table 6-1 Alarms to be cleared before package upgrade

BUS_ERR DBMS_PROTECT_MODE POWER_ABNORMAL
CFCARD_FAILED FAN_FAIL SWDL_AUTOMATCH_IN

H
CFCARD_OFFLINE HARD_BAD SYNC_DISABLE
COMMUN_FAIL NESTATE_INSTALL SYNC_FAIL
DBMS_ERROR - -

l A cold reset on the CXPR not configured with any configuration may result in service
interruption.
l If NEs, configured with protection, are upgraded on the same ring, activating them at the
same time may result in service interruption.
l If NEs, not configured with any protection, are upgraded on the same ring, activating them
at the same time may result in service interruption.

T2000 and software package for the upgrade

Precautions
CAUTION
l During the process of the data backup, software rollback, and software submission, the active/
standby switching for the CXPR boards should not be performed.
l During the package upgrade, do not insert, remove any board, configure any service, and
reset any board by using commands. Otherwise, the loading fails and rollback occurs.
l During the package upgrade, do not modify any configuration. Otherwise, rollback may occur
or the modified configuration is lost.
l When the board loaded with software is in service, the board automatically matches the
loaded software. In this case, if you query the software version, the query result may show
that the software is of the original version. The version information is updated only after the
board finishes writing the flash and the resetting.
NOTE
In the following cases, perform other operations five minutes later.

l The active board is restarted after a reset.
l The active and standby boards are switched.
l Matched loading is performed for the active and standby boards, and the loading operation is complete.
l The rollback is complete.
l The software is submitted.
Procedure
Step 1 Select Data Center > Device Operation from the main menu to open the Device Operation
tab. The device types are displayed in the device tree on the left.
Step 2 Select the device type to be operated in the device tree area and right-click in the Device View
tab. Select New Task > Package Upgrade Task. The Task Management tab is displayed
automatically.

Step 3 Enter the task name in the displayed Create Task [Package Upgrade] dialog box, and select
device type, device version and devices to be operated separately from the Device Type drop-
down list, the Device Version drop-down list and the device tree area. The information of
selected devices is displayed in the Device Table area. This step is performed to confirm the
devices to be operated.

NOTE
l Task name can only contain alpha numeric characters and underscore line. It can have a maximum 20
characters.
l Click , and the selected device type, device version, device names and IP addresses will be
displayed in the device tree area.
l Click , and the physical location, device name and IP address of the selected device will be
l Click to import the device IP address from the selected location. In the Import dialog box, select
the text file that contains the device IP address to be imported, and click Import. In the Importing
dialog box, click Details to view the device name and the operation result of the device IP address to
be imported. The device and its imported IP address will be displayed in the device tree area.
l Select the device to be exported in the device tree area. Click to export the device IP address. In
the Export dialog, select the location to export the device IP address and click Export. The selected
device IP address will be exported successfully at the selected location. The Operation Result dialog
appears, click OK to close the Operation Result dialog.
l Click to delete the selected device(s) from the Device Table area.
Step 4 Click Next. After the displayed Validating upgrade mode of selected devices process bar
disappears automatically, the Operation Configuration [Package Upgrade] dialog box is
displayed. This step is performed to select and configure the operations of the package upgrade
task.
1. Select the target version from the Target Version drop-down list to load the package file
to the selected target version.
2. Optional: Select the check box Start Time, and click to select the date and time for
the task to be executed. Task operation is performed for the selected operations at the
scheduled start time.

3. Select the check box PreCheck, and click the link Configure PreCheck Items in the
Select Operation(s) area. The Configure Pre-Check Operation dialog box is displayed.
Select the Check item and click OK to finish the configuration to PreCheck operation.
l If the Alarm check box is selected, T2000 checks the device alarm status.
l If the Health check box is selected, T2000 checks if the device is up and running or
not.
4. Select the check box Backup, and click the link Configure Backup Information. The
Configure Backup Operation dialog box is displayed. Select the appropriate content type
in the Content Type drop-down list and click OK to finish the configuration to Backup
operation.
NOTE
If you select Pause Before Current Operation check box, T2000 will pause before performing this
operation until you start it manually.
5. Select the check box Load Software, and click the link Configure Package. Select the
software package file(s) to be loaded and click OK in the displayed Select Package File
(s) dialog box.
6. Select the check box Dispense and the package file(s) can be loaded to different boards on
a device at the same time. No configuration is required for the dispense operation.

7. Select the check box Activate, and Click the link Configure Activation. Select and
configure the parameters in the displayed Configure Activation dialog box and then click
OK.
NOTE
The check box Pause Before Current Operation is selected by default, but the selection could be
cancelled.
NOTE
l If you select the check box Activation time, click to set the activate date and time, at which
the Group1 of boards will be activated automatically.
l If the quantity of devices to be operated is more than 1, you can click to display a Create
New Group dialog box. Thus, device(s) can be moved to a new group.
l If the quantity of groups is more than 1, you can click to delete the selected group. The
device(s) in the deleted group will move to the next group automatically.
l The device(s) in the same group can be activated at the same time. But the device(s) in different
groups will be activated in order.
8. Select the check box Commit to clear the former software of device(s) and commit the
newly loaded software to device(s). No configuration is required for the commit operation.
9. Select the check box PostCheck, and click the link Configure PostCheck Items. The
Configure Post-Check Operation dialog box is displayed. Select the Check item and
click OK to finish the configuration to PostCheck operation.
Step 5 Click Next to display the Confirmation [Package Upgrade] dialog box. Make sure the
configuration of every operation is correct.

NOTE
You can click Previous to re-configure every operation.
Step 6 Click OK. The task will be added into Task Management tab automatically.
Step 7 In the Task Management tab, right-click the newly created task and click Start Task. Click
Yes in the displayed Task Start Confirmation dialog box and the process of package upgrade
will be displayed in the Operation Status area.

NOTE
l The task will be moved to Running automatically since started and will be moved to Completed
automatically when the task is finished.
l Right--click the task and click Delete Task to delete the task.
l If you select Pause Before Current Operation check box, T2000 will pause before performing this
operation until you perform step 7 to start it manually.
l When the package upgrade task is finished or any operation fails, you can right-click the task and select
View Check Reports to check the details.
----End
Related Information
The problems that commonly occur during the package loading and their solutions are as follows:
l The submission of the software fails and the SWDL_COMMIT_FAIL alarm is reported.
To solve this problem, handle SWDL_COMMIT_FAIL alarm, wait a while after the NE
is activated and then submit the software.
l After rollback, the boards cannot start normally. To solve this problem, perform the
following operations:
– Check whether the SWDL_ROLLBACK_FAIL alarm is reported and handle
SWDL_ROLLBACK_FAIL alarm.
– Check whether the SWDL_PKG_NOBDSOFT alarm is reported and handle
SWDL_PKG_NOBDSOFT alarm.
6.2 Software Package Diffusion

The software package diffusion function provides an upgrade and maintenance method that
features higher efficiency and simpler operation for the networkwide upgrade.
In the case of package diffusion, the software package is diffused among NEs which then try to
load the software package at the same time. In this way, the efficiency in software package
upgrade is highly increased, and less manual interference and fewer operations are reduced
during this process.
6.2.2 State Model
This section describes the running state model for package diffusion inside an NE.
Certain rules should be observed when using the software package diffusion technology.
6.2.4 Creating a Package Diffusion Upgrade Task
This section describes how to upgrade the software package by means of diffusion.

In the case of package diffusion, the software package is diffused among NEs which then try to
load the software package at the same time. In this way, the efficiency in software package
upgrade is highly increased, and less manual interference and fewer operations are reduced
during this process.

The software package is diffused layer by layer. In this way, several NEs can load the software
package simultaneously to balance the network load and to use the network bandwidth equally.
This is the main feature of the package diffusion.
The package diffusion is applicable to all networking environment.
6.2.2 State Model

This section describes the running state model for package diffusion inside an NE.
As a method of diffusing the software package in a network, the package diffusion is responsible
only for loading and upgrading the software package between NEs in the network.
6.1.2 State Model shows the state model of software package upgrade.
State Model of Software Package Diffusion

Figure 6-3 shows the state model for software package diffusion inside an NE.

Figure 6-3 State model for package diffusion

Start
NE is in the normal status
Setting No
information Suspension state
succeeds?
Yes
Initialization state
Receives No
software-ready
information?
Yes
Pending state
Are files and No

data prepared on the
upstream node?
Yes
Transmission state
Receiving No
software
succeeds?
Yes
Completion state
Downstream Yes Data is diffused to the

node exists? downstream nodes
No
All the NEs are in
Package upgrade
completion state
End
The state model for package diffusion is described as follows.

l Normal state. No diffusion information is set on the node, or the diffusion is completed.
l Initialization state. Diffusion information is successfully set on the NE. This state is
essential for later diffusion.
NOTE
l The source node receives the information, indicating that the files are ready, from the application
module.
l A node rather than the source node receives the information, indicating that the files are ready,
from the upstream node.
l Pending state. The local node is waiting for file data from the upstream node.
l Transmission state. The local node is receiving file data from the upstream node.
l Completion state. In this state, the local node waits until the diffusion on the downstream
node is completed.
l Suspension state. In this state, the local node informs the upstream and downstream nodes
of updating diffusion information.

Certain rules should be observed when using the software package diffusion technology.
Precautions
Observe the following rules when using the software package diffusion technology.
l The diffusion network should not contain any NE of the type that is not supported by the
software package for diffusion.
l On all NEs involved in the diffusion, the FLASH on the CXPR board should have sufficient
space for the software package, and the file system in the memory can hold the file of the
maximum size in the software package.
l All NEs involved in the package diffusion must be in the same diffusion network and the
communication between every two NEs must be available.
l In one diffusion network, only one software package can be diffused at a time.
l Only one source node is present in a diffusion network. Except the source node, each node
should have a maximum of one upstream node. One upstream node should not repeat any
downstream node. Downstream nodes should not repeat each other.
l In a diffusion network, the quantity of nodes allowed is 100.
6.2.4 Creating a Package Diffusion Upgrade Task

This section describes how to upgrade the software package by means of diffusion.
Prerequisite
l You must be a T2000 user with "NE and network operator" authority or higher and enter
the Main Topology.
l The target NEs and the gateway NE for them must be created and logged into. The T2000
server can normally communicate with NEs.
l At least two target NEs supporting the package diffusion must be present. NEs in the same
diffusion group to be created must be of the same type and no diffusion group is created.

l Make sure that the active and standby CXPR boards are of the same type, and NE software
versions are consistent. Otherwise, the database cannot be synchronized and services are
delivered abnormally during the package upgrade. As a result, the package upgrade may
be rolled back. For details, see 8.3 Querying the Board Information Report.
l Make sure that the protection switching can be performed normally for boards configured
with 1+1 protection switching.
l If an NE is configured with only one CXPR board, a cold reset on the CXPR board may
result in an automatic cold reset of all the service boards. As a result, services are
interrupted. Thus, prepare a spare board during the upgrade.
l Before upgrading the software package, perform "Precheck" to check the NE health. Load
the software package if all the items pass the check.
l You would better clear all the alarms of the NE, but the alarms in Table 6-2 must be cleared,
because the alarms may cause service interruption or rollback of the package upgrade. The
alarms that cannot be cleared may affect the services during switching or reset. It is
recommended to request Huawei technical support engineers to confirm the impact.
Table 6-2 Alarms to be cleared before package diffusion upgrade

BUS_ERR DBMS_PROTECT_MODE POWER_ABNORMAL
CFCARD_FAILED FAN_FAIL SWDL_AUTOMATCH_IN

H
CFCARD_OFFLINE HARD_BAD SYNC_DISABLE
COMMUN_FAIL NESTATE_INSTALL SYNC_FAIL
DBMS_ERROR - -

l A cold reset on the CXPR not configured with any configuration may result in service
interruption.
l If NEs, configured with protection, are upgraded on the same ring, activating them at the
same time may result in service interruption.
l If NEs, not configured with any protection, are upgraded on the same ring, activating them
at the same time may result in service interruption.

T2000 and software package for the upgrade

Precautions
CAUTION
l When performing the package diffusion upgrade operation, the minimum number of NEs is
2. If there is only one NE, refer to 6.1.4 Creating a Package Upgrade Task.
l During the process of the data backup, software rollback, and software submission, the active/
standby switching for the CXPR boards should not be performed.
l During the package diffusion upgrade, do not insert, remove any board, configure any service,
and reset any board by using commands. Otherwise, the loading fails and rollback occurs.
l During the package diffusion upgrade, do not modify any configuration. Otherwise, rollback
may occur or the modified configuration is lost.
l When the board loaded with software is in service, the board automatically matches the
loaded software. In this case, if you query the software version, the query result may show
that the software is of the original version. The version information is updated only after the
board finishes writing the flash and the resetting.
NOTE
In the following cases, perform other operations five minutes later.

l The working board restarts after resetting.
l The active and standby boards are switched.
l Matched loading is performed for the active and standby boards, and the loading operation is complete.
l The rollback is completed.
l The software is submitted.
Procedure
Step 1 Select Data Center > Device Operation from the main menu to open the Device Operation
tab. The device types are displayed in the device tree on the left.
Step 2 Select the device type to be operated in the device tree area and right-click in the Device View
tab. Select New Task > Package Diffusion Upgrade Task. The Task Management tab is
displayed automatically.

Step 3 Enter the task name and select the activation level in the displayed Create Task [Package
Diffusion Upgrade] dialog box. Select device type, device version and devices to be operated
separately from the Device Type drop-down list, the Device Version drop-down list and the
device tree area. The information of selected devices is displayed in the Device Table area. This
step is performed to confirm the devices to be operated.

NOTE
l Task name can only contain alpha numeric characters and underscore line. It can have a maximum 20
characters.
l You can select Device or Board from the Activation Level drop-down list. If Board is selected, you
can get default activation groups
l Click , and the selected device type, device version, device names and IP addresses will be
l Click , and the physical location, device name and IP address of the selected device will be
l Click to import the device IP address from the selected location. In the Import dialog box, select
the text file that contains the device IP address to be imported, and click Import. In the Importing
dialog box, click Details to view the device name and the operation result of the device IP address to
be imported. The device and its imported IP address will be displayed in the device tree area.
l Select the device to be exported in the device tree area. Click to export the device IP address. In
the Export dialog, select the location to export the device IP address and click Export. The selected
device IP address will be exported successfully at the selected location. The Operation Result dialog
appears, click OK to close the Operation Result dialog.
l Click to delete the selected device(s) from the Device Table area.
Step 4 Click Next. After the displayed Validating upgrade mode of selected devices process bar
disappears automatically, the Operation Configuration [Package Diffusion Upgrade] dialog
box is displayed. This step is performed to select and configure the operations of the package
diffusion upgrade task.
1. Optional: Select the target version from the Target Version drop-down list to load the
package file to the selected target version.

2. Optional: Select the check box Start Time, and click to select the date and time for
the task to be executed. Task operation is performed for the selected operations at the
scheduled start time.
3. Select the check box PreCheck, and click the link Configure PreCheck Items in the
Select Operation(s) area. The Configure Pre-Check Operation dialog box is displayed.
Select the Check item and click OK to finish the configuration to PreCheck operation.
l If the Alarm check box is selected, T2000 checks the device alarm status.
l If the Health check box is selected, T2000 checks if the device is up and running or
not.
4. Select the check box Backup, and click the link Configure Backup Information. The
Configure Backup Operation dialog box is displayed. Select the appropriate content type
in the Content Type drop-down list and click OK to finish the configuration to Backup
operation.
NOTE
If you select Pause Before Current Operation check box, T2000 will pause before performing this
operation until you start it manually.
5. Select the check box Load Software, and click the link Configure Package. Select the
software package file(s) to be loaded and click OK in the displayed Select Package File
(s) dialog box.

6. Select the check box Dispense and the package file(s) can be loaded to different boards on
a device at the same time. No configuration is required for the dispense operation.
NOTE
The dispense operation will be started only after the T2000 detected the software package has already
been loaded to all the NEs to avoid the anomalies occurring in the expanding process.
7. Select the check box Activate, and click the link Configure Activation. Select and
configure the parameters in the displayed Configure Activation dialog box and then click
OK.
NOTE
The check box Pause Before Current Operation is selected by default, but the selection could be
cancelled.
l If you select Device in the Activation Level drop-down list in Step 3, the Configure
Activation dialog box will be as below.
NOTE
l If you select the check box Activation time, click to set the activate date and time, at
which the Group1 of boards will be activated automatically.
l Click to display a Create New Group dialog box. Thus, device(s) can be moved to a
new group.
l The device(s) in the same group can be activated at the same time. But the device(s) in
different groups will be activated in order.
l If you select Board in the Activation Level drop-down list in Step 3, the Configure
Activation dialog box will be as below.

NOTE
l If you select the check box Activation time, click to set the activate date and time, at
which the Group1 of boards will be activated automatically.
l Select the check box Select Files, and click . You can import the text file which contains
board information that can be used for grouping the board(s) in the displayed Select
Software dialog box.
l Click Get Default Activation Group, and click Close in the displayed process bar.
l Click to display a Create New Group dialog box. Thus, device(s) can be moved to a
new group.
l The device(s) in the same group can be activated at the same time. But the device(s) in
different groups will be activated in order.
l The default group cannot be deleted.
8. Select the check box Commit to clear the former software of device(s) and commit the
newly loaded software to device(s). No configuration is required for the commit operation.
9. Select the check box PostCheck, and click the link Configure PostCheck Items. The
Configure Post-Check Operation dialog box is displayed. Select the Check item and
click OK to finish the configuration to PostCheck operation.
Step 5 Click Next to display the Confirmation [Package Diffusion Upgrade] dialog box. Make sure
the configuration of every operation is correct.

NOTE
You can click Previous to re-configure every operation.
Step 6 Click OK. The task will be added into Task Management tab automatically.
Step 7 In the Task Management tab, right click the newly created task and click Start Task. Click
Yes in the displayed Task Start Confirmation dialog box and the process of package upgrade
will be displayed in the Operation Status area.

NOTE
l The task will be moved to Running automatically since started and will be moved to Completed
automatically when the task is finished.
l Right-click the task and click Delete Task to delete the task.
l If you select Pause Before Current Operation check box, T2000 will pause before performing this
operation until you perform step 7 to start it manually.
l When the package upgrade task is finished or any operation fails, you can right-click the task and select
View Check Reports to check the details.
----End
Related Information
The problems that commonly occur during the package loading and their solutions are as follows:
l The submission of the software fails and the SWDL_COMMIT_FAIL alarm is reported.
To solve this problem, handle SWDL_COMMIT_FAIL alarm, wait a while after the NE
is activated and then submit the software.
l After rollback, the boards cannot start normally. To solve this problem, perform the
following operations:
– Check whether the SWDL_ROLLBACK_FAIL alarm is reported and handle
SWDL_ROLLBACK_FAIL alarm.
– Check whether the SWDL_PKG_NOBDSOFT alarm is reported and handle
SWDL_PKG_NOBDSOFT alarm.

Maintenance Guide 7 Remote Maintenance Guide
7 Remote Maintenance Guide
About This Chapter
Remote maintenance guide the user how to enabling the remote maintenance user and
establishing the remote maintenance.
7.1 Introduce
Summarizes how to perform the remote maitenance.
7.2 Enabling a Remote Maintenance User
A remote maintenance user is a network management user who logs in to the T2000 server on
a remote maintenance client. By default, the remote maintenance user is "Disabled". Hence,
enable the remote maintenance user before starting the remote maintenance.
7.3 Establishing Remote Maintenance
This section describes how the T2000 server establishes remote maintenance connection with
the remote terminal.

7 Remote Maintenance Guide Maintenance Guide
7.1 Introduce
Summarizes how to perform the remote maitenance.
A remote computer (remote end) can connect to the T2000 server on site (local end) through the
public switched telephone network (PSTN) or the Internet. The remote computer then can
perform in-time maintenance to the equipment.
Figure 7-1 shows a connection for remote maintenance. A modem should be installed at each
of the remote maintenance terminal and the T2000 server. The dial-up connection program
should be set. The hardware and software should be configured before the T2000 is installed.
Connection for remote maintenance
Figure 7-1 Connection for remote maintenance
Serial port
PSTN/
Internet
Remote Modem Modem Serial port
maintenance
terminal T2000
server
Optical
network
When you use the remote maintenance function to maintain the equipment, the T2000 should
perform the following operations in cooperation with the remote end.
l Enabling an remote maintenance user
l Establishing remote maintenance
7.2 Enabling a Remote Maintenance User

A remote maintenance user is a network management user who logs in to the T2000 server on
a remote maintenance client. By default, the remote maintenance user is "Disabled". Hence,
enable the remote maintenance user before starting the remote maintenance.

Prerequisite
The operator must have the "NM administrator" authority or higher.
Procedure
Step 1 Choose System > Remote Maintenance User Management from the Main Menu. The Remote
Maintenance User Management dialog box is displayed.
Step 2 In the dialog box, set the Enable/Disable parameter to Enable. Set other attributes of the remote
maintenance user.
Step 3 Click Apply and click Close in the displayed Operation Result dialog box.
Step 4 Click OK and click Close in the displayed Operation Result dialog box to finish the task.
----End
7.3 Establishing Remote Maintenance

This section describes how the T2000 server establishes remote maintenance connection with
the remote terminal.

7 Remote Maintenance Guide Maintenance Guide
Prerequisite
l The communication connection between the remote maintenance terminal and the T2000
server must have been configured.
l The remote maintenance user must have been enabled.
l The shortcut icon of the dial-up connection has already been created on the desktop, for
example, Remote Maintenance.
l The dial-up telephone number, user name and password of the T2000 server must be known
to maintenance personnel at the remote maintenance terminal.
Context
CAUTION
To ensure network security, set the Enable/Disable parameter of the remote maintenance user
to Disable after the remote maintenance.
Procedure
Step 1 On the T2000 server, query the status of the remote maintenance connection. If the remote
maintenance connection is established, go to Step 5. If not established, go to Step 2. The query
methods are listed as follows.
l If the Windows operating system is installed, right-click Network Neighbor and click the
Attribute tab to query the status of the remote maintenance connection.
l If the Sun workstation is installed, open a terminal window and run the ifconfig -a command
to query the status of the remote maintenance connection.
Step 2 Double-click the shortcut icon of the dial-up connection on the desktop, for example, Remote
Maintenance, to dial up.
Step 3 Enter the user name(ppp_user) and password in the displayed dialog box.
Step 4 Enter the user name and password. Press the Enter key and click the D button in the lower right
corner to establish the connection.
NOTE
After you enter the password and press the Enter key, a line of junk characters are displayed. This is normal.
Step 5 Query the IP address for dial-up access to network.

l If the Windows operating system is installed, choose Start > All Programs >
Attachment > Command Prompt to display the Command Prompt window. Enter ipconfig
-a in the dialog box and query the dynamic IP address for dial-up access to network.
l If the Sun workstation is installed, display a terminal window and run the ipconfig -a
command to query dynamic IP address for dial-up access to network.
Step 6 Inform the maintenance personnel at the remote end of the queried IP address.

Step 7 The remote maintenance user dials up the T2000 server and logs in to the T2000 client. After
the login succeeds, you can perform the remote maintenance.
----End

Maintenance Guide 8 Task Set
8 Task Set
About This Chapter
Common operation tasks include the operations performed by using the T2000 and the operations
performed on site. Learning how to perform these operations helps quickly locate and rectify
faults during the equipment maintenance.
8.1 Querying T2000 Operation Logs
To detect the illegal operations, you should check operation logs on the T2000 periodically.
8.2 Querying Current Alarms of a Board
Periodically querying alarms helps detecting and rectifying a fault in time. This section describes
the prerequisites and procedures for querying the current alarms of a board by using the T2000.
8.3 Querying the Board Information Report
This section describes how to query the board information report. The board information
includes the board type, status, software version and so on.
8.4 Checking the Optical Power
When the receive or transmitted optical power of an optical interface is abnormal, bit errors
maybe generated and the optical components may be damaged. This section describes the
prerequisites and procedures for querying the board optical power by using the T2000.
8.5 Performing the LSP Ping Test
You can perform the LSP ping test to check the connectivity of the tunnel. This section describes
the prerequisites and procedures for performing the LSP ping test by using the T2000.
8.6 Performing the LSP Traceroute Test
You can perform the LSP Traceroute test to locate a fault. This section describes the prerequisites
and procedures for performing the LSP Traceroute test by using the T2000.
8.7 Checking Data Consistency Between an NE and the T2000
By performing the data consistency check between an NE and the T2000, you can compare the
data configuration on the T2000 with the configuration data on the NE and then obtain a report
on the result of the consistency check. Perform the consistency check for all the NEs monthly
so that the T2000 can manage the NEs properly.
8.8 Uploading the NE Configuration Data

8 Task Set Maintenance Guide
The NE configuration data on the T2000 may be inconsistent with that on the NE. During
maintenance, you need to keep the data consistent on the T2000 and the NE. If the network runs
normally and the data on the NE is correct, upload the data from the NE to the T2000.
8.9 Configuring Port Loopback
The port loopback configuration is usually changed for locating equipment faults. By changing
the loopback mode, you can locate the fault.
8.10 Performing the MPLS Tunnel Protection Switching
You can perform the MPLS tunnel protection switching on the T2000 to realize the switching
of services between different MPLS tunnels.
8.11 Performing the 1+1 Protection Switching for CXPR boards
You can perform the 1+1 protection switching for CXPR boards on the T2000 to realize the
switching of status between two CXPR boards.
8.12 Performing IF 1+1 Protection Switch
The IF 1+1 protection switching is an important maintenance operation.
8.13 Querying an IF 1+1 Protection Group
You can know the current status of an 1+1 protection group by querying the IF 1+1 protection
group.
8.14 Querying the Working State of AM
You can know the change of the AM mode by querying the working state of AM.
8.15 Setting the State of an ODU Transmitter
the state of an ODU transmitter can be mute or unmute. When the ODU transmitter is in the
unmute state, the ODU transmits and receives microwave signals normally. When the ODU
transmitter is in the mute state, the ODU transmitter does not work, but the ODU can receives
microwave signals.
8.16 Resetting Boards
In the case of resetting boards, the board software is reset. The board reset is classified into warm
reset and cold reset. The warm reset does not affect running services. The cold reset, however,
usually affects the running services.
8.17 Testing the Transmitted Optical Power of the Optical Interface
If the mean transmitted optical power is excessively high or low, bit errors occur on the
equipment. The bit errors affect services and even damage components on the equipment. This
section describes how to test the transmitted optical power at optical interfaces of the equipment
on site to ensure that the mean transmitted optical power of each optical interface is normal.
8.18 Testing the Receive Optical Power of the Optical Interface
If the receive optical power is excessively high or low, bit errors occur on the equipment. The
bit errors affect the services or even damage components on the equipment. This section
describes how to test the receive optical power at optical interfaces of the equipment on site to
ensure that the receive optical power of each optical interface is normal.
8.19 Replacing Boards on Site
When replacing a board, remove and insert it as required; make sure that the mapping relations
between the interfaces and cables are not changed before and after the replacement; observe
indicators to determine the running state of the board.
8.20 Powering On the Equipment
This section describes how to connect the power supply to the equipment to ensure that the
equipment can be powered on normally.
8.21 Powering Off the Equipment

This section describes how to power off the equipment.

8.22 Querying and Setting the Working Mode of Ethernet Interface
This section describes how to query and set the working mode of Ethernet interface.
8.23 Querying Protection Configuration
This section describes the basic method for querying the protection scheme that is configured
in the equipment when a fault or service interruption occurs.
8.24 Inspecting and Cleaning the Optical Fiber Connectors
Cleaning optical components is to remove dust or other dirt to avoid performance degradation
of optical transmission systems. Inspecting and cleaning fiber connectors used in fiber optic
connections are introduced here.

8.1 Querying T2000 Operation Logs

To detect the illegal operations, you should check operation logs on the T2000 periodically.
Prerequisite
l The T2000 user must log in to the T2000 and enter the Main Topology.
l You must be a T2000 user with "NM Administrator" authority or higher.
Procedure
Step 1 Choose System > Browse NMS Log from the Main Menu. The Browse Log tab is displayed.
Step 2 Click Filter. Configure the appropriate parameters in the displayed Filter dialog box and click
OK.
Step 3 Optional: Click Refresh to check the logs.
Step 4 Make sure that no illegal operations such as abnormal or malicious operations and illegal logins
are recorded in the logs.
CAUTION
If there are illegal operations recorded in the logs, you need to set the operation authority and
management authority again. For details, see "Security Management" of the OptiX iManager
T2000 Operation Guide for RTN NE Management.
----End
8.2 Querying Current Alarms of a Board

Periodically querying alarms helps detecting and rectifying a fault in time. This section describes
the prerequisites and procedures for querying the current alarms of a board by using the T2000.
Prerequisite
l You must be a T2000 user with "NE and Network Monitor" authority or higher.
Procedure
Step 1 Right-click the target NE icon in the Main Topology of the T2000. Choose Fault > Browse
Current Alarms to display the Browse Current Alarms window.

Step 2 Click Synchronize. The Operation Progress dialog box is displayed indicating the
synchronization progress.
NOTE
To stop the query, you can click Cancel.
Step 3 After the alarm query is complete, the Operation Result dialog box is displayed. Click Close.
Step 4 Record and confirm new alarms of the NE.

----End
8.3 Querying the Board Information Report

This section describes how to query the board information report. The board information
includes the board type, status, software version and so on.
Prerequisite
l The board must be created.
Procedure
Step 1 Choose Report > Board Information Report from the Main Menu.
Step 2 In the Object Tree, select an NE or a board on the NE and click .

Step 3 Click Query and the Query progress bar display.

NOTE
You can click Cancel and click Yes in the displayed Confirm dialog box to cancel the querying.
Step 4 Click the Board Information Report tab and view the board information.
NOTE
l Commonly, the software version of each board should be of the same version.
l You can double-click the Remarks field and enter the information. Then, click Apply to save the
information.
Step 5 Optional: Click Print or Save As to export the report.
----End
8.4 Checking the Optical Power

When the receive or transmitted optical power of an optical interface is abnormal, bit errors
maybe generated and the optical components may be damaged. This section describes the
prerequisites and procedures for querying the board optical power by using the T2000.
Prerequisite
l The performance monitoring function must be enabled and the parameters for this function
must be set.
NOTE
For details on how to enable the performance monitoring function and how to set the parameters for
this function, see the relevant chapter about the performance management in the OptiX iManager
T2000 Operation Guide for RTN NE Management.

T2000
Checking Criteria
For the technical specifications of the mean transmitted optical power and receive optical power
of different optical interfaces, refer to Technical Specifications of Boards in the OptiX RTN
950 Radio Transmission System Product Description manual.
Procedure
Step 1 Select and right-click the target NE. Choose NE Explorer.
Step 2 Select the board installed with optical interface from the left-hand side of the NE Explorer
window. Then, choose Performance > Current Performance from the Function Tree.
Step 3 In Performance Event Type, select Transmitted Optical Power and Receive Optical
Power. Then, click Query.

Step 4 Click OK in the displayed Operation Result dialog box to complete the querying operation.
NOTE
If the query is stopped or fails, the Operation Result dialog box, indicating that the operation is partially
successful, is displayed. Then, you can perform the following operations:
l Click Detail to check detailed information about the operation object, the operation result, and the
cause.
l Click Save As to save the detailed information as a file.
Step 5 Check whether the performance values of Transmitted Optical Power and Receive Optical
Power are within the normal range.
Step 6 If the performance values of the laser are beyond the specified range, handle the situation
according to 3.1 General Fault Handling Flow.
----End
8.5 Performing the LSP Ping Test

You can perform the LSP ping test to check the connectivity of the tunnel. This section describes
the prerequisites and procedures for performing the LSP ping test by using the T2000.
Prerequisite
l An MPLS tunnel must be created.
Procedure
Step 2 Click NEs from the left side of the NE Explorer window. Choose Configuration > MPLS
Management > Unicast Tunnel Management from the Function Tree.
Step 3 Click the OAM Parameters tab, and then select a tunnel.
NOTE
When the Node Type of the tunnel is Ingress, you can perform the Ping test.
Step 4 Click OAM Operation, and then select Ping Test.

Step 5 In the displayed Ping Test dialog box, configure the corresponding parameters in the right-hand
Value pane.

Step 6 Click Start Test to start the test.

NOTE
To stop the test, you can click Stop Test.
Step 7 Determine the connectivity of the tunnel according to the test result displayed in the lower Test
Result pane.
NOTE
If the contents of prerequisite are not conformed, the Operation Result dialog box will be displayed to
show the hint information.
----End
8.6 Performing the LSP Traceroute Test

You can perform the LSP Traceroute test to locate a fault. This section describes the prerequisites
and procedures for performing the LSP Traceroute test by using the T2000.

Prerequisite
l An MPLS tunnel must be created.
Procedure
Step 2 Click NEs from the left side of the NE Explorer window. Choose Configuration > MPLS
Management > Unicast Tunnel Management from the Function Tree.
Step 3 Click the OAM Parameters tab, and then select a tunnel.
NOTE
When the Node Type of the tunnel is Ingress, you can perform the traceroute test.
Step 4 Click OAM Operation, and then select Traceroute Test.

Step 5 In the displayed Traceroute Test dialog box, configure the corresponding parameters in the
right-hand Value pane.

Step 6 Click Start Test to start the test.

NOTE
To stop the test, you can click Stop Test.
Step 7 Determine whether the tunnel is faulty according to the test result displayed in the lower Test
Result pane.
NOTE
If the contents of prerequisite are not conformed, the Operation Result dialog box will be displayed to
show the hint information.
----End
8.7 Checking Data Consistency Between an NE and the

T2000
By performing the data consistency check between an NE and the T2000, you can compare the
data configuration on the T2000 with the configuration data on the NE and then obtain a report

on the result of the consistency check. Perform the consistency check for all the NEs monthly
so that the T2000 can manage the NEs properly.
Prerequisite
Reference Standard
The operation result indicates that the data configuration on the NE is consistent with the data
configuration on the T2000.
Precautions
Checking data consistency between an NE and the T2000 does not affect the data configuration
on the NE and the T2000.
Procedure
Step 2 Select the target NE from the left-hand Object Tree, and then click .
Step 3 Select one or more NEs from the Configuration Data Management List.
Step 4 Click Consistency Check, or right-click the NE or NEs to choose Consistency Check from the
shortcut menu.
Step 5 Click OK in the displayed Confirm dialog box. Then, a progress bar is displayed indicating the
operation progress.
NOTE
To stop the consistency check, you can click Cancel.
Step 6 The Operation Result dialog box, indicating that the operation is successful, is displayed. Click
Close.
NOTE
If the uploading is stopped or the operation fails, the Operation Result dialog box, indicating that the
operation is partially successful, is displayed. Then, you can perform the following operations:
cause.
----End
8.8 Uploading the NE Configuration Data

The NE configuration data on the T2000 may be inconsistent with that on the NE. During
maintenance, you need to keep the data consistent on the T2000 and the NE. If the network runs
normally and the data on the NE is correct, upload the data from the NE to the T2000.

Prerequisite
Precautions
After uploading the data, you need to check whether the data is consistent. For details, see 8.7
Checking Data Consistency Between an NE and the T2000.
Procedure
Step 2 Select the target NE from the left-hand Object Tree, and then click .
Step 3 Select one or more NEs from the Configuration Data Management List.
Step 4 Click Upload, or right-click the NE or NEs to choose Upload from the shortcut menu.
Step 5 Click OK in the displayed Confirm dialog box to start the uploading. Then, a progress bar is
displayed in the Upload window to indicate the operation progress.
NOTE
To stop the uploading, you can click Cancel.
Step 6 The Operation Result dialog box, indicating that the operation is successful, is displayed. Click
Close.
NOTE
If the uploading is stopped or the operation fails, the Operation Result dialog box, indicating that the
operation is partially successful, is displayed. Then, you can perform the following operations:
cause.
----End
8.9 Configuring Port Loopback

The port loopback configuration is usually changed for locating equipment faults. By changing
the loopback mode, you can locate the fault.
Prerequisite

Context
Loopback Description
Non-Loopback Indicates the normal status. When the equipment is operating normally,
loopback is not required.
Inloop At the local equipment, the outgoing services of an port are looped back
and input to this port.
Outloop At the local equipment, the incoming services of an port are looped back
and output to this port.
Procedure
Step 2 Select the target port in the NE Explorer.
Interface Configuration Entry
PDH 1. Choose Configuration > Interface Management > PDH Interface from
interface the Function Tree.
2. In the Advanced Attributes tab, select the target port.
3. Double-click the relevant Loopback Mode parameter. You can choose
Non-Loopback, Inloop or Outloop from the drop-down list.
Ethernet 1. Choose Configuration > Interface Management > Ethernet Interface

interface from the Function Tree.
3. Double-click the relevant MAC Loopback parameter. You can choose
4. Double-click the relevant PHY Loopback parameter. You can choose
Non-Loopback or Inloop from the drop-down list.
Microwave 1. Choose Configuration > Interface Management > Microwave

interface Interface from the Function Tree.
3. Double-click the relevant IF Port Loopback parameter. You can choose
4. Double-click the relevant Composite Port Loopback parameter. You can
choose Non-Loopback, Inloop or Outloop from the drop-down list.
ATM IMA 1. Choose Configuration > Interface Management > ATM IMA
port Management from the Function Tree.
2. In the ATM Interface Management tab, select the target port.
3. Double-click the relevant Loopback parameter. You can choose Non-
Loopback, Inloop or Outloop from the drop-down list.

Step 3 Select the appropriate loopback mode and click Apply. Then, the current loopback mode of the
port is modified.
CAUTION
The loopback may cause service interruption. After the loopback is set on the port for five
minutes, the port will return to the Non-Loopback status automatically.
NOTE
Step 4 Optional: Click Query to query the loopback status of the port.
----End
8.10 Performing the MPLS Tunnel Protection Switching

You can perform the MPLS tunnel protection switching on the T2000 to realize the switching
of services between different MPLS tunnels.
Prerequisite
Protection switching includes forced switching, manual switching, and exercise switching.
l In the case of forced switching, the state of the protection channel is not considered, unless
the protection channel is responding to the bridge request of a higher priority. When the
automatic switching fails due to some reason, the forced switching can be performed to
restore the services.
l Commands for manual switching are valid only when there is no signal failure or signal
degradation on the protection tunnel. In the case of manual switching, services can be
manually switched to a working or protection tunnel.
l The exercise switching is used to test the APS protocol. In fact, the services are not switched,
and only the computation result of the protocol is displayed.
NOTE
In the case of locked switching, services in the tunnel are not switched when they should be switched. The
services, however, can be restored when they should be restored.
Procedure
Step 1 Select the source NE of the tunnel in the Main Topology of the T2000. Right-click the NE to
choose NE Explorer.
Step 2 Choose Configuration > APS Protection Management from the Function Tree.
Step 3 Click Query, and then select the protection group to be switched.

Step 4 Click Function in the lower-right area, and then select the target switching operation in the
displayed menu.
Step 5 In the Confirmation dialog box, click OK.
Step 6 The Operation Result dialog box is displayed. ClickClose. The protection switching is
complete.
----End
8.11 Performing the 1+1 Protection Switching for CXPR

boards
You can perform the 1+1 protection switching for CXPR boards on the T2000 to realize the
switching of status between two CXPR boards.
Prerequisite
l You must be a T2000 user with "NE and network operator" authority or higher.
l The 1+1 board protection group must be available.
l The protection board must be working normally.
Board 1+1 protection switching includes working/protection switching, and restore working/
protection.
l Working/protection switching is performed to change the protection status in the protection

group, when the slot and the board name of Active Board are the same as that of Working
Board.
l Restore working/protection is performed to cancel the protection switching and return to
the initial protection status, when the slot and the board name of Active Board are the same
as that of Protection Board.
Impact on System
Performing the 1+1 Protection Switching for CXPR boards does not affect services when the
switching is normally performed.

If the protection board is abnormal, the services may be interrupted when you perform the
switching.
Procedure
l Working/protection switching.
1. Select an NE in the Main Topology of the T2000. Right-click the NE to choose NE
Explorer.
2. Choose Configuration > Board 1+1 Protection from the Function Tree.
3. In the 1+1 Protection List tab, select SCC Protection Pair of the NE. Click
Working/Protection Switching.
4. Click OK in the displayed Confirm dialog box. In the displayed Operation Result
dialog box, click Close.
5. Click Query. In the displayed Operation Result dialog box, click Close. If the slot
and the board name of Protection Board are displayed in Active Board, it indicates
that the 1+1 protection switching is complete.
6. Query the alarms and performance events on the T2000. If new alarms and
performance events do not occur and services are normal, it indicates that the switching
is successful.
l Restore working/protection.
1. Select an NE in the Main Topology of the T2000. Right-click the NE to choose NE
Explorer.
2. Choose Configuration > Board 1+1 Protection from the Function Tree.
3. In the 1+1 Protection List tab, select SCC Protection Pair of the NE. Record the
slot and the board name of Active Board. Then, click Restore Working/
Protection.
4. Click OK in the displayed Confirm dialog box. In the displayed Operation Result
dialog box, click Close.
5. Click Query. In the displayed Operation Result dialog box, click Close. If the slot
and the board name of Working Board are displayed in Active Board, it indicates
that the 1+1 protection switching is already canceled..
6. Query the alarms and performance events on the T2000. If new alarms and
performance events do not occur and services are normal, it indicates that the switching
is successfully cancelled.
----End
8.12 Performing IF 1+1 Protection Switch

The IF 1+1 protection switching is an important maintenance operation.
Prerequisite
l An IF 1+1 protection group must be configured.
l The user must have the system level authority.

Procedure
Step 1 Select the NE from the Object Tree in the NE Explorer. Choose Configuration > Microwave
Link Configuration from the Function Tree.
Step 2 Click the IF 1+1 Protection tab.
Step 3 In Slot Mapping Relation, select the working unit or the protection unit of a protection group.
Right-click on the selected unit and select the required switching mode from the displayed menu.
The system displays a prompt dialog box.
Step 4 Click Yes.

The system displays a prompt dialog box indicating that the command is successfully issued.
Step 5 Click OK.
Step 6 Click Query.
----End
8.13 Querying an IF 1+1 Protection Group

You can know the current status of an 1+1 protection group by querying the IF 1+1 protection
group.
Prerequisite
l An IF 1+1 protection group must be configured.
l The user must have the system level authority.

T2000
Procedure
Step 1 Select an NE from the Object Tree in the NE Explorer, and then choose Configuration >
Microwave Link Configuration from the Function Tree.
Step 2 Click the IF 1+1 Protection tab.
Step 3 Click Query, and then check the working status of the IF 1+1 protection group in the Slot
Mapping Relation area.
----End
8.14 Querying the Working State of AM

You can know the change of the AM mode by querying the working state of AM.
Prerequisite
l The communication between the T2000 and the NE must be normal.

l You must be an NM user with "NE monitor" authority or higher.
Related Information
Only the equipment that is configured with Hybrid radio service supports the query of the
working state of AM.
Procedure
Step 1 Select an NE from the Object Tree in the NE Explorer.
Step 2 Choose Configuration > Interface Management > Microwave Interface from the Function
Tree.
Step 3 Select the corresponding IFE2 board in the IF Attributes tab page.
Step 4 Click Query.

The current modulation modes of the transmit end and the receive end of the IFE2 board are
displayed.
----End
8.15 Setting the State of an ODU Transmitter

the state of an ODU transmitter can be mute or unmute. When the ODU transmitter is in the
unmute state, the ODU transmits and receives microwave signals normally. When the ODU
transmitter is in the mute state, the ODU transmitter does not work, but the ODU can receives
microwave signals.
Prerequisite
l The communication between the T2000 and the NE must be normal.
l You must be an NM user with "NE maintainer" authority or higher.
Procedure
Step 1 Select an NE from the Object Tree in the NE Explorer.
Step 2 Choose Configuration > Microwave Link Configuration from the Function Tree.
Step 3 Click the IF/ODU Configuration tab.
Step 4 Click the slot icon of the ODU, and then specify TX Status.
NOTE
If the automatic release function is set, the ODU releases the mute function five minutes after the ODU
transmitter is muted manually.
Step 5 Click Apply.
----End

8.16 Resetting Boards

In the case of resetting boards, the board software is reset. The board reset is classified into warm
reset and cold reset. The warm reset does not affect running services. The cold reset, however,
usually affects the running services.
Prerequisite
Precautions
NOTE
l In the case of the warm reset, correct applications and data are loaded on the equipment. The warm reset
of a board usually does not affect the running services.
l In the case of the cold reset, correct applications and data before the CPU power-off are restored. The cold
reset takes a longer time than the warm reset. The cold reset of a board usually affects the running services.
l If the board is configured with 1+1 protection, a cold reset of the board triggers protection switching.
l During the cold reset of the board, the working status of the board is displayed in blue on the T2000, which
indicates the board is in "Running & Uninstalled" status. In this case, the BD_STATUS alarm is reported.
When the cold reset is complete, the working status of the board is displayed in green on the T2000, which
indicates the board is in "Running & Installed" status. In this case, the BD_STATUS alarm stops.
l During the warm reset of the board, the T2000 displays nothing, but the PROG indicator on the board is
green and blinks. When the warm reset is complete, the PROG indicator on the board turns green and is
always on.
l The board data is not lost after the board is reset.
Procedure
l Performing a warm reset on the board
1. Double-click the target NE icon in the Main Topology of the T2000 to display the
Running Status slot view.
2. Select and right-click the CXPR board. Choose warm reset. Then, click OK in the
displayed warning dialog box.
3. In the displayed Operation Result dialog box, click Close to complete the reset
operation.
NOTE
There is an RST button on the CXPR board. If the RST button is pressed, a warm reset is performed on
the board.
l Performing a cold reset on the board
1. Double-click the target NE icon in the Main Topology of the T2000 to display the
Running Status slot view.
2. Select and right-click the target board. Choose cold reset. Then, click OK in the
displayed warning dialog box.
3. In the displayed Operation Result dialog box, click Close to complete the reset
operation.

l The board supports hot plugging. In the case of hot plugging, a cold reset is performed on
the board. It is not recommended to perform a cold reset on the board by means of hot
plugging.
----End
8.17 Testing the Transmitted Optical Power of the Optical

Interface
If the mean transmitted optical power is excessively high or low, bit errors occur on the
equipment. The bit errors affect services and even damage components on the equipment. This
section describes how to test the transmitted optical power at optical interfaces of the equipment
on site to ensure that the mean transmitted optical power of each optical interface is normal.
Prerequisite
l Fiber jumper connections at optical interfaces must be tested and the test result must be
normal.
Checking Criteria
Query the relevant interface specifications, such as the optical interface type and the working
wavelength, according to the barcode on the optical interface board. Refer to Technical
Specifications of Boards in the OptiX RTN 950 Radio Transmission System Product
Description manual.

l T2000 and PC
l Optical power meter
l Test fiber jumpers with different connectors
l Fiber connectors
l Fiber cleaning tools
Test Connection Diagram

Figure 8-1 shows the connections for the test of the mean transmitted optical power of the OptiX
RTN 950 equipment.

Figure 8-1 Connections for the test of the mean transmitted optical power at the optical interface
PC
CXPR
Optical
power meter
Precautions
DANGER
During the test, avoid direct eye exposure to the laser beams.
Procedure
Step 1 Set the target optical interface by using the T2000 to make the optical interface work in the
transmitted state.
NOTE
For the Ethernet optical interface, set it to the enabled state on the T2000.
1. On the Main Topology of the T2000, select and right-click the target NE. Select NE
Explorer from the displayed shortcut menu.
2. Select the target Ethernet board in the NE Explorer. Choose Configuration > Interface
Management > Ethernet Interface from the Function Tree.
3. Enable the target Ethernet optical interface in the Enable Port parameter of General
Attributes tab.
Step 2 Disconnect the fiber at the OUT port of the tested optical interface and put the protective cap on
the fiber connector.
Step 3 Draw out the optical module to check the label on it. Then, insert it back to the original position.
You can learn the type of the optical interface. Based on the type of the optical interface, obtain
the specifications such as working wavelength and mean transmitted optical power of this optical
interface from the checking criteria.
Step 4 Set the wavelength of the optical power meter to make it consistent with the working wavelength
of the tested optical interface.

CAUTION
Set the wavelength of the optical power meter consistent with the working wavelength of the
tested optical interface so that the optical power work normally. Then, proceed with the next
step.
Step 5 Connect the OUT port of the optical interface to the optical power meter by using the test fiber
jumper that maps the optical interface.
Step 6 Observe the reading on the optical power meter. Record the value when the reading does not
change. The value indicates the mean transmitted optical power of the tested optical interface.
Step 7 Check whether the optical power value obtained is within the range of the mean transmitted
optical power.
l If the optical power value obtained is within the range, proceed to Step 10.
l If the optical power value obtained is beyond the range, proceed to Step 8.
Step 8 Check and the fiber connector, and clean it if necessary, according to 8.24 Inspecting and
Cleaning the Optical Fiber Connectors.
Step 9 Perform Step 5 through Step 7 to test the mean transmitted optical power of the optical interface
again till the value obtained is within the normal range.
Step 10 Restore the fiber connection of the tested port.
Step 11 Repeat the previous steps to test the mean transmitted optical power at all the optical interfaces
of the equipment one by one.
----End
8.18 Testing the Receive Optical Power of the Optical

Interface
If the receive optical power is excessively high or low, bit errors occur on the equipment. The
bit errors affect the services or even damage components on the equipment. This section
describes how to test the receive optical power at optical interfaces of the equipment on site to
ensure that the receive optical power of each optical interface is normal.
Prerequisite
l Fiber jumper connections at optical interfaces must be tested and the test result must be
normal.
l The mean launched optical power at optical interfaces must be tested and the test result
must be normal.
l Fibers from the adjacent station must be routed to the optical distribution frame (ODF) of
the local station and must provide optical signals to the local station.

NOTE
l The Ethernet optical interface must be set to the enabled state on the T2000 for sending optical
signals externally.
l For methods on how to set the optical interface, see 8.17 Testing the Transmitted Optical
Power of the Optical Interface.
l The flange must be clean and properly connected to the fiber connector.
Checking Criteria
Query the relevant interface specifications, such as the optical interface type and the working
wavelength, according to the barcode on the optical interface board. Refer to Technical
Specifications of Boards in the OptiX RTN 950 Radio Transmission System Product
Description manual.

l Test fiber jumpers with different connectors
l Fiber connector
l Fiber cleaning tools
l Optical attenuator
Test Connection Diagram

The OptiX RTN 950 equipment supports the Ethernet optical interfaces. Figure 8-2 shows the
connections for the test of the receive optical power at the optical interface of the local station.
Figure 8-2 Connections for the test of the receive optical power at the optical interface
Fiber jumper
at the IN Fiber jumper
interface ODF ODF
OUT IN OUT IN
Optical
interface Optical interface
Optical power
meter
Local station Adjacent station
Procedure
Step 1 Set the wavelength of the optical power meter to make it consistent with the working wavelength
of the tested optical interface.
Step 2 Remove the fiber jumper from the IN port of the tested optical interface on the local station.
Then, connect it to the optical power meter.

Step 3 Observe the reading on the optical power meter. Record the value when the reading does not
change. The value indicates the receive optical power of the tested optical interface.
Step 4 Check whether the optical power value obtained is within the normal range. The receive optical
power must follow the standard: sensitivity + 3 dBm < receive optical power (tested) < overload
threshold - 5 dBm. For the nominal values of the sensitivity and the overload threshold, see the
checking criteria.
l If the optical power value obtained is within the normal range, proceed to Step 8.
l If the optical power value obtained is beyond the normal range:
– When the receive optical power is less than the sensitivity plus 3 dBm, proceed to Step
5.
– When the receive optical power is larger than the overload threshold minus 5 dBm,
proceed to Step 6.
Step 5 Check whether the fiber connector, and the fiber flange and the optical attenuator on the ODF
side are contaminated.
l If the fiber connector is contaminated, clean it according to 8.24 Inspecting and Cleaning
the Optical Fiber Connectors.
l If the fiber flange or the optical attenuator on the ODF side is contaminated, replace the fiber
flange or the optical attenuator.
Proceed to Step 7.
Step 6 Check whether the optical attenuator is normal.

l If the optical attenuator is normal, add an optical attenuator on the ODF side.
l If the optical attenuator is not normal, replace the optical attenuator.
Step 7 Perform Step 2 to Step 4 to test the receive optical power of the optical interface again till the
value obtained is within the normal range.
Step 8 Restore the fiber connection of the tested interface.
Step 9 Repeat the previous steps to test the receive optical power at all the optical interfaces of the
equipment one by one.
----End
8.19 Replacing Boards on Site

When replacing a board, remove and insert it as required; make sure that the mapping relations
between the interfaces and cables are not changed before and after the replacement; observe
indicators to determine the running state of the board.
Prerequisite
A new board must be available.

ESD wrist strap, ESD bag, and cross screwdriver

Precautions
Before replacing a board, read Safety Precautions for Using the Equipment carefully.
The chassis of the OptiX RTN 950 and the OptiX RTN 910 are different, but the board
replacement operations are similar. Thus, the board replacement illustrations mentioned below
consider the OptiX RTN 910 as an example.
DANGER
Avoid direct eye exposure to the laser source from the optical interface board or from inside the
fiber, because laser beams can cause permanent eye damage.
CAUTION
l When replacing a board, make sure that the board is not connected to any fibers or cables.
l The optical interfaces and the fiber jumper connectors must be clean.
Procedure
Step 1 Properly wear the ESD wrist strap according to .
Step 2 Record the connection relations between board interfaces and fibers or cables.
Step 3 Remove fibers or cables from the board interfaces.
Step 4 Remove the board.
l Remove the CXPR or processing board:
Use a screwdriver to loosen the captive screws on the right and left sides of the board. Then,
the screws are automatically sprung out. See Figure 8-3.
Figure 8-3 Loosening screws with a screwdriver
Loosen the captive screw

Hold the ejector levers of the board and pull them outward to disengage the board from the
backplane socket. Then, remove the board from the slot slowly with stable force. See Figure
8-4.
Figure 8-4 Removing the board (1)
Remove the board gently
l Remove the FAN or PIU board:

Hold the front panel and tack switches of the board to disengage the board from the backplane
socket. Then, remove the board from the slot slowly with stable force until the board is
completely disengaged from the chassis. See Figure 8-5.

Figure 8-5 Removing the board (2)
Remove the board

slowly out of the slot
Step 5 Put the replaced board in an antistatic bag. Record the NE name and the fault on a maintenance
label and then affix the label to the bag.
Step 6 Insert a new board.
l Insert a new FAN or PIU board:
Hold the front panel and tact switches of the board, and slide the board slowly into the relevant
slot along the guide rails of the chassis. Push the front panel of the board gently until the
board completely engages with the backplane sockets. Then, you can release the front panel
and the tact switches. See Figure 8-6.

Figure 8-6 Inserting the board (1)
Insert the board slowly

into the slot
l Insert the CXPR or processing board:

Use both hands to hold the ejector levers and pull them outward. Then, insert the board and
slide it gently into the relevant slot along the right and left guide rails. In addition, align the
grooves of the upper and lower ejector levers on the front panel of the board with the upper
and lower edges of the chassis. Push the front panel of the board into the slot gently until the
board engages with the backplane sockets. Then, pull the ejector levers inward to make the
board completely inserted into the slot. See Figure 8-7.

Figure 8-7 Inserting the board (2)
Push it in gently
Use a screwdriver to tighten the captive screws on the right and left sides of the board. See
Figure 8-8.
Figure 8-8 Tightening screws with a screwdriver
Tighten the captive screw
Step 7 According to the connection relations between interfaces and fibers or cables, insert the fibers
or cables into the interfaces on the board. For details, see OptiX RTN 950 Radio Transmission
System IDU Quick Installation Guide.

Step 8 Check whether the STAT and PROG indicators on the front panel of each board are green. If
the STAT and PROG indicators are green, it indicates that the board is successfully replaced.
Otherwise, repeat the previous steps to insert/remove or replace the board.
----End
8.20 Powering On the Equipment

This section describes how to connect the power supply to the equipment to ensure that the
equipment can be powered on normally.
Prerequisite
The external power supply must be provided.

Screwdriver
Precautions
CAUTION
Dot insert or remove any power plugs and the PIU board when the power is on.
Procedure
Step 1 Make sure that the external power voltage is sufficient to avoid excessively high voltage
damaging the equipment.
Step 2 Check the power cable of the chassis. Make sure that the power cable is connected to the PIU
board correctly.
Step 3 Check the connector of the power cable to ensure that the connector is connected firmly. If the
connector is connected loosely, tighten the fastening screws of the connector by using a
screwdriver.
Step 4 Turn the power switch, which connects the external power supply and the PIU board, to the on
position.
Step 5 Observe the STAT and PROG indicators of the CXPR board.
l If the PROG indicator flashes, the board software is being initialized and loaded.
l After the board software is loaded successfully, the STAT and PROG indicator, which stay
on in green.
----End
8.21 Powering Off the Equipment

This section describes how to power off the equipment.

Precautions
CAUTION
If the equipment is powered off, it stops running and all the services on this equipment are
interrupted.
Procedure
Step 1 Turn off the power switch, which connects the external power supply and the PIU board, to the
off position.
Step 2 Make sure that indicators on all the boards are off and the equipment is powered off.
----End
8.22 Querying and Setting the Working Mode of Ethernet

Interface
This section describes how to query and set the working mode of Ethernet interface.
Prerequisite
You must be an NM user with "NE and network operator" authority or higher.
Procedure
Step 1 Right-click the NE and choose NE Explorer. The NE Explorer dialog box is displayed.
Step 2 Select the desired board in the NE Explorer, and then choose Configuration > Interface
Management > Ethernet Interface from the Function Tree.
Step 3 In the General Attributes tab, click Query, you can query the working mode of the port.
Step 4 Double-click the Working Mode field of the desired port to modify the working mode of the
board.

NOTE
The working modes of different Ethernet interfaces are as follows:

l The FE electrical interface can be set to 100M full-duplex or auto-negotiation working mode.
l The FE optical interface can be set to 100M full-duplex working mode.
l The GE optical interface can be set to 1000M half-duplex, 1000M full-duplex or auto-negotiation
working mode.
Step 5 Click Apply and click Yes in the displayed Warning dialog box. The working mode of the
Ethernet interface is set.
----End
8.23 Querying Protection Configuration

This section describes the basic method for querying the protection scheme that is configured
in the equipment when a fault or service interruption occurs.
Prerequisite
You must be an NM user with "NE and Network Operator" authority or higher.
The equipment supports the 1+1 protection of boards. For details, see the OptiX RTN 950 Radio
Transmission System IDU Hardware Description.
Procedure
Step 1 Right-click the NE and choose NE Explorer. The NE Explorer dialog box is displayed.
Step 2 Select the desired NE in the NE Explorer. choose Configuration > Board 1+1 Protection
from the Function Tree. Then, the 1+1 protection pair is listed in the 1+1 Protection List tab.
Step 3 Select the desired protection, and click Query. Click Close on the Operation Result dialog
box. Then, the details of the protection pairs are displayed.
----End
8.24 Inspecting and Cleaning the Optical Fiber Connectors

of optical transmission systems. Inspecting and cleaning fiber connectors used in fiber optic
connections are introduced here.
8.24.1 Overview
Overview of the purpose and procedure of cleaning optical fiber connectors, the items that may
cause pollution to optical connectors are also introduced here.
8.24.2 Protection of Optical Connectors
The requirements of optical connector protection are listed here.
8.24.3 Tools, Equipment and Materials
The recommended tools, equipment and materials used in cleaning the optical connector are
listed here.

8.24.4 Inspecting Optical Connectors

The following describes how to inspect the optical connectors and check the status of the fiber
surface.
8.24.5 Cleaning Optical Fiber Connectors Using Cartridge Cleaners
Clean the fiber optic only in the case that there are flaws on it. The following describes how to
clean the fiber optic with a type of CLETOP cassette cleaner.
8.24.6 Cleaning Optical Fiber Connectors Using Lens Tissue
Clean the fiber optic only in the case that there are flaws on it. The following procedure provides
the steps to clean the fiber connectors using lens tissue.
8.24.7 Cleaning Optical Modules Using Optical Cleaning Sticks
Optical modules must be cleaned with special cleaning tools and materials. The following
procedure provides the steps to clean optical adapters using optical cleaning sticks.
8.24.1 Overview
Overview of the purpose and procedure of cleaning optical fiber connectors, the items that may
cause pollution to optical connectors are also introduced here.
of optical transmission systems. Here describes how to inspect and clean fiber connectors used
in fiber optic connections.
Figure 8-9 shows the optical fiber connector.
Figure 8-9 Optical fiber connector
The following items should be removed because they pollute optical connectors that are
extensively adopted in optical transmission systems:
l Dust
l Oils (frequently from human hands)
l Film residues (condensed from vapors in the air)
l Powdery coatings (left after water or other solvents evaporate)
Dust is the most common dirt in optical connectors. Even small dust that can be seen only under
a microscope can affect the quality of optical signals, degrade the system performance and cause
potential instability in network operation.
A one-micrometer dust granule on an optical connector of a single mode fiber can block 1%
light and cause 0.05 dB lost. A nine-micrometer dust granule that cannot be seen by human eyes

can block an entire fiber core. Therefore, small dirt even that cannot be seen by human eyes
should be removed.
NOTE
Before you connect any optical component, make sure that you have inspected and cleaned the component.
General Procedure
Table 8-1 below introduces the general procedure of how to inspect and clean the optical fiber
connectors.
Table 8-1 General procedure of inspecting and cleaning the optical fiber connectors
Operation Details
Cleaning Optical Fiber Connectors Using Refer to "8.24.5 Cleaning Optical Fiber
Cartridge Cleaners Connectors Using Cartridge Cleaners"
Cleaning Optical Fiber Connectors Using Refer to "8.24.6 Cleaning Optical Fiber
Lens Tissue Connectors Using Lens Tissue"
Cleaning Optical Adapters Using Optical Refer to "8.24.7 Cleaning Optical Modules
Cleaning Sticks Using Optical Cleaning Sticks"
8.24.2 Protection of Optical Connectors

The requirements of optical connector protection are listed here.
The requirements of optical connector protection are:
l All optical interface boards must be transported and stored in reliable packing. This serves
to avoid mechanical and electrostatic damages and to reduce vibrations.
l Store the protective caps in an antistatic bag.
l Cover the optical interfaces of the replaced boards with protective caps in time. Store them
in proper packages to keep the optical interfaces clean.
l The protective caps recommended are shown in Figure 8-10, The protective caps not
recommended are shown in Figure 8-11.
Figure 8-10 Protective caps recommended

Figure 8-11 Protective caps not recommended
NOTE
The air filter caps made of soft rubber are not recommended, which tends to collect dust and sundries. This
type of caps provides poor dustproof function.
8.24.3 Tools, Equipment and Materials

The recommended tools, equipment and materials used in cleaning the optical connector are
listed here.
The recommended tools, equipment and materials are listed below:
l Optical fiberscope with 400x magnification (a video fiberscope is recommended)
l CLETOP cassette cleaner, see Figure 8-12
l Clean solvent( Isoamylol is preferred, propyl can be used alcohol or formalin is never used)
l Non-woven lens tissue, lint-free wipes or fiber cleaning tissue (Non-woven lens tissue is
recommended)
l Special cleaning roll
l Optical cleaning sticks used for optical connectors or cotton swabs (medical cotton or long
fiber cotton) See Figure 8-13 and Figure 8-14

Figure 8-12 CLETOP cassette cleaner
Figure 8-13 Cleaning stick for the SC and FC optical interface (just for reference)
Figure 8-14 Cleaning stick for the LC optical interface
8.24.4 Inspecting Optical Connectors

The following describes how to inspect the optical connectors and check the status of the fiber
surface.

The tools, equipment and materials are listed below:


Precautions
WARNING
Laser is dangerous. The light is not visible to the eyes with or without laser protective glasses.
Do not look into optical connectors or interfaces. Failure to follow this warning can cause damage
to the eyes, or even blindness.
Use a fiberscope equipped with a safety device or a desktop video fiberscope when you inspect
the optical connectors. If one is not available, turn off the lasers and disconnect both ends of the
fiber before you inspect the optical connectors
CAUTION
Electro static discharge (ESD) is hazardous to the electronic equipment. Use proper handlings
to prevent damage to the electronic equipment. Failure to follow this caution can cause
equipment damage and/or loss of traffic
Procedure
Step 1 Turn off the lasers before the inspection. Disconnect both ends of the fiber to be inspected.
Step 2 Test the optical power using a power meter. Ensure that there is no laser light on the optical
connector.
Step 3 Use a fiberscope to inspect the fiber to check if there is any dirt or damage. Refer to the examples
shown below.
l For an image of the intact fiber optic surface through a fiberscope that can be used
successfully in the equipment, see Figure 8-15.
Figure 8-15 An intact fiber

l For images of fibers through a fiberscope with imperfections that can impair the function of
the assembly, see Figure 8-16 . The image on the left shows clearly a damaged fiber. Severely
damaged fibers must not be used in the system equipment. Otherwise, permanent and severe
damage to the assembly can occur. The image on the right shows a fiber that is suspect. If
the output power is within an acceptable range, the fiber might not cause any damage to the
assembly. If the output power is unstable or falls outside the acceptable range, however, the
fiber can cause damage to the assembly and must not be used.
Figure 8-16 Damaged or suspect fibers
NOTE
The views shown do not represent the entire surface of the fiber optic. Much of the surface is the metal
connector and only the 800-micron core is the actual fiber.
l For details on acceptable and unacceptable fibers, see Figure 8-17, Figure 8-18 and Figure
8-19.
Figure 8-17 An intact fiber

Figure 8-18 Acceptable fibers with imperfections
Figure 8-19 Unacceptable fibers with imperfections
Step 4 If any dirt is detected, clean the optical connector. For details, refer to "8.24.5 Cleaning Optical
Fiber Connectors Using Cartridge Cleaners" and "8.24.6 Cleaning Optical Fiber
Connectors Using Lens Tissue".
Step 5 If any damage is detected, replace the fiber or board.
----End
8.24.5 Cleaning Optical Fiber Connectors Using Cartridge Cleaners

Clean the fiber optic only in the case that there are flaws on it. The following describes how to
clean the fiber optic with a type of CLETOP cassette cleaner.

Prerequisite
Before cleaning, inspect the fiber optic surface with a fiberscope or a magnifier to determine the
extent to which the fiber optic might be damaged or dirty. Clean the fiber optic only in the case
that there are flaws on it. If there are not, do not clean it. That is because the cleaning itself might
introduce dust, dirt, or cause potential damage to the fiber optic.
The following procedure provides the steps to clean the fiber connectors using cartridge type
cleaners. There are several types of cartridge cleaners. The following describes a type of
CLETOP cassette cleaner.

l CLETOP cassette cleaner

Precautions
WARNING
CAUTION
The electrostatic discharge may damage the equipment. Before touching the equipment, board
or integrated circuit (IC) chip, you must wear the ESD wrist strap to prevent electrostatic
discharge on human body from damaging the static-sensitive components, and ensure that the
other end of the strap is properly grounded. Otherwise, the equipment may be damaged or the
service may be interrupted.
Procedure
Step 2 Use an optical power meter to measure and ensure that there is no laser light on the optical
connector.
Step 3 Press down and hold the lever of the cassette cleaner, and the shutter slides back and exposes a
new cleaning area. See Figure 8-20.

Figure 8-20 Using the CLETOP cassette cleaner
Step 4 Place the fiber tip lightly against the cleaning area so that the end face is flat on the cleaning
area
Step 5 Drag the fiber tip lightly on one cleaning area in the direction of the arrow once. See Figure
8-21. Do it again on the other cleaning area in the same direction as the first time once. See
Figure 8-22.
CAUTION
Do not scrub the fiber against fabric or clean over the same cleaning area more than once.
Otherwise, the connector can be dirtied or damaged.
Figure 8-21 Dragging the fiber tip lightly on one cleaning area

Figure 8-22 Dragging the fiber tip lightly on the other cleaning area
Step 6 Release the lever of the cassette cleaner to close the cleaning area.
Step 7 Use a fiberscope to inspect the adapter to check if there is any dirt. For details refer to the
examples shown in 8.24.4 Inspecting Optical Connectors. If the optical adapter is still dirty,
repeat the Step 1 to Step 6.
Step 8 Connect the fiber connector to the board.
Step 9 Turn on the lasers after you connect the fiber to the board.
----End
8.24.6 Cleaning Optical Fiber Connectors Using Lens Tissue

Clean the fiber optic only in the case that there are flaws on it. The following procedure provides
the steps to clean the fiber connectors using lens tissue.
Prerequisite
Before cleaning, inspect the fiber optic surface with a fiberscope or a magnifier to determine the
extent to which the fiber optic might be damaged or dirty. Clean the fiber optic only in the case
that there are flaws on it. If there are not, do not clean it. That is because the cleaning itself might
introduce dust, dirt, or cause potential damage to the fiber optic.
The following procedure provides the steps to clean the fiber connectors using lens tissue. Use
only the special materials for cleaning the fiber connectors. Refer to the local site practices.



l Clean solvent. (Isoamylol is preferred, propyl can be used. alcohol or formalin is never
used)
l Non-woven lens tissue, lint-free wipes or fiber cleaning tissue (Non-woven lens tissue is
recommended)
l Special cleaning roll
Precautions
WARNING
CAUTION
or integrated circuit (IC) chip, you must wear the ESD wrist strap to prevent electrostatic
discharge on human body from damaging the static-sensitive components, and ensure that the
other end of the strap is properly grounded. Otherwise, the equipment may be damaged or the
service may be interrupted.
Procedure
Step 2 Use an optical power meter to measure and ensure that there is no laser light on the optical
connector.
Step 3 Place a small amount of cleaning solvent on the lens tissue.
Step 4 Clean the fiber tip on the lens tissue. See Figure 8-23 and Figure 8-24.
CAUTION
Do not scrub the fiber against fabric or clean over the same cleaning area more than once. Failure
to comply can result in connector dirt or damage.

Figure 8-23 Cleaning the fiber tip with the lens tissue on the desk
Figure 8-24 Cleaning the fiber tip with the lens tissue on the hand
Step 5 Repeat step 4 several times on the areas of the lens tissue that have not been used.
Step 6 Use the compressed gas to blow off the fiber tip.
NOTE
l When you use the compressed gas, keep the injector nozzle as close as possible to the fiber connector
surface without touching it.
l When you use the compressed gas, first spray it into the air as the initial spray of compressed air can
contain some condensation or propellant. Such condensation leaves behind a filmy deposit.
l If the compressed gas is not available, a clean roll can be used.
Step 7 Use a fiberscope to inspect the adapter to check if there is any dirt. For details refer to the
examples shown in 8.24.4 Inspecting Optical Connectors. If the optical adapter is still dirty,
Step 8 Do not touch the fiber connector after you clean it. Connect it to the optical interface board at
once. If it is not used for the time being, put a protective cap on it.

NOTE
A piece of lens tissue can be used for only one time.
----End
8.24.7 Cleaning Optical Modules Using Optical Cleaning Sticks

Optical modules must be cleaned with special cleaning tools and materials. The following
procedure provides the steps to clean optical adapters using optical cleaning sticks.
Prerequisite
There are several types of optical cleaning sticks and cotton swabs that can be used. Refer to the
local site practices. You can obtain these tools and materials from a fiber cable and connector
manufacturer.


l Clean solvent. (Isoamylol is preferred, propyl can be used. alcohol or formalin is never
used)
l Optical cleaning sticks used for optical connectors or cotton swabs (medical cotton or long
fiber cotton)
Precautions
WARNING
CAUTION
or integrated circuit (IC) chip, to prevent the electrostatic discharge on the human body damaging
the static-sensitive components, you must wear the ESD wrist strap and ensure the other end of
the strap is properly grounded. Otherwise, the equipment may be damaged or the service may
be interrupted.

Procedure
Step 1 Before checking the fiber connector, disable the laser and disconnect the two ends of the fiber
from other components.
Step 2 Use the optical power meter to test and make sure that no laser light is present at the fiber module.
Step 3 Select the cleaning stick with a proper diameter for a certain type of the module.
NOTE
For the SC and FC optical interface, use the cleaning stick with a diameter of 2.5 mm; for the LC optical
interface, use the cleaning stick with a diameter of 1.25 mm. See Figure 8-13 and Figure 8-14.
Step 4 Place a small amount of cleaning solvent on the optical cleaning stick.
Step 5 Place the optical cleaning stick lightly on the optical modules so that cleaning solvent is against
the fiber tip. Turn the stick clockwise four to five times and make sure that there is direct contact
between the stick tip and fiber tip. Hold the stick straight out from the module.
Step 6 Use the compressed gas to blow off the fiber tip.
NOTE
l When you use the compressed gas, keep the injector nozzle close to the connector surface without
touching it.
l When you use the compressed gas, first spray it into the air as the initial spray of compressed air can
contain some condensation or propellant. Such condensation leaves behind a filmy deposit.
Step 7 Use a fiberscope to inspect the fiber tip to check if there is any dirt. For details refer to the
examples shown in "8.24.4 Inspecting Optical Connectors". If the optical fiber tip is still dirty,
Step 8 Connect the fiber to the board, or put a protective cap on the interface.
----End

Maintenance Guide 9 Alarm
9 Alarm
About This Chapter
This chapter describes basic concepts related to alarms and how to handle related alarms of the
equipment.
9.1 Basic Concepts Related to Alarms

Alarms are always the information sources for checking the running state of equipment and for
locating faults. Hence, it is necessary to understand the basic concepts related to alarms.
9.2 Alarm List
This chapter describes all the alarms that may be generated by the OptiX RTN 950.
9.3 Alarm Handling
This chapter describes how to handle related alarms of the equipment.

9 Alarm Maintenance Guide
9.1 Basic Concepts Related to Alarms

Alarms are always the information sources for checking the running state of equipment and for
locating faults. Hence, it is necessary to understand the basic concepts related to alarms.
9.1.1 Alarm Reporting Flow
The alarm reporting flow indicates the entire process from alarm generation to alarm notification.
The alarm reporting flow provides guidelines for the user to handle alarms.
9.1.2 Alarm Correlation
The OptiX RTN 950 supports the alarm correlation analysis function. Learning the alarm
correlation can facilitate the fault locating. This section mainly describes the correlation rules
of common service alarms of the OptiX RTN 950, and explains the alarm correlation by taking
the ETH_LINK_DOWN alarm as the example.
9.1.3 Alarm Category
According to the standards and functions of the T2000, alarms are classified into several
categories.
9.1.4 Alarm Severity
The alarm severity always indicates the importance, impact and urgency of an alarm. Alarms
are classified into four categories by the severity, that is, critical alarms, major alarms, minor
alarms and warning alarms.
9.1.5 Alarm Notification
Instant awareness of alarms is very important for handling alarms and maintaining the network.
The equipment and the T2000 provide different means of notifying alarms to the user.
9.1.1 Alarm Reporting Flow

The alarm reporting flow indicates the entire process from alarm generation to alarm notification.
The alarm reporting flow provides guidelines for the user to handle alarms.
Figure 9-1 shows the alarm reporting flow.

Figure 9-1 Alarm reporting flow diagram

The board monitors the alarm
and the alarm is saved in the
alarm database of the board
Whether Yes The alarm is sheltered

to set the alarm and the board does
shelter? not monitor the alarm
No
The alarm is saved in the alarm
database of the system control
board
Whether Yes The alarm is suppressed

to set the alarm and the board does not
suppression? report the alarm any more
No
The alarm is automatically

reported
Whether to Yes
set the equipment alarm Discard the alarm data
filtering?
No
The NM monitors the NM
The alarm data is saved
alarm and the alarm is Yes
in the NM server
saved in the NM server
Whether
Analyse the alarm correlation to set the alarm
suppression?
No
Displayed on the NM client
Whether
No
to set the alarm
reporting?
Yes
The alarm data is sent to the

receive ternimal
NOTE
For details on the alarm suppression, alarm synchronization, alarm automatic reporting, alarm filtering and
alarm notification, see the OptiX iManager T2000 Online Help.
9.1.2 Alarm Correlation

The OptiX RTN 950 supports the alarm correlation analysis function. Learning the alarm
correlation can facilitate the fault locating. This section mainly describes the correlation rules
of common service alarms of the OptiX RTN 950, and explains the alarm correlation by taking
the ETH_LINK_DOWN alarm as the example.

Concepts
When faults or anomalies occur in the network, a series of alarms are reported. Some of the
alarms are crucial to fault locating and these alarms are considered as key alarms. Some alarms
interfere in the fault locating and these alarms are considered as interference alarms. Then, the
key alarms and the interference alarms have the alarm correlation.
Alarms with correlation have the following features:
l Alarms (root alarm) directly caused by faults or anomalies can generate some other alarms
(non-root alarms). The root alarms and non-root alarms have the alarm correlation.
l If multiple alarms result from the same fault or anomaly, these alarms have the alarm
correlation.
To make the alarm information facilitate the fault locating in a more effective manner, you can
set the alarm correlation rules on the T2000 and enable the alarm correlation analysis function.
Then, you can make the NE only report the key alarms, that is, make the key alarms suppress
the relevant interference alarms.
Rules
The alarm correlation rules for the OptiX RTN 950 are as follows:
l The alarm suppression is realized in the same equipment.
l The root alarm suppresses the non-root alarm.
l The alarm resulting from the fault at the lower layer of the service hierarchical model
suppresses the alarm resulting from the fault at the upper layer of the service hierarchical
model.
Layers, from the lower to the upper in the service hierarchical model, are physical, data link,
tunnel, PW and emulated service. In the model, the upper layers depend on the services provided
by the lower layers. When a lower layer and a upper layer have faults at the same time, to remove
the fault at the upper layer, the fault at the lower layer must be removed first. At this time, the
alarm resulting from the lower-layer fault suppresses the alarm resulting from the upper-layer
fault.
NOTE
l Be cautious to set the alarm correlation rules, because they are the basis of the alarm correlation analysis
and can affect the result of the analysis.
l Normally, use the default correlation rules on the T2000.
l The alarm correlation analysis function is disabled by default. To use the alarm correlation rules to
perform the alarm correlation analysis, you need to manually enable the analysis function.
As show in Figure 9-2, the alarm correlation rules are illustrated based on the Ethernet services
carried at the Ethernet port.

Figure 9-2 Alarm correlation rules of the Ethernet services carried at the Ethernet port
LSR_NO_FITED
Physical
LASER_MOD_ERR ETH_LOS LASER_SHUT
ETH_LINK_DOWN
Data-Link MPLS_TUNNEL_FDI
LAG_MEMBER_ MAC_FCS_EXC ETH_EFM_DF

DOWN
ETH_EFM_ MAC_FCS_SD ETH_EFM_

LOOPBACK REMFAULT
ETH_EFM_EVENT
MPLS_TUNNEL_ MPLS_TUNNEL_
FDI MISMERGE
Tunnel
MPLS_TUNNEL_
MISMATCH
MPLS_TUNNEL_ MPLS_TUNNEL_ MPLS_TUNNEL_BDI

BDI LOCV 与MPLS_PW_FDI
MPLS_TUNNEL_ MPLS_TUNNEL_ MPLS_TUNNEL_SF

UNKNOWN Excess
MPLS_TUNNEL_SD
MPLS_PW_FDI MPLS_PW_MISM
PW ERGE
MPLS_PW_BDI MPLS_PW_MISM
ATCH
MPLS_PW_LOCV MPLS_PW_BDI
MPLS_PW_UNKN MPLS_PW_Excess MPLS_PW_SF

OWN
MPLS_PW_SD
ETH_CFM_RDI ETH_CFM_MISME ETH_CFM_

Emulated RGE DefMACstatus
Service
（Ethernet） ETH_CFM_UNEXP
ERI
ETH_CFM_LOC ETH_CFM_RDI
FDBSIZEALM_ ETH_CFM_SF
ELAN
ETH_CFM_SD
A1 A2 Alarm A1 suppresses alarm A2 A N Alarm A suppresses the notification

message N sent by the local NE
N N indicates the notification message that is sent N1 N2 Notification message N1 suppresses
or received by the NE notification message N2
A N The NE generates alarm A and N A Notification message N suppresses
sends the notification message N to alarm A
other NEs

Illustration
As shown in Figure 9-3, an E-Line service is configured between NE1 and NE3, and NE2 is
involved. Each segment of the service is over the FE link. In addition, the alarm correlation
analysis function is enabled for NE1, NE2 and NE3.
Figure 9-3 Illustration of the alarm correlation analysis
ETH _LINK_ DOWN ETH_ LINK _ DOWN MPLS_TUNNEL_FDI
NE 1 NE 2 NE 3
When the receive working mode is inconsistent with the transmit working mode on the FE link
between NE1 and NE2, the ETH_LINK_DOWN alarm is reported at the relevant ports on NE1
and NE2. Because the alarm correlation analysis function is enabled for the three NEs, the
ETH_LINK_DOWN alarm suppresses the MPLS_TUNNEL_BDI, LAG_MEMBER_DOWN
(if there is an LAG), MAC_FCS_EXC and ETH_EFM_DF alarms. In the meantime, NE2
transmits the MPLS_TUNNEL_FDI notification packet to NE3. After NE3 receives the
notification packet, the MPLS_TUNNEL_LOCV alarm is suppressed.
According to the previous illustration, if all the NEs in the network are enabled with the alarm
correlation analysis function, when faults occur in the network, the NEs only need to report the
key alarms to the T2000. This can facilitate the fault location.
9.1.3 Alarm Category

According to the standards and functions of the T2000, alarms are classified into several
categories.
The six types of alarms are listed as follows:

l Communication alarm, which indicates anomalies in NE communication and optical signal
communication, such as interruption of NE communication and loss of optical signals.
l Processing alarm, which indicates anomalies in software processing, such as failure to back
up database, and failure to perform protection switching.
l Equipment alarm, which indicates anomalies in equipment hardware, such as failure of the
laser and loopback of the optical interface.
l Service alarm, which indicates anomalies in service status and network QoS, such as MS
performance over-threshold.
l Environment alarm, which indicates anomalies in the power supply system and the
equipment room environment (temperature, relative humidity, access control, and so on),
such as excessively high temperature of the power supply module.
l Security alarm, which indicates anomalies in security of the T2000 and NE, such as logout
of the NE user.

9.1.4 Alarm Severity

The alarm severity always indicates the importance, impact and urgency of an alarm. Alarms
are classified into four categories by the severity, that is, critical alarms, major alarms, minor
alarms and warning alarms.
Table 9-1 lists details on how to handle alarms at different severity levels.
Table 9-1 Alarm severity

Alarm Severity Definition Handling Principle
Critical alarm The critical severity level Handle it immediately.

indicates that a service
affecting condition has
occurred and an immediate
corrective action is required.
Such a severity can be
reported, for example, when
a managed object becomes
totally out of service and its
capability must be restored.
Major alarm The major severity level Handle it urgently.

indicates that a service
affecting condition has
developed and an urgent
corrective action is required.
Such a severity can be
reported, for example, when
there is a severe degradation
in the capability of the
managed object and its full
capability must be restored.
Minor alarm The minor severity level Find the alarm cause, handle
indicates the existence of a it correctly, and remove the
non-service affecting fault potential trouble.
condition and that corrective
action should be taken in
order to prevent a more
serious (for example, service
affecting) fault. Such a
severity can be reported, for
example, when the detected
alarm condition is not
currently degrading the
capacity of the managed
object.

Alarm Severity Definition Handling Principle
Warning alarm The warning severity level Analyze the alarm cause, and
indicates the detection of a remove the potential trouble.
potential or impending
service affecting fault, before
any significant effects have
been felt. Action should be
taken to further diagnose (if
necessary) and correct the
problem in order to prevent it
from becoming a more
serious service affecting
fault.
9.1.5 Alarm Notification

Instant awareness of alarms is very important for handling alarms and maintaining the network.
The equipment and the T2000 provide different means of notifying alarms to the user.
Alarm Notifying Means of the T2000

The T2000 has the following means of notifying alarms.
l Alarm color
l Alarm browsing interface
l Alarm box
l Sound box
l Remote alarm notification
Alarm Notifying Means of the Equipment

The equipment mainly uses the alarm indicators on the cabinet and boards to notify alarms at
different severity levels.
9.2 Alarm List

This chapter describes all the alarms that may be generated by the OptiX RTN 950.
9.2.1 SL91CXPR Board Alarm List
9.2.2 TND1EF8T Board Alarm List
9.2.3 TND1EF8F Board Alarm List
9.2.4 TND1EG2 Board Alarm List
9.2.5 TND1ML1/TND1ML1A Board Alarm List
9.2.6 TND1IFE2 Board Alarm List
9.2.7 TND1AUXQ Board Alarm List

9.2.8 TND1PIU Board Alarm List

9.2.9 TND1FAN Board Alarm List
9.2.10 ODU Alarm List
9.2.1 SL91CXPR Board Alarm List

BD_NOT_INSTALLED LTI RELAY_ALARM_MINOR
BD_STATUS MPLS_TUNNEL_BDI S1_SYN_CHANGE
BFD_DOWN MPLS_TUNNEL_Excess SECU_ALM
BUS_ERR MPLS_TUNNEL_FDI SWDL_ACTIVATED_TIM

EOUT
CFCARD_FAILED MPLS_TUNNEL_LOCV SWDL_AUTOMATCH_IN

H
CFCARD_OFFLINE MPLS_TUNNEL_MISMA SWDL_COMMIT_FAIL

TCH
CLK_NO_TRACE_MODE MPLS_TUNNEL_MISMER SWDL_INPROCESS

GE
COMMUN_FAIL MPLS_TUNNEL_SD SWDL_NEPKGCHECK
DBMS_ERROR MPLS_TUNNEL_SF SWDL_PKG_NOBDSOFT
DBMS_PROTECT_MODE MPLS_TUNNEL_UNKNO SWDL_PKGVER_MM

WN
ETH_APS_LOST MSSW_DIFFERENT SWDL_ROLLBACK_FAIL
ETH_APS_PATH_MISMA NESF_LOST SYN_BAD

TCH
ETH_APS_SWITCH_FAIL NESTATE_INSTALL SYNC_C_LOS
ETH_APS_TYPE_MISMA PATCH_ACT_TIMEOUT SYNC_DISABLE

TCH
EXT_SYNC_LOS PATCH_DEACT_TIMEOU SYNC_F_M_SWITCH

T
EXT_TIME_LOC PATCH_ERR SYNC_FAIL
GSP_ISIS_NB_AUTH_ER PATCH_PKGERR SYNC_LOCKOFF

R
GSP_RSVP_NB_AUTH_E PATCHFILE_NOTEXIST SYSLOG_COMM_FAIL

RR
GSP_RSVP_NB_DOWN POWER_ABNORMAL TEMP_OVER
GSP_TNNL_DOWN PW_DOWN TR_LOC

HARD_BAD RELAY_ALARM_CRITIC W_OFFLINE

AL
RELAY_ALARM_IGNOR WRG_BD_TYPE
LAG_DOWN E
LAG_MEMBER_DOWN RELAY_ALARM_MAJOR -
9.2.2 TND1EF8T Board Alarm List

ETH_LOS LOOP_ALM HARD_BAD
ETH_LINK_DOWN ETH_AUTO_LINK_DOW BD_STATUS

N
MAC_FCS_EXC TEMP_OVER TR_LOC
FLOW_OVER POWER_ABNORMAL WRG_BD_TYPE
9.2.3 TND1EF8F Board Alarm List

BD_STATUS LASER_MOD_ERR OUT_PWR_ABN
ETH_AUTO_LINK_DOW LASER_SHUT POWER_ABNORMAL

N
ETH_LINK_DOWN LOOP_ALM TEM_HA
ETH_LOS LSR_BCM_ALM TEM_LA
FLOW_OVER LSR_NO_FITED TEMP_OVER
HARD_BAD LSR_WILL_DIE TR_LOC
IN_PWR_ABN MAC_FCS_EXC WRG_BD_TYPE
9.2.4 TND1EG2 Board Alarm List

BD_STATUS LASER_MOD_ERR OUT_PWR_ABN
ETH_AUTO_LINK_DOW LASER_SHUT POWER_ABNORMAL

N
ETH_LINK_DOWN LOOP_ALM TEM_HA
ETH_LOS LSR_BCM_ALM TEM_LA
FLOW_OVER LSR_NO_FITED TEMP_OVER

HARD_BAD LSR_WILL_DIE TR_LOC
IN_PWR_ABN MAC_FCS_EXC WRG_BD_TYPE
9.2.5 TND1ML1/TND1ML1A Board Alarm List

ALM_E1RAI DOWN_E1_AIS PPP_NCP_FAIL
ALM_IMA_LIF HARD_BAD T_ALOS
ALM_IMA_LODS IMA_GROUP_LE_DOWN TEMP_OVER
ALM_IMA_RE_RX_UNUS IMA_GROUP_RE_DOWN TR_LOC

ABLE
ALM_IMA_RE_TX_UNUS IMAE1_DELAY UP_E1_AIS

ABLE
ALM_IMA_RFI LFA VC_AIS
BD_STATUS LMFA VC_LOC
CES_JTROVR_EXC LOOP_ALM VC_RDI
CES_JTRUDR_EXC MP_DELAY VP_AIS
CES_LOSPKT_EXC MP_DOWN VP_LOC
CES_MALPKT_EXC POWER_ABNORMAL VP_RDI
CES_MISORDERPKT_EX PPP_LCP_FAIL WRG_BD_TYPE

C
CES_STRAYPKT_EXC - -
9.2.6 TND1IFE2 Board Alarm List

AM_DOWNSHIFT BUS_ERR HARD_BAD
IF_CABLE_OPEN LOOP_ALM MW_BER_EXC
MW_BER_SD MW_FECUNCOR MW_LIM
MW_LOF MW_RDI R_LOC
RADIO_FADING_MA RPS_INDI TEMP_ALARM

RGIN_INSUFF
TR_LOC VOLT_LOS WRG_BD_TYPE

9.2.7 TND1AUXQ Board Alarm List

BD_STATUS FLOW_OVER POWER_ABNORMAL
ETH_AUTO_LINK_DOW HARD_BAD TEMP_OVER

N
ETH_LINK_DOWN LOOP_ALM TR_LOC
ETH_LOS MAC_FCS_EXC WRG_BD_TYPE
9.2.8 TND1PIU Board Alarm List

BD_STATUS THUNDERALM WRG_BD_TYPE
POWER_ABNORMAL - -
9.2.9 TND1FAN Board Alarm List

BD_STATUS FAN_FAIL WRG_BD_TYPE
9.2.10 ODU Alarm List

BD_STATUS CONFIG_NOSUPPORT HARD_BAD
IF_INPWR_ABN LOOP_ALM POWER_ALM
RADIO_MUTE RADIO_RSL_LOW RADIO_RSL_HIGH
RADIO_TSL_LOW RADIO_TSL_HIGH TEMP_ALARM
9.3 Alarm Handling

This chapter describes how to handle related alarms of the equipment.
9.3.1 Alarm Handling Flow
This section describes the flowchart for handling alarms on the OptiX RTN 950 equipment.
9.3.2 AM_DOWNSHIFT
9.3.3 ALM_ALS
9.3.4 ALM_E1RAI
9.3.5 ALM_IMA_LIF
9.3.6 ALM_IMA_LODS

9.3.7 ALM_IMA_RE_RX_UNUSABLE
9.3.8 ALM_IMA_RE_TX_UNUSABLE
9.3.9 ALM_IMA_RFI
9.3.10 BD_NOT_INSTALLED
9.3.11 BD_STATUS
9.3.12 BFD_DOWN
9.3.13 BUS_ERR
9.3.14 CES_JTROVR_EXC
9.3.15 CES_JTRUDR_EXC
9.3.16 CES_LOSPKT_EXC
9.3.17 CES_MALPKT_EXC
9.3.18 CES_MISORDERPKT_EXC
9.3.19 CES_STRAYPKT_EXC
9.3.20 CFCARD_FAILED
9.3.21 CFCARD_OFFLINE
9.3.22 CLK_NO_TRACE_MODE
9.3.23 COMMUN_FAIL
9.3.24 CONFIG_NOSUPPORT
9.3.25 DBMS_ERROR
9.3.26 DBMS_PROTECT_MODE
9.3.27 DOWN_E1_AIS
9.3.28 ETH_APS_LOST
9.3.29 ETH_APS_PATH_MISMATCH
9.3.30 ETH_APS_SWITCH_FAIL
9.3.31 ETH_APS_TYPE_MISMATCH
9.3.32 ETH_AUTO_LINK_DOWN
9.3.33 ETH_LINK_DOWN
9.3.34 ETH_LOS
9.3.35 EXT_SYNC_LOS
9.3.36 EXT_TIME_LOC
9.3.37 FAN_FAIL
9.3.38 FLOW_OVER
9.3.39 GSP_ISIS_NB_AUTH_ERR

9.3.40 GSP_RSVP_NB_AUTH_ERR
9.3.41 GSP_RSVP_NB_DOWN
9.3.42 GSP_TNNL_DOWN
9.3.43 HARD_BAD
9.3.44 IMA_GROUP_LE_DOWN
9.3.45 IMA_GROUP_RE_DOWN
9.3.46 IMAE1_DELAY
9.3.47 IN_PWR_ABN
9.3.48 LAG_DOWN
9.3.49 LAG_MEMBER_DOWN
9.3.50 LASER_MOD_ERR
9.3.51 LASER_SHUT
9.3.52 LFA
9.3.53 IF_CABLE_OPEN
9.3.54 IF_INPWR_ABN
9.3.55 LMFA
9.3.56 LOOP_ALM
9.3.57 LSR_BCM_ALM
9.3.58 LSR_NO_FITED
9.3.59 LSR_WILL_DIE
9.3.60 LTI
9.3.61 MAC_FCS_EXC
9.3.62 MP_DELAY
9.3.63 MP_DOWN
9.3.64 MPLS_TUNNEL_BDI
9.3.65 MPLS_TUNNEL_Excess
9.3.66 MPLS_TUNNEL_FDI
9.3.67 MPLS_TUNNEL_LOCV
9.3.68 MPLS_TUNNEL_MISMATCH
9.3.69 MPLS_TUNNEL_MISMERGE
9.3.70 MPLS_TUNNEL_SD
9.3.71 MPLS_TUNNEL_SF
9.3.72 MPLS_TUNNEL_UNKNOWN

9.3.73 MW_BER_EXC
9.3.74 MW_BER_SD
9.3.75 MW_LIM
9.3.76 MW_LOF
9.3.77 MW_RDI
9.3.78 MW_FECUNCOR
9.3.79 MSSW_DIFFERENT
9.3.80 NESF_LOST
9.3.81 NESTATE_INSTALL
9.3.82 OUT_PWR_ABN
9.3.83 PATCH_ACT_TIMEOUT
9.3.84 PATCH_DEACT_TIMEOUT
9.3.85 PATCH_ERR
9.3.86 PATCH_PKGERR
9.3.87 PATCHFILE_NOTEXIST
9.3.88 POWER_ABNORMAL
9.3.89 POWER_ALM
9.3.90 PPP_LCP_FAIL
9.3.91 PPP_NCP_FAIL
9.3.92 PW_DOWN
9.3.93 R_LOC
9.3.94 RADIO_FADING_MARGIN_INSUFF
9.3.95 RADIO_RSL_LOW
9.3.96 RADIO_RSL_HIGH
9.3.97 RADIO_TSL_LOW
9.3.98 RADIO_TSL_HIGH
9.3.99 RADIO_MUTE
9.3.100 RELAY_ALARM_CRITICAL
9.3.101 RELAY_ALARM_MAJOR
9.3.102 RELAY_ALARM_MINOR
9.3.103 RELAY_ALARM_IGNORE
9.3.104 RPS_INDI
9.3.105 S1_SYN_CHANGE

9.3.106 SECU_ALM
9.3.107 SWDL_ACTIVATED_TIMEOUT
9.3.108 SWDL_AUTOMATCH_INH
9.3.109 SWDL_COMMIT_FAIL
9.3.110 SWDL_INPROCESS
9.3.111 SWDL_NEPKGCHECK
9.3.112 SWDL_PKG_NOBDSOFT
9.3.113 SWDL_PKGVER_MM
9.3.114 SWDL_ROLLBACK_FAIL
9.3.115 SYN_BAD
9.3.116 SYNC_C_LOS
9.3.117 SYNC_DISABLE
9.3.118 SYNC_F_M_SWITCH
9.3.119 SYNC_FAIL
9.3.120 SYNC_LOCKOFF
9.3.121 SYSLOG_COMM_FAIL
9.3.122 T_ALOS
9.3.123 TEM_HA
9.3.124 TEM_LA
9.3.125 TEMP_ALARM
9.3.126 TEMP_OVER
9.3.127 THUNDERALM
9.3.128 TR_LOC
9.3.129 UP_E1_AIS
9.3.130 VC_AIS
9.3.131 VC_LOC
9.3.132 VC_RDI
9.3.133 VOLT_LOS
9.3.134 VP_AIS
9.3.135 VP_LOC
9.3.136 VP_RDI
9.3.137 WRG_BD_TYPE

9.3.1 Alarm Handling Flow

This section describes the flowchart for handling alarms on the OptiX RTN 950 equipment.
Prerequisite
l You must log in to the T2000 and display the Main Topology.
l You must be an NM user with "NE and network monitor" authority or higher.
Alarm-Handling Flowchart
Figure 9-4 describes the process of handling alarms on the OptiX RTN 950 equipment.
Figure 9-4 Flowchart for handling alarms
Start
Display Browse Current

Alarms interface
Query alarm locating

information
Whether No Click Details to display

there are alarm
Online Help
parameters
Yes
Record alarm parameters
Click Details to display

Online Help
Whether Locate the alarm causes

alarm parameters No and clear the alarms step
indicate alarm by step according to
causes handling procedure
Yes
Whether No
Clear the alarms according Contact Huawei engineers
the alarms are
to the handling procedures for technical support
cleared
Yes
End

Procedure
Step 1 On the Main Topology of the T2000, right-click the NE icon and choose Fault > Browse
Current Alarms to display the Browse Current Alarms dialog box.
Step 2 View the Locating Info column and record the locating information for each alarm.
NOTE
l The alarm locating information includes the NE that reports the alarm, slot number, board name, sub-
slot number, sub-board name, port ID, channel ID, clock source number, and other index information.
l The locating information is specific to alarms.
l If an alarm is displayed on a green background, it indicates that the alarm is cleared.
Step 3 Query and record alarm parameters in the Alarm Details field in the lower left corner.
NOTE
Certain alarm parameters indicate the alarm causes. The T2000 detects and analyzes the alarm causes, and
displays the alarm information. You can quickly find the causes of alarms according to such alarm
parameters.
Step 4 In the Handling Suggestion field in the lower right corner, click Details to display the T2000
Online Help interface, where the details on alarm handling are displayed.

l If there are alarm parameters, check whether the alarm parameters indicate the alarm causes.
If yes, go to Step 5.
l If not, go to Step 6.
l If there are no alarm parameters, go to Step 6.
Step 5 Try to clear the alarms according to the handling procedure for each alarm.
Go to Step 7.
Step 6 Find the cause of each alarm and clear the alarms step by step according to the Online Help and
experience of handling alarms.
Step 7 On the T2000, make sure that the alarms are cleared and no new alarm occurs.
NOTE
If any of the alarms cannot be cleared according to the Online Help, contact Huawei engineers for technical
support. For the contact information, see 3.15 Fault Notification and Technical Support.
----End
9.3.2 AM_DOWNSHIFT
Description
The AM_DOWNSHIFT is an alarm indicating the downshift of the AM scheme. This alarm
occurs when the AM scheme is downshifted from the highest-efficiency scheme to the lower-
efficiency scheme. When the AM scheme is upshifted from the lower-efficiency scheme to the
highest scheme, this alarm is cleared.
Attribute
Alarm ID Alarm Severity Alarm Type
0x32FA Major Communication alarm
Parameters
None.
None.

Impact on System
When the AM_DOWNSHIFT alarm occurs, the transmission capacity is reduced.
Possible Causes
The possible cause of the AM_DOWNSHIFT alarm is the degradation of the working channels.
l The external factors (for example, the climate) cause the degradation of the working
channels.
l There are interferences around the working channels.
l The ODU at the transmit end has abnormal transmit power.
l The ODU at the receive end has abnormal receive power.
Handling Procedure
Step 1 Check whether the external factors (for example, the climate) cause the degradation of the
working channels.
If... Then...
Yes The downshift is a normal phenomenon and there is no need to handle it.
No Proceed to next step.
Step 2 Check whether there are interferences around the working channels.
If... Then...
Yes Eliminate the interferences.
Step 3 Use the T2000 to check whether the transmit power of the ODU at the transmit end is abnormal.
If... Then...
Yes Rectify the fault according to the alarm at the transmit end. For how to rectify the fault,
see "Troubleshooting Microwave Links".
Step 4 Rectify the fault of the receive power at the receive end.
----End
Related Information
None.

9.3.3 ALM_ALS
Description
The ALM_ALS is an alarm of automatic laser shutdown (ALS). When the ALS function is
enabled on an optical interface of the board, but no input of light is detected, the laser is shut
down automatically. In this case, this alarm occurs on the board.
Attribute
0x0128 Minor Equipment alarm
Parameters
None.
None.
Impact on System
When the ALM_ALS alarm occurs, the system will suppresses the LSR_BCM_ALM and
OUT_PWR_ABN alarms.
Possible Causes
The cause of the ALM_ALS alarm is as follows:
The laser detects no input of light and the ALS function is enabled.
Handling Procedure
l Cause: The laser detects no input of light and the ALS function is enabled.
1. Disable the ALS function, and the alarm will be cleared automatically.
2. Optional: Rectify the faulty of no input of light, and then restart the ALS function.
----End
Related Information
None.
9.3.4 ALM_E1RAI
Description
The ALM_E1RAI is an E1 link alarm indicator on the opposite NE.

Attribute
0xf886 Minor Communication alarm
Parameters
None
None
Impact on System
When the ALM_E1RAI alarm occurs, the downlink services on the local NE are interrupted.
Possible Causes
The possible causes of the ALM_E1RAI alarm are as follows:
l Cause 1: The T_ALOS, LFA, LMFA, UP_E1_AIS or DOWN_E1_AIS alarm occurs at the
opposite end of the E1 link, and the local end receives the ALM_E1RAI alarm inserted in
the downstream by the opposite end.
l Cause 2: The physical link is interrupted.
Handling Procedure
l Cause 1: The T_ALOS, LFA, LMFA, UP_E1_AIS or DOWN_E1_AIS alarm occurs at the
opposite end of the E1 link, and the local end receives the ALM_E1RAI alarm inserted in
the downstream by the opposite end.
1. Check whether the T_ALOS, LFA, LMFA, UP_E1_AIS, or DOWN_E1_AIS alarm
occurs at the opposite end of the E1 link. For details, refer to 8.2 Querying Current
Alarms of a Board.
2. If yes, clear these alarms on the opposite NE firstly. Then, check whether the
ALM_E1RAI alarm is cleared.
1. Check whether the physical link to the opposite NE is interrupted.
2. If yes, modify the interrupted physical link.
----End
Related Information
None.
9.3.5 ALM_IMA_LIF
Description
The ALM_IMA_LIF is an alarm of out-of-frame in the IMA link. This alarm indicates
delimitation of received IMA frames is lost on the local NE.

Attribute
0xf87e Major Communication alarm
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN, for example,
Alarm Parameters (hex): 0x01 0x08. For details about each parameter, refer to the following
table.
Name Meaning
Parameter 1, Parameter 2 Indicates the ATM trunk.
Impact on System
l In the case of the ALM_IMA_LIF alarm, the IMA link in the IMA group indicated by the
alarm parameter is unavailable and thus the number of available links in the IMA group
decreases. If the service bandwidth configured for this IMA group is greater than the service
bandwidth of the available links in the IMA group, congestion occurs at the IMA ports. As
a result, the cells are lost.
l After the ALM_IMA_LIF alarm is cleared, the IMA link automatically becomes available.
l The ALM_IMA_LIF alarm will be suppressed when the UP_E1_AIS alarms occurs.
Possible Causes
The possible causes of the ALM_IMA_LIF alarm are as follows:
l Cause 1: The IMA protocols at the two ends fail to negotiate with each other.
l Cause 2: The physical link for the IMA link becomes faulty.
Handling Procedure
1. On the T2000, set the IMA Protocol Enable Status parameter to Disabled for the
NEs at the two ends. For details, refer to Configuring the IMA in Feature
Description.
2. Check the configuration of the IMA group at the two ends and ensure that the IMA
group parameters are matched.
3. Set the IMA Protocol Enable Status parameter to Enabled for the NEs at the two
ends to re-activate the IMA protocol. Then, check whether the alarm is cleared.
1. Check whether the fibers or cables are correctly connected to the ports on the NEs at
the two ends. If not, correct the fiber or cable connection.

2. Check whether the fibers or cables are faulty. If yes, replace the fibers or cables.
----End
Related Information
Frame delimitation out-of-frame
The physical layer performs frame delimitation. The start bytes of frames indicate the start point
of the field carrying information. If the frame delimitation bytes in the input bit stream are
unknown, the bit stream is considered as out-of-frame.
9.3.6 ALM_IMA_LODS
Description
The ALM_IMA_LODS is an alarm indicating that the differential delay in the IMA link crosses
the threshold. This alarm indicates that the maximum differential delay among the receive links
in the local IMA group crosses the threshold.
Attribute
0xf87f Major Communication alarm
Parameters
table.
Name Meaning
Impact on System
l In the case of the ALM_IMA_LODS alarm, the IMA link in the IMA group indicated by
the alarm parameter is unavailable and thus the number of available links in the IMA group
l After the ALM_IMA_LODS alarm is cleared, the IMA link automatically becomes
available.
Possible Causes
The possible causes of the ALM_IMA_LODS alarm are as follows:

Handling Procedure
Description.
----End
Related Information
Differential Delay
Differential delay indicates the delay difference of the services among the E1 links. A buffer of
1024 cells is provided for delay in each E1 link. The maximum differential delay is 256 ms.
9.3.7 ALM_IMA_RE_RX_UNUSABLE
Description
The ALM_IMA_RE_RX_UNUSABLE is an alarm indicating the unavailability of receiving
signals in the IMA link on the opposite NE. This alarm indicates that the IMA link fails to receive
signals and is unavailable.
Attribute
Parameters
table.

Name Meaning
Impact on System
l In the case of the ALM_IMA_RE_RX_UNUSABLE alarm, the IMA link in the IMA group
indicated by the alarm parameter is unavailable and thus the number of available links in
the IMA group decreases. If the service bandwidth configured for this IMA group is greater
than the service bandwidth of the available links in the IMA group, congestion occurs at
the IMA ports. As a result, the cells are lost.
l After the ALM_IMA_RE_RX_UNUSABLE alarm is cleared, the IMA link automatically
becomes available.
Possible Causes
The possible causes of the ALM_IMA_RE_RX_UNUSABLE alarm are as follows:
Handling Procedure
Description.
----End
Related Information
None.
9.3.8 ALM_IMA_RE_TX_UNUSABLE
Description
The ALM_IMA_RE_TX_UNUSABLE is an alarm indicating the unavailability of transmitting
signals in the IMA link on the opposite NE. This alarm indicates that the IMA link fails to
transmit signals and is unavailable.

Attribute
Parameters
table.
Name Meaning
Impact on System
l In the case of the ALM_IMA_RE_TX_UNUSABLE alarm, the IMA link in the IMA group
indicated by the alarm parameter is unavailable and thus the number of available links in
the IMA group decreases. If the service bandwidth configured for this IMA group is greater
than the service bandwidth of the available links in the IMA group, congestion occurs at
the IMA ports. As a result, the cells are lost.
l After the ALM_IMA_RE_TX_UNUSABLE alarm is cleared, the IMA link automatically
becomes available.
Possible Causes
The possible causes of the ALM_IMA_RE_TX_UNUSABLE alarm are as follows:
Handling Procedure
Description.

----End
Related Information
None.
9.3.9 ALM_IMA_RFI
Description
The ALM_IMA_RFI alarm indicates out-of-frame of the frames received in the remote IMA
link. When delimitating the frames received in the remote IMA link fails, the ALM_IMA_RFI
alarm is reported.
Attribute
0xf880 Major Communication alarm
Parameters
table.
Name Meaning
Impact on System
l In the case of the ALM_IMA_RFI alarm, the IMA link in the IMA group indicated by the
alarm parameter is unavailable and thus the number of available links in the IMA group
l After the ALM_IMA_RFI alarm is cleared, the IMA link automatically becomes available.
Possible Causes
The possible causes of the ALM_IMA_RFI alarm are as follows:

Handling Procedure
Description.
----End
Related Information
Frame delimitation out-of-frame
The physical layer performs frame delimitation. The start bytes of frames indicate the start point
of the field carrying information. If the frame delimitation bytes in the input bit stream are
unknown, the bit stream is considered as out-of-frame.
9.3.10 BD_NOT_INSTALLED
Description
The BD_NOT_INSTALLED is an alarm indicating that the logical board is not created in the
corresponding slot. If a physical board is inserted in the corresponding slot, but the logical board
is not created on the T2000, the CXPR reports the BD_NOT_INSTALLED alarm.
Attribute
Parameters
None.
None.
Impact on System
l When the BD_NOT_INSTALLED alarm occurs, the corresponding board cannot be
configured with services.
l Alarms will not occur on the board which reports the BD_NOT_INSTALLED alarm.

Possible Causes
The causes of the BD_NOT_INSTALLED alarm is as follows:
A physical board is inserted in the slot, but the corresponding logical board is not created on the
T2000.
Handling Procedure
l Cause: A physical board is inserted in the slot, but the corresponding logical board is not
created on the T2000.
1. Check whether the physical board keeps in use.
– If yes, go to step 2.
– If not, go to step 3.
2. On the T2000, add the logical board to the corresponding slot, and then the alarm is
automatically cleared. For details, refer to Adding Boards in the Configuration
Guide manual.
3. Remove the board from the equipment and keep it in proper storage with anti-static
bag. The alarm will be automatically cleared.
----End
Related Information
None.
9.3.11 BD_STATUS
Description
The BD_STATUS alarm indicates that the physical board is out of service. When the logical
board is created on the T2000 but the physical board is not inserted in the equipment, the
BD_STATUS alarm is reported.
Attribute
0x77 Major Equipment alarm
Parameters
None.
None.
Impact on System
l The physical board is not inserted in the equipment, and thus the configuration data on the
system control board cannot be delivered to this physical board. As a result, configuration
of services fails.

l Alarms will not occur on the board which reports the BD_STATUS alarm.
Possible Causes
The possible causes of the BD_STATUS alarm are as follows:
l Cause 1: The board is undergoing cold reset.

l Cause 2: The board is not inserted, or the board is inserted but in poor contact with the
backplane.
l Cause 3: The inter-board communication fails.
Handling Procedure
l Cause 1: The board is undergoing cold reset.
1. On the T2000, Check whether the working status of the board is displayed in blue in
the Running Status basic slots. If yes, the board is undergoing cold reset.
2. Wait for three to five minutes and the working status of the board turns green and is
always on. Then, check whether the BD_STATUS alarm ends.
l Cause 2: The board is not inserted, or the board is inserted but in poor contact with the
backplane.
1. Check whether the board is not inserted. If yes, insert the board.
2. Check whether the board properly contacts the backplane or the pins of connectors on
the backplane are all normal. If not, recover the abnormal pins and reinsert the board.
l Cause 3: The inter-board communication fails.
1. On the T2000. check whether the HARD_BAD or COMMUN_FAIL alarm occurs
on the board which reports the BD_STATUS alarm or on the system control board.
2. If yes, replace the board and then check whether the BD_STATUS alarm is cleared.
----End
Related Information
None.
9.3.12 BFD_DOWN
Description
The BFD_DOWN is a BFD session interruption alarm. When the port detects that the BFD state
turns to DOWN, this alarm is reported.
Attribute
0x327F Minor Communication alarm

Parameters
None.
None.
Impact on System
When the BFD session is interrupted, the LPT switching is triggered.
Possible Causes
The possible causes of the BFD_DOWN alarm are as follows:
l Cause 1: The port is not enabled.

l Cause 2: The Tag configured at the two ends is inconsistent.
l Cause 3: The board of the opposite NE is faulty.
l Cause 4: The fiber or cable is faulty.
Handling Procedure
l Cause 1: The port is not enabled.
1. On the T2000, check whether the ports at the two ends are all enabled. For details,
refer to Setting the General Attributes of Ethernet Interfaces in OptiX RTN 950 Radio
Transmission System Configuration Guide manual.
2. If not, enable the ports first and then check whether the alarm is cleared.
l Cause 2: The Tag configured at the two ends is inconsistent.
1. On the T2000, check whether the Tag configured at the two ends is consistent. For
details, refer to Setting the Layer 2 Attributes of Ethernet Interfaces in OptiX RTN
950 Radio Transmission System Configuration Guide manual.
2. If not, modify the configuration to match each other and then check whether the alarm
is cleared.
l Cause 3: The board of the opposite NE is faulty.
1. Check whether any hardware alarm, such as the HARD_BAD alarm, occurs on the
opposite NE.
2. If yes, clear the hardware alarm on the opposite NE first and then check whether the
BFD_DOWN alarm is cleared.
l Cause 4: The fiber or cable is faulty.
1. Check whether the fiber or cable connected to the port is loose. If yes, fasten the loose
fiber or cable.
2. If the BFD_DOWN alarm persists, replace the fiber or cable and then check whether
the BFD_DOWN alarm is cleared.
----End
Related Information
None.

9.3.13 BUS_ERR
Description
The BUS_ERR alarm indicates that the bus is faulty. When the board detects that the bus
becomes abnormal, the BUS_ERR alarm is reported.
Attribute
0x179 Critical Equipment alarm
Parameters
table.
Name Meaning
Parameter 1 Indicates the type of bus faults.

l 0x01: BUS_LOS.
l 0x02: BUS_OOF.
l 0x03: BUS_LOF.
l 0x04: BUS_OOA.
l 0x05: BUS_RX_DOWN. Refer to Cause 3.
l 0x06: BUS_TX_DOWN.
l 0x07: BUS_SPI_DOWN.
l 0x08: BUS_SCI_ERR.
l 0x09: BUS_OPP_CLK_LOC.
Parameter 2 Indicates the number of the faulty bus .
Impact on System
l In the case of the BUS_ERR alarm, the services that are transmitted over the bus are
interrupted or have bit errors.
l The BUS_ERR alarm will be suppressed when the HARD_BAD alarm occurs.
Possible Causes
The possible causes of the BUS_ERR alarm are as follows:

l Cause 1: The board is not properly housed in the slot.

l Cause 3: The board detects the inter-board bus is abnormal.
Handling Procedure
l Cause 1: The board is not properly housed in the slot.
1. Check whether the pins on the backplane are in normal status. If not, modify the
abnormal pins.
2. Re-insert the board that reports the BUS_ERR alarm. For details, refer to 8.19
Replacing Boards on Site.
1. Cold-reset the board that reports the BUS_ERR alarm. For details, refer to 8.16
Resetting Boards.
2. If the BUS_ERR alarm persists, replace the board that reports this alarm. For details,
refer to 5 Replacing Components.
l Cause 3: The board detects the inter-board bus is abnormal.
1. On the T2000, check whether the alarms, which indicates the clock source is lost or
is degraded, occurs. For details, refer to 8.2 Querying Current Alarms of a Board.
2. If yes, clear the clock-related alarms first, and then check whether the BUS_ERR
alarm is cleared.
3. If the BUS_ERR alarm persists, check whether the board is properly housed in the
slot. Please refer to the handling procedure of Cause 1.
----End
Related Information
None.
9.3.14 CES_JTROVR_EXC
Description
The CES_JTROVR_EXC is an alarm indicating that the number of jitter buffer overflows
exceeds the specified threshold value. If the number of jitter buffer overflows exceeds the
specified threshold value in a period (by default, 2.5s), this alarm occurs.
Attribute
0x3201 Major Communication alarm
Parameters
None.
None.

Impact on System
l The buffer area does not have enough space for the received frames, and thus the packet
loss occurs.
l If the number of jitter buffer overflows is lower than the specified threshold value in another
period (by default, 10s), this alarm is cleared automatically.
l The CES_JTROVR_EXC alarm will be suppressed when the CES_LOSPKT_EXC alarm
occurs.
Possible Causes
The possible causes of the CES_JTROVR_EXC alarm are as follows:
l Cause 1: The clocks may be not synchronous.
l Cause 2: The set buffer area is too small.
Handling Procedure
1. On the T2000, check whether there is the LTI alarm, which indicates the clocks are
not synchronous so that the ingress rate and egress rate of the buffer area are
inconsistent.
2. If yes, clear the LTI alarm first, and then check whether the CES_JTROVR_EXC
alarm is cleared.
1. On the T2000, query the configuration value of the buffer area. For details, refer to
CES Service Operation Tasks in the Configuration Guide manual.
2. According to the network plan, confirm whether the Jitter Compensation Buffering
Time can be set to a bigger value. If yes, expand the buffer area. Then, check whether
the alarm is cleared.
----End
Related Information
None.
9.3.15 CES_JTRUDR_EXC
Description
The CES_JTRUDR_EXC is an alarm indicating that the number of jitter buffer underflows
exceeds the specified threshold value. If the number of jitter buffer underflows continuously
exceeds the specified threshold value in a period (by default, 2.5s), this alarm occurs.
Attribute

Parameters
None.
None.
Impact on System
l No packets are transmitted in the buffer area, and thus the buffer area underflows.
l If the number of jitter buffer underflows is continuously lower than the specified threshold
value in another period (by default, 10s), this alarm is cleared automatically.
l The CES_JTRUDR_EXC alarm will be suppressed when the CES_LOSPKT_EXC alarm
occurs.
Possible Causes
The possible causes of the CES_JTRUDR_EXC alarm are as follows:

Handling Procedure
1. On the T2000, check whether there is the LTI alarm, which indicates the clocks are
not synchronous so that the ingress rate and egress rate of the buffer area are
inconsistent.
2. If yes, clear the LTI alarm first, and then check whether the CES_JTRUDR_EXC
alarm is cleared.
1. On the T2000, query the configuration value of the buffer area. For details, refer to
CES Service Operation Tasks in the Configuration Guide manual.
2. According to the network plan, confirm whether the Jitter Compensation Buffering
Time can be set to a bigger value. If yes, expand the buffer area. Then, check whether
----End
Related Information
None.
9.3.16 CES_LOSPKT_EXC
Description
The CES_LOSPKT_EXC is an alarm indicating that the number of lost CES packets exceeds
the specified threshold value in a unit time. If the number of lost frames continuously exceeds
the specified threshold value in a period (by default, 2.5s), this alarm occurs.

Attribute
0x31FC Major Communication alarm
Parameters
None.
None.
Impact on System
l When the packet loss rate exceeds the threshold value, the all "1"s signal is inserted in the
downstream. Thus, the services may be interrupted.
l If the number of lost frames is continuously lower than the specified threshold value in
another period (by default, 10s), this alarm is cleared automatically.
l When the CES_LOSPKT_EXC alarm occurs, the system suppresses the
CES_JTROVR_EXC, CES_JTRUDR_EXC, CES_MALPKT_EXC,
CES_MISORDERPKT_EXC and CES_STRAYPKT_EXC alarms.
Possible Causes
The possible causes of the CES_LOSPKT_EXC alarm are as follows:
l Cause 1: The bandwidth configured to the tunnel or PW is so low that the link is baffled.
l Cause 2: The cable, fiber or optical module is faulty and the signals on the link degrades.
Handling Procedure
1. On the T2000, check whether the bandwidth configured to the tunnel or PW which
carries the service is too low.
2. If yes, re-configure the tunnel or PW with a bigger bandwidth. Then, check whether
1. Make sure that the cable or fiber is well connected to the port.
2. Optional: clean the fiber and the optical module and then check whether the alarm is
cleared. For details, refer to 8.24 Inspecting and Cleaning the Optical Fiber
Connectors.
3. If the CES_LOSPKT_EXC alarm persists, replace the related fiber or optical module.
For details, refer to 5.9 Replacing the Pluggable Optical Module.
----End
Related Information
None.

9.3.17 CES_MALPKT_EXC
Description
The CES_MALPKT_EXC is an alarm indicating that the number of deformed CES packets
exceeds the specified threshold value in a unit time. If the CESoETH frame contains valid TDM
data without any error indication, but the data frame is not of the specified size, this frame is
taken as a deformed frame. If the number of deformed frames continuously exceeds the specified
threshold value in a period (by default, 2.5s), this alarm occurs.
Attribute
0x31FC Major Communication alarm
Parameters
None.
None.
Impact on System
l When the deformed frames are detected and then discarded, the packet loss rate is too high.
l If the rate of deformed frames is continuously lower than the specified threshold value in
another period (by default, 10s), this alarm is cleared automatically.
l The CES_MALPKT_EXC alarm will be suppressed when either the CES_LOSPKT_EXC
alarm or the CES_STRAYPKT_EXC alarm occurs.
Possible Causes
The possible causes of the CES_MALPKT_EXC alarm are as follows:
l Cause 1: The configured parameters of the service is incorrect, such as the high path.
Handling Procedure
l Cause 1: The configured parameters of the service is incorrect, such as the high path.
1. On the T2000, check whether the parameters of the service is correctly configured.
For details, refer to CES Service Operation Tasks in the Configuration Guide manual.
2. If not, modify the parameter of the service and then check whether the alarm is cleared.

Connectors.
----End
Related Information
None.
9.3.18 CES_MISORDERPKT_EXC
Description
The CES_MISORDERPKT_EXC is an alarm indicating that the number of lost out-of-order
CES packets exceeds specified threshold value in a unit time. If the rate of lost out-of-order
packets continuously exceeds the specified threshold value in a period (by default, 2.5s), this
alarm occurs.
Attribute
0x31FD Major Communication alarm
Parameters
None.
None.
Impact on System
l The packets are out of order, and thus the packet loss rate is too high.
l Of the rate of rate out-of-order packets is continuously lower than the specified threshold
value in another period (by default, 10s), this alarm is cleared automatically.
l The CES_MISORDERPKT_EXC alarm will be suppressed when either the
CES_LOSPKT_EXC alarm or the CES_STRAYPKT_EXC alarm occurs.
Possible Causes
The possible causes of the CES_MISORDERPKT_EXC alarm are as follows:

Handling Procedure
Connectors.
----End
Related Information
None.
9.3.19 CES_STRAYPKT_EXC
Description
The CES_STRAYPKT_EXC is an alarm indicating that the number of errored packets exceeds
specified threshold value in a unit time. If the number of errored packets continuously exceeds
the specified threshold value in a period (by default, 2.5s), this alarm occurs.
Attribute
0x31FE Major Communication alarm
Parameters
None.
None.
Impact on System
l When the errored packets are detected and then discarded, the packet loss rate is too high.
l If the number of errored packets is continuously lower than the specified threshold valued
in another period (by default, 10s), this alarm is cleared automatically.
l The CES_STRAYPKT_EXC alarm will be suppressed when the CES_LOSPKT_EXC
alarm occurs.

l When the CES_STRAYPKT_EXC alarm occurs, the system suppresses the

CES_MALPKT_EXC and CES_MISORDERPKT_EXC alarms.
Possible Causes
The possible causes of the CES_STRAYPKT_EXC alarm are as follows:
l Cause 1: The parameter configuration of the service is incorrect.

l Cause 2: The fiber or cable is misconnected.
Handling Procedure
l Cause 1: The parameter configuration of the service is incorrect.
1. On the T2000, check whether the parameter configuration of the service is correct.
2. If not, modify the configuration to recover the correct service. For details, refer to
Configuring a CES Service in the Configuration Guide manual.
l Cause 2: The fiber or cable is misconnected.
1. Check whether the fiber or cable is misconnected.
2. If yes, reconnect the fiber or calbe and check whether the alarm is cleared.
----End
Related Information
None.
9.3.20 CFCARD_FAILED
Description
The CFCARD_FAILED alarm indicates that the operation on the CF card fails.
Attribute
Parameters
None.
None.
Impact on System
When the CFCARD_FAILED alarm occurs, the database cannot be backed up to the CF card
or be restored from the CF card. This alarm may cause rollback of the package loading upgrade.

Possible Causes
The possible causes of the CFCARD_FAILED alarm are as follows:
l Cause 1: The CF card is faulty and initialization of the CF card fails.

l Cuase 2: The system control board is faulty and creation of the file system of the CF card
fails.
Handling Procedure
l Cause 1: The CF card is faulty and initialization of the CF card fails.
1. Replace the CF card and check whether the alarm is cleared. For details, refer to the
OptiX RTN 950 Radio Transmission System IDU Quick Installation Guide manual.
l Cause 2: The system control board is faulty and creation of the file system of the CF card
fails.
1. Check whether the HARD_BAD alarm occurs on the system control board.
2. If yes, cold-reset the system control board. For details, refer to 8.16 Resetting
Boards.
3. If the CFCARD_FAILED alarm persists, replace the system control board. For details,
----End
Related Information
None.
9.3.21 CFCARD_OFFLINE
Description
The CFCARD_OFFLINE alarm indicates that the CF card is out of service.
Attribute
Parameters
None.
None.
Impact on System
When the CFCARD_FAILED alarm occurs, the database cannot be backed up to the CF card
or be restored from the CF card. This alarm may cause rollback of the package loading upgrade.

Possible Causes
The possible cause of the CFCARD_OFFLINE alarm is as follows:
l Cause 1: The CF card is not inserted.
l Cause 2: The CF card is in poor contact with the system control board.
l Cause 3: The system control board is faulty.
Handling Procedure
l Cause 1: The CF card is not inserted.
1. Check whether the CF card is installed on the system control board.
2. If not, install the CF card. For details, refer to the OptiX RTN 950 Radio Transmission
System IDU Quick Installation Guide manual.
l Cause 2: The CF card is in poor contact with the system control board.
1. Check whether the CF card is loosened. If yes, re-insert the CF card.
2. If the CFCARD_OFFLINE alarm persists, replace the CF board.
1. Check whether the HARD_BAD alarm occurs on the system control board.
2. If yes, cold-reset the system control board. For details, refer to 8.16 Resetting
Boards.
3. If the CFCARD_FAILED alarm persists, replace the system control board. For details,
----End
Related Information
None.
9.3.22 CLK_NO_TRACE_MODE
Description
The CLK_NO_TRACE_MODE alarm indicates that the clock enters the non-tracing mode.
When the current system clock has no clock source to trace, the CLK_NO_TRACE_MODE
alarm is reported.
Attribute
0x014d Minor Equipment alarm
Parameters

table.
Name Meaning
Parameter 1 l 0x01: The clock changes from the tracing mode to the holdover mode.
l 0x02: The clock enters the free-run mode.
Impact on System
In the case of the CLK_NO_TRACE_MODE alarm, the clock is in the non-tracing mode. In
this case, the system clock is of low quality. If the low-quality clock results in the asynchronous
state among NEs, the BER of services increases.
Possible Causes
The possible causes of the CLK_NO_TRACE_MOD alarm are as follows:
l Cause 1: The SSM protocol is not enabled.

l Cause 2: The priority table of system clock sources is not configured and the NE adopts
the default priority table.
l Cause 3: Except the internal clock source, other clock sources in the priority table lose the
existence status and thus are not traceable.
l Cause 4: Except the internal clock source, other clock sources in the priority table have
excessive frequency deviation and thus are not traceable.
Handling Procedure
l Cause 1: The SSM protocol is not enabled.
1. On the T2000, check whether the SSM protocol is enabled at both ends. For details,
refer to Configuring the Clock Source Protection in Configuration Guide manual.
2. If not, enable the SSM protocol at both ends.
l Cause 2: The priority table of system clock sources is not configured and the NE adopts
the default priority table.
1. On the T2000, check whether the priority table of clock sources is configured. For
details, refer to Configuring the NE Clock Source.
2. If not, re-configure the priority table of clock sources, which should include other
available clock sources.
l Cause 3: Except the internal clock source, other clock sources in the priority table lose the
existence status and thus are not traceable.
1. On the T2000, check whether there is the SYNC_C_LOS alarm. For details, refer to
8.2 Querying Current Alarms of a Board.
2. If yes, clear the SYNC_C_LOS alarm first. Then, the system clock can trace any other
clock source except the internal clock source.
l Cause 4: Except the internal clock source, other clock sources in the priority table have
excessive frequency deviation and thus are not traceable.
1. On the T2000, check whether there is the SYN_BAD alarm.

2. If yes, clear the SYN_BAD alarm first. Then, the system clock can trace any other
clock source except the internal clock source.
----End
Related Information
None.
9.3.23 COMMUN_FAIL
Description
The COMMUN_FAIL alarm indicates that the inter-board communication fails. When the
communication between the system control board and other boards is interrupted, the
COMMUN_FAIL alarm is reported.
Attribute
0xC7 Major Equipment alarm
Parameters
table.
Name Meaning
Parameter 1 Indicates the slot number of the board which fails in communicating with the
system control board.
Parameter 2 Reserved. By default, parameter 2 is 0.
Parameter 3 Indicates the path number of the path that reports the alarm. The indication is as
follows:
l 0x01: An alarm that occurs in path 1 of the RS485.
l 0x02: An alarm that occurs in path 2 of the RS485.
l 0x03: Inter-board Ethernet communication.
l 0x04: Inter-subrack Ethernet emergency communication.

Impact on System
l When the COMMUN_FAIL alarm occurs, the configuration data on the system control
board cannot be delivered to the board or the board fails to work. As a result, the service
cannot be configured or the equipment-level protection switching fails.
l The COMMUN_FAIL alarm will be suppressed when the HARD_BAD alarm occurs.
Possible Causes
In the case of the COMMUN_FAIL alarm, first check whether one board or multiple boards
report the COMMUN_FAIL alarm. The possible causes of the COMMUN_FAIL alarm are as
follows:
l Cause 1 for one board reporting the alarm: The board is undergoing cold reset.
l Cause 2 for one board reporting the alarm: The board is faulty.
l Cause 1 for multiple boards reporting the alarm: The EXT interface on the system control
board is directly connected to a hub or switch.
l Cause 2 for multiple boards reporting the alarm: The CXPR board is off service or is faulty.
l Cause 3 for multiple boards reporting the alarm: The PIU board is improperly inserted or
faulty. As a result, the power supply to the backplane is insufficient.
Handling Procedure
l Cause 1 for one board reporting the alarm: The board is undergoing cold reset.
1. On the T2000, Check whether the working status of the board is displayed in blue in
the Running Status basic slots. If yes, the board is undergoing cold reset.
2. Wait for three to five minutes and the working status of the board turns green and is
always on. Then, check whether the COMMUN_FAIL alarm ends.
l Cause 2 for one board reporting the alarm: The board is faulty.
1. Replace the board that reports the HARD_ERR alarm. For details, refer to 5 Replacing
Components.
l Cause 1 for multiple boards reporting the alarm: The EXT interface on the system control
board is directly connected to a hub or switch.
1. Check whether the EXT interface on the system control board is directly connected
to a hub or switch. If yes, the VLAN of the equipment may be lost, and thus the EXT
interface on the local NE is interconnected to the ETH ports of other transmission
equipment on the network. As a result, the IP addresses of the boards on different
equipment conflict.
2. Disconnect the EXT interface from the hub or switch, or connect the EXT interface
indirectly to the hub or switch.
NOTE
l The VLAN of the equipment isolates different NEs on the network to ensure that
communication on each NE does not affect each other.
l The main subrack and extended subrack are connected through the EXT interface, which
transfers the management information and thus cannot be connected to any hub or switch.
l Cause 2 for multiple boards reporting the alarm: The CXPR board is off service or is faulty.
1. Check whether the CXPR board reports the BD_STATUS or BUS_ERR alarm.

2. If yes, clear the BD_STATUS or BUS_ERR alarm first and check whether the
COMMUN_FAIL alarm is cleared.
3. If the COMMUN_FAIL alarm persists, replace the CXPR board and check whether
the COMMUN_FAIL alarm is cleared. For details, refer to 5 Replacing
Components.
l Cause 3 for multiple boards reporting the alarm: The PIU board is improperly inserted or
faulty. As a result, the power supply to the backplane is insufficient.
1. Check whether the PIU board is properly inserted. If not, re-insert the power input
board properly.
2. Check whether the PIU board reports the HARD_BAD alarm. If yes, replace the
power input board. For details, refer to 5 Replacing Components.
----End
Related Information
None.
9.3.24 CONFIG_NOSUPPORT
Description
The CONFIG_NOSUPPORT is an alarm indicating that the configuration is not supported. This
alarm is reported if the ODU detects that the configured parameters do not match those of the
ODU.
Attribute
0x0280 Major Processing alarm
Parameters
table.

Name Meaning
Parameter 1 Indicates the mismatched parameter.
l 0x01: Indicates the frequency configuration error.
l 0x02: Indicates the TR spacing configuration error.
l 0x03: Indicates the transmit power configuration error.
l 0x04: Indicates the ATPC threshold configuration error.
l 0x05: Indicates the bandwidth configuration error.
l 0x06: Indicates the modulation mode configuration error.
Impact on System
The ODU fails to work normally. If the equipment is configured with 1+1 FD protection, the
main ODU generates the CONFIG_NOSUPPORT alarm. In this case, IF 1+1 protection
switching may be triggered.
Possible Causes
The type of the ODU mismatches the configured parameters.
Handling Procedure
Step 1 Determine the mismatched parameter according to the alarm parameters.
Step 2 Check whether the ODU interface parameters meet the network planning requirements when
the alarm parameters are 0x01–0x03. For details, refer to the OptiX RTN 950 Radio Transmission
System Configuration Guide manual.
If... Then...
Yes Replace the ODU with a correct one.
No Modify the parameters.
Step 3 Check whether the IF interface parameters meet the network planning requirements when the
alarm parameters are 0x04–0x06.
If not, modify the parameters. For details, refer to the OptiX RTN 950 Radio Transmission System
IDU Configuration Guide manual.
----End
Related Information
None.
9.3.25 DBMS_ERROR
Description
The DBMS_ERROR is a database error alarm indicating the database file verification failure.

Attribute
0xB9 Major Processing alarm
Parameters
table.
Name Meaning
Parameter 1 Indicates the alarm type, which indicates the error code that causes the alarm.
Parameter 2 Indicates the database storage area that has errors.

l 0x00: FDB0.
l 0x01: FDB1.
l 0x02: DRDB.
Parameter 3 Indicates the ID of the database that has errors.

l 0x00: Entire database storage area that has errors.
l 0x01 - 0xFF: Specific database that has errors.
Impact on System
When the DBMS_ERROR alarm occurs, the data in the database cannot be backed up or
automatically restored. Hence, the data in the database is lost.
Possible Causes
The possible causes of the DBMS_ERROR alarm are as follows:
l Cause 1: The database files are damaged, and thus the database operation fails.
l Cause 2: The CXPR board is faulty.
Handling Procedure
l Cause 1: The database files are damaged, so the database operation fails.
1. Restore the database by backing up the database manually, and then check and test
the backup database. For details, refer to Backing Up the NE Configuration Data to a
Local Server.
2. After the database is restored, the alarm is cleared automatically.

1. Check whether the hardware alarms such as the HARD_BAD alarm occur on the
CXPR board.
2. If yes, replace the CXPR board, and then check whether the DBMS_ERROR alarm
is cleared. For details, refer to 5 Replacing Components.
----End
Related Information
None.
9.3.26 DBMS_PROTECT_MODE
Description
The DBMS_PROTECT_MODE is an alarm indicating that the NE database enters the protection
mode.
Attribute
0x00C6 Critical Processing alarm
Parameters
None.
None.
Impact on System
When the DBMS_PROTECT_MODE alarm occurs, the NE database is in the protection mode
and cannot be backed up. In addition, all the new configuration data in the database is lost after
the NE resets.
Possible Causes
The cause of the DBMS_PROTECT_MODE alarm is as follows:
The NE software is frequently reset in a certain period.
Handling Procedure
l Cause: The NE software is frequently reset in a certain period.
1. Find out the cause for the frequent resetting of the NE software and then handle it.
2. After the fault is rectified, reset the NE software. As a result, the database exits the
protection mode. Thus, check whether the alarm is cleared.
----End

Related Information
None.
9.3.27 DOWN_E1_AIS
Description
The DOWN_E1_AIS is an alarm indicating the downstream 2 Mbit/s signals. If the board detects
that the downstream E1 signals is all "1"s, this alarm occurs.
Attribute
0xC9 Minor Communication alarm
Parameters
None.
None.
Impact on System
When the DOWN_E1_AIS alarm occurs, the services are interrupted..
Possible Causes
The possible causes of the DOWN_E1_AIS alarm are as follows:
l Cause 1: The UP_E1_AIS or T_ALOS alarm occurs on the same board.
Handling Procedure
l Cause 1: The UP_E1_AIS or T_ALOS alarm occurs on the same board.
1. On the T2000, check whether the UP_E1_AIS or T_ALOS alarm occurs on the same
board. For details, refer to 8.2 Querying Current Alarms of a Board.
2. If yes, clear the UP_E1_AIS or T_ALOS alarm first and check whether the
DOWN_E1_AIS alarm is cleared.
1. On the T2000, check whether the hardware-related alarms occur on the local board or
on the cross-connect board, such as the HARD_BAD alarm.
2. If yes, cold-reset the board that reports the hardware-related alarm and check whether
the DOWN_E1_AIS alarm is cleared. For details, refer to 8.16 Resetting Boards.
3. If the DOWN_E1_AIS alarm persists, replace the related board and check whether
the DOWN_E1_AIS alarm is cleared. For details, refer to 5 Replacing
Components.
----End

Related Information
None.
9.3.28 ETH_APS_LOST
Description
The ETH_APS_LOST alarm indicates loss of the APS frames. When no APS frames are received
from the protection channel, the ETH_APS_LOST alarm is reported.
Attribute
0x3222 Minor Communication alarm
Parameters
None.
None.
Impact on System
l In the case of the ETH_APS_LOST alarm, service protection cannot be performed.
l The ETH_APS_LOST alarm will be suppressed when the
ETH_APS_PATH_MISMATCH alarm occurs.
l When the ETH_APS_LOST alarm occurs, the system suppresses the
ETH_APS_SWITCH_FAIL and ETH_APS_TYPE_MISMATCH alarms.
Possible Causes
The possible causes of the ETH_APS_LOST alarm are as follows:
l Cause 1: The opposite end is not configured with protection.
l Cause 2: The configuration of the APS protection group is inconsistent at the two ends.
l Cause 3: The APS protection group is not enabled.
l Cause 4: Services in the protection channel are interrupted.
Handling Procedure
l Cause 1: The opposite end is not configured with protection.
1. On the T2000, check whether the opposite end is configured with protection. For
details, refer to Creating an MPLS Tunnel Protection Group in the OptiX RTN 950
Radio Transmission System Configuration Guide.
2. If not, configure the APS protection group and make sue the configuration at the two
ends is consistent. Then, enable the APS protocol.
l Cause 2: The configuration of the APS protection group is inconsistent at the two ends.

1. On the T2000, check whether the configuration is consistent at the two ends.
2. If not, modify the configuration of the APS protection group so that the configuration
at the two ends is consistent.
l Cause 3: The APS protection group is not enabled.
1. Check whether the APS protocol is enabled at the two ends.
2. If not, set the status of the enabled APS protocol to Disabled. Then, enable the APS
protocol at the two ends.
l Cause 4: Services in the protection channel are interrupted.
1. Check whether there are alarms indicating loss of signals or service degrade in the
protection channel, such as the ETH_LOS alarm.
2. If yes, take the first to clear these alarms.
----End
Related Information
None.
9.3.29 ETH_APS_PATH_MISMATCH
Description
The ETH_APS_PATH_MISMATCH is an alarm indicating that the working and protection
paths of the APS are inconsistent. This alarm occurs when the working and protection paths of
the equipment in the protection group are inconsistent at the two ends.
Attribute
Parameters
None.
None.
Impact on System
l In the case of the ETH_APS_PATH_MISMATCH alarm, the services cannot be protected.
l When the ETH_APS_PATH_MISMATCH alarm occurs, the system suppresses the
ETH_APS_LOST, ETH_APS_SWITCH_FAIL, and ETH_APS_TYPE_MISMATCH
alarms.
Possible Causes
The possible causes of the ETH_APS_PATH_MISMATCH alarm are as follows:

l Cause 1: The configured working and protection paths of the equipment in the protection
group at the two ends are inconsistent.
l Cause 2: Certain physical links are incorrectly connected.
Handling Procedure
l Cause 1: The configured working and protection paths of the equipment in the protection
group at the two ends are inconsistent.
1. On the T2000, check whether the configuration is consistent at the two ends of the
APS protection group. For details, refer to Creating an MPLS Tunnel Protection Group
in the OptiX RTN 950 Radio Transmission System Configuration Guide.
2. If the configuration is inconsistent, modify the configuration of the APS protection
group, and make sure that the configuration is consistent at the two ends of the APS
protection group. Then, check whether the alarm is cleared.
l Cause 2: Certain physical links are incorrectly connected.
1. Check whether the fiber and cable connections are correct on each NE from the local
end to the opposite end.
2. If not, reconnect the fibers and cables, and then check whether this alarm is cleared.
----End
Related Information
None.
9.3.30 ETH_APS_SWITCH_FAIL
Description
The ETH_APS_SWITCH_FAIL alarm indicates a protection switching failure. When the
request signals in the transmitted APS frames are inconsistent with the bridge signals in the
received APS frames for 50 ms, the switching fails and the ETH_APS_SWITCH_FAIL alarm
is reported.
Attribute
0x3221 Major Processing failure alarm
Parameters
None.
None.
Impact on System
l In the case of the ETH_APS_SWITCH_FAIL alarm, the services cannot be protected.

l The ETH_APS_SWITCH_FAIL alarm will be suppressed when the

ETH_APS_PATH_MISMATCH or ETH_APS_LOST alarm occurs.
Possible Causes
The possible cause of the ETH_APS_SWITCH_FAIL alarm is as follows:
The configuration of the APS protection group is inconsistent at the two ends.
Handling Procedure
l Cause: The configuration of the APS protection group is inconsistent at the two ends.
1. On the T2000, check whether the configuration is consistent at the two ends of the
APS protection group. For details, refer to Creating an MPLS Tunnel Protection Group
in the OptiX RTN 950 Radio Transmission System Configuration Guide.
2. Modify the configuration of the APS protection group so that the configuration at the
two ends is consistent.
3. Re-deactivate and re-activate the APS protection at the two ends.
----End
Related Information
None.
9.3.31 ETH_APS_TYPE_MISMATCH
Description
The ETH_APS_TYPE_MISMATCH is an alarm indicating the protection scheme information
mismatch. This alarm occurs when the information in the received APS frames is inconsistent
with the APS protection scheme configured at the local end.
Attribute
0x321F Major Communication alarm
Parameters
table.

Name Meaning
Parameter 1 The indication of Parameter 1 is as follows:
l 0x01: Inconsistency of protection group protection type. Refer to Cause 1.
l 0x02: Inconsistency of protection group switching mode. Refer to Cause 2.
l 0x03: Inconsistency of protection group revertive mode. Refer to Cause 3.
Impact on System
l The ETH_APS_TYPE_MISMATCH alarm may cause the APS protection failure, and thus
the services cannot be effectively protected.
l The ETH_APS_TYPE_MISMATCH alarm will be suppressed when the
ETH_APS_PATH_MISMATCH or ETH_APS_LOST alarm occurs.
Possible Causes
The possible causes of the ETH_APS_TYPE_MISMATCH alarm are as follows:
l Cause 1: Inconsistency of protection group protection type.

l Cause 2: Inconsistency of protection group switching mode.
l Cause 3: Inconsistency of protection group revertive mode.
Handling Procedure
l Cause: Inconsistency of protection group protection type, switching mode, or revertive
mode.
1. On the T2000, check whether the configuration of the protection group is consistent
at the two ends. For details, refer to Creating an MPLS Tunnel Protection Group in
the OptiX RTN 950 Radio Transmission System Configuration Guide.
2. If not, modify the configuration of the APS protection group so that the configuration
at the two ends is consistent. Then, re-enable the APS protocol and the alarm will be
cleared automatically.
----End
Related Information
None.
9.3.32 ETH_AUTO_LINK_DOWN
Description
The ETH_AUTO_LINK_DOWN is a port automatic link down alarm. When the LPT triggers
the shutdown of the physical port, this alarm is reported.

Attribute
Parameters
None
None
Impact on System
When the alarm occurs, the LPT triggers the shutdown of the physical port, and related services
at other ports are interrupted.
Possible Causes
The possible causes of the ETH_AUTO_LINK_DOWN alarm are as follows:
l Cause 1: BFD is bound to the active LPT port. When the board is faulty and the BFD state
is DOWN, the standby LPT port is disabled.
l Cause 2: The fiber or network cable connected to the active LPT port becomes faulty. As
a result, the standby LPT port is disabled.
Handling Procedure
l Cause 1: BFD is bound to the active LPT port. When the board is faulty and the BFD state
is DOWN, the standby LPT port is disabled.
1. Check whether any hardware alarm, such as the HARD_BAD alarm, occurs on the
two NEs.
2. If yes, clear the hardware alarm first and then check whether the
ETH_AUTO_LINK_DOWN alarm is cleared.
l Cause 2: The fiber or network cable connected to the active LPT port becomes faulty. As
a result, the standby LPT port is disabled.
1. Remove and insert the fiber or network cable, and then check whether the alarm is
cleared.
2. If the alarm persists, replace the fiber or the network cable.
----End
Related Information
None.

9.3.33 ETH_LINK_DOWN
Description
The ETH_LINK_DOWN alarm indicates that the Ethernet port connection is faulty. When the
Ethernet port is incorrectly connected, the port fails to negotiate and the ETH_LINK_DOWN
alarm is reported.
Attribute
0x31F9 Critical Communication alarm
Parameters
None.
None.
Impact on System
l When the ETH_LINK_DOWN alarm occurs during data transmission, the Ethernet port
fails to negotiate and to receive data. As a result, the services are interrupted.
l The ETH_LINK_DOWN alarm will be suppressed when the ETH_LOS alarm occurs.
l In the case of the ETH_LINK_DOWN alarm, the system suppresses the
LAG_MEMBER_DOWN and MAC_FCS_EXC alarms.
Possible Causes
The possible causes of the ETH_LINK_DOWN alarm are as follows:
l Cause 1: The Ethernet ports on the local NE and opposite NE work in different modes and
thus fail to negotiate.
l Cause 2: Inloop is set on the port.
Handling Procedure
l Cause 1: The Ethernet ports on the local NE and opposite NE work in different modes and
thus fail to negotiate.
1. On the T2000, check whether the Ethernet ports at the two ends work in the same
mode.
2. If not, modify the configuration so that they work in the same mode. Then, check
whether the alarm is cleared. For details, refer to 8.22 Querying and Setting the
Working Mode of Ethernet Interface.
l Cause 2: Inloop is set on the port.
1. On the T2000, check whether the ports at the two ends reports the LOOP_ALM alarm.

2. If yes, clear the LOOP_ALM alarm first and then check whether the
ETH_LINK_DOWN alarm is cleared.
1. On the T2000, check whether there is hardware-related alarm occurs on the board of
the two NEs, such as the HARD_BAD alarm.
2. If yes, replace the board that reports the hardware-related alarm and then check
whether the ETH_LINK_DOWN alarm is cleared. For details, refer to 5 Replacing
Components.
----End
Related Information
None.
9.3.34 ETH_LOS
Description
The ETH_LOS alarm indicates that the connection to the Ethernet port is lost. When the Ethernet
port receives no Ethernet signals, the ETH_LOS alarm is reported.
Attribute
0xeb Critical Communication alarm
Parameters
None.
None.
Impact on System
l When the ETH_LOS alarm occurs, the Ethernet port cannot receive data and thus the
services are interrupted.
l The ETH_LOS alarm will be suppressed when one of the LSR_NO_FITED and
LASER_MOD_ERR alarms occurs.
l In the case of the ETH_LOS alarm, the system will suppresses the other alarms related to
Ethernet service.
Possible Causes
The possible causes of the ETH_LOS alarm are as follows:
l Cause 1: The cable or fiber is not properly connected to the Ethernet port.
l Cause 2: The network cable or fiber is faulty.
l Cause 3: The optical power received by the local NE is excessively low.

Handling Procedure
l Cause 1: The cable or fiber is not properly connected to the Ethernet port.
1. Check whether the cable or fiber is properly connected to the Ethernet port. Reconnect
the loosen cable or fiber.
l Cause 2: The network cable or fiber is faulty.
1. Check whether the cable or fiber is faulty. Replace the faulty cable or fiber.
l Cause 3: The optical power received by the local NE is excessively low.
1. On the T2000, check whether the OUT_PWR_ABN alarm occurs on the opposite NE.
If yes, clear the OUT_PWR_ABN alarm first and check whether the ETH_LOS alarm
on the local NE is cleared. For details, refer to 8.2 Querying Current Alarms of a
Board.
2. If the ETH_LOS alarm persists, clean the receive interface and the fiber header. For
details, refer to 8.24 Inspecting and Cleaning the Optical Fiber Connectors.
3. If the ETH_LOS alarm still persists, check whether the flange or optical attenuator is
correctly connected and whether the attenuation of the optical attenuator is excessively
high. Correctly use the flange and optical attenuator.
4. If the ETH_LOS alarm still persists, adjust the optical power so that the optical power
is within the normal range by adding or removing optical attenuators.
1. Replace the processing board that reports the alarm. For details, refer to 5 Replacing
Components.
2. If the ETH_LOS alarm persists, replace the processing board on the opposite NE.
----End
Related Information
None.
9.3.35 EXT_SYNC_LOS
Description
The EXT_SYNC_LOS is an alarm indicating the loss of external clock source. This alarm occurs
when the system detects the loss of the external clock source traced by the equipment.
Attribute
0xB8 Critical Equipment alarm

Parameters
Name Meaning
Parameter 1 Indicates the lost external clock source.

l 0x01: The first channel of the external clock source.
l 0x02: The second channel of the external clock source.
Impact on System
When the EXT_SYNC_LOS alarm occurs, the external clock source of the system is lost and
cannot be traced by the equipment. In this case, the clock quality is degraded, which affects the
service quality. Thus, bit errors may be generated.
Possible Causes
The possible causes of the EXT_SYNC_LOS alarm are as follows:
l Cause 1: The configured mode of the external clock source is inconsistent with the actual
mode of the clock input.
l Cause 3: The clock input cable connection is incorrect.
l Cause 4: The signal at the physical interface of the external clock source is lost.
Handling Procedure
l Cause 1: The configured mode of the external clock source is inconsistent with the actual
mode of the clock input.
1. On the T2000, check whether the actual mode and the configured mode of the clock
input are consistent. For details, refer to Configuring the NE Clock Source in the
Configuration Guide manual.
2. If the actual mode and the configured mode of the clock input are inconsistent,
reconfigure the mode of the external clock source. Make sure that both the configured
mode and the actual mode of the clock input are 2 MHz or 2 Mbit/s, and then check
whether the alarm is cleared.
1. On the T2000, check whether the hardware alarms such as the HARD_BAD alarm
occur on the CXPR board.
2. If yes, clear these alarms and then check whether the EXT_SYNC_LOS alarm is
cleared.
l Cause 3: The clock input cable connection is incorrect.
1. Check whether the clock input cable connection is correct.
2. If not, reconnect the clock cable and check whether the alarm is cleared.
l Cause 4: The signal at the physical interface of the external clock source is lost.
1. Check whether the output signals of the external clock equipment are normal.

2. If not, replace the faulty external clock equipment, and then check whether the alarm
is cleared.
----End
Related Information
None.
9.3.36 EXT_TIME_LOC
Description
The EXT_TIME_LOC alarm indicates loss of the external time source. When the external time
input port is enabled but the board detects no input external time signals, the EXT_TIME_LOC
alarm is reported.
Attribute
0x32AC Major Equipment alarm
Parameters
None.
None.
Impact on System
In the case of the EXT_TIME_LOC alarm, the time of the local NE cannot be synchronized with
the external time device that is connected to the enabled external time port on the local NE.
Possible Causes
The possible causes of the EXT_TIME_LOC alarm are as follows:
l Cause 1: The cable is disconnected or loosened from the external time interface.
l Cause 2: The external time device does not output signals.
Handling Procedure
l Cause 1: The cable is disconnected or loosened from the external time interface.
1. Check whether the cable is disconnected or loosened from the external time interface.
If the cable is disconnected or loosened from the external time interface, reconnect
the cable.
2. If the alarm persists, check whether the cable is faulty. If the cable is faulty, replace
the faulty cable.
l Cause 2: The external time device does not output signals.

1. Check whether the external time device outputs signals. If the external time device
does not output signals, replace the external time device.
----End
Related Information
None.
9.3.37 FAN_FAIL
Description
The FAN_FAIL alarm indicates that a fan is faulty. When a fan becomes faulty, the FAN_FAIL
alarm is reported.
Attribute
Parameters
table.
Name Meaning
Parameter 1 Indicates the number of faulty fans.
Impact on System
l When any fan on the FAN board becomes faulty, the other fans rotate at the full rate for
proper heat dissipation.
l If the FAN_FAIL alarm is not cleared in a timely manner, the boards on the NE may be
damaged due to over-heat and thus the services on the NE may be interrupted.
Possible Causes
The cause of the FAN_FAIL alarm is as follows:
One or more fans on the fan board are faulty.
Handling Procedure
l Cause: One or more fans on the fan board are faulty.

1. Re-insert the FAN board.

2. If the FAN_FAIL alarm persists, replace the FAN board. For details, refer to 5.5
Replacing the FAN Board.
----End
Related Information
None.
9.3.38 FLOW_OVER
Description
The FLOW_OVER is an alarm indicating that the received flow of the port exceeds the threshold.
This alarm occurs when the received flow of the Ethernet port exceeds the Max Reserved
Bandwidth.
Attribute
0x300D Minor Equipment alarm
Parameters
table.
Name Meaning
Parameter 1, Parameter 2 Indicates that the received flow exceeds the threshold. The unit is
Mbit/s.
Impact on System
l During the data transmission, if the configured bandwidth is lower than the actual flow at
the port, the FLOW_OVER alarm occurs and packet loss may occurs.
l If the configured bandwidth is higher than the actual flow at the port, the alarm occurs but
the system and services are not affected.
Possible Causes
The cause of the FLOW_OVER alarm is as follows:
The actually received flow of the port is higher than the configured Max Reserved
Bandwidth.

Handling Procedure
l Cause: The actually received flow of the port is higher than the configured Max Reserved
Bandwidth.
1. Refer to the alarm parameters and check whether the actually received flow reaches
the port bandwidth limit.
2. On the T2000, check whether the Max Reserved Bandwidth reaches the port
bandwidth limit. For details, refer to Setting the Layer 3 Attributes of an Ethernet
Interface in the OptiX RTN 950 Radio Transmission System Configuration Guide
manual.
3. Increase the Max Reserved Bandwidth of the port to a value that is higher than the
actually received flow. Then, check whether the alarm is cleared.
4. The port has no spare bandwidth. Decrease the data flow transmitted from the opposite
NE to avoid packet loss and check whether the alarm is cleared.
----End
Related Information
None.
9.3.39 GSP_ISIS_NB_AUTH_ERR
Description
The GSP_ISIS_NB_AUTH_ERRN alarm indicates the ISIS neighbor authentication error.
When the authentication configured on the two neighbors is inconsistent, the alarm occurs.
Attribute
0x32C4 Major Communication alarm
Parameters
table.

Name Meaning
Parameter 1 to parameter 4 Indicates the IP site of the local NE.
Parameter 5 to parameter 8 Indicates the IP site of the opposite NE.
Impact on System
l When the GSP_ISIS_NB_AUTH_ERR alarm occurs, service signals are not affected. But
as the neighborhood cannot be created, the reachable of control packet is affected.
l When the authentication configured on the two neighbors is consistent, the alarm is cleared
automatically.
Possible Causes
The cause of the GSP_ISIS_NB_AUTH_ERR alarm is as follows:
The authentication configured on the two neighbors is inconsistent.
Handling Procedure
l Cause: The authentication configured on the two neighbors is inconsistent.
1. On the T2000, check whether the authentication configured on the two neighbors is
consistent. For details, refer to Configuring the IGP-ISIS Protocol in the OptiX RTN
NOTE
The short querying procedure is as follows:

NE Explorer > Configuration > Control Plane Configuration > IGP-ISIS
Configuration > Port Configuration .
2. If not, modify the authentication configuration on the two neighbors and make the
Authentication Mode and Authentication Type be consistent. Then, check whether
----End
Related Information
None.
9.3.40 GSP_RSVP_NB_AUTH_ERR
Description
The GSP_RSVP_NB_AUTH_ERRN alarm indicates the RSVP neighbor authentication error.
When the authentication configured on the two neighbors is inconsistent, the alarm occurs.

Attribute
Parameters
table.
Name Meaning
Impact on System
l When the GSP_RSVP_NB_AUTH_ERR alarm occurs, service signals are not affected.
But as the neighborhood cannot be created, the reachable of control packet is affected.
l When the authentication configured on the two neighbors is consistent, the alarm is cleared
automatically.
Possible Causes
The cause of the GSP_RSVP_NB_AUTH_ERR alarm is as follows:
The authentication configured on the two neighbors is inconsistent.
Handling Procedure
l Cause: The authentication configured on the two neighbors is inconsistent.
1. On the T2000, check whether the authentication configured on the two neighbors is
consistent.
2. If not, modify the authentication configurations on the two neighbors and make sure
that the configurations of Authentication Type be consistent. Then, check whether
----End
Related Information
None.

9.3.41 GSP_RSVP_NB_DOWN
Description
The GSP_RSVP_NB_DOWN alarm indicates the RSVP neighbor down. When the receiving
of RSVP hello packets is interrupted, the alarm occurs.
Attribute
Parameters
table.
Name Meaning
Impact on System
l When the GSP_RSVP_NB_DOWN alarm occurs, service signals are not affected. but the
reachable of control packet is affected.
l When the receiving of RSVP hello packets is recovered, the alarm is cleared automatically.
Possible Causes
The cause of the GSP_RSVP_NB_DOWN alarm is as follows:
l Cause 1: The RSVP protocol is disabled on the neighbor NE.

l Cause 2: The physical link is faulty.
Handling Procedure
l Cause 1: The RSVP protocol is disabled on the neighbor NE.
1. On the T2000, check whether the RSVP protocol is enabled on the neighbor NE. For
details, refer to Configuring the MPLS-RSVP Protocol in the OptiX RTN 950 Radio

2. If not, re-enable the RSVP protocol and check whether the GSP_RSVP_NB_DOWN
alarm is cleared.
1. Check whether the physical link connected to the two neighbor NEs is faulty.
2. If yes, repair the faulty link and check whether the alarm is cleared.
1. On the T2000, check whether the HARD_BAD alarm occurs on the line board or on
the system control board of the two neighbor NEs.
2. If yes, cold-reset the board that reports the HARD_BAD alarm and check whether the
GSP_RSVP_NB_DOWN alarm is cleared. For details, refer to 8.16 Resetting
Boards.
3. If the GSP_RSVP_NB_DOWN alarm persists, replace the related board and check
whether the GSP_RSVP_NB_DOWN alarm is cleared. For details, refer to 5
Replacing Components.
----End
Related Information
None.
9.3.42 GSP_TNNL_DOWN
Description
The GSP_TNNL_DOWN alarm indicates the tunnel down. When the tunnel turns from the up
state into the down state, the alarm occurs.
Attribute
Parameters
None.
None.
Impact on System
l When the GSP_TNNL_DOWN alarm occurs, services carried on the faulty tunnel are not
interrupted.
l When the tunnel turns from the down state into the up state, the alarm is cleared
automatically.
Possible Causes
The cause of the GSP_TNNL_DOWN alarm is as follows:

l Cause 1: The Ethernet port is not enabled.

Handling Procedure
l Cause 1: The Ethernet port is not enabled.
1. On the T2000, check whether the Ethernet ports at the two ends of the tunnel are all
enabled. For details, refer to Setting the General Attributes of Ethernet Interfaces in
OptiX RTN 950 Radio Transmission System Configuration Guide manual.
2. If not, enable the Ethernet ports first and then check whether the alarm is cleared.
1. Check whether the physical link connected to the two neighbor NEs is faulty.
2. If yes, repair the faulty link and check whether the alarm is cleared.
1. On the T2000, check whether the HARD_BAD alarm occurs on the line board or on
the system control board of the two neighbor NEs.
2. If yes, cold-reset the board that reports the HARD_BAD alarm and check whether the
GSP_TNNL_DOWNN alarm is cleared. For details, refer to 8.16 Resetting
Boards.
3. If the GSP_TNNL_DOWN alarm persists, replace the related board and check
whether the GSP_TNNL_DOWN alarm is cleared. For details, refer to 5 Replacing
Components.
----End
Related Information
None.
9.3.43 HARD_BAD
Description
The HARD_BAD alarm indicates a hardware fault. When a board detects a hardware fault, the
board reports the HARD_BAD alarm.
Attribute
0xEC Critical Equipment alarm
Parameters

table.

Name Meaning
Parameter 1 Indicates the type of the cause that results in the hardware failure.
l 0x01: The power module operates abnormally. Refer to Cause 1.
l 0x02: The board is improperly installed (the board is poorly connected to the
backplane. For example, the board is not seated tight). Refer to Cause 2.
l 0x03: The 38M system clock 1 is abnormal. Refer to Cause 3 when 0x03 and
the following parameters are detected.
l 0x04: The 38M system clock 2 is abnormal.
l 0x05: The 2M clock source is abnormal.
l 0x06: The digital phase-locked loop is faulty.
l 0x07: The 38M service clock is lost.
l 0x08: The bus is abnormal.
l 0x09: The TPS protection board is abnormal.
l 0x10: The main oscillator of the clock is faulty.
l 0x11: The frequency offset of the main oscillator is excessive.
l 0x12: The standby oscillator stops running.
l 0x13: The processor is faulty.
l 0x14: The memory component is faulty.
l 0x15: The programmable logic component is faulty.
l 0x16: The SDH component is faulty.
l 0x17: The data communication component is faulty.
l 0x18: The clock components are faulty.
l 0x19: The interface component is faulty.
l 0x20: The power supply components are faulty.
l 0x21: Other faults.
l 0x22: The analog phase-locked loop is abnormal.
l 0x23: The 32M clock fails.
l 0x26: The loop of the cross-connect chip fails.
l 0x27: The 8k in-service bus of the board is lowered.
l 0x28: The system 2M frame header 1 is lost.
l 0x29: The system 2M frame header 2 is lost.
l 0x30: The DSP clock-driver chip clock is lost.
l 0x31: The DSP output clock is lost.
l 0x32: RTM module is off service.
l 0x33: Chip faults.

Name Meaning
Parameter 2 l 0x01: Indicates the A bus is abnormal.

l 0x02: Indicates the B bus is abnormal.
l 0xff: No indications.
Parameter 3 0xff: Reserved.
Impact on System
l If the board that reports the HARD_BAD alarm is the working board, the HARD_BAD
alarm triggers protection switching.
l If the board that reports the HARD_BAD alarm is the protection board, protection switching
cannot be performed and the services may be interrupted.
l If the board that reports HARD_BAD alarm is not configured with protection switching,
the services carried on the board will be affected.
l When the HARD_BAD alarm occurs, the system suppresses COMMUN_FAIL and
BUS_ERR alarms.
Possible Causes
The possible causes of the HARD_BAD alarm are as follows:
l Cause 1: The external power supply fails.

l Cause 2: The board is poorly connected to the backplane.
Handling Procedure
l Cause 1: The external power supply fails.
1. Make sure that the power supply to the NE is normal and then check whether the alarm
is cleared. For details, refer to OptiX RTN 950 IDU Quickly Installation Guide.
l Cause 2: The board is poorly connected to the backplane.
1. Remove and re-insert the board to make the board is well connected to the backplane.
Then, check whether the alarm is cleared. For details, refer to 8.19 Replacing Boards
on Site.
1. Cold-reset the board that reports the alarm and then check whether the alarm is cleared.
For details, refer to 8.16 Resetting Boards.
2. If the HARD_BAD alarm persists, replace the board that reports this alarm. For details,
----End
Related Information
None.

9.3.44 IMA_GROUP_LE_DOWN
Description
The IMA_GROUP_LE_DOWN alarm indicates a failure of the local IMA group. When the
IMA protocol is not enabled on the local NE or the number of enabled links in the IMA group
is less than the minimum number of enabled links in the IMA group, the
IMA_GROUP_LE_DOWN alarm is reported.
Attribute
Parameters
None.
None.
Impact on System
When the IMA_GROUP_LE_DOWN alarm occurs, the services in the IMA group are
interrupted.
Possible Causes
The possible causes of the IMA_GROUP_LE_DOWN alarm are as follows:
l Cause 1: The IMA protocol is not enabled on the local NE.

l Cause 2: The number of enabled links in the local IMA group is less than the configured
minimum number of the enabled links in the IMA group.
Handling Procedure
l Cause 1: The IMA protocol is not enabled on the local NE.
group parameters are matched. For details, refer to Configuring the IMA in the OptiX
RTN 950 Radio Transmission System Feature Description manual.
2. On the T2000, set the IMA Protocol Enable Status parameter to Enabled for the
local NE.
l Cause 2: The number of enabled links in the local IMA group is less than the configured
1. On the T2000, check whether there is the ALM_IMA_LIF alarm. For details, refer to
2. If yes, clear the ALM_IMA_LIF alarm first to enable the member links in the local
IMA group. When the actual number of enabled links reaches the configured minimum

number of enabled links, the IMA_GROUP_LE_DOWN alarm will be cleared

automatically.
3. Optional: Configure new member links in the local IMA group.
----End
Related Information
None.
9.3.45 IMA_GROUP_RE_DOWN
Description
The IMA_GROUP_RE_DOWN alarm indicates a failure of the remote IMA group. When the
IMA protocol is not enabled on the remote NE or the number of enabled links in the IMA group
is less than the minimum number of enabled links in the IMA group, the
IMA_GROUP_RE_DOWN alarm is reported.
Attribute
Parameters
None.
None.
Impact on System
When the IMA_GROUP_LE_DOWN alarm occurs, the services in the IMA group are
interrupted.
Possible Causes
The possible causes of the IMA_GROUP_RE_DOWN alarm are as follows:
l Cause 1: The IMA protocol is not enabled on the remote NE.

l Cause 2: The number of enabled links in the remote IMA group is less than the configured
Handling Procedure
l Cause 1: The IMA protocol is not enabled on the remote NE.
group parameters are matched. For details, refer to Configuring the IMA in the OptiX
RTN 950 Radio Transmission System Feature Description manual.

2. On the T2000, set the IMA Protocol Enable Status parameter to Enabled for the
remote NE.
l Cause 2: The number of enabled links in the remote IMA group is less than the configured
1. On the T2000, check whether there is the ALM_IMA_RIF alarm. For details, refer to
2. If yes, clear the ALM_IMA_RIF alarm first to enable the member links in the remote
IMA group. When the actual number of enabled links reaches the configured minimum
number of enabled links, the IMA_GROUP_LE_DOWN alarm will be cleared
automatically.
3. Optional: Configure new member links in the remote IMA group.
----End
Related Information
None.
9.3.46 IMAE1_DELAY
Description
The IMAE1_DELAY is an E1 delay alarm. When the delay of the transmitted service in the
IMA link exceeds the threshold value of the differential delay of the link, the alarm occurs.
Attribute
0x327D Minor Communication alarm
Parameters
None.
None.
Impact on System
The alarm indicates that delay or congestion occurs to the transmitted IMA service.
Possible Causes
The cause of the IMAE1_DELAY alarm is as follows:
The E1 physical route is faulty.
Handling Procedure
l Cause: The E1 physical route is faulty.

1. Remove and then insert the electrical interface of the E1 link, and then check whether
the alarm is cleared. For details, refer to OptiX RTN 950 Radio Transmission Syste
IDU Quick Installation Guide.
2. If the IMAE1_DELAY alarm persists, replace the board that reports the
IMAE1_DELAY alarm. For details, refer to 5 Replacing Components.
----End
Related Information
None.
9.3.47 IN_PWR_ABN
Description
The IN_PWR_ABN is an alarm indicating that the input optical power is abnormal.
Attribute
Parameters
None.
None.
Impact on System
When the IN_PWR_ABN alarm occurs, the service transmission performance is affected. If the
service transmission performance is severely affected, the services are interrupted.
Possible Causes
The possible causes of the IN_PWR_ABN alarm are as follows:
l Cause 1: The transmitted optical power of the opposite NE is abnormal.
l Cause 2: The receive optical power is higher than the normal range.
l Cause 3: The receive optical power is lower than the normal range.
l Cause 4: The receive board is faulty.
Handling Procedure
l Cause 1: The transmitted optical power of the opposite NE is abnormal.
1. On the T2000, check whether there is OUT_PWR_ABN on the opposite NE.
2. If yes, clear the OUT_PWR_ABN alarm on the opposite NE first and check whether
the IN_PWR_ABN alarm is cleared.

3. If the IN_PWR_ABN alarm persists, query the receive optical power of the local NE
on the T2000. For details, refer to 8.4 Checking the Optical Power.
– If the receive optical power is higher than the normal range, refer to the handling
procedure of Cause 2.
– If the receive optical power is lower than the normal range, refer to the handling
procedure of Cause 3.
l Cause 2: The receive optical power is higher than the normal range.
1. Add proper attenuators at the receive optical interface which reports the
IN_PWR_ABN alarm to adjust the receive optical power to the normal range. Then
check whether the IN_PWR_ABN alarm is cleared.
l Cause 3: The receive optical power is lower than the normal range.
1. Check whether the bending radius of the fiber is less than 6 cm. If yes, spool the fiber
jumper again, and then check whether the alarm is cleared.
2. Check whether the optical attenuator is properly connected. If not, adjust the optical
attenuator to a proper position and check whether the IN_PWR_ABN alarm is cleared.
3. Check whether the optical module is loose. If yes, fasten the optical module and check
4. If the IN_PWR_ABN alarm persists, replace the optical module. For details, refer to
5.9 Replacing the Pluggable Optical Module.
5. Clean the fiber headers of the NEs on the two ends. For details, refer to 8.24 Inspecting
and Cleaning the Optical Fiber Connectors.
l Cause 4: The receive board is faulty.
1. Check whether the processing board or cross-connect board of the local NE reports
the hardware alarms, such as the HARD_BAD or TEMP_OVER alarm.
2. If yes, replace the board. For details, refer to 5 Replacing Components.
----End
Related Information
9.3.48 LAG_DOWN
Description
The LAG_DOWN alarm indicates that the link aggregation group (LAG) is unavailable. When
the number of enabled ports in the LAG is 0, the LAG_DOWN alarm is reported.
Attribute
Parameters
None.
None.

Impact on System
In the case of the LAG_DOWN alarm, the services are interrupted.
Possible Causes
The possible causes of the LAG_DOWN alarm are as follows:
l Cause 1: No LAG is configured on the opposite NE.
l Cause 2: All member ports in the LAG are unavailable.
Handling Procedure
l Cause 1: No LAG is configured on the opposite NE.
1. On the T2000, query whether the LAG is configured on the opposite NE. For details,
refer to LAG Operation Tasks in OptiX RTN 950 Radio Transmission System Feature
Description manual.
2. If not, configure the LAG on the opposite NE and check whether the alarm is cleared.
l Cause 2: All member ports in the LAG are unavailable.
1. When a port in the LAG is unavailable, the ETH_LOS, ETH_LINK_DOWN or
LAG_MEMBER_DOWN alarm occurs in the system. For details, refer to 8.2
Querying Current Alarms of a Board.
2. clear the ETH_LOS, ETH_LINK_DOWN or LAG_MEMBER_DOWN alarm to
enable the member ports in the LAG and the LAG_DOWN alarm will be cleared
automatically.
----End
Related Information
None.
9.3.49 LAG_MEMBER_DOWN
Description
The LAG_MEMBER_DOWN is an alarm indicating that the member port of the link
aggregation group (LAG) is unavailable. This alarm occurs when the member port cannot be
activated and cannot work as the backup.
Attribute
Parameters


table.
Name Meaning
Parameter 1 Indicates the board ID.
Parameter 2 Indicates the sub-board ID.

0xff: No sub-board.
Parameter 3, Parameter 4 Indicates the port number ID.
Parameter 5 Indicates the cause that makes the port unavailable.

l 0x01: The port connection is unavailable. Refer to cause 1.
l 0x02: The port fails to receive the LACP packet. Refer to cause
2.
l 0x03: The port works in the half-duplex mode. Refer to cause
3.
l 0x04: Loopback is set on the port. Refer to cause 4.
Impact on System
l When the LAG_MEMBER_DOWN alarm occurs, in the case of the load-sharing mode,
packets may be continuously lost due to the insufficient bandwidth.
l in other cases, the link switching is triggered and packets are lost in a short period.
l The LAG_MEMBER_DOWN alarm will be suppressed when the ETH_LINK_DOWN
alarm occurs.
l When the LAG_MEMBER_DOWN alarm occurs, the system suppresses the
MAC_FCS_EXC alarm.
Possible Causes
The possible causes of the LAG_MEMBER_DOWN alarm are as follows:
l Cause 1: The port connection is unavailable.
l Cause 2: The port fails to receive the LACP packet.
l Cause 3: The port works in the half-duplex mode.
l Cause 4: Loopback is set on the port.
Handling Procedure
l Cause 1: The port connection is unavailable.
1. On the T2000, check whether the LAG member port which reports the alarm is enabled
according to the alarm parameters. For details, refer to Setting the General Attributes
of Ethernet Interfaces in OptiX RTN 950 Radio Transmission System Configuration
Guide manual.

2. If not, enable the LAG member port first and then check whether the alarm is cleared.
3. If the alarm persists, check whether the ETH_AUTO_LINK_DOWN alarm occurs on
the port which reports the LAG_MEMBER_DOWN alarm. For details, refer to 8.2
4. If yes, clear the ETH_AUTO_LINK_DOWN alarm first and then check whether the
LAG_MEMBER_DOWN alarm is cleared.
l Cause 2: The port fails to receive the LACP packet.
1. On the T2000, check whether the opposite port is added into the LAG group. For
details, refer to LAG Operation Tasks in OptiX RTN 950 Radio Transmission
System Feature Description manual.
2. If not, add the opposite port into the LAG group and check whether this alarm is
cleared.
3. If the alarm persists, check whether the ETH_LOS or FLOW_OVER alarm occurs on
the port which reports the LAG_MEMBER_DOWN alarm.
4. If yes, clear the ETH_LOS or FLOW_OVER alarm first and then check whether the
LAG_MEMBER_DOWN alarm is cleared.
l Cause 3: The port works in the half-duplex mode.
1. Modify the working mode of the port to Auto-Negotiation or Full-Duplex and then
check whether the LAG_MEMBER_DOWN alarm is cleared. For details, refer to
8.22 Querying and Setting the Working Mode of Ethernet Interface.
1. Release the loopback of the port and check whether the LAG_MEMBER_DOWN
alarm is cleared. For details, refer to 8.9 Configuring Port Loopback.
----End
Related Information
None.
9.3.50 LASER_MOD_ERR
Description
The LASER_MOD_ERR alarm indicates mismatch of the optical module. When the inserted
optical module is not supported by the board, the LASER_MOD_ERR alarm occurs.
Attribute
Parameters
None.
None.

Impact on System
l When the LASER_MOD_ERR alarm occurs, the optical module cannot start working, the
signals are lost and the services are interrupted.
l The LASER_MOD_ERR alarm will be suppressed when the LSR_NO_FITED alarm
occurs.
l When the LSR_NO_FITED alarm occurs, the system suppresses the ETH_LOS and other
alarms related to optical module.
Possible Causes
The cause of the LASER_MOD_ERR alarm is as follows:
The installed optical module is not of the same type or speed as requested.
Handling Procedure
l Cause: The installed optical module is not of the same type or speed as requested.
1. Replace a proper optical module according to the version mapping table. For details,
refer to 5.9 Replacing the Pluggable Optical Module.
----End
Related Information
None.
9.3.51 LASER_SHUT
Description
The LASER_SHUT is an alarm indicating that the board laser is shut down.
Attribute
0xf815 Major Processing alarm
Parameters
None.
None.
Impact on System
l When the LASER_SHUT alarm occurs, the services are interrupted.
l In the case of LASER_SHUT alarm, the system will suppresses the LSR_BCM_ALM and
OUT_PWR_ABN alarms.

Possible Causes
The possible causes of the LASER_SHUT alarm are as follows:
l Cause 1: The user shuts down the laser.

l Cause 2: The board reports the HARD_BAD alarm, and the software shut the laser
automatically.
Handling Procedure
l Cause 1: The user shuts down the laser.
1. Remove the alarm shutdown setting, and then check whether the alarm is cleared. For
details, refer to Configuring Interfaces in OptiX RTN 950 Radio Transmission
System Configuration Guide manual.
l Cause 2: The board reports the HARD_BAD alarm, and the software shut the laser
automatically.
1. On the T2000, check the current alarms or the history alarms for the HARD_BAD
alarm.
2. If the HARD_BAD alarm occurs, cold-reset the board. For details, refer to 8.16
Resetting Boards.
3. If the alarm persists, replace the board. For details, refer to 5 Replacing
Components.
----End
Related Information
None.
9.3.52 LFA
Description
The LFA is an alarm indicating the loss of E1 basic frame alignment. This alarm indicates that
the E1 double frame is failed in basic frame delimitation and that the delimitation synchronous
status is lost.
Attribute
Parameters
None.
None.

Impact on System
l When the LFA alarm occurs, the relevant E1 link is deactivated, and then the available
links in the IMA group are reduced.
l For the VCTRUNK link that is bound with only one path, if the LFA alarm occurs, the
l After the LFA alarm is cleared, the relevant E1 link in the IMA group is automatically
activated.
l The LFA alarm will be suppressed when the UP_E1_AIS alarm occurs.
Possible Causes
The possible causes of the LFA alarm are as follows:
l Cause 1: The frame format of the E1 signals transmitted from the opposite NE is
inconsistent with the received frame format that is specified at the local NE.
l Cause 2: The equipment is faulty.
Handling Procedure
1. On the T2000, check whether the frame format of the E1 signals transmitted from the
opposite NE is consistent with the received frame format that is specified at the local
NE. For details, refer to Setting the Advanced Attributes of PDH Interfaces in OptiX
RTN 950 Radio Transmission System Configuration Guide manual.
2. If not, modify the configuration and make sure the frame formats of the E1 signals at
the two NEs match. Then, check whether the LFA alarm is cleared.
1. On the T2000, check whether the hardware-related alarms occur on the related boards
of the two NEs, such as the HARD_BAD alarm.
the LFA alarm is cleared. For details, refer to 8.16 Resetting Boards.
3. If the LFA alarm persists, replace the related board and check whether the LFA alarm
is cleared. For details, refer to 5 Replacing Components.
----End
Related Information
Basic frame
According to ITU-T Recommendation G.704, a basic frame shows the format in which the frame
synchronization sequence (FAS) is carried in the even frames, and the non-frame
synchronization sequence (NFAS) is carried in the odd frames.
9.3.53 IF_CABLE_OPEN
Description
The IF_CABLE_OPEN is an alarm indicating that the IF cable is disconnected.

Attribute
0x323F Major Equipment alarm
Parameters
table.
Name Meaning
Parameter 1 Indicates the ID of the IF port that reports the alarm. For example, 0x01 indicates
that the alarm is reported by IF port 1 of the related board.
Impact on System
The services carried over the IF port are interrupted.
Possible Causes
l The IF cable is loose or faulty.
l The IF port on the IF board is faulty.
l The power module of the ODU is faulty.
Handling Procedure
Step 1 Check whether the connector of the IF cable is loose or whether the connector is not properly
made.
If... Then...
The connector is loose Tighten the connector.
The connector is not properly made Make a new connector. For details refer to Quick
Installation Guide.
None of the above Go to the next step.
Step 2 Check whether the jacket of the IF cable is damaged.
If... Then...
Yes Use a multimeter to test whether the IF cable conducts electricity well, and replace the
cable if the IF cable fails to conduct electricity.
No Go to the next step.
Step 3 Replace the IF board.

If... Then...
The alarm disappears after the IF board is The fault is rectified, and the alarm handling
replaced is complete.
The alarm persists after IF board is replaced Go to the next step.
Step 4 Replace the ODU.
----End
Related Information
None.
9.3.54 IF_INPWR_ABN
Description
The IF_INPWR_ABN is an alarm indicating that the input IF power of the ODU is abnormal.
Attribute
0x312D Major Equipment alarm
Parameters
table.
Name Meaning
Parameter 1 l 0x01 indicates that the input power is too high.
l 0x02 indicates that the input power is too low.
Impact on System
The services on the ODU are interrupted. If 1+1 protection is configured, 1+1 HSB switching
may be triggered.
Possible Causes
l There is an inloop operation on the IF port.
l The IF board is faulty.
l The IF cables are faulty.

Handling Procedure
Step 1 Check whether there is an inloop operation on the IF port.
If... Then...
Yes Cancel the loopback operation.
Step 2 Check whether the IF cables are soggy, broken, or pressed.
If... Then...
Yes Replace the IF cables.
Step 3 Check whether the cable connector workmanship meets the requirement.
If... Then...
No Make a new connector.
Yes Go to the next step.
Step 4 Replace the IF board connecting to the ODU that reports the IF_INPWR_ABN alarm..
If... Then...
The alarm disappears after the board is The fault is rectified, and the alarm handling
The alarm persists after the board is Go to the next step.
replaced
Step 5 Replace the ODU that reports the IF_INPWR_ABN alarm.
----End
Related Information
None.
9.3.55 LMFA
Description
The LMFA is an alarm indicating the loss of E1 multiframe alignment. This alarm indicates that
the E1 CRC-4 frame is failed in multiframe delimitation and that the delimitation synchronous
status is lost.

Attribute
Parameters
None.
None.
Impact on System
l When the LMFA alarm occurs, the relevant E1 link is deactivated, and then the available
links in the IMA group are reduced.
l For the VCTRUNK link that is bound with only one path, if the LMFA alarm occurs, the
l After the LMFA alarm is cleared, the relevant E1 link in the IMA group is automatically
activated.
l The LMFA alarm will be suppressed when the UP_E1_AIS alarm occurs.
Possible Causes
The possible causes of the LMFA alarm are as follows:
Handling Procedure
1. On the T2000, check whether the frame format of the E1 signals transmitted from the
opposite NE is consistent with the received frame format that is specified at the local
NE. For details, refer to Setting the Advanced Attributes of PDH Interfaces in OptiX
2. If not, modify the configuration and make sure the frame formats of the E1 signals at
the two NEs match. Then, check whether the LMFA alarm is cleared.
1. On the T2000, check whether the hardware-related alarms occur on the related boards
of the two NEs, such as the HARD_BAD alarm.
the LMFA alarm is cleared. For details, refer to 8.16 Resetting Boards.
3. If the LMFA alarm persists, replace the related board and check whether the LMFA
alarm is cleared. For details, refer to 5 Replacing Components.
----End

Related Information
Basic frame
According to ITU-T Recommendation G.704, a basic frame shows the format in which the frame
synchronization sequence (FAS) is carried in the even frames, and the non-frame
synchronization sequence (NFAS) is carried in the odd frames.
Multiframe
A multiframe contains 8 basic frames, and it can be checked in the CRC mode.
9.3.56 LOOP_ALM
Description
The LOOP_ALM is an alarm indicating the loopback. This alarm occurs when the service
loopback is set.
Attribute
0x00F0 Minor Equipment alarm
Parameters
table.

Name Meaning
Parameter 1 Indicates the loopback type.

l 0x00: Optical/Electrical interface inloop.
l 0x01: Optical/Electrical interface outloop.
l 0x02: Path inloop.
l 0x03: Path outloop.
l 0x04: Loopback at the client side.
l 0x05: Loopback at the multiplexing side.
l 0x06: SPI inloop.
l 0x07: SPI outloop.
l 0x08: Inloop at the ATM layer.
l 0x09: Outloop at the ATM layer.
l 0x0A: Inloop at the PHY layer.
l 0x0B: Outloop at the PHY layer.
l 0x0C: Inloop at the MAC layer.
l 0x0D: Outloop at the MAC layer.
l 0x0E: VC-4 timeslot inloop.
l 0x0F: VC-4 timeslot outloop.
l 0x10: VC-3 timeslot inloop.
l 0x11: VC-3 timeslot outloop.
l 0x12: VC-12 timeslot inloop.
l 0x13: VC-12 timeslot outloop.
Impact on System
When the LOOP_ALM alarm occurs, there is the loopback in the system, and services at the
optical interface or in the path which reports the alarm are interrupted.
Possible Causes
The possible causes of the LOOP_ALM alarm are as follows:
l Cause 2: Loops exists in the service.
Handling Procedure
1. On the T2000, check whether the loopback is set on the port which reports the
LOOP_ALM alarm. For details, refer to 8.9 Configuring Port Loopback.
2. If yes, release the loopback of the port and check whether the LOOP_ALM alarm is
cleared.

l Cause 2: Loops exists in the service.

1. On the T2000, check whether loops exist in the service.
2. If yes, modify the service configuration and delete the loops.
3. Optional: For Ethernet services, enable the function of loopback port shutdown to
release the service loopback and then check whether the alarm is cleared. For details,
refer to Setting the Advanced Attributes of Ethernet Interfaces in the OptiX RTN
----End
Related Information
None.
9.3.57 LSR_BCM_ALM
Description
The LSR_BCM_ALM is an alarm indicating that the bias current of the laser crosses the
threshold.
Attribute
0x003A Major Equipment alarm
Parameters
table.
Name Meaning
Parameter 1 Indicates the bias current crosses the threshold.

l 0x01: The bias current is excessively high.
l 0x02: The bias current is excessively low.
Impact on System
l When the LSR_BCM_ALM alarm occurs, the gain is insufficient or the laser is damaged,
in the severe case of which the services may be interrupted.
l The LSR_BCM_ALM alarm will be suppressed when one of the LASER_MOD_ERR,
ALM_ALS and LASER_SHUT alarms occurs.

Possible Causes
The possible causes of the LSR_BCM_ALM alarm are as follows:
l Cause 1: The laser is aged.
l Cause 2: This board is faulty.
Handling Procedure
1. Replace the optical module on the port which reports the LSR_BCM_ALM alarm and
then, check whether the alarm is cleared. For details, refer to 5.9 Replacing the
Pluggable Optical Module.
l Cause 2: This board is faulty.
1. Replace the board which reports the LSR_BCM_ALM alarm and then, check whether
the alarm is cleared. For details, refer to 5 Replacing Components.
----End
Related Information
None.
9.3.58 LSR_NO_FITED
Description
The LSR_NO_FITED is an alarm indicating that the laser is not installed. This alarm occurs
when the optical port is enabled but not installed with the optical module.
Attribute
Parameters
None.
None.
Impact on System
l When the LSR_NO_FITED alarm occurs, the data cannot be transmitted on the optical
port.
l In the case of the LSR_NO_FITED alarm, the system suppresses the ETH_LOS and all the
other alarms related to optical module.
Possible Causes
The possible causes of the LSR_NO_FITED alarm are as follows:

l Cause 1: The enabled optical port is not installed with the optical module.
l Cause 2: The optical module or the board is faulty, so that the optical module cannot be
detected.
Handling Procedure
l Cause 1: The enabled optical port is not installed with the optical module.
1. Check whether the optical port is installed with the optical module.
2. If not, install a proper optical module to the optical port according to the version
mapping table. Then, check whether the alarm is cleared.
l Cause 2: The optical module or the board is faulty, so that the optical module cannot be
detected.
1. Replace the optical module on the port and then, check whether the alarm is cleared.
2. Replace the board which reports the LSR_NO_FITED alarm and then, check whether
the alarm is cleared. For details, refer to 5 Replacing Components.
----End
Related Information
None.
9.3.59 LSR_WILL_DIE
Description
The LSR_WILL_DIE is an alarm indicating that the a laser will be out of work soon. This alarm
indicates that the laser is unavailable.
Attribute
Parameters
None.
None.
Impact on System
l When the LSR_WILL_DIE alarm occurs, bit errors occur in the services. If the optical
module is not replaced in a timely manner, the services are interrupted after the laser is
damaged.
l The LSR_WILL_DIE alarm will be suppressed when one of the LSR_NO_FITED and
LASER_MOD_ERR alarms occurs.

Possible Causes
The possible causes of the LSR_WILL_DIE alarm are as follows:
l Cause 2: The detection circuit of the board is faulty.
Handling Procedure
1. Replace the optical module and check whether the alarm is cleared. For details, refer
to 5.9 Replacing the Pluggable Optical Module.
l Cause 2: The detection circuit of the board is faulty.
1. Replace the board which reports the LSR_WILL_DIE alarm and check whether the
alarm is cleared. For details, refer to 5 Replacing Components.
----End
Related Information
None.
9.3.60 LTI
Description
The LTI is an alarm indicating the loss of synchronization clock source.
Attribute
Parameters
table.

Name Meaning
Parameter 1 Indicates the type of the synchronization source that is lost.

l 0x01: All the synchronization sources of the system clock are lost.
l 0x02: All the synchronization sources of the first 2M phase-locked source are
lost.
l 0x03: All the synchronization sources of the second 2M phase-locked source
are lost.
Impact on System
When the LTI alarm occurs, the pointer justification may increase due to a low quality clock
and make the bit error rate increase.
Possible Causes
The possible causes of the LTI alarm are as follows:
l Cause 1: The external clock source received by the clock interface of CXPR is lost.
l Cause 2: The line clock source is lost.
l Cause 3: The clock source is locked. In this case, when the current clock source is lost, it
cannot be switched to other normal clock source automatically.
Handling Procedure
l Cause 1: The external clock source signal received by the clock interface of CXPR is lost.
1. On the T2000, check whether the EXT_SYNC_LOS alarm occurs. For details, refer
to 8.2 Querying Current Alarms of a Board.
2. If yes, clear the EXT_SYNC_LOS alarm and then check whether this alarm is cleared.
l Cause 2: The line clock source is lost.
1. On the T2000, check whether the signal loss alarms such as the ETH_LOS alarms
occur. If yes, clear these alarms and then check whether the LTI alarm is cleared.
2. If the LTI alarm persists, perform a cold reset on the CXPR board, and then check
whether this alarm is cleared. For details, refer to 8.16 Resetting Boards.
3. If the alarm persists, replace the CXPR board, and then check whether the alarm is
cleared. For details, refer to 5 Replacing Components.
l Cause 3: The clock source is locked. In this case, when the current clock source is lost, it
cannot be switched to other normal clock source automatically.
1. On the T2000, check whether the clock source is in the "non-revertive" state. If yes,
re-configure the clock source so that it can recover automatically. Then, check whether
the alarm is cleared. For details, refer to Configuring the Clock Source Reversion in
2. Check whether the SYNC_LOCKOFF alarm occurs in the system. If yes, clear the
SYNC_LOCKOFF alarm first and then check whether the TOP_LTI alarm is cleared.
----End

Related Information
None.
9.3.61 MAC_FCS_EXC
Description
The MAC_FCS_EXC is an alarm indicating that the bit error threshold-crossing event is detected
at the MAC layer. The software detects the number of bytes received by the MAC chip and the
number of bytes that have bit errors, and calculates whether the number of bit errors exceeds the
threshold. Then MAC_FCS_EXC alarm occurs when the threshold is crossed.
Attribute
0x31FA Major Communication alarm
Parameters
None.
None.
Impact on System
l When the MAC_FCS_EXC alarm occurs, the service performance may be degraded and
the services may be interrupted.
l The MAC_FCS_EXC alarm will be suppressed when one of the ETH_LOS,
ETH_LINK_DOWN and LAG_MEMBER_DOWN alarms occurs.
Possible Causes
The possible causes of the MAC_FCS_EXC alarm are as follows:
l Cause 1: The line signals degrade.

l Cause 2: The input optical power is abnormal.
l Cause 3: The fiber header is dirty.
Handling Procedure
1. On the T2000, check whether the LOOP_ALM alarm occurs. If yes, clear the
LOOP_ALM alarm first and then check whether the MAC_FCS_EXC alarm is
cleared. For details, refer to 8.2 Querying Current Alarms of a Board.
2. If the MAC_FCS_EXC alarm persists, check whether the DOS attack exists. If yes,
isolate the DOS attack source, and then check whether the MAC_FCS_EXC alarm is
cleared.

3. If the MAC_FCS_EXC alarm still persists, check whether any fault occurs in the fiber
or cable. Replace the faulty fiber or cable, and then check whether the
MAC_FCS_EXC alarm is cleared.
l Cause 2: The input optical power is abnormal.
1. Check whether the IN_PWR_ABN alarm occurs on the port which reports the
MAC_FCS_EXC alarm.
2. If yes, clear the IN_PWR_ABN alarm first and then check whether the
MAC_FCS_EXC alarm is cleared.
l Cause 3: The fiber header is dirty.
1. Clean the fiber header and the receive optical interface on the board. For details, refer
to 8.24 Inspecting and Cleaning the Optical Fiber Connectors.
----End
Related Information
None.
9.3.62 MP_DELAY
Description
The MP_DELAY delay is an alarm indicating the group member delay. This alarm occurs when
the delay of the group members exceeds the configured threshold.
Attribute
Parameters
table.
Name Meaning
Parameter 3, Parameter 4 Indicates the port ID.

Name Meaning
Parameter 5 Indicates the timeslot number or the path number.

0xff: Parameter 5 is reserved.
Impact on System
When the MP_DELAY alarm occurs, the services in the MP group are affected and the service
signals degrade.
Possible Causes
The possible causes of the MP_DELAY alarm are as follows:

l Cause 2: The configured value of the Enable Differential Delay is too low.
Handling Procedure
1. Check whether the congestion occurs at the network side. If yes, perform the expansion
as required, and then check whether the alarm is cleared. For details, refer to the OptiX
2. If the MP_DELAY alarm persists, replace the cable of the port which reports the alarm.
Then, check whether the MP_DELAY alarm is cleared.
l Cause 2: The configured value of the Enable Differential Delay is too low.
1. On the T2000, check whether the configured value of the Enable Differential
Delay is too low. For details, refer to Creating MP Groups in the OptiX RTN 950 Radio
2. Increase the value of the Enable Differential Delay depending on the actual scene,
and check whether the MP_DELAY alarm is cleared.
----End
Related Information
None.
9.3.63 MP_DOWN
Description
The MP_DOWN alarm indicates a failure of the MP group. When the number of enabled links
in the MP group is less than the configured minimum number of enabled links in the MP group,
the MP_DOWN alarm is reported. The default minimum number of enabled links is 1.

Attribute
Parameters
None.
None.
Impact on System
l When the MP group fails, all the services transmitted over the MP group are interrupted.
l When the number of enabled links in the MP group is more than the configured minimum
number of enabled links in the MP group, the MP_DOWN alarm is cleared automatically.
Possible Causes
The possible causes of the MP_DOWN alarm are as follows:
l Cause 1: The number of enabled links in the MP group is less than the configured Min
Activated Link Count of the MP group.
l Cause 2: The configuration of MP group on the two ends is inconsistent.
l Cause 3: The NCP protocol is abnormal.
Handling Procedure
l Cause 1: The number of enabled links in the MP group is less than the configured Min
Activated Link Count of the MP group.
1. On the T2000, check whether the number of enabled links in the MP group is less than
the configured Min Activated Link Count of the MP group. For details, refer to
Configuring ML-PPP in the Configuration Guide manual.
2. If yes, modify the configuration value of Min Activated Link Count to less than the
number of enabled links in the MP group, and check whether the MP_DOWN alarm
is cleared.
l Cause 2: The configuration of MP group on the two ends is inconsistent.
1. On the T2000, check whether the configuration of MP group on the two ends is
consistent. If not, modify the configuration on the two ends and make it be consistent.
For details, refer to Configuring ML-PPP in the Configuration Guide manual.
2. Click Reset and enable the the MP protocol again. Then, check whether the
MP_DOWN alarm is cleared.
l Cause 3: The NCP protocol is abnormal.
1. On the T2000, check whether the PPP_LCP_FAIL or PPP_NCP_FAIL alarm occurs
on the links in the MP group. For details, refer to 8.2 Querying Current Alarms of
a Board.

2. If yes, clear the PPP_LCP_FAIL or PPP_NCP_FAIL alarm first, and check whether
the MP_DOWN alarm is cleared.
1. On the T2000, check whether any alarms occur on the links in the MP group indicating
loss of signals, such as the T_ALOS alarm.
2. If yes, clear the T_ALOS alarm first, and check whether the MP_DOWN alarm is
cleared.
----End
Related Information
None.
9.3.64 MPLS_TUNNEL_BDI
Description
The MPLS_TUNNEL_BDI is an alarm of tunnel backward defect indication. This alarm occurs
when the BDI packet is received at the receive end indicating that the forward tunnel is faulty.
Attribute
Parameters
table.
Name Meaning
Impact on System
When the MPLS_TUNNEL_BDI alarm occurs, the services at the transmit side are affected.
Possible Causes
The cause of the MPLS_TUNNEL_BDI alarm is as follows:
The upstream NE detects that the tunnel is faulty.

Handling Procedure
l Cause: The upstream NE detects that the tunnel is faulty.
1. Check whether an anomaly occurs on the physical link between the local NE and the
upstream NE, such as a fiber or cable cut, an optical module fault or a board fault.
2. If yes, remove the anomaly, and then check whether the alarm is cleared.
----End
Related Information
None.
9.3.65 MPLS_TUNNEL_Excess
Description
The MPLS_TUNNEL_Excess is an alarm indicating that excessive trail termination source
identifiers are received. During three consecutive CV/FFD periods, this alarm occurs when five
or more than five correct CV/FFD packets are received.
Attribute
0x320F Minor Communication alarm
Parameters
table.
Name Meaning
Impact on System
The services may be interrupted or redundant packets are received.
Possible Causes
The possible causes of the MPLS_TUNNEL_Excess alarm are as follows:
l Cause 1: The OAM attributes configured at the two ends are inconsistent.
l Cause 2: The tunnel configuration is incorrect, that is, many tunnels are configured with
the same ingress node ID and same tunnel ID.

l Cause 3: The misconnection occurs on the physical link.
Handling Procedure
l Cause 1: The OAM attributes configured at the two ends are inconsistent.
1. On the T2000, check whether the OAM attributes configured at the two ends are
consistent. For details, refer to Setting the MPLS OAM Parameters of a Tunnel in the
OptiX RTN 950 Radio Transmission System Feature Description manual.
2. If not, modify the configuration to match each other, and then check whether the alarm
is cleared.
l Cause 2: The tunnel configuration is incorrect, that is, many tunnels are configured with
the same ingress node ID and same tunnel ID.
1. On the T2000, check whether there are many tunnels configured with the same ingress
node ID and same tunnel ID.
2. If yes, delete the redundant tunnels or modify the Tunnel ID as other numbers. Then,
check whether the alarm is cleared.
1. Check whether the fiber or cable is correctly connected.
2. If not, recover the correct connection and check whether the alarm is cleared.
----End
Related Information
None.
9.3.66 MPLS_TUNNEL_FDI
Description
The MPLS_TUNNEL_FDI is an alarm of tunnel forward defect indication. This alarm occurs
when the FDI packet is received, indicating a tunnel at the physical layer is faulty.
Attribute
Parameters
table.

Name Meaning
Impact on System
When the MPLS_TUNNEL_FDI alarm occurs, the services maybe interrupted.
Possible Causes
The cause of the MPLS_TUNNEL_FDI alarm is as follows:
The upstream NE detects that a fault occurs at the physical layer.
Handling Procedure
l Cause: The upstream NE detects that a fault occurs at the physical layer.
1. Check whether an anomaly occurs on the physical link between the local NE and the
upstream NE, such as a fiber or cable cut, an optical module fault or a board fault.
2. If yes, remove the anomaly, and then check whether the alarm is cleared.
----End
Related Information
None.
9.3.67 MPLS_TUNNEL_LOCV
Description
The MPLS_TUNNEL_LOCV is an alarm indicating the loss of tunnel connectivity verification.
This alarm occurs when the expected CV/FFD packet is not received within a period of three
consecutive cycles.
Attribute
0x320E Critical Communication alarm
Parameters
table.

Name Meaning
Impact on System
l When the MPLS_TUNNEL_LOCV alarm occurs, the services that the faulty tunnel carries
are interrupted.
l The MPLS_TUNNEL_LOCV alarm will be suppressed when the MPLS_TUNNEL_FDI
alarm occurs.
Possible Causes
The possible causes of the MPLS_TUNNEL_LOCV alarm are as follows:
l Cause 1: The CV/FFD is stopped at the ingress node.

l Cause 2: The service is configured to an incorrect port.
l Cause 4: The network is severely congested.
Handling Procedure
l Cause 1: The CV/FFD is stopped at the ingress node.
1. On the T2000, check whether the CV/FFD is stopped at the ingress node. For details,
refer to Starting the CV/FFD for a Tunnel in the OptiX RTN 950 Radio Transmission
System Feature Description manual.
2. If the CV/FFD is stopped, restart the CV/FFD and check whether the alarm is cleared.
l Cause 2: The service is configured to an incorrect port.
1. On the T2000, check whether the service is configured to the correct port.
2. If not, re-configure the service to the correct port and check whether the alarm is
cleared.
1. On the T2000, check whether there is COMMUN_FAIL alarm on the opposite NE.
For details, refer to 8.2 Querying Current Alarms of a Board. If yes, it indicates
that the opposite NE is undergoing reset. Clear the COMMUN_FAIL first and check
whether the MPLS_TUNNEL_LOCV alarm on the local NE is cleared.
2. On the T2000, check whether the alarms related to boards or optical modules occur
on the two NEs that the faulty link connects. If yes, clear these alarms and then check
whether the MPLS_TUNNEL_LOCV alarm is cleared.
3. If the alarm persists, check whether the fiber or cable is faulty. If yes, replace the faulty
fiber or cable.
1. Select a bigger parameter value for the Detection Packet Period. For details, refer to
Setting the MPLS OAM Parameters of a Tunnel in the OptiX RTN 950 Radio
Transmission System Feature Description manual.

2. Check the bandwidth utilization of the tunnel. If the bandwidth is already exhausted,
increase the bandwidth or avoid the transmission of a large amount of unauthorized
data. Then, check whether the alarm is cleared.
----End
Related Information
None.
9.3.68 MPLS_TUNNEL_MISMATCH
Description
The MPLS_TUNNEL_MISMATCH is an alarm indicating the trail termination source identifier
mismatch. This alarm occurs when no CV/FFD packets with correct trail termination source
identifiers are received within a period of three consecutive CV/FFD cycles.
Attribute
0x3210 Critical Communication alarm
Parameters
table.
Name Meaning
Impact on System
When the MPLS_TUNNEL_MISMATCH alarm occurs, the services maybe interrupted or
packets from other tunnels are received.
Possible Causes
The possible causes of the MPLS_TUNNEL_MISMATCH alarm are as follows:
l Cause 1: The tunnel configuration is incorrect, that is, the source NE and the sink NE in a
specific tunnel are configured with the inconsistent LSR ID or tunnel ID.

Handling Procedure
l Cause 1: The tunnel configuration is incorrect, that is, the tunnel source NE and the tunnel
sink NE are configured with the inconsistent LSR ID or tunnel ID.
1. On the T2000, check whether the tunnel configuration at the tunnel source NE is
consistent with the configuration at the tunnel sink NE.
2. If not, modify the configuration to match each other and check whether the alarm is
cleared.
----End
Related Information
None.
9.3.69 MPLS_TUNNEL_MISMERGE
Description
The MPLS_TUNNEL_MISMERGE is an alarm indicating that the trail termination source
identifier is incorrectly merged. This alarm occurs when the CV/FFD packets with correct and
incorrect trail termination source identifiers are received within a period of three consecutive
CV/FFD cycles.
Attribute
Parameters
table.
Name Meaning
Impact on System
When the MPLS_TUNNEL_MISMERGE alarm occurs, the packets from other tunnels are
received.

Possible Causes
The possible causes of the MPLS_TUNNEL_MISMERGE alarm are as follows:
l Cause 1: The tunnel configuration is incorrect, that is, there are many tunnels with the same
labels or IDs on the sink NE.
Handling Procedure
l Cause 1: The tunnel configuration is incorrect, that is, there are many tunnels with the same
label or ID on the sink NE.
1. On the T2000, check whether there are many tunnels with the same label or ID on the
sink NE.
2. If yes, delete the redundant tunnels or modify the Tunnel configuration. Then, check
----End
Related Information
None.
9.3.70 MPLS_TUNNEL_SD
Description
The MPLS_TUNNEL_SD is an alarm indicating the tunnel signal is degraded. This alarm occurs
when the packet loss ratio of the connectivity check (CC) packets exceeds the SD threshold but
not the SF threshold.
Attribute
Parameters
table.

Name Meaning
Impact on System
When the MPLS_TUNNEL_SD alarm occurs, the service quality degrades and a small amount
of packets are lost.
Possible Causes
The possible cause of the MPLS_TUNNEL_SD alarm are as follows:
l Cause 1: The service bit error ratio is excessively high.

l Cause 2: No bandwidth is available.
l Cause 3: Other anomalies occur on the carrier layer.
Handling Procedure
1. On the T2000, check whether the MAC_FCS_EXC alarm occurs. For details, refer to
2. If yes, clear the MAC_FCS_EXC first, and then check whether the
MPLS_TUNNEL_SD alarm is cleared.
1. On the T2000, check whether the bandwidth configured to the tunnel is fully used.
2. If yes, expand the bandwidth of tunnel or eliminate the source where a large amount
of illegal data is transmitted. Then, check whether the alarm is cleared.
1. On the T2000, check whether other anomalies occur on the carrier layer.
2. If yes, remove the configuration inconsistency fault or the protocol operation anomaly,
and then check whether the alarm is cleared.
----End
Related Information
None.
9.3.71 MPLS_TUNNEL_SF
Description
The MPLS_TUNNEL_SF is an alarm indicating the tunnel signal is severely degraded. This
alarm occurs when the loss ratio of the CC packets exceeds the SF threshold but CC packets can
still be received in three consecutive periods.

Attribute
Parameters
table.
Name Meaning
Impact on System
When the MPLS_TUNNEL_SF alarm occurs, the service quality degrades severely and a large
amount of packets are lost.
Possible Causes
The possible cause of the MPLS_TUNNEL_SF alarm are as follows:
Handling Procedure
1. On the T2000, check whether the MAC_FCS_EXC alarm occurs. For details, refer to
2. If yes, clear the MAC_FCS_EXC first, and then check whether the
MPLS_TUNNEL_SD alarm is cleared.
1. On the T2000, check whether other anomalies occur on the carrier layer.
2. If yes, remove the configuration inconsistency fault or the protocol operation anomaly,
and then check whether the alarm is cleared.
----End

Related Information
None.
9.3.72 MPLS_TUNNEL_UNKNOWN
Description
The MPLS_TUNNEL_UNKNOWN is an alarm indicating the tunnel unknown defect. This
alarm occurs when the type and the cycle of the continuity check packets received within a
certain period (three times of the cycle) are not the expected type and cycle.
Attribute
Parameters
table.
Name Meaning
Impact on System
When the MPLS_TUNNEL_UNKNOWN alarm occurs, the OAM function is affected.
Possible Causes
The cause of the MPLS_TUNNEL_UNKNOWN alarm is as follows:
The OAM attributes configured at the two ends are inconsistent, such as the type or cycle of the
CC packet.
Handling Procedure
l Cause: The OAM attributes configured at the two ends are inconsistent, such as the type
or cycle of the CC packet.
1. On the T2000, check whether the OAM attributes configured at the two ends are
consistent. For details, refer to Setting the MPLS OAM Parameters of a Tunnel in the
OptiX RTN 950 Radio Transmission System Feature Description manual.

2. If not, modify the configuration to match each other, and then check whether the alarm
is cleared.
----End
Related Information
None.
9.3.73 MW_BER_EXC
Description
The MW_BER_EXC is an alarm indicating that there are excessive bit errors on the microwave
link. This alarm is reported if the BER on the microwave link crosses the specified threshold
(10-3 by default).
Attribute
0x3246 Minor Service alarm
Parameters
table.
Name Meaning
Parameter 1 Indicates the ID of the line port that reports the alarm. For example, 0x01
indicates that the alarm is reported by port 1 of the related board.
Parameters 2–3 Indicate the ID of the path that reports the alarm. For example, 0x00 0x01
indicates that the alarm is reported by path 1.
Impact on System
The services over the port are interrupted.
Possible Causes
l Signal fading on the microwave link is too high.
l The transmitter at the remote end is faulty.
l The receiver at the local end is faulty.

Handling Procedure
Step 1 Check whether the MW_FECUNCOR alarm is reported.
If... Then...
Yes Clear the MW_FECUNCOR alarm.
Step 2 Replace the local IF board.
Step 3 Check whether the alarm is cleared. If the alarm persists, replace the opposite IF board.
----End
Related Information
None.
9.3.74 MW_BER_SD
Description
The MW_BER_SD is an alarm indicating that signal deteriorates on the microwave link. This
alarm is reported if the BER on the microwave link crosses the specified threshold (10-6 by
default) and does not reach the MW_BER_EXC alarm threshold (10-3 by default).
Attribute
Parameters
table.
Name Meaning
Parameter 1 Indicates the ID of the IF port that reports the alarm. For example, 0x01
Parameters 2–3 Indicate the ID of the path that reports the alarm. For example, 0x00 0x01
indicates that the alarm is reported by path 1.

Impact on System
The service performance over the port deteriorates, and channel switching may be triggered if
the 1+1 FD/SD protection is provided.
Possible Causes
l Signal fading on the microwave link is too high.
l The transmitter at the remote end is faulty.
l The receiver at the local end is faulty.
Handling Procedure
Step 1 Check whether the MW_FECUNCOR alarm is reported.
If... Then...
Yes Clear the MW_FECUNCOR alarm.
Step 2 Replace the local IF board.

Step 3 Check whether the alarm is cleared. If the alarm persists, replace the opposite IF board.
----End
Related Information
None.
9.3.75 MW_LIM
Description
The MW_LIM is an alarm indicating that a mismatched microwave link identifier is detected.
This alarm is reported if a board detects a mismatched Link ID in the microwave frame
overheads.
Attribute
Parameters
table.

Name Meaning
Parameter 1 Indicates the IF port that reports the alarm. For example, 0x01 indicates that the
alarm is reported by port 1 of the related board.
Impact on System
The microwave link fails to carry services.
Possible Causes
l The Link ID of the local station mismatches the Link ID of the remote station.
l The receive frequency at the local end is incorrectly configured.
l The direction of the antenna is incorrectly configured. As a result, the antenna receives the
microwave from other stations.
Handling Procedure
Step 1 Determine the IF port that reports the alarm according to alarm parameters.
Step 2 Check whether the Link ID of the local station matches the Link ID of the remote station.
If ... Then ...

No, Modify the data configuration.
Yes, Go to the next step.
Step 3 Check whether the receive/transmit frequencies at the local end are consistent with those at the
remote end.
If ... Then ...

No, Modify the data configurations.
Yes, Go to the next step.
Step 4 Adjust the direction of the antenna to align it properly with the antenna at the remote end.
----End
Related Information
None.
9.3.76 MW_LOF
Description
The MW_LOF is an alarm indicating that the Reed Solomon (RS) frame is lost.

Attribute
Parameters
table.
Name Meaning
Impact on System
The services are interrupted. If the system is configured with protection, protection switching
may be triggered.
Possible Causes
l The microwave link performance degrades.
l The transmit unit of the remote station is faulty.
l The receive unit of the local station is faulty.
l The working modes of the IF units at the local and the remote stations are the same.
l The working modes of the ODUs at the local and the remote stations are the same.
Handling Procedure
Step 1 Refer to Troubleshooting Microwave Links.
----End
Related Information
None.
9.3.77 MW_RDI
Description
The MW_RDI is an alarm indicating that there are defects at the remote end of the microwave
link. This alarm is reported if an IF board detects an RDI in the microwave frame overheads.

Attribute
0x312B Minor Communication alarm
Parameters
table.
Name Meaning
alarm is reported by port 1 of the board.
Impact on System
If the local station is configured with reverse switching and both the active and standby boards
receive the MW_RDI alarm at the same time, the 1+1 switching may be triggered. This alarm
also indicates that service reception at the remote station may be interrupted.
Possible Causes
After detecting a service alarm that is caused by a microwave link fault, the receive station returns
a microwave link fault indication to the transmit station.
Handling Procedure
Step 1 Handle the microwave alarm occurred to the remote station.
----End
Related Information
None.
9.3.78 MW_FECUNCOR
Description
The MW_FECUNCOR is an alarm indicating that the Reed Solomon (RS) encoding cannot be
corrected.

Attribute
Parameters
table.
Name Meaning
Impact on System
Bit errors occur to the services. If the system is configured with 1+1 FD/SD protection, channel
protection switching may be triggered.
Possible Causes
l The microwave link performance degrades.
l The transmit unit of the remote station is faulty.
l The receive unit of the local station is faulty.
Handling Procedure
Step 1 Refer to Troubleshooting Microwave Links.
----End
Related Information
None.
9.3.79 MSSW_DIFFERENT
Description
The MSSW_DIFFERENT is an alarm indicating that the NE software versions on the CXPR
boards are inconsistent.

Attribute
0x023b Major Processing alarm
Parameters
table.
Name Meaning
Parameter 1 0x01: Files in the FLASH.

0x02: Software that is running currently.
0x03: Software in the CF card.
Parameter 2, Parameter 3 Indicates the number of the inconsistent file on the system control
boards.
Parameter 4 Indicates the alarm cause.

l 0x04: The versions of the files in the working and the protection
areas of a single system control board are inconsistent. Refer to
cause 1.
l 0x08: The versions of the files on the working system control
board are inconsistent with those on the protection system
control board, or in the same directory, files of the working board
do not have the same name as those of the protection board. Refer
to cause 2.
l 0x0C: The versions of the files in the working and the protection
areas of a single system control board are inconsistent, and the
versions of the files of the working system control board and the
protection system control board are inconsistent. Refer to cause
3.
Impact on System
l When the NE software versions of the working system control board and the protection
system control board are inconsistent, the protection switching of the system is affected.
l If no NE software exists on the FLASH, the system cannot restart after the system is
powered off or reset.
Possible Causes
The possible causes of the MSSW_DIFFERENT alarm are as follows:

l Cause 1: The versions of the files in the working and the protection areas of a single system
control board are inconsistent.
l Cause 2: The versions of the files on the working system control board are inconsistent
with those on the protection system control board, or in the same directory, files of the
working board do not have the same name as those of the protection board.
control board are inconsistent, and the versions of the files of the working system control
board and the protection system control board are inconsistent.
Handling Procedure
control board are inconsistent.
1. Determine the correct software version according to the version mapping table.
2. Reload the correct software. For details, refer to 6 Software Package Upgrade and
Package Diffusion.
l Cause 2: The versions of the files on the working system control board are inconsistent
with those on the protection system control board, or in the same directory, files of the
working board do not have the same name as those of the protection board.
1. On the T2000, query the software version of the two boards and determine the correct
software version according to the version mapping table. For details, refer to 8.3
Querying the Board Information Report.
Package Diffusion.
3. If the alarm persists, replace the board with the incorrect software version. For details,
control board are inconsistent, and the versions of the files of the working system control
board and the protection system control board are inconsistent.
1. On the T2000, query the software version of the two boards and determine the correct
software version according to the version mapping table. For details, refer to 8.3
Querying the Board Information Report.
Package Diffusion.
3. If the alarm persists, replace the board with the incorrect software version. For details,
----End
Related Information
None.
9.3.80 NESF_LOST
Description
The NESF_LOST is an alarm indicating that part of the NE software is lost.

Attribute
0x00d7 Critical Equipment alarm
Parameters
table.
Name Meaning
Parameter 1, Parameter 2 Indicates the type of the file that is lost in the board software.
Impact on System
l When the NESF_LOST alarm occurs, if the NE is not reset, the services are not affected.
l Once the NE is reset, the services on the entire NE are interrupted.
Possible Causes
The possible cause of the NESF_LOST alarm is as follows:
Part of the software on the CXPR board is lost or damaged.
Handling Procedure
l Cause: Part of the software on the CXPR board is lost or damaged.
1. Press and hold the CF RCV button of the CXPR board for 5 seconds to restore the NE
database from the CF card.
2. If the NESF_LOST alarm persists, replace the CF card for a new one which is loaded
the normal software. Then, reload the software to the CXPR board.
----End
Related Information
None.
9.3.81 NESTATE_INSTALL
Description
The NESTATE_INSTALL is an alarm indicating that the NE is in the installing state. This alarm
occurs when the NE is just delivered from the factory or when the user issues the command to
initialize the NE.

Attribute
0xC5 Critical Processing alarm
Parameters
None.
None.
Impact on System
When the NESTATE_INSTALL alarm occurs, no configuration exists at the NE side. Reload
the configuration at the NE side. Otherwise, the NE cannot be configured with services.
Possible Causes
The possible causes of the NESTATE_INSTALL alarm are as follows:
l Cause 1: The NE is configured with no data or the verification to the command issued by
the user to initialize the NE is not performed. Therefore, the NE is in the initializing state.
Handling Procedure
l Cause 1: The NE is configured with no data or the verification to the command issued by
the user to initialize the NE is not performed. Therefore, the NE is in the initializing state.
1. Issue the NE configuration data and perform the verification. Then, check whether
1. Cold-reset the CXPR board and check whether the NESTATE_INSTALL alarm is
cleared. For details, refer to 8.16 Resetting Boards.
2. If the NESTATE_INSTALL alarm persists, replace the CXPR board and check
whether the NESTATE_INSTALL alarm is cleared. For details, refer to 5 Replacing
Components.
----End
Related Information
None.
9.3.82 OUT_PWR_ABN
Description
The OUT_PWR_ABN is an alarm indicating that the output optical power is abnormal.

Attribute
0x001A Critical Equipment alarm
Parameters
None.
None.
Impact on System
When the OUT_PWR_ABN alarm occurs, the service transmission performance is affected. In
severe cases, the services are interrupted.
Possible Causes
The possible causes of the OUT_PWR_ABN alarm are as follows:
l Cause 1: The output optical power is excessively high or low.

Handling Procedure
l Cause 1: The output optical power is excessively high or low.
1. Replace the optical module on the port which reports the alarm and check whether the
alarm is cleared. For details, refer to 5.9 Replacing the Pluggable Optical Module.
1. Replace the board which reports the alarm and check whether the alarm is cleared.
For details, refer to 5 Replacing Components.
----End
Related Information
None.
9.3.83 PATCH_ACT_TIMEOUT
Description
The PATCH_ACT_TIMEOUT is an alarm indicating that activating the patch package times
out. This alarm occurs when the patch package is in the active state for a period longer than the
specified period of time. In this case, the user needs to process the patch package.

Attribute
0x31E8 Minor Equipment alarm
Parameters
None.
None.
Impact on System
When the PATCH_ACT_TIMEOUT alarm occurs, it does not affect services.
Possible Causes
The cause of the PATCH_ACT_TIMEOUT alarm is as follows:
The patch package is in the active state for a period longer than the specified period of time.
Handling Procedure
l Cause: The patch package is in the active state for a period longer than the specified period
of time.
1. Check whether the activated patch package is normal.
2. If yes, run the patch package to make the it valid. If not, delete the patch package.
Then, the alarm is cleared automatically.
----End
Related Information
None.
9.3.84 PATCH_DEACT_TIMEOUT
Description
The PATCH_DEACT_TIMEOUT is an alarm indicating that deactivating the patch package
times out. This alarm occurs when the patch package is in the inactive state for a period longer
than the specified period of time. In this case, the user needs to process the patch package.
Attribute
0x31E7 Minor Equipment alarm

Parameters
None.
None.
Impact on System
When the PATCH_DEACT_TIMEOUT alarm occurs, it does not affect services.
Possible Causes
The cause of the PATCH_DEACT_TIMEOUT alarm is as follows:
The patch package is in the inactive state for a period longer than the specified period of time.
Handling Procedure
l Cause: The patch package is in the inactive state for a period longer than the specified
period of time.
1. To make the patch package valid, activate the patch package.
2. Otherwise, delete the patch package. Then, the alarm is cleared automatically.
----End
Related Information
None.
9.3.85 PATCH_ERR
Description
The PATCH_ERR is an alarm indicating that the automatic patch loading fails. If there are
patches in the running state before the NE is reset, normally, the patches are automatically loaded
and executed after the NE is reset. If the loading fails due to an anomaly, the PATCH_ERR
alarm occurs.
Attribute
0x026D Major Equipment alarm
Parameters
None.
None.
Impact on System
The function of the patch is unavailable.

Possible Causes
The cause of the PATCH_ERR alarm is as follows:
The loading of the patches which are in the running state fails after the NE is reset.
Handling Procedure
l Cause: The loading of the patches which are in the running state fails after the NE is reset.
1. Reload the patch files and check whether the alarm is cleared.
2. If the PATCH_ERR alarm persists, download the correct patch files and then load
them. For details, refer to the OptiX iManager T2000 Online Help.
3. If the PATCH_ERR alarm still persists, replace the board that reports the alarm and
reload the patch files. For details, refer to 5 Replacing Components.
----End
Related Information
None.
9.3.86 PATCH_PKGERR
Description
The PATCH_PKGERR is an alarm indicating that the patch package file is incorrect.
Attribute
0x31F6 Minor Equipment alarm
Parameters
None.
None.
Impact on System
When the PATCH_PKGERR alarm occurs, if the board is protection board, the protection
switching cannot be performed and the services maybe interrupted.
Possible Causes
The cause of the PATCH_PKGERR alarm is as follows:
The patch package file is damaged or deleted.

Handling Procedure
l Cause: The patch package file is damaged or deleted.
1. Reload the patch files and check whether the alarm is cleared.
2. If the PATCH_ERR alarm persists, download the correct patch files and then load
them. For details, refer to the OptiX iManager T2000 Online Help.
3. If the PATCH_ERR alarm still persists, replace the board that reports the alarm and
reload the patch files. For details, refer to 5 Replacing Components.
----End
Related Information
None.
9.3.87 PATCHFILE_NOTEXIST
Description
The PATCHFILE_NOTEXIST is an alarm indicating that the patch file does not exist. If there
are patches in the running state before the NE is reset, normally, the patches are automatically
loaded and executed after the NE is reset. If the system finds that the patch files do not exist, the
PATCHFILE_NOTEXIST alarm occurs.
Attribute
0x026C Major Equipment alarm
Parameters
None.
None.
Impact on System
When the PATCHFILE_NOTEXIST alarm occurs, the patch cannot function.
Possible Causes
The possible cause of the PATCHFILE_NOTEXIST alarm is as follows:
The system finds that the patch files which are in the running state do not exist after the NE is
reset.
Handling Procedure
l Cause: The system finds that the patch files which are in the running state do not exist after
the NE is reset.

1. Newly download the patch files and then load them. For details, refer to the OptiX
iManager T2000 Online Help.
2. If the PATCHFILE_NOTEXIST alarm persists, replace the board that reports the
alarm and reload the patch files. For details, refer to 5 Replacing Components.
----End
Related Information
None.
9.3.88 POWER_ABNORMAL
Description
The POWER_ABNORMAL alarm indicates a power supply failure. When the power supply to
the board becomes abnormal, the POWER_ABNORMAL alarm is reported.
Attribute
0x19c Major Equipment alarm
Parameters
Name Meaning
Parameter 1 l 0x00: The 1.1 V power supply fails.

l 0x01: The 1.2 V power supply fails.
l 0x06: The 5 V power supply fails.
Parameter 2 l 0x00: The 1.2 V power supply fails.

l 0x03: The 3.3 VB power supply fails.

Name Meaning
Parameter 3 l 0x00: The 2nd -48 V power supply fails.

l 0x01: The 2nd 48 V power supply fails.
l 0x02: The 1st -48 V power supply fails.
l 0x03: The 1st 48 V power supply fails.
Impact on System
In the case of the POWER_ABNORMAL alarm, the power supply is abnormal and the board
may fail to function normally.
Possible Causes
In the case of the POWER_ABNORMAL alarm, first check whether one board or multiple
boards report the POWER_ABNORMAL alarm. The possible causes of the
POWER_ABNORMAL alarm are as follows:
l Cause for one board reporting the alarm: The power supply unit on the board is faulty.
l Cause 1 for multiple boards reporting the alarm: The PIU board is faulty.
l Cause 2 for multiple boards reporting the alarm: The power input is abnormal.
Handling Procedure
l Cause for one board reporting the alarm: The power supply unit on the board is faulty.
1. Cold-reset the board that reports the POWER_ABNORMAL alarm. For details, refer
to 8.16 Resetting Boards.
2. On the T2000, check whether the board enters state Running Status after cold reset.
NOTE
The COMMUN_FAIL alarm is reported during the cold reset. When the COMMUN_FAIL
alarm ends, the board enters state Running Status.
– If the board fails to enter state Running Status, it indicates that the board is faulty
and needs to be replaced.
– If the board enters state Running Status, check whether the
POWER_ABNORMAL alarm ends
3. If the POWER_ABNORMAL alarm persists, replace the board that reports this alarm.
For details, refer to 5 Replacing Components.
l Cause 1 for multiple boards reporting the alarm: The PIU board is faulty.
1. Check whether there is HARD_BAD, BUS_ERR or COMMUN_FAIL alarm on the
PIU board which indicates the hardware is faulty.
2. If yes, clear these alarms first and then check whether the POWER_ABNORMAL
alarm is cleared.
l Cause 2 for multiple boards reporting the alarm: The power input is abnormal.
1. Check whether the power supply to the NE is normal. For details, refer to the OptiX
RTN 950 Radio Transmission System IDU Quickly Installation Guide manual.

2. If not, make sure that another power supply is connected to the NE and check whether
the POWER_ABNORMAL alarm is cleared.
----End
Related Information
None.
9.3.89 POWER_ALM
Description
The POWER_ALM is an alarm indicating that the power supply fails. This alarm is reported if
the ODU detects that its power module fails.
Attribute
0x017F Major Equipment alarm
Parameters
table.
Name Meaning
Parameter 1 Indicates the ID of the power supply that reports the alarm. For example, 0x01
indicates that the alarm is reported by the first group of power supply of the board.
Parameter 2 l 0x01: Indicates that the active power fails.
l 0x02: Indicates that the standby power fails.
Parameter 3 l 0x01: Indicates over-voltage.

l 0x02: Indicates under-voltage.
Impact on System
The ODU fails to work normally.
Possible Causes
The power module of the ODU is faulty.

Handling Procedure
Step 1 Replace the ODU that reports the POWER_ALM alarm.
----End
Related Information
None.
9.3.90 PPP_LCP_FAIL
Description
The PPP_LCP_FAIL is an alarm of LCP protocol negotiation failure. This alarm occurs when
the encapsulation type of the local port is set to PPP, but the negotiation with the opposite port
fails.
Attribute
Parameters
None.
None.
Impact on System
When the PPP_LCP_FAIL alarm occurs, the LCP negotiation fails and the services are
interrupted.
Possible Causes
The possible causes of the PPP_LCP_FAIL alarm are as follows:
l Cause 1: The configuration parameters of the port are inconsistent at the two ends.
l Cause 2: The network is baffled or of poor quality and The LCP protocol runs abnormally.
l Cause 3: the physical link is interrupted.
Handling Procedure
l Cause 1: The configuration parameters of the port are inconsistent at the two ends.
1. On the T2000, check whether the configuration parameters of the opposite port are
consistent with that of the local port. For details, refer to Configuring Interfaces in the

2. If not, modify the configuration to make it consistent at the two ends. Then, check
l Cause 2: The network is baffled or of poor quality and The LCP protocol runs abnormally.
1. On the T2000, check whether the bandwidth configured to the tunnel which connects
to the port is too low. For details, refer to Configuring an MPLS Tunnel in the
2. If yes, re-configure the tunnel with a bigger bandwidth. Then, check whether the alarm
is cleared.
1. Check whether the physical link is normal.
2. If not, modify the faulty physical link and check whether this alarm is cleared.
----End
Related Information
None.
9.3.91 PPP_NCP_FAIL
Description
The PPP_NCP_FAIL is an alarm of NCP negotiation failure. When it is detected that a link with
PPP encapsulation type is not added into the MP group, this alarm occurs.
Attribute
Parameters
None.
None.
Impact on System
When the PPP_NCP_FAIL alarm occurs, the NCP negotiation fails and the services are
interrupted.
Possible Causes
The possible causes of the PPP_NCP_FAIL alarm are as follows:
l Cause 1: A link with PPP encapsulation type is not added into the MP group.
l Cause 2: The network is baffled or of poor quality and The NCP protocol runs abnormally.

Handling Procedure
l Cause 1: A link with PPP encapsulation type is not added into the MP group.
1. On the T2000, check whether all links with PPP encapsulation type are added into the
MP group. For details, refer to Configuring ML-PPP in the Configuration Guide
manual.
2. If not, add the link into the MP group. Then, check whether the alarm is cleared.
l Cause 2: The network is baffled or of poor quality and The NCP protocol runs abnormally.
1. On the T2000, check whether the bandwidth configured to the tunnel which connects
to the port is too low. For details, refer to Configuring an MPLS Tunnel in the
2. If yes, re-configure the tunnel with a bigger bandwidth. Then, check whether the alarm
is cleared.
1. Check whether the physical link is normal.
2. If not, modify the faulty physical link and check whether this alarm is cleared.
----End
Related Information
None.
9.3.92 PW_DOWN
Description
The PW_DOWN alarm indicates that the PW service connection is interrupted.
Attribute
Parameters
ID Name
Parameter 1 to Parameter 4 Indicate the index number of the faulty PW.
Parameter 5 to Parameter 8 Indicate the running state of the local end.
Parameter 9 to Parameter 12 Indicate the running state of the opposite end.
Impact on System
In the case of the PW_DOWN alarm, the services carried by the PW are already interrupted.

Possible Causes
The possible causes of the PW_DOWN alarm are as follows:
l Cause 1: The PW configuration at the local and remote ends is inconsistent.
l Cause 3: The tail fiber is not properly connected to the optical interface on the board.
l Cause 4: The optical module is faulty.
Handling Procedure
l Cause 1: The PW configuration at the local and remote ends is inconsistent.
1. On the T2000, query the type of the service that the PW carries and check whether
the PW configuration at the two NEs is consistent.
2. If not, modify the configuration so that the PW configuration at the two NEs is
consistent.
1. On the T2000, check whether the bandwidth configured to the tunnel is too small.
2. If yes, expand the bandwidth or eliminate the source where a large amount of illegal
data is transmitted. Then, check whether the alarm is cleared.
l Cause 3: The tail fiber is not properly connected to the optical interface on the board.
1. Check whether the tail fibers are properly connected to the optical interfaces on the
boards at the two NEs.
2. If not, properly re-connect the tail fibers.
1. On the T2000, check whether the NEs at the two ends report any alarm related to the
optical module, such as the LSR_WILL_DIE alarm. For details, refer to 8.2
2. If yes, replace the faulty optical module. For details, refer to 5.9 Replacing the
Pluggable Optical Module.
1. On the T2000, check whether the hardware-related alarms occur on the board of the
two NEs, such as the HARD_BAD alarm.
the DOWN_E1_AIS alarm is cleared. For details, refer to 8.16 Resetting Boards.
3. If the DOWN_E1_AIS alarm persists, replace the related board and check whether
the DOWN_E1_AIS alarm is cleared. For details, refer to 5 Replacing
Components.
----End
Related Information
None.
9.3.93 R_LOC

Description
The R_LOC is an alarm indicating that clock signal is not detected at the receive end. This alarm
is reported if the line board fails to extract clock signal from the line signal.
Attribute
Parameters
table.
Name Meaning
Parameter 1 Indicates the ID of the line port that reports the alarm. For example, 0x01
Parameters 2–3 Indicate the path ID.
Impact on System
The service carried over the port is interrupted. If the system is configured with protection,
protection switching may be triggered.
Possible Causes
l The transmit unit of the remote site is faulty.
l The receive unit of the local site is faulty.
Handling Procedure
Step 1 Based on the alarm parameters, locate the line port that reports the alarm.
Step 2 Perform port inloop at the local end.
If... Then...
The alarm persists Replace the local board that reports the R_LOC alarm.
The alarm disappears Go to the next step.
Step 3 Replace the line board at the opposite site.

If... Then...
The alarm disappears after the board is The fault is rectified, and the alarm handling
The alarm persists after the board is Go to the next step.
replaced
Step 4 Replace the CXPR board at the opposite.
If... Then...
The CXPR board at the opposite end is Refer to 5.1 Replacing the CXPR with the 1
configured with the 1+1 protection scheme +1 Protection.
The CXPR board at the opposite end is not Refer to 5.2 Replacing the CXPR Without
configured with the 1+1 protection scheme the 1+1 Protection.
----End
Related Information
None.
9.3.94 RADIO_FADING_MARGIN_INSUFF
Description
The RADIO_FADING_MARGIN_INSUFF is an alarm indicating that the mean received power
of the ODU is lower than the threshold of the received power (the threshold value is about the
receiver sensitivity + 14dB).
When the received power of the ODU in consecutive six hours is lower than the threshold, the
system reports the alarm. When the mean received power of the ODU becomes normal in three
minutes after the alarm is reported, the alarm is cleared. The alarm is reported once every 24
hours.
Attribute
Alarm Severity Alarm Type
Minor Equipment alarm
Parameters
table.
Name Meaning
Parameter 0 The value is always 0x01.

Name Meaning
Parameter 1, Parameter 2 The value is always 0xff 0xff.
Parameter 3, Parameter 4 The value is always 0xff 0xff.
Impact on System
If the MW_LOF or MW_FECUNCOR alarm is not generated, the service is not affected.
Possible Causes
l The ODU fault of the transmit end causes the abnormal transmit power.
l The direction of the antenna is deflected.
l The transmission environment changes.
l The fade margin in the case of rain and fog in the network planning is insufficient.
Handling Procedure
Step 1 Use the NMS to check whether the power of the ODU at the transmit end is normal.
If ... Then ...

The transmit power is abnormal Rectify the fault according to the alarm at the transmit end.
For how to rectify the fault, see Troubleshooting
Microwave Links.
The transmit power is normal Proceed to the next step.
Step 2 Check whether the direction of the antenna is deflected.
If ... Then ...

The direction of the antenna is deflected Adjust the direction of the antenna.
The direction of the antenna is not deflected Proceed to the next step.
Step 3 Check whether the transmission environment changes. For example, check whether any building
blocks the transmission, any large area of water surface such as a lake changes the link fading
significantly.
If ... Then ...

The transmission environment changes Contact the network planning department for
re-planning the transmission trail.
The transmission environment does not Proceed to the next step.
change
Step 4 If the alarm is reported frequently, contact the network planning department for increasing the
fade margin by re-planning the transmission trail.
----End

Related Information
None.
9.3.95 RADIO_RSL_LOW
Description
The RADIO_RSL_LOW is an alarm indicating that the radio receive power is too low. This
alarm is reported if the detected receive power is equal to or below the lower threshold of the
ODU (–90 dBm).
Attribute
0x027E Critical Service alarm
Parameters
table.
Name Meaning
Parameter 1 Indicates the RF port that reports the alarm.
Impact on System
If there is neither the MW_LOF nor the MW_FECUNCOR alarm, the services are not affected.
Possible Causes
l The microwave link signal is too much attenuated.
l The transmit power of the remote site is too low.
l The ODU of the local site is faulty.
Handling Procedure
Step 1 Check whether the transmit power of the remote site is normal.
If... Then...
No Replace the ODU of the remote site.
Step 2 Check whether the alarm occurs frequently.

If... Then...
The alarm occurs occasionally Contact the network planning department to change the
design to increase the anti-fading performance.
The alarm occurs frequently Go to the next step.
Step 3 Check whether the antennas at both ends are properly adjusted.
If... Then...
No Adjust the antenna again.
Step 4 Check whether the polarization direction of the antenna, ODU, and hybrid coupler is correctly
set.
If... Then...
No Correct the polarization direction.
Step 5 Check whether the outdoor units such as antennas, combiner, ODU, and flexible waveguide are
wet, damp, or damaged.
If... Then...
Yes Replace the unit that is wet, damp, or damaged.
Step 6 Check whether the antenna gain at both the transmit and receive sides meets the requirement.
If... Then...
No Replace the antenna.
Step 7 Check whether there is a mountain or building in the transmit direction.
If... Then...
Yes Contact the network planning department to change the design to avoid mountain or
building interference.
Step 8 Replace the ODU and the coupler at the local site in turn.
If... Then...
The RADIO_RSL_LOW alarm is cleared after the ODU The alarm handling is complete.
and the coupler are replaced
The RADIO_RSL_LOW alarm persists after the ODU Go to the next step.
and the coupler are replaced

Step 9 Replace the ODU and the coupler at the opposite site in turn.
----End
Related Information
None.
9.3.96 RADIO_RSL_HIGH
Description
The RADIO_RSL_HIGH is an alarm indicating that the radio receive power is too high. This
alarm is reported if the detected receive power is equal to or higher than the upper threshold of
the ODU (–20 dBm).
Attribute
0x027D Critical Service alarm
Parameters
table.
Name Meaning
Impact on System
The service transmission is affected. If the system is configured with 1+1 protection, protection
Possible Causes
l There is a strong interference source nearby.
Handling Procedure

If... Then...
The alarm disappears after the ODU is The fault is rectified, and the alarm handling
The alarm persists after the ODU is replaced Go to the next step.
Step 2 Remove the nearby strong interference source.
----End
Related Information
None.
9.3.97 RADIO_TSL_LOW
Description
The RADIO_TSL_LOW is an alarm indicating that the radio transmit power is too low. This
alarm is reported if the detected transmit power is below the lower power threshold of the ODU.
Attribute
0x027B Critical Service alarm
Parameters
table.
Name Meaning
Impact on System
Possible Causes
The ODU is faulty.

Handling Procedure
----End
Related Information
None.
9.3.98 RADIO_TSL_HIGH
Description
The RADIO_TSL_HIGH is an alarm indicating that the radio transmit power is too high. This
alarm is reported if the detected transmit power is higher than the upper power threshold of the
ODU.
Attribute
0x027C Critical Service alarm
Parameters
table.
Name Meaning
Impact on System
Possible Causes
The ODU is faulty.
Handling Procedure
----End

Related Information
None.
9.3.99 RADIO_MUTE
Description
The RADIO_MUTE is an alarm indicating that radio transmitter is muted.
Attribute
0x027F Warning Equipment alarm
Parameters
table.
Name Meaning
Impact on System
The transmitter does not launch services.
Possible Causes
l The transmitter of the local site is muted.
l The data configuration of the ODU is incorrect.
l The IF board is faulty, causing abnormal IF output.
Handling Procedure
Step 1 Check whether the transmitter of the ODU is muted.
If... Then...
Yes Cancel the muting operation.
Step 2 Check whether there is an CONFIG_NOSUPPORT alarm.

If... Then...
Yes Handle the CONFIG_NOSUPPORT alarm.
Step 3 Replace the IF board.
----End
Related Information
None.
9.3.100 RELAY_ALARM_CRITICAL
Description
The RELAY_ALARM_CRITICAL is an alarm of critical alarm inputs. This alarm occurs when
the user sets the severity of an available alarm input to critical and there is such an alarm input.
Attribute
Parameters
table.
Name Meaning
Parameter 1 Indicates the number of the alarm input/output.

Range of parameter 1: 0x01 to 0x08.
Impact on System
l When the RELAY_ALARM_CRITICAL alarm occurs, it does not affect the operation of
the board or the services on the NE.
l This alarm is a non-root alarm. When there is no other critical alarm on the equipment, this
alarm will be cleared automatically.
Possible Causes
The cause of the RELAY_ALARM_CRITICAL alarm is as follows:
There is a critical alarm input.

Handling Procedure
l Cause: There is a critical alarm input.
1. Check the alarm parameters and confirm the number of the alarm input/output.
2. Rectify the fault of the equipment to stop the alarm input, and then check whether the
RELAY_ALARM_CRITICAL alarm is cleared.
----End
Related Information
None.
9.3.101 RELAY_ALARM_MAJOR
Description
The RELAY_ALARM_MAJOR is an alarm of major alarm inputs. This alarm occurs when the
user sets the severity of an alarm input to major and there is such an alarm input.
Attribute
Parameters
table.
Name Meaning

Impact on System
l When the RELAY_ALARM_MAJOR alarm occurs, it does not affect the operation of the
board or the services on the NE.
l This alarm is a non-root alarm. When there is no other major alarm on the equipment, this
Possible Causes
The cause of the RELAY_ALARM_MAJOR alarm is as follows:

There is a major alarm input.
Handling Procedure
l Cause: There is a major alarm input.
RELAY_ALARM_MAJOR alarm is cleared.
----End
Related Information
None.
9.3.102 RELAY_ALARM_MINOR
Description
The RELAY_ALARM_MINOR is an alarm of minor alarm inputs. This alarm occurs when the
user sets the severity of an available alarm input to minor and there is such an alarm input.
Attribute
Parameters
table.
Name Meaning

Impact on System
l When the RELAY_ALARM_MINOR alarm occurs, it does not affect the operation of the
l This alarm is a non-root alarm. When there is no other minor alarm on the equipment, this

Possible Causes
The cause of the RELAY_ALARM_MINOR alarm is as follows:
There is a minor alarm input.
Handling Procedure
l Cause: There is a minor alarm input.
RELAY_ALARM_MINOR alarm is cleared.
----End
Related Information
None.
9.3.103 RELAY_ALARM_IGNORE
Description
The RELAY_ALARM_IGNORE is an alarm of warning alarm inputs. This alarm occurs when
the user sets the severity of an available alarm input to warning and there is such an alarm input.
Attribute
0x3014 Warning Equipment alarm
Parameters
table.
Name Meaning

Impact on System
l When the RELAY_ALARM_IGNORE alarm occurs, it does not affect the operation of the

l This alarm is a non-root alarm. When there is no other warning alarm on the equipment,
this alarm will be cleared automatically.
Possible Causes
The cause of the RELAY_ALARM_IGNORE alarm is as follows:
There is a warning alarm input.
Handling Procedure
l Cause: There is a warning alarm input.
RELAY_ALARM_IGNORE alarm is cleared.
----End
Related Information
None.
9.3.104 RPS_INDI
Description
The RPS_INDI is an alarm indicating that the microwave protection switching is detected.
Attribute
Parameters
table.
Name Meaning
Parameter 1 Indicates the ID of the protection group, and defaults as 0x01.
Parameter 2 Indicates the type of protection switching.
0x01 indicates HSB protection switching.
0x02 indicates HSM protection switching.

Impact on System
During the HSB protection switching, services are interrupted. After the HSB protection
switching is complete, the services become normal.
During the HSM protection switching, no bit errors are generated, and services are not affected.
Possible Causes
l The possible causes of the HSB protection switching are as follows:
– 1. The external switching triggered by the switching command that is issued by the
NMS software, occurs.
– 2. The automatic switching triggered by equipment failure or a service defect, occurs.
– 3. The reverse switching occurs. When the reserve switching of the HSB protection
group is enabled, the HSB protection switching occurs if both the protection and the
working IF boards report the MW_RDI alarm.
l The possible cause of the HSM protection switching is as follows: The working path
degrades.
Handling Procedure
l Determine the type of the protection switching based on the alarm parameters.
l Cause 1 of HSB switching: External switching occurs. That is, NMS issues a command to
trigger the switching.
Follow the steps:
1. Select the NE from the Object Tree in the NE Explorer.
2. The IF 1+1 protection group dialog box is displayed. Choose Configuration > IF 1
+1 Protection from the Function Tree.
3. Click Query. Query Equipment Switching Status in Protection Group.
If Equipment Switching Status in Protection Group is set to Forced switching or
Manual switching, the NMS issues a command to perform external switching.
4. Identify the cause of the forced switching, and clear the external switching
immediately.In Slot Mapping Relation, select the working unit or the protection unit
of a protection group. Right-click and choose Clear switching from the shortcut menu.
Click OK in the displayed dialog box.
l Cause 2 of HSB switching: Automatic switching occurs. That is, the equipment is faulty,
or the service is defective.
Follow the steps:
1. Check whether any of the following faults or alarms occur. If any of the following
faults or alarms occur, rectify the faults or clear the alarms.
– The IF board hardware is faulty, or the ODU hardware is faulty, focus on the alarms
such as HARD_BAD and TEMP_ALARM.
– POWER_ALM, VOLT_LOS (IF board)
– RADIO_TSL_HIGH, RADIO_TSL_LOW or RADIO_RSL_HIGH
– IF_INPWR_ABN or CONFIG_NOSUPPORT
– R_LOC or MW_LOF

NOTE
l If the switching is non-revertive, the services are not automatically switched to the working
path when the working path is restored to normal, and the RPS_INDI alarm persists. In this
case, you need to manually switch the services from the protection path to the working
path. The RPS_INDI alarm is cleared only when the switching is successful.
l If the switching is revertive, the services are automatically switched to the working path
only when the specified wait-to-restore (WTR) time expires after the working path is
restored to normal. The RPS_INDI alarm is cleared only when the switching is successful.
l Cause 3 of HSB switching: Reverse switching occurs. If the reverse switching function of
the HSB protection group is enabled, the switching is triggered when the MW_RDI alarm
is reported by the working and protection IF boards.
For the handling procedure, see MW_RDI.
l Switching cause of the HSM: The working path degrades. This symptom is normal without
any impact on services. Hence, no measure is required to handle the symptom.
----End
Related Information
None.
9.3.105 S1_SYN_CHANGE
Description
The S1_SYN_CHANGE is an alarm indicating the switching of the clock source in the S1 byte
mode. This alarm occurs when, in the SSM mode, the traced clock source is switched.
Attribute
0x00C1 Major Equipment alarm
Parameters
table.
Name Meaning
Parameter 1 Indicates the type of the switched clock source.

l 0x01: System clock.
l 0x02: First 2M clock.
l 0x03: Second 2M clock.

Impact on System
When the S1_SYN_CHANGE alarm occurs, if the new clock source has a lower quality, pointer
justifications and bit errors are generated. As a result, the quality of services is affected.
Possible Causes
The possible causes of the S1_SYN_CHANGE alarm are as follows:
l Cause 1: The external BITS clock is lost.

l Cause 2: The service signals are lost.
l Cause 3: The S1_SYN_CHANGE alarm is generated at the upstream NE.
Handling Procedure
l Cause 1: The external BITS clock is lost.
2. If yes, clear the EXT_SYNC_LOS alarm and then check whether this alarm is cleared.
l Cause 2: The service signals are lost.
1. On the T2000, check whether the ETH_LOS or T_ALOS alarm occurs.
2. If yes, clear the ETH_LOS or T_ALOS alarm first and then check whether this alarm
is cleared.
l Cause 3: The S1_SYN_CHANGE alarm is generated at the upstream NE.
1. On the T2000, check whether the S1_SYN_CHANGE alarm occurs at the upstream
NE.
2. If yes, clear the S1_SYN_CHANGE alarm occurs at the upstream NE first and check
whether the S1_SYN_CHANGE alarm at the local NE is cleared.
----End
Related Information
None.
9.3.106 SECU_ALM
Description
The SECU_ALM is an alarm indicating that an illegal user fails to log in to the NE.
Attribute
0x00C8 Major Equipment alarm

Parameters
table.
Name Meaning
Parameter 1 Indicates the type of the login terminal.
Parameter 2, Parameter 3 Indicates the login errors.
Parameter 4, Parameter 5 Indicates the first two characters of the user name that is locked
after the login verification fails.
Impact on System
l After the password is incorrectly entered for three consecutive times, the user account is
temporarily locked. Two minutes later, the user account can be used for another login.
l The alarm ends immediately after it is reported.
Possible Causes
The cause of the alarm is as follows:
An illegal user fails to log in to the NE.
Handling Procedure
l Cause: An illegal user fails to log in to the NE.
1. Query the NE security log to check the user name that is used for the login. For details,
refer to 8.1 Querying T2000 Operation Logs.
2. Log in to the NE with a correct user name.
----End
Related Information
After the login password are incorrectly entered for three consecutive times, the network
management system automatically locks the screen. Only the administrator can unlock the
screen.
9.3.107 SWDL_ACTIVATED_TIMEOUT
Description
The SWDL_ACTIVATED_TIMEOUT is an alarm indicating the activation timeout of the
software package. This alarm occurs when the NE does not perform the commit operation a
certain time later after the board software is activated during the software package loading.

Attribute
0x23d Critical Processing alarm
Parameters
None.
None.
Impact on System
When the SWDL_ACTIVATED_TIMEOUT alarm occurs, the software in the two areas of the
double-area boards on the NE is inconsistent. If any board becomes abnormal, rollback.
Possible Causes
The cause of the SWDL_ACTIVATED_TIMEOUT alarm is as follows:
The NE does not perform the commit operation 30 minutes later after the software is activated.
Handling Procedure
l Cause: The NE does not perform the commit operation in 30 minutes later after the software
is activated.
1. Check whether the software package loading is complete.
2. If yes, continue the commit operation of the software package loading. Then the alarm
is cleared automatically.
----End
Related Information
None.
9.3.108 SWDL_AUTOMATCH_INH
Description
The SWDL_AUTOMATCH_INH is an alarm indicating that the automatic match function is
disabled.
Attribute
0x0a0e Minor Processing alarm

Parameters
None.
None.
Impact on System
When the SWDL_AUTOMATCH_INH alarm occurs, the alarmed board cannot automatically
match the software from the CXPR board. Thus, the consistency of the software version on the
entire NE is affected and some functions of the NE may operate abnormally.
Possible Causes
The cause of the SWDL_AUTOMATCH_INH alarm is as follows:
The automatic match function is disabled.
Handling Procedure
l Cause: The automatic match function is disabled.
1. Issue the order to enable the automatic switch function, and then check whether the
alarm is cleared.
----End
Related Information
None.
9.3.109 SWDL_COMMIT_FAIL
Description
The SWDL_COMMIT_FAIL is an alarm indicating that the NE fails to commit the software.
This alarm occurs when the NE fails to commit the software for certain boards during the
software package loading.
Attribute
0x0a0b Minor Processing alarm
Parameters
None.
None.

Impact on System
When the SWDL_COMMIT_FAIL alarm occurs, the software versions of the two file systems
on the system control board are inconsistent.
Possible Causes
The possible causes of the SWDL_COMMIT_FAIL alarm are as follows:
l Cause 1: The commit operation on the NE fails for certain boards.
Handling Procedure
l Cause 1: The commit operation on the NE fails for certain boards.
1. Check whether the software currently running on the system control board is consistent
with the software to be loaded. For details, refer to 8.3 Querying the Board
Information Report.
2. If the software currently running on the system control board is inconsistent with the
software to be loaded, restart the software package loading. After the software package
loading is successful, the alarm is cleared automatically. For details, refer to 6
Software Package Upgrade and Package Diffusion.
1. Check whether the hardware alarms such as the HARD_BAD alarm occur on the
system control board. For details, refer to 8.2 Querying Current Alarms of a
Board.
2. If yes, replace the system control board, and then check whether the
SWDL_COMMIT_FAIL alarm are cleared. For details, refer to 5 Replacing
Components.
----End
Related Information
None.
9.3.110 SWDL_INPROCESS
Description
The SWDL_INPROCESS is an alarm indicating that the NE is loading the software package.
Attribute
0x0a0c Minor Processing alarm
Parameters
None.

None.
Impact on System
When the SWDL_INPROCESS alarm occurs, the NE is loading the software package. The
operations, including modifying configurations, uploading/downloading files, and backing up
the database, are prohibited.
Possible Causes
The cause of the SWDL_INPROCESS alarm is as follows:
The NE is loading the software package.
Handling Procedure
l Cause: The NE is loading the software package.
1. Wait until the software package loading is complete, and check whether the alarm is
cleared.
----End
Related Information
None.
9.3.111 SWDL_NEPKGCHECK
Description
The SWDL_NEPKGCHECK is an alarm indicating that when a file in the software package is
lost or fails to pass the check, the file cannot be modified. When a file in the software package
is lost or fails to pass the check, the system will modify the file from the other normal files. If
the modification fails, the SWDL_NEPKGCHECK occurs.
Attribute
0x023e Critical Processing alarm
Parameters
None.
None.
Impact on System
l When the alarm occurs, the operations of the package loading of the NE cannot be complete.
l When the file is complete and passes the check, the alarm will be cleared automatically.

Possible Causes
The cause of the SWDL_NEPKGCHECK alarm is as follows:
The file type mismatches or a file is lost.
Handling Procedure
l Cause: The file type mismatches or a file is lost.
1. Check whether the file type matches, and whether a file is lost. If file mismatch or fie
loss occurs, download the mapping software again.
2. Perform the software package loading again, and update the software package. Then
check whether the alarm is cleared. For details, refer to 6.1.4 Creating a Package
Upgrade Task.
----End
Related Information
None.
9.3.112 SWDL_PKG_NOBDSOFT
Description
The SWDL_PKG_NOBDSOFT is an alarm indicating that the files of some boards are not in
the software package for loading and the board matching fails.
Attribute
0x0a09 Minor Processing alarm
Parameters
None.
None.
Impact on System
As the software of the board is not contained in the software package, the board cannot perform
automatic match. As a result, the software version of the board is inconsistent with that of the
NE. Some functions may operate abnormally.
Possible Causes
The cause of the SWDL_PKG_NOBDSOFT alarm is as follows:
The files of some boards are not in the customized software package.

Handling Procedure
l Cause: The files of some boards are not in the customized software package.
1. Re-download an integrate software package and perform the software package loading
for a second time. When the software package loading is complete, the
SWDL_PKG_NOBDSOFT alarm is cleared automatically. For details, refer to 6
----End
Related Information
None.
9.3.113 SWDL_PKGVER_MM
Description
The SWDL_PKGVER_MM is an alarm indicating that the consistency check of the software
package version fails.
Attribute
0x0a0d Minor Processing alarm
Parameters
None.
None.
Impact on System
If the software versions on the NE are inconsistent, some functions of the NE may operate
abnormally.
Possible Causes
The cause of the SWDL_PKGVER_MM alarm is as follows:
The version information in the description file of the software package is inconsistent with the
actual version information.
Handling Procedure
l Cause: The version information in the description file of the software package is
inconsistent with the actual version information.
1. Re-download an correct software package and perform the software package loading
for a second time. When the software package loading is complete, the

SWDL_PKGVER_MM alarm is cleared automatically. For details, refer to 6

----End
Related Information
None.
9.3.114 SWDL_ROLLBACK_FAIL
Description
The SWDL_ROLLBACK_FAIL is an alarm indicating that the rollback fails for certain boards
during the software package loading.
Attribute
0x0a0a Minor Processing alarm
Parameters
None.
None.
Impact on System
When the SWDL_ROLLBACK_FAIL alarm occurs, The failed boards may have the software
inconsistent with the NE software. Hence, some functions of the failed boards may be affected.
Possible Causes
The possible cause of the SWDL_ROLLBACK_FAIL alarm is as follows:
Rollback of certain boards fails during rollback of the entire NE.
Handling Procedure
l Cause: Rollback of certain boards fails during rollback of the entire NE.
1. Check whether there is MSSW_DIFFERENT alarm. For details, refer to 8.2 Querying
Current Alarms of a Board.If yes, clear the alarm first.
2. Restart the software package loading. After the software package loading is
successful, the alarm is cleared automatically. For details, refer to 6 Software Package
Upgrade and Package Diffusion.
----End
Related Information
None.

9.3.115 SYN_BAD
Description
The SYN_BAD is an alarm indicating that the synchronization clock source is degraded. This
alarm occurs when the synchronization clock source traced by the equipment is degraded.
Attribute
Parameters
None.
None.
Impact on System
If the clock source is degraded, tracing it may cause bit errors to the services.
Possible Causes
The possible causes of the SYN_BAD alarm are as follows:
l Cause 1: The quality of the traced clock source is degraded.

l Cause 2: The board that reports the SYN_BAD alarm has a hardware failure.
Handling Procedure
l Cause 1: The quality of the traced clock source is degraded.
1. Replace the current clock source with a normal one and check whether the SYN_BAD
alarm is cleared. For details, refer to Configuring the NE Clock Source in the OptiX
2. If the SYN_BAD alarm persists, check whether the input clock is correctly configured.
If not, modify the configuration and check whether the SYN_BAD alarm is cleared.
l Cause 2: The board that reports the SYN_BAD alarm has a hardware failure.
1. On the T2000, check whether there is the HARD_BAD or TEMP_OVER alarm
indicating the hardware is faulty.
2. If yes, clear these alarms first and check whether the SYN_BAD alarm is cleared.
----End
Related Information
None.

9.3.116 SYNC_C_LOS
Description
The SYNC_C_LOS is an alarm indicating the loss of synchronization source level. This alarm
occurs when the clock source of a service board is lost in the priority table.
Attribute
0x006F Warning Equipment alarm
Parameters
None.
None.
Impact on System
When the SYNC_C_LOS alarm occurs, the relevant clock source is lost and cannot be traced
by the equipment. The services are slightly degraded.
Possible Causes
The possible causes of the SYNC_C_LOS alarm are as follows:
l Cause 1: The external clock is lost.

l Cause 2: The input service signals related to the clock source are lost.
Handling Procedure
l Cause 1: The external clock is lost.
2. If yes, clear the EXT_SYNC_LOS alarm and then check whether the SYNC_C_LOS
alarm is cleared.
l Cause 2: The input service signals related to the clock source are lost.
1. On the T2000, check whether the T_ALOS or ETH_LOS alarm occurs which
indicates the input service signals are lost. For details, refer to 8.2 Querying Current
Alarms of a Board.
2. If yes, clear the alarm indicating the loss of service signals fist, and then check whether
the SYNC_C_LOS alarm is cleared.
----End

Related Information
9.3.117 SYNC_DISABLE
Description
The SYNC_DISABLE is an alarm indicating that the automatic synchronization function of the
system control board is disabled. When the automatic synchronization function of the system
control board is disabled, the SYNC_DISABLE alarm occurs.
Attribute
0x31F8 Minor Processing alarm
Parameters
None.
None.
Impact on System
l When the SYNC_DISABLE alarm occurs, the batch backup cannot be initiated. Thus, the
data of the working and protection boards is inconsistent.
l When the automatic synchronization function of the system control board is enabled, the
alarm is cleared automatically.
Possible Causes
The cause of the SYNC_DISABLE alarm is as follows:
The automatic synchronization function of the system control board is disabled.
Handling Procedure
l Cause: The automatic synchronization function of the system control board is disabled.
1. Issue an order to set the automatic synchronization state of the system control board
to enabled, and then check whether the alarm is cleared.
2. If the SYNC_DISABLE alarm persists, replace the board that reports the alarm. For
detail, refer to 5 Replacing Components.
----End
Related Information
None.

9.3.118 SYNC_F_M_SWITCH
Description
The SYNC_F_M_SWITCH is an alarm indicating that the clock source is switched in a manual
or forced manner.
Attribute
Parameters
table.
Name Meaning
Parameter 1 Indicates the slot ID.

0xFF: No sub-board.
Parameter 3, Parameter 4 Indicates the port ID.

l Parameter 1=0x00, Parameter 2=0xf0, Parameter 3=0x00,
Parameter 4=0x01: First external clock source.
Parameter 4=0x02: Second external clock source.
Parameter 4=0x01: Internal clock source.
Impact on System
When the SYNC_F_M_SWITCH alarm occurs, the NE clock works in the forced or manual
switching state. This alarm does not affect services.
Possible Causes
The cause of the SYNC_F_M_SWITCH alarm is as follows:
The NE issues the command of manual or forced switching to the clock source.

Handling Procedure
l Cause: The NE issues the command of manual or forced switching to the clock source.
1. Check the alarm parameters to confirm the relevant clock source.
2. Referring to the actual scene, remove the manual or forced switching from the relevant
clock source, and then check whether the alarm is cleared. For details, refer to the
OptiX iManager T2000 Online Help.
----End
Related Information
None.
9.3.119 SYNC_FAIL
Description
The SYNC_FAIL is an alarm indicating that the backup of the databases on the active and
standby system control boards fails.
Attribute
0x24f Minor Processing alarm
Parameters
None.
None.
Impact on System
When the SYNC_FAIL alarm occurs, the data on the working CXPR and protection CXPR
cannot be synchronized. When the CXPR 1+1 protection switching is performed, the system
may run in an abnormal state as the data is lost or conflicts.
Possible Causes
The possible causes of the SYNC_FAIL alarm are as follows:
l Cause 1: The databases of the active and standby system control boards are damaged during
the batch backup of the databases.
l Cause 2: The communication between the active and standby system control boards is
interrupted during the batch backup of the databases.
l Cause 3: The software versions of the active and standby system control boards are
inconsistent.

Handling Procedure
l Cause 1: The databases of the active and standby system control boards are damaged during
the batch backup of the databases.
1. Check whether the DBMS_ERROR alarm occurs on the NE. For details, refer to 8.2
2. If yes, clear the DBMS_ERROR alarm first, and then check whether the SYNC_FAIL
alarm is cleared.
l Cause 2: The communication between the active and standby system control boards are
interrupted during the batch backup of the databases.
1. Check whether the COMMUN_FAIL alarm occurs on the NE.
2. If yes, clear the COMMUN_FAIL alarm first, and then the NE restarts the batch
backup automatically.
l Cause 3: The software versions of the active and standby system control boards are
inconsistent.
1. On the T2000, query and record the software versions of the active and standby system
control boards. Then, check whether the software versions are consistent. For details,
refer to 8.3 Querying the Board Information Report.
2. If the software versions are inconsistent, determine the correct software versions
according to the version mapping table. Then, replace the system control board with
the incorrect software. For details, refer to 5 Replacing Components.
----End
Related Information
None.
9.3.120 SYNC_LOCKOFF
Description
The SYNC_LOCKOFF is an alarm indicating that the clock source is locked out.
Attribute
Parameters
None.
None.
Impact on System
l When the SYNC_LOCKOFF alarm occurs, the relevant clock source is locked and cannot
be traced by the NE.

l This alarm does not affect services.
Possible Causes
The cause of the SYNC_LOCKOFF alarm is as follows:
A specific clock source is locked out.
Handling Procedure
l Cause: A specific clock source is locked out.
1. On the T2000, confirm the locked clock source. For details, refer to Switching a Clock
Source in the OptiX RTN 950 Radio Transmission System Configuration Guide
manual.
2. Unlock the clock source and then check whether the alarm is cleared.
----End
Related Information
None.
9.3.121 SYSLOG_COMM_FAIL
Description
The SYSLOG_COMM_FAIL is an alarm indicating that the communication between the NE
and the SYSLOG server fails. This alarm occurs when the NE and the SYSLOG server have an
abnormal connection or session in the TCP mode.
Attribute
0x312A Major Equipment alarm
Parameters
table.
Name Meaning
Parameters 1-4 Indicates the IP address of the SYSLOG server.
Parameter 5 l 0x01: The connection is interrupted.

l 0x02: The session is abnormal.

Impact on System
When the SYSLOG_COMM_FAIL alarm occurs, the SYSLOG information of the NE cannot
be sent to the SYSLOG server.
Possible Causes
The possible causes of the SYSLOG_COMM_FAIL alarm are as follows:
l Cause 1: The connection between the NE and the SYSLOG server is interrupted.
l Cause 2: In the DCN communication mode, the gateway NE in not configured.
Handling Procedure
l Cause 1: The connection between the NE and the SYSLOG server is interrupted.
1. Check whether the connection between the NE and the SYSLOG server is interrupted.
2. If interrupted, modify the physical connection to recover the good connection. Then,
check whether the alarm is cleared.
l Cause 2: In the DCN communication mode, the gateway NE in not configured.
1. On the T2000, check whether the gateway NE is configured.
NOTE
In the DCN communication mode, the logs of the NE that does not directly connect to the
SYSLOG servers must be transmitted to a gateway NE that directly communicates with the
SYSLOG servers through DCN.
2. If not, configure a proper gateway NE, and check whether the alarm is cleared.
----End
Related Information
None.
9.3.122 T_ALOS
Description
The T_ALOS alarm indicates loss of signals at the E1 port. When an E1 port does not access
any service, the T_ALOS alarm is reported.
Attribute
0x6B Major Communication alarm
Parameters
None.
None.

Impact on System
In the case of the T_ALOS alarm, the service is interrupted.
Possible Causes
The possible causes of the T_ALOS alarm are as follows:
l Cause 1: No E1 service is transmitted from the opposite port.

l Cause 2: The E1 cable is loosened or disconnected from the port.
l Cause 3: The opposite equipment is faulty.
l Cause 4: The cable is faulty.
l Cause 5: The interface board that reports the T_ALOS alarm is faulty.
Handling Procedure
l Cause 1: No E1 service is transmitted from the opposite port.
1. Check whether the E1 service is transmitted from the opposite port normally.
2. If not, recover the normal E1 service transmission from the opposite port.
l Cause 2: The E1 cable is loosened or disconnected from the port.
1. Check whether the E1 cable is loosened or disconnected from the port.
2. If yes, properly re-insert the E1 cable. Make sure that the E1 cable is in good contact
with the port.
l Cause 3: The opposite equipment is faulty.
1. On the ODF, perform self-loop (hardware inloop) on the channel with the T_ALOS
alarm.
2. If the T_ALOS alarm ends, it indicates that the opposite equipment is faulty. Take
priority to rectify the fault of the opposite equipment.
l Cause 4: The cable is faulty.
1. If the T_ALOS alarm ends after the self-loop, perform self-loop (hardware inloop) on
the channel with the T_ALOS alarm at the interface board.
2. If the T_ALOS alarm ends, it indicates that the E1 cable is faulty. In this case, replace
the E1 cable.
l Cause 5: The interface board that reports the T_ALOS alarm is faulty.
1. If the T_ALOS alarm ends after the self-loop, perform inloop on the channel with the
T_ALOS alarm on the T2000. For details, refer to 8.9 Configuring Port
Loopback.
2. If the T_ALOS alarm ends, it indicates that the interface board is faulty. In this case,
replace the interface board. For details, refer to 5 Replacing Components.
----End
Related Information
None.

9.3.123 TEM_HA
Description
The TEM_HA is an alarm indicating that the temperature of the laser is excessively high.
Attribute
0x01d Major Equipment alarm
Parameters
None.
None.
Impact on System
If the TEM_HA alarm is not cleared for a long time, the laser may be faulty. Consequently, the
Possible Causes
The possible causes of the TEM_HA alarm are as follows:
l Cause 1: The working environment temperature is excessively high.

Handling Procedure
l Cause 1: The working environment temperature is excessively high.
1. Check whether the environment temperature is higher than 60 centigrade.
2. If yes, cool the environment temperature down to the range of -20 to 60 centigrade
and then check whether the TEM_HA alarm is cleared.
1. Replace the optical module on the port that reports the TEM_HA alarm, and then
check whether the alarm is cleared. For details, refer to 5.9 Replacing the Pluggable
Optical Module.
2. If the TEM_HA alarm persists, replace the board that reports the alarm. For details,
----End
Related Information
None.

9.3.124 TEM_LA
Description
The TEM_LA is an alarm indicating that the temperature of the laser is excessively low.
Attribute
0x01e Major Equipment alarm
Parameters
None.
None.
Impact on System
If the TEM_LA alarm is not cleared for a long time, the laser may be faulty. Consequently, the
Possible Causes
The possible causes of the TEM_LA alarm are as follows:
l Cause 1: The working environment temperature is excessively low.

Handling Procedure
l Cause 1: The working environment temperature is excessively low.
1. Check whether the environment temperature is lower than -20 centigrade.
2. If yes, warm the environment temperature up to the range of -20 to 60 centigrade and
then check whether the TEM_LA alarm is cleared.
1. Replace the optical module on the port that reports the TEM_LA alarm, and then check
whether the alarm is cleared. For details, refer to 5.9 Replacing the Pluggable Optical
Module.
2. If the TEM_LA alarm persists, replace the board that reports the alarm. For details,
----End
Related Information
None.

9.3.125 TEMP_ALARM
Description
The TEMP_ALARM is an alarm indicating that the temperature crosses the threshold.
Attribute
0x00A6 Minor Environment alarm
Parameters
table.
Name Meaning
Parameter 1 l 0x01: Indicates that the temperature crosses the upper threshold.
l 0x02: Indicates that the temperature crosses the lower threshold.
Impact on System
The board fails to work normally.
Possible Causes
l The board temperature crosses the threshold.
l The temperature detecting circuit is faulty.
Handling Procedure
Step 1 If the alarm is reported by the ODU, install a sunshade to control the temperature.
Step 2 If the alarm is reported by a board of the IDU, check whether the temperature control devices,
such as air-conditioners, operate normally.
If... Then...
No Adjust the temperature control devices.
Step 3 If the ambient temperature is normal and there is no heat-sinking problem, replace the board that
reported the TEMP_ALARM.
----End

Related Information
None.
9.3.126 TEMP_OVER
Description
The TEMP_OVER alarm indicates that the board working temperature reaches the threshold.
When the system detects that the working temperature of the board reaches the lower or upper
threshold, the TEMP_OVER alarm is reported.
Attribute
0x1C Major Equipment alarm
Parameters
table.
Name Meaning
Parameter 1 Indicates the threshold-crossing type of the board working temperature.

l 0x01: The board working temperature is higher than the upper threshold.
l 0x02: The board working temperature is lower than the lower threshold.
Impact on System
l Excessive (high or low) working temperature brings high risk for the system. If the system
operates with high risk for a long time, bit errors may occur and the services may be
interrupted. Hence, remove the risk in a timely manner.
l To avoid alarm jitter, the TEMP_OVER alarm is cleared only when the working
temperature rises to 5°C higher than the lower threshold or drops to 5°C lower than the
upper threshold.
Possible Causes
The possible causes of the TEMP_OVER alarm are as follows:
l Cause 1: The cooling or warming device is faulty and thus the working temperature is
excessively high or low.
l Cause 2: The upper and lower thresholds of the alarm are improperly set.
l Cause 3: The fan stops rotating .

Handling Procedure
l Cause 1: The cooling or warming device is faulty and thus the working temperature is
excessively high or low.
1. Check whether the environment temperature in the equipment room is higher than
60 centigrade or lower than -20 centigrade.
2. If yes, check whether the cooling or warming device functions normally. If not, take
priority to rectify the fault of the cooling or warming device.
l Cause 2: The upper and lower thresholds of the alarm are improperly set.
1. Check whether the current working temperature, upper and lower temperature
thresholds for the board are proper. For details, refer to 2.2.4 Browsing the Current
Performance Events in the Routine Maintenance.
2. If the upper and lower temperature thresholds are set improperly, re-set the upper and
lower temperature thresholds.
l Cause 3: The fan stops rotating .
1. Check whether the FAN_FAIL occurs. If yes, take priority to handle the
FAN_FAIL alarm.
1. Check whether the any hardware-related alarm occurs on the board that reports the
TEMP_OVER alarm, such as the HARD_BAD alarm.
2. If yes, replace the board. For details, refer to 5 Replacing Components.
----End
Related Information
None.
9.3.127 THUNDERALM
Description
The THUNDERALM is an alarm indicating the lightning protection failure. If the system detects
the lightning protection circuit fails, the THUNDERALM occurs.
Attribute
0xF893 Minor Environment alarm
Parameters
None.
None.

Impact on System
When the THUNDERALM occurs, the system operation and services are not affected, but the
lightning protection function fails.
Possible Causes
The possible causes of the THUNDERALM alarm are as follows:
l Cause 1: The fuse tube of the lightning protection circuit is interrupted.

Handling Procedure
l Cause 1: The fuse tube of the lightning protection circuit is interrupted.
1. Replace the fuse tube, and then check whether the alarm is cleared.
1. Replace the board that reports the THUNDERALM alarm. For details, refer to 5
Replacing Components.
----End
Related Information
None.
9.3.128 TR_LOC
Description
The TR_LOC is an alarm indicating that the clock of the CXPR board is faulty. This alarm occurs
when a board detects that the clock of the CXPR board is lost, the frame header is lost, or the
CXPR board is faulty.
Attribute
0x000E Major Equipment alarm
Parameters
table.

Name Meaning
Parameter 1 Indicates the board ID from which the lost clock is transmitted.
l 0x01: CXPR board with the small slot number.
l 0x02: CXPR board with the big slot number.
l 0x03: The two CXPR boards.
Parameter 2 Indicates the detailed fault information.

l 0x01: Clock of the CXPR board with the small slot number is lost.
l 0x02: Frame header of the CXPR board with the small slot number is lost.
l 0x04: Bus indicating the status of the CXPR board with the small slot number
is faulty.
l 0x08: Clock of the CXPR board with the big slot number is lost.
l 0x10: Frame header of the CXPR board with the big slot number is lost.
l 0x20: Bus indicating the status of the CXPR board with the big slot number
is faulty.
Impact on System
When the TR_LOC occurs, the board fails to work normally.
l If the protection CXPR board is detected to be faulty, the services are not affected.
l If the working CXPR board is detected to be faulty, the services are switched and some
services are transiently interrupted.
Possible Causes
The possible causes of the TR_LOC alarm are as follows:
l Cause 1: The clock line of the CXPR board is faulty.
l Cause 2: The board that reports the TR_LOC alarm is faulty.
Handling Procedure
l Cause: The board is faulty.
1. On the T2000, check whether the alarm occurs on most service boards. For details,
refer to 8.2 Querying Current Alarms of a Board.
2. If yes, the CXPR board is faulty. In this case, replace the faulty CXPR board and check
whether the alarm is cleared. For details, refer to 5 Replacing Components.
3. If only the one board reports the alarm, replace it. Then, check whether the alarm is
cleared.
----End
Related Information
None.

9.3.129 UP_E1_AIS
Description
The UP_E1_AIS is an alarm indicating the generation of an alarm in the upstream 2 Mbit/s
signals. This alarm occurs when the upstream E1 signals are detected to be all "1"s.
Attribute
Parameters
None.
None.
Impact on System
l In the case of the UP_E1_AIS alarm, the E1 signals are unavailable and the service is
interrupted.
l The UP_E1_AIS alarm will be suppressed when the T_ALOS alarms occurs.
l When the UP_E1_AIS alarm occurs, the system suppresses the LFA, LMFA and
ALM_IMA_LIF alarms.
Possible Causes
The possible causes of the UP_E1_AIS alarm are as follows:
l Cause 1: The T_ALOS alarm occurs on the opposite NE.

l Cause 2: Inloop is set for the E1 port.
Handling Procedure
l Cause 1: The T_ALOS alarm occurs on the opposite NE.
1. On the T2000, check whether the T_ALOS alarm occurs on the opposite NE. For
details, refer to 8.2 Querying Current Alarms of a Board.
2. If yes, clear the T_ALOS alarm on the oppostie NE first and check whether the
UP_E1_AIS alarm on the local NE is cleared.
l Cause 2: Inloop is set for the E1 port.
1. On the T2000, check whether there is the LOOP_ALM alarm on the E1 port.
2. If yes, set Non-Loopback for the E1 port and check whether the UP_E1_AIS alarm
is cleared. For details, refer to 8.9 Configuring Port Loopback.

1. On the T2000, check whether there is any hardware-related alarm on the two NEs,
such as the HARD_BAD alarm.
the UP_E1_AIS alarm is cleared. For details, refer to 8.16 Resetting Boards.
3. If the UP_E1_AIS alarm persists, replace the related board and check whether the
UP_E1_AIS alarm is cleared. For details, refer to 5 Replacing Components.
----End
Related Information
None.
9.3.130 VC_AIS
Description
The VC_AIS alarm indicates the generation of a virtual channel (VC) connection alarm. When
the VC with the segment and end point attributes receives AIS cells, the VC_AIS alarm is
reported, indicating that the upstream ATM service is abnormal.
Attribute
0X00E4 Major Communication alarm
Parameters
table.
Name Meaning
Parameter 1, Parameter 2 Indicates the ATM Trunk.
Impact on System
l If the continuity check (CC) sink is enabled on an upstream NE but the NE does not receive
any CC cells, the NE reports the VC_LOC alarm and inserts the AIS cells to the
downstream. In this way, the VC_AIS alarm occurs on the local NE. In this case, the
connection, though not interrupted, is not loaded with any service.
l In other cases, the local NE detects the VC connection is interrupted when the VC_AIS
alarm occurs. The local NE continues inserting the AIS cells to the downstream NE and
returns the RDI cells to the upstream NE.
l In the following case, the VC_AIS will be cleared automatically.

– Receiving the user CC cells

– The CC is disabled
– Not receiving any VCAIS cell in a period of 2.5s (±0.5s)
l When the VC_AIS alarm occurs, the system suppresses the VC_LOC alarm.
Possible Causes
The possible causes of the VC_AIS alarm are as follows:
l Cause 1: An upstream NE reports the VC_LOC alarm and thus inserts the AIS cells to the
downstream NE.
l Cause 4: The board on the local NE is faulty.
Handling Procedure
l Cause 1: An upstream NE reports the VC_LOC alarm and thus inserts the AIS cells to the
downstream NE.
1. On T2000, check whether there is any VC_LOC alarm with the same ATM connection
ID. For details, refer to 8.2 Querying Current Alarms of a Board.
2. If yes, clear the VC_LOC alarm to stop insertion of the AIS cells.
1. Cold-reset the board that reports the VC_AIS alarm. For details, refer to 8.16
Resetting Boards.
2. If the VC_AIS alarm persists, replace the board that reports this alarm. For details,
----End
Related Information
Unidirectional connection
A complete bidirectional connection is divided into a forward unidirectional connection and a

backward unidirectional connection. The same NE is for the reference of the forward and
backward connections.
End and segment
An end point refers to the termination point on the chain network and functions to monitor the
entire virtual connection.
A segment point always refers to a segment on a link and the segment is monitored.
Segment end point
A segment end point is one segment end attribute. The segment end attributes include segment
point, end point, segment end point, and non-segment non-end-point.
l If the segment end attribute is set for an NE, the NE can capture alarms on the segment and
end point.
l If the segment point attribute is set for an NE, the NE can only capture the alarms on the
segment.

l If the end point attribute is set for an NE, the NE can only capture the alarms on the end
point.
l If the non-segment non-end-point attribute is set for an NE, the NE cannot capture any
alarm on the segment and end point.
9.3.131 VC_LOC
Description
The VC_LOC alarm indicates loss of connectivity check (CC) on the virtual channel (VC). When
the CC is enabled but no CC cells are received for more than 3.5s (±0.5s), the VC_LOC alarm
is reported. When any CC cell is received, the VC_LOC alarm is cleared automatically.
Attribute
Parameters
table.
Name Meaning
Impact on System
l If the CC sink is enabled on the local NE but the local NE does not receive any CC cells,
the service connection, though not interrupted, is not loaded with any user service.
l In other cases, the service is interrupted when the VC_LOC alarm occurs.
l When the VC_LOC alarm occurs, the system automatically inserts AIS cells to the
downstream.
l The VC_LOC alarm will be suppressed when the VC_AIS alarm occurs.
Possible Causes
The possible causes of the VC_LOC alarm are as follows:
l Cause 1: The CC sink is enabled on the local NE, but no CC source is enabled on the
upstream NE. As a result, the local NE does not receive any CC cells.

Handling Procedure
1. On the T2000, check whether the CC Activate Flag on the local NE is set to Sink
activate or Source + sink activate. For details, refer to Setting the CC Activation
Status in the OptiX RTN 950 Radio Transmission System Feature Description manual.
2. If yes, modify the configuration of CC Activate Flag to Deactivate and check whether
1. Cold-reset the board that reports the VC_LOC alarm. For details, refer to 8.16
Resetting Boards.
2. Replace the board that reports the VC_LOC alarm. For details, refer to 5 Replacing
Components.
----End
Related Information
None.
9.3.132 VC_RDI
Description
The VC_RDI is an alarm indicating that a fault occurs in the remote end of a virtual channel
(VC) connection. When a forward or backward VC connection that is set with the segment and
end point attribute receives the RDI cells, the VC_RDI alarm is reported, showing that the
downstream services are abnormal.
Attribute
0x00E5 Major Communication alarm
Parameters
table.
Name Meaning

Impact on System
l When the VC_RDI alarm occurs, it just shows that the services in the receive direction of
the downstream VC connection are abnormal. The AIS cells are received in a segment point
of the connection, and the RDI cells are returned to the upstream connection. The services
are not affected.
l If no VCRDI cell is received in a period of 2.5s (±0.5s), the VC_RDI alarm is cleared
automatically.
Possible Causes
The possible causes of the VC_RDI alarm are as follows:
l Cause 1: The VC_AIS alarm occurs in the receive direction of the downstream connection.
l Cause 2: The ATM processing chip of the board is faulty.
Handling Procedure
l Cause 1: The VC_AIS alarm occurs in the receive direction of the downstream connection.
1. On the T2000, check whether the VC_AIS alarm is generated on the VC connection
which reports the VC_RDI alarm on the downstream NE. For details, refer to 8.2
2. If yes, clear the VC_AIS alarm on the downstream NE first and then check whether
the VC_RDI alarm on the local NE is cleared.
1. Cold-reset the board that reports the VC_RDI alarm. For details, refer to 8.16
Resetting Boards.
2. If the VC_RDI alarm persists, replace the board that reports this alarm. For details,
----End
Related Information
backward unidirectional connection. The direction of the forward and backward connections is
based on the same node.
End and segment
An end point refers to the termination point in the chain network, and it is used to monitor the
The segment point is, generally, used to monitor a segment of the whole link.
Segment and end point
This is one of the segment end attributes. The segment end attributes include: segment point,
end point, segment and end point, non segment and end point.
l If an NE is set with the segment end point attribute, it can capture the alarms that are
generated at segments and ends.

l If an NE is set with the segment point attribute, it can capture the alarms that are generated
at segments.
l If an NE is set with the end point attribute, it can capture the alarms that are generated at
ends.
l If an NE is set with the non segment end point attribute, it fails to capture the alarms that
are generated at segments and ends.
9.3.133 VOLT_LOS
Description
The VOLT_LOS is an alarm indicating that the power is not available. When the IF board detects
that the input or output voltage signals are lost, the VOLT_LOS alarm is reported.
Attribute
Parameters
table.
Name Meaning
Parameter 1 Indicates the type of the power that reports the alarm.
l 0x01: Indicates –48 V/+24 V power output.
l 0x02: Indicates –48 V/+24 V power input.
l 0x03: Indicates +5 V power output.
l 0x04: Indicates +3.3 V power output.
l 0x05: Indicates lightning power.
Impact on System
If the alarm is reported by the IF board, the ODU connected to the IF board fails to work.
Possible Causes
l The output power is abnormal.
l The input power is abnormal.
l Lightning occurs.

Handling Procedure
Step 1 Determine the type of the power supply that reports the alarm based on the alarm parameter.
If... Then...
In the case of the input power alarm Go to Step 2.
In the case of the output power alarm Go to Step 3.
In the case of the lightning alarm Contact the engineers to provide power
supply and to check whether lightning
protection is provided.
Step 2 Replace the IF board that reports the alarm.

Step 3 Check the power switch of the ODU.
If... Then...
The power switch is off Turn on the power switch.
The power switch is on Proceed to the next step.
Step 4 Check the IF jumper, IF cable, or ODU section by section for a short circuit.
If... Then...
A short circuit exists Replace the short-circuit component, and

then replace the IF board that reports the
alarm.
No short circuit exists Replace the IF board that reports the

alarm.
CAUTION
If the alarm is generated due to a short circuit, replace the short-circuit cable or ODU, and then
replace the IF board. Otherwise, the new IF board may be damaged.
----End
Related Information
None.

9.3.134 VP_AIS
Description
The VP_AIS is an alarm indicating the generation of a virtual path (VP) connection alarm. When
a forward or backward VP connection that is set with the segment and end point attribute receives
the AIS cells, the VP_AIS alarm is reported, showing that the upstream ATM service is
abnormal.
Attribute
Parameters
table.
Name Meaning
Impact on System
l If the continuity check (CC) sink is enabled on an upstream NE but the NE does not receive
any CC cells, the NE reports the VP_LOC alarm and inserts the AIS cells to the downstream.
In this way, the VP_AIS alarm occurs on the local NE. In this case, the connection, though
not interrupted, is not loaded with any service.
l In other cases, the local NE detects the VP connection is interrupted when the VP_AIS
alarm occurs. The local NE continues inserting the AIS cells to the downstream NE and
returns the RDI cells to the upstream NE.
l In the following case, the VP_AIS will be cleared automatically.
– Receiving the user CC cells
– The CC is disabled
– Not receiving any VPAIS cell in a period of 2.5s (±0.5s)
l When the VP_AIS alarm occurs, the system suppresses the VP_LOC alarm.
Possible Causes
The possible causes of the VP_AIS alarm are as follows:
l Cause 1: An upstream NE reports the VP_LOC alarm and thus inserts the AIS cells to the
downstream NE.

Handling Procedure
l Cause 1: An upstream NE reports the VP_LOC alarm and thus inserts the AIS cells to the
downstream NE.
1. On T2000, check whether there is any VP_LOC alarm with the same ATM connection
ID. For details, refer to 8.2 Querying Current Alarms of a Board.
2. If yes, clear the VP_LOC alarm to stop insertion of the AIS cells.
1. Cold-reset the board that reports the VP_AIS alarm. For details, refer to 8.16 Resetting
Boards.
2. If the VP_AIS alarm persists, replace the board that reports this alarm. For details,
----End
Related Information
backward unidirectional connection. The same NE is for the reference of the forward and
backward connections.
End and segment
An end point refers to the termination point on the chain network and functions to monitor the
A segment point always refers to a segment on a link and the segment is monitored.
Segment end point
A segment end point is one segment end attribute. The segment end attributes include segment
point, end point, segment end point, and non-segment non-end-point.
l If the segment end attribute is set for an NE, the NE can capture alarms on the segment and
end point.
l If the segment point attribute is set for an NE, the NE can only capture the alarms on the
segment.
l If the end point attribute is set for an NE, the NE can only capture the alarms on the end
point.
l If the non-segment non-end-point attribute is set for an NE, the NE cannot capture any
alarm on the segment and end point.
9.3.135 VP_LOC
Description
The VP_LOC alarm indicates loss of connectivity check (CC) on the virtual channel (VP). When
the CC is enabled but no CC cells are received for more than 3.5s (±0.5s), the VP_LOC alarm
is reported. When any CC cell is received, the VP_LOC alarm is cleared automatically.

Attribute
Parameters
table.
Name Meaning
Impact on System
l If the CC sink is enabled on the local NE but the local NE does not receive any CC cells,
the service connection, though not interrupted, is not loaded with any user service.
l In other cases, the service is interrupted when the VP_LOC alarm occurs.
l When the VP_LOC alarm occurs, the system automatically inserts AIS cells to the
downstream.
l The VP_LOC alarm will be suppressed when the VP_AIS alarm occurs.
Possible Causes
The possible causes of the VP_LOC alarm are as follows:
l Cause 2: No bandwidth is available on the local NE and thus the CC cells cannot be received.
Handling Procedure
1. On the T2000, check whether the CC Activate Flag on the local NE is set to Sink
activate or Source + sink activate. For details, refer to Setting the CC Activation
Status in the OptiX RTN 950 Radio Transmission System Feature Description manual.
2. If yes, modify the configuration of CC Activate Flag to Deactivate and check whether
l Cause 2: No bandwidth is available on the local NE and thus the CC cells cannot be received.

For details, refer to the OptiX RTN 950 Radio Transmission System Configuration
Guide manual.
1. Cold-reset the board that reports the VP_LOC alarm. For details, refer to 8.16
Resetting Boards.
2. Replace the board that reports the VP_LOC alarm. For details, refer to 5 Replacing
Components.
----End
Related Information
None.
9.3.136 VP_RDI
Description
The VP_RDI is an alarm indicating that a fault occurs in the remote end of a virtual path (VP)
connection. When a forward or backward VP connection that is set with the segment and end
point attribute receives the RDI cells, the VP_RDI alarm is reported, showing that the
downstream services are abnormal.
Attribute
Parameters
table.
Name Meaning
Impact on System
l When the VP_RDI alarm occurs, it just shows that the services in the receive direction of
the downstream VP connection are abnormal. The AIS cells are received in a segment point

of the connection, and the RDI cells are returned to the upstream connection. The services
are not affected.
l If no VCRDI cell is received in a period of 2.5s (±0.5s), the VP_RDI alarm is cleared
automatically.
Possible Causes
The possible causes of the VP_RDI alarm are as follows:
l Cause 1: The VP_AIS alarm occurs in the receive direction of the downstream connection.
Handling Procedure
l Cause 1: The VP_AIS alarm occurs in the receive direction of the downstream connection.
1. On the T2000, check whether the VP_AIS alarm is generated on the VP connection
which reports the VP_RDI alarm on the downstream NE. For details, refer to 8.2
2. If yes, clear the VP_AIS alarm on the downstream NE first and then check whether
the VP_RDI alarm on the local NE is cleared.
1. Cold-reset the board that reports the VP_RDI alarm. For details, refer to 8.16
Resetting Boards.
2. If the VP_RDI alarm persists, replace the board that reports this alarm. For details,
----End
Related Information

backward unidirectional connection. The direction of the forward and backward connections is
based on the same node.
End and segment
An end point refers to the termination point in the chain network, and it is used to monitor the
The segment point is, generally, used to monitor a segment of the whole link.
Segment and end point
This is one of the segment end attributes. The segment end attributes include: segment point,
end point, segment and end point, non segment and end point.
l If an NE is set with the segment end point attribute, it can capture the alarms that are
generated at segments and ends.
l If an NE is set with the segment point attribute, it can capture the alarms that are generated
at segments.

l If an NE is set with the end point attribute, it can capture the alarms that are generated at
ends.
l If an NE is set with the non segment end point attribute, it fails to capture the alarms that
are generated at segments and ends.
9.3.137 WRG_BD_TYPE
Description
The WRG_BD_TYPE alarm indicates that the physical board is of a wrong type. When one
physical board and its logical board are not of the same type, the WRG_BD_TYP alarm is
reported.
Attribute
Parameters
None.
None.
Impact on System
l When the WRG_BD_TYPE alarm occurs, the running services and system are not affected,
but no other service can be configured on the very board.
l The WRG_BD_TYPE alarm will be suppressed when the BD_STATUS alarm occurs.
l When the WRG_BD_TYPE alarm occurs, the system will suppress the other alarms.
Possible Causes
The possible causes of the WRG_BD_TYPE alarm are as follows:
l Cause 1: The physical board and its logical board configured on the T2000 are not of the
same type.
Handling Procedure
l Cause 1: The physical board and its logical board configured on the T2000 are not of the
same type.
1. Check the engineering documents to see whether the logical board configured on the
T2000 is wrong or the physical board is wrong.
– If the logical board configured on the T2000 is wrong, re-configure a correct logical
board on the T2000.

– If the physical board is wrong, replace the physical board with a board of the correct
type. For details, refer to 5 Replacing Components.
1. Check whether the board software is matched with the board hardware. If not, reload
the board software or replace the board.
2. If the WRG_BD_TYPE alarm persists, replace the board that reports this alarm.
----End
Related Information
None.

Maintenance Guide 10 Performance Event
10 Performance Event
About This Chapter
This chapter describes basic concepts related to performance events and how to handle related
performance events of the equipment.
10.1 Basic Concepts Related to Performance Events
You can use the performance management function to find out the potential risks of the network
running and thus to minimize the network failure risks. Understand the basic concepts before
performing any operation to monitor the performance.
10.2 Performance Event List
This chapter describes all performance events supported by the OptiX RTN 950.
10.3 Performance Event Handling
This section describes performance events of the equipment in terms of the indication, attribute,
parameter, impact on system, probable cause, related alarm, handling procedure, and reference
information in the alphabetical order (A to Z).

10 Performance Event Maintenance Guide
10.1 Basic Concepts Related to Performance Events

You can use the performance management function to find out the potential risks of the network
running and thus to minimize the network failure risks. Understand the basic concepts before
performing any operation to monitor the performance.
10.1.1 Performance Reporting Flow
The performance reporting flow indicates the entire process from the detection of performance
events on the board to notification on the T2000. The performance reporting consists of the
performance monitoring enabling, performance automatic reporting, and over-threshold
performance event notification.
10.1.2 Performance Event Category
When the optical transport network is running normally, internal and external factors, such as
noise sources, dispersion, and fiber break, may affect the transmission quality in the forms of
bit error, jitter, drift, and delay. The influence is called transmission impairment. On the T2000,
the performance events reflect the transmission impairment.
10.1.3 Performance Threshold
The user can set the performance threshold to mask the performance events that vary within the
normal range. In this way, the user can focus on the performance events that are severely
degraded.
10.1.1 Performance Reporting Flow

The performance reporting flow indicates the entire process from the detection of performance
events on the board to notification on the T2000. The performance reporting consists of the
performance monitoring enabling, performance automatic reporting, and over-threshold
performance event notification.
Figure 10-1 shows the performance reporting flow.

Figure 10-1 Performance reporting flow
Whether to No
enable the performance End
monitoring?
Yes
The board collects the

performance data and saves the
result in the performance register
The performance data is saved

to the performance register on
the system control board
Does the Yes The abnormal performance

current performance cross
event is reported to the NM
the threshold?
No
Whether to
enable the automatic
reporting?
Yes
The performance data is No

reported to the NM and End
saved in the database
NOTE
For details on the specific operations at each phase of the performance reporting flow, see the OptiX
iManager T2000 Online Help.
Performance Monitoring
The board monitors the performance. By default, the performance monitoring function of a board
is enabled. For example, in the case of the 15-minute performance, the board detects a spare
performance register and clears the data in the register at the beginning of each period, and then
counts the performance events. At the end of a period, the statistics performance data is refreshed
and then stored in the register.
NOTE
The data in the performance register supports wrapped storage.

Automatic Reporting
If the automatic reporting function is enabled, the system control board automatically reports
the performance events to the T2000 at the end of each monitoring period.
NOTE
The performance data and NE management information are reported in the same DCC channel. In the case
of large-volume performance data, the network communication is affected. Hence, do not modify the
configuration of the performance monitoring, unless required. By default, you can enable the performance
monitoring in the entire network, but only need to set performance automatic reporting for the ports where
faults are likely to occur.
Performance Over-Threshold Reporting

If detecting performance over-threshold, the T2000 reports an abnormal event accordingly. The
performance over-threshold abnormal event is different from the ordinary abnormal event,
because the T2000 processes the former exceptionally and supports exclusive settings. In the
case of such an event, the T2000 displays a dialog box, reminding the user of the event.
10.1.2 Performance Event Category

When the optical transport network is running normally, internal and external factors, such as
noise sources, dispersion, and fiber break, may affect the transmission quality in the forms of
bit error, jitter, drift, and delay. The influence is called transmission impairment. On the T2000,
the performance events reflect the transmission impairment.
In the case of the OptiX RTN 950, there are SDH performance events and RMON performance
events.
l SDH performance events, which mainly indicate the state of equipment point justification
caused by the bit error and jitter.
l RMON performance events, which mainly indicate communication quality at the ports that
carry data services.
SDH Performance Event

The SDH performance events are classified into the following categories:
l Management layer performance event
l E1 performance event
RMON Performance Event

The RMON performance events are classified into the following categories:
l Ethernet performance event
l CES performance event
l L2VPN performance event
l QoS performance event
l ATMoPWE3 performance event
l ATM/IMA performance event
l Tunnel performance event

l PW performance event
l MP performance event
l PPP performance event
10.1.3 Performance Threshold

The user can set the performance threshold to mask the performance events that vary within the
normal range. In this way, the user can focus on the performance events that are severely
degraded.
Threshold, also called tolerance, indicates the extreme performance value for the transport
network to operate normally. The performance threshold is used to determine whether the
equipment is working normally. If a performance specification crosses the expected performance
threshold, this indicates a performance degrade trend. In this case, the user should highly regard
and handle the performance.
Normally, some margin should be reserved to set the performance threshold, and thus to find
out problems beforehand.
10.2 Performance Event List

This chapter describes all performance events supported by the OptiX RTN 950.
10.2.1 SL91CXPR Performance Event List
10.2.2 TND1EF8T Performance Event List
10.2.3 TND1EF8F Performance Event List
10.2.4 TND1EG2 Performance Event List
10.2.5 TND1ML1/TND1ML1A Performance Event List
10.2.6 TND1IFE2 Performance Event List
10.2.7 TND1AUXQ Performance Event List
10.2.8 TND1PIU Performance Event List
10.2.9 TND1FAN Performance Event List
10.2.10 ODU Performance Event List
10.2.1 SL91CXPR Performance Event List
Table 10-1 SDH Performance Event List
Performance Event Indication Performance Event Category

Name
BDTEMPCUR Current board temperature Management layer performance

event
BDTEMPMAX Maximum board
temperature


Name
BDTEMPMIN Minimum board

temperature
CPUUSAGECUR Current CPU usage
CPUUSAGEMAX Maximum CPU usage
CPUUSAGEMIN Minimum CPU usage
MEMUSAGECUR Current memory usage
MEMUSAGEMAX Maximum memory usage
MEMUSAGEMIN Minimum memory usage
Table 10-2 RMON Performance Event

Performance Event Name Indication Performance Event
Category
MPLS_TUNNEL_FD Delay of the tunnel service Tunnel performance event
MPLS_TUNNEL_FDV Delay variation of the

tunnel service
MPLS_TUNNEL_FL Count of lost packets of the

tunnel service
MPLS_TUNNEL_FLR Tunnel packet loss ratio
PW_RCVBYTES Count of bytes received on PW performance event

PW
PW_RCVPKTS Count of packets received

on PW
PW_SNDBYTES Count of bytes transmitted

on PW
PW_SNDPKTS Count of packets

transmitted on PW
TUNNEL_RCVBYTES Count of bytes received on Tunnel performance event

tunnel
TUNNEL_RCVPKTS Count of packets received

on tunnel
TUNNEL_SNDBYTES Count of bytes transmitted

on tunnel
TUNNEL_SNDPKTS Count of packets

transmitted on tunnel


Category
VUNI_RCVBYTES Count of bytes received at L2VPN performance event

V-UNI
VUNI_RCVPKTS Count of packets received

at V-UNI
VUNI_SNDBYTES Count of bytes transmitted

at V-UNI
VUNI_SNDPKTS Count of packets

transmitted at V-UNI
VUNI_RCVBYTES Count of bytes received at L3VPN performance event

V-UNI
VUNI_RCVPKTS Count of packets received

at V-UNI
VUNI_SNDBYTES Count of bytes transmitted

at V-UNI
VUNI_SNDPKTS Count of packets

transmitted at V-UNI
10.2.2 TND1EF8T Performance Event List


Name

event
temperature

temperature

Category
RXOCTETS Bytes received Ethernet performance event
RXPKTS Packets received
TXOCTETS Bytes transmitted


Category
TXPKTS Packets transmitted
10.2.3 TND1EF8F Performance Event List

Name

event
temperature

temperature
OSPITMPCUR Current value of laser Laser performance event

temperature
OSPITMPMAX Maximum value of laser

temperature
OSPITMPMIN Minimum value of laser

temperature
RPLCUR Current value of laser

receiving power
RPLMAX Maximum value of laser

receiving power
RPLMIN Minimum value of laser

receiving power
TLBCUR Current value of laser

transmitting bias current
TLBMAX Maximum value of laser

TLBMIN Minimum value of laser

TPLCUR Current value of laser

transmitting power
TPLMAX Maximum value of laser

transmitting power


Name
TPLMIN Minimum value of laser

transmitting power

Category
10.2.4 TND1EG2 Performance Event List

Name

event
temperature

temperature
OSPITMPCUR Current value of laser Laser performance event

temperature
OSPITMPMAX Maximum value of laser

temperature
OSPITMPMIN Minimum value of laser

temperature
RPLCUR Current value of laser

receiving power
RPLMAX Maximum value of laser

receiving power
RPLMIN Minimum value of laser

receiving power


Name
TLBCUR Current value of laser

TLBMAX Maximum value of laser

TLBMIN Minimum value of laser

TPLCUR Current value of laser

transmitting power
TPLMAX Maximum value of laser

transmitting power
TPLMIN Minimum value of laser

transmitting power

Category
10.2.5 TND1ML1/TND1ML1A Performance Event List

Name

event
temperature

temperature
E1_LCV_SDH Count of coding violations E1 performance event

at the E1 line side


Name
E1_LES_SDH Count of coding violation

seconds at the E1 line side
E1_LLOSS_SDH Count of coding violation

loss-of-signal seconds at
the E1 line side
E1_LSES_SDH Count of coding violation

severely errored seconds at
the E1 line side

Category
ATM_CELL_AVAILABILI Availability of cells in ATM/IMA performance event

TY percentage
ATM_CORRECTED_HCSE Count of cells received

RR with correctable HCS
errors
ATM_IF_INRATE_AVG Average rate of normal

cells received by the port
ATM_IF_INRATE_MAX Maximum rate of normal

ATM_IF_INRATE_MIN Minimum rate of normal

ATM_IF_OUTRATE_AVG Average rate of normal

cells transmitted by the
port
ATM_IF_OUTRATE_MAX Maximum rate of normal

port
ATM_IF_OUTRATE_MIN Minimum rate of normal

port
ATM_RCVCELLS Count of total cells

received
ATM_RCVIDLECELLS Count of total idle cells

received


Category
ATM_SNDCELLS Count of total cells

transmitted
ATM_UNCORRECTED_HC Count of cells received

SERR with uncorrectable HCS
errors
ATMPW_LOSPKTS Count of packets lost ATMoPWE3 performance

event
ATMPW_MISORDERPKTS Count of out-of-order
packets
ATMPW_RCVCELLS Count of cells received
ATMPW_SNDCELLS Count of cells transmitted
ATMPW_UNKNOWNCELL Count of unknown cells

S
CES_JTROVR Count of jitter buffer CES performance event

overflow times
CES_JTRUDR Count of jitter buffer

underflow times
CES_LOSPKTS Count of lost packets
CES_MALPKTS Count of malformed

packets
CES_MISORDERPKTS Count of packets lost due

to the out-of-order
condition
CES_STRAYPKTS Count of misconnected

packets
MP_RX_BW_UTILIZATIO MP bandwidth utilization MP performance event

N in receive direction
MP_RX_BYTES Count of received MP

bytes
MP_RX_ERRPKTS Count of received errored

MP packets
MP_RX_PKTS Count of received MP

service packets
MP_RX_TOTALPKTS Count of received total MP

packets
MP_TX_BW_UTILIZATIO MP bandwidth utilization

N in transmitted direction


Category
MP_TX_BYTES Count of transmitted MP

bytes
MP_TX_PKTS Count of transmitted MP

service packets
MP_TX_TOTALPKTS Count of transmitted total

MP packets
PPP_DROPLONGPKTS Count of oversize packets ML-PPP performance event
PPP_IFINPKTS Count of packets received

at the interface
PPP_IFOUTPKTS Count of packets

transmitted at the interface
PPP_RX_BW_UTILIZATIO PPP bandwidth utilization PPP performance event

N in receive direction
PPP_RX_BYTES Count of receive bytes
PPP_RX_FCSPKTS Count of receive fcs errors
PPP_RX_LOSPKTS Count of lost PPP packets

in receive direction
PPP_RX_PKTS Count of receive packets
PPP_TX_BW_UTILIZATIO PPP bandwidth utilization

N in transmitted direction
PPP_TX_BYTES Count of transmit bytes
PPP_TX_LOSPKTS Count of lost PPP packets

in transmitted direction
PPP_TX_PKTS Count of transmit packets
10.2.6 TND1IFE2 Performance Event List

Table 10-11 SDH Performance Events List
Name

events
temperature


Name

temperature
Table 10-12 Microwave Performance Events List

Name
ACMDOWNCNT Count of the downshift of the AM performance events

AM scheme
ACMUPCNT Count of the upshift of the

AM scheme
IFBBE Microwave link background Microwave link bit error

block errors performance events
IFES Microwave link errored

seconds
IFSES Microwave link severely

errored seconds
IFUAS Microwave link unavailable

seconds
IFCSES Microwave link consecutive

severely errored seconds
FEC_BEF_COR_ER FEC bit error rate before FEC performance events

correction
FEC_COR_BYTE_CN Byte count corrected by FEC

T
FEC_UNCOR_BLOC Frame count uncorrect by

K_CNT FEC
QPSKWS Working time of the QPSK AM performance events

mode
QAMWS16 Working time of the 16QAM

mode

mode

mode
QAMWS128 Working time of the

128QAM mode


Name
QAMWS256 Working time of the

256QAM mode
10.2.7 TND1AUXQ Performance Event List

Category
BDTEMPCUR Current board temperature Management layer

performance event
BDTEMPMAX Maximum board temperature
BDTEMPMIN Minimum board temperature

Category
10.2.8 TND1PIU Performance Event List

None
10.2.9 TND1FAN Performance Event List

None

10.2.10 ODU Performance Event List

Table 10-15 SDH Performance Events List
Performance Event Indication Performance Event
Name Category
BDTEMPCUR Current board temperature Management layer

performance events
BDTEMPMAX Maximum board temperature
BDTEMPMIN Minimum board temperature
Table 10-16 Microwave Performance Events List

Name Category
TSL_MAX Maximum value of Microwave power performance

microwave transmit signal events
level
TSL_MIN Minimum value of

microwave transmit signal
level
TSL_CUR Current value of microwave

transmit signal level
RSL_MAX Maximum value of

microwave receive signal
level
RSL_MIN Minimum value of

microwave receive signal
level
RSL_CUR Current value of microwave

receive signal level
RLHTT Duration when the receive

power of the ODU is lower
than the upper threshold
RLLTT Duration when the receive

power of the ODU is lower
than the lower threshold
TLHTT Duration when the transmit

power of the ODU is higher
than the upper threshold


Name Category
TLLTT Duration when the transmit

power of the ODU is higher
than the lower threshold
10.3 Performance Event Handling

This section describes performance events of the equipment in terms of the indication, attribute,
parameter, impact on system, probable cause, related alarm, handling procedure, and reference
information in the alphabetical order (A to Z).
10.3.1 ATM_CELL_AVAILABILITY
10.3.2 ATMPW_LOSPKTS
10.3.3 ATMPW_MISORDERPKTS
10.3.4 CES_JTROVR
10.3.5 CES_JTRUDR
10.3.6 E1_LCV_SDH
10.3.7 E1_LES_SDH
10.3.8 E1_LSES_SDH
10.3.9 MEMUSAGECUR
10.3.10 MEMUSAGEMAX
10.3.11 MEMUSAGEMIN
10.3.12 ACMDOWNCNT and ACMUPCNT
10.3.13 BDTMPMAX, BDTMPMIN, and BDTMPCUR
10.3.14 RSLMAX, RSLMIN and RSLCUR
10.3.15 TSLMAX, TSLMIN, and TSLCUR
10.3.16 RLHTT, RLLTT, TLHTT, TLLTT
10.3.17 IFBBE, IFES, IFSES, IFCSES, and IFUAS
10.3.18 FEC_BEF_COR_ER, FEC_COR_BYTE_CNT, and FEC_UNCOR_BLOCK_CNT
10.3.19 QPSKWS, QAMWS16, QAMWS32, QAMWS64, QAMWS128, and QAMWS256
10.3.1 ATM_CELL_AVAILABILITY
Description
The ATM_CELL_AVAILABILITY indicates the percentage that the available cells count.

Attribute
Performance Event ID Performance Event Type
519 RMON performance event
Impact on System
None.
Generation Principle and Possible Causes

When the percentage of available cells is counted, the ATM_CELL_AVAILABILITY
performance event occurs.
Procedure
None.
Related Information
None.
10.3.2 ATMPW_LOSPKTS
Description
The ATMPW_LOSPKTS indicates the count of lost packets of the ATM emulation service.
Attribute
Impact on System
None.

Determine the quality of the received services by calculating the number of lost packets of the
specified ATM emulation service. The possible causes of the ATMPW_LOSPKTS performance
event are as follows:
l A strong interference source exists near the equipment.
l The board at the transmit or receive end is faulty.
l The fan is faulty.

Related Alarms
None.
Procedure
Step 1 Locate and remove the interference source near the equipment, and then check whether the
performance event is cleared.
Step 2 Replace the faulty board, and then check whether the performance event is cleared.
----End
Related Information
None.
10.3.3 ATMPW_MISORDERPKTS
Description
The ATMPW_MISORDERPKTS indicates the count of disordered packets of the ATM
emulation service.
Attribute
Impact on System
None.

Determine the quality of the received services at the port by calculating the number of disordered
packets of the specified ATM emulation service. The possible causes of the
ATMPW_MISORDERPKTS performance event are as follows:
l A strong interference source exists near the equipment.
l The board at the transmit or receive end is faulty.
l The fan is faulty.
Related Alarms
None.

Procedure
Step 1 Locate and remove the interference source near the equipment, and then check whether the
performance event is cleared.
Step 2 Replace the faulty board, and then check whether the performance event is cleared.
----End
Related Information
None.
10.3.4 CES_JTROVR
Description
The CES_JTROVR indicates the count of jitter buffer overflow times.
Attribute
Impact on System
None.

When the packets in the buffer are full, if service packets are received, the buffer overflows. The
main causes of the CES_JTROVR performance event are as follows:
l The clock mode is incorrectly set, and thus the frequencies for transmitting and receiving
packets are inconsistent.
l During network congestion, burst packets may cause overflow of buffer.
Related Alarms
None.
Procedure
Step 1 Check whether the clock modes of the NEs at the two ends are consistent. If the clock modes
are consistent and the clock source is the system clock, check whether the system clocks of the
NEs at the two ends are synchronized.
Step 2 Check whether the network traffic is congested. If yes, modify the parameters in the jitter buffer
of the CES PW.
----End

Related Information
None.
10.3.5 CES_JTRUDR
Description
The CES_JTRUDR indicates the count of jitter buffer underflow times.
Attribute
Impact on System
None.

The main causes of the CES_JTRUDR performance events are as follows:
l The clock mode is incorrectly set, and thus the frequencies for transmitting and receiving
packets are inconsistent.
l The network is faulty.
l The network is congested.
Related Alarms
None.
Procedure
Step 1 Check whether the clock modes of the NEs at the two ends are consistent. If the clock modes
are consistent and the clock source is the system clock, check whether the system clocks of the
NEs at the two ends are synchronized.
Step 2 The performance event of packet loss may cause underflow of buffer. Hence, check whether the
CES_LOSPKTS performance event is reported. If yes, see the procedure for handling the
CES_LOSPKTS performance event.
Step 3 If the CES_LOSPKTS performance event is reported, the chip may be abnormal. In this case,
replace the board.
----End
Related Information
None.

10.3.6 E1_LCV_SDH
Description
The E1_LCV_SDH indicates the count of coding violations at the E1 line side.
Attribute
0x0c SDH performance event
Impact on System
The service has bit errors. Find out the cause and handle the problem in a timely manner to avoid
the occurrence of any alarm, which may affect the signal transmission quality.

When the coding violations at the line side are counted, the E1_LCV_SDH performance event
occurs.
l External causes
– The cable performance is degraded, and the cable has extremely high attenuation.
– The cable connector is of an incorrect type.
– The equipment is improperly grounded.
– A strong interference source is present near the equipment.
– The working temperature is extremely high or extremely low, and the equipment cannot
tolerate such temperature.
l Equipment causes
– An incorrect service code is selected.
– The board becomes faulty, or the performance of the board is degraded.
Related Alarms
None.
Procedure
Step 1 First eliminate external causes, such as poor grounding, extremely high operating temperature,
extremely low or extremely high received optical power of the processing board.
Step 2 Check whether the correct E1 service code is selected. If not, modify the code of the services
received by a board by setting the code type of the board.
----End

Related Information
None.
10.3.7 E1_LES_SDH
Description
The E1_LSES_SDH indicates the coding violation errored seconds at the E1 line side.
Attribute
0x0D SDH performance event
Impact on System

When the coding violation errored seconds at the E1 line side are counted, the E1_LSES_SDH
performance event occurs.
l External causes
l Equipment causes
– The board becomes faulty, or the performance of the board is degraded.
Related Alarms
None.
Procedure
Step 1 Refer to the method of handling the E1_LCV_SDH performance event.
----End

Related Information
None.
10.3.8 E1_LSES_SDH
Description
The E1_LSES_SDH indicates the coding violation severely errored seconds at the E1 line side.
Attribute
0x0E SDH performance event
Impact on System

When the coding violation severely errored seconds at the E1 line side are counted, the
E1_LSES_SDH performance event occurs.
l External causes
l Equipment causes
– The board fails or the board performance is degraded.
Related Alarms
None.
Procedure
Step 1 Refer to the method of handling the E1_LCV_SDH performance event.
----End

Related Information
None.
10.3.9 MEMUSAGECUR
Description
The MEMUSAGECUR performance event indicates the current memory usage ratio.
Attribute
0x3A4C SDH performance event
Impact on System
None

The MEMUSAGECUR performance event is generated to indicate the current memory usage
ratio.
Related Alarms
None
Procedure
None
Related Information
None
10.3.10 MEMUSAGEMAX
Description
The MEMUSAGEMAX performance event indicates the maximum memory usage ratio.
Attribute
0x3A4A SDH performance event

Impact on System
None

The MEMUSAGEMAX performance event is generated when the memory usage ratio reaches
the maximum value.
Related Alarms
None
Procedure
None
Related Information
None
10.3.11 MEMUSAGEMIN
Description
The MEMUSAGEMIN performance event indicates the minimum memory usage ratio.
Attribute
0x3A4B SDH performance event
Impact on System
None

The MEMUSAGEMIN performance event is reported when the memory usage ratio reaches the
minimum value.
Related Alarms
None
Procedure
None

Related Information
None
10.3.12 ACMDOWNCNT and ACMUPCNT
Description
l The ACMDOWNCNT indicates count of the downshift of the AM scheme.
l The ACMUPCNT indicates count of the upshift of the AM scheme.
Attribute
Attribute Description
Basic unit of a performance event ACMDCNT, ACMUCNT
Unit -
Impact on System
None.
Related Alarms
None.
10.3.13 BDTMPMAX, BDTMPMIN, and BDTMPCUR
Performance Event Meaning

l BDTMPMAX stands for "Maximum board temperature".
l BDTMPMIN stands for "Minimum board temperature".
l BDTMPCUR stands for "Current board temperature".
Performance Event Attribute

Performance Event Attribute Description
Performance event cell None
Unit 0.1ºC

Excessively high or low board temperature might cause faults such as degradation of the board
working performance and bit errors.

Relevant Alarm
If the board temperature crosses the threshold, the TEMP_ALARM alarm occurs.
10.3.14 RSLMAX, RSLMIN and RSLCUR

l RSLMAX stands for "Maximum value of microwave receive signal level".
l RSLMIN stands for "Maximum value of microwave receive signal level".
l RSLCUR "Current value of microwave receive power".

Performance event cell RSL
Unit 0.1 dBm

When the microwave receive power is overly low or overly high, bit errors might occur and the
service might be interrupted.
Relevant Alarm
If the receive power crosses the threshold, the RADIO_RSL_HIGH or RADIO_RSL_LOW
alarm occurs.
10.3.15 TSLMAX, TSLMIN, and TSLCUR

l TSLMAX stands for "maximum value of microwave transmit signal level".
l TSLMIN stands for "minimum value of microwave transmit signal level".
l TSLCUR stands for "current value of microwave transmit signal level".

Performance event cell TSL
Unit 0.1 dBm


When the microwave transmit power is too low or too high, the receive power at the opposite
station will be too low or too high. Moreover, bit errors might occur and services might be
interrupted.
Relevant Alarm
If the transmit power crosses the threshold, the RADIO_TSL_HIGH or
RADIO_TSL_LOW alarm can occur.
10.3.16 RLHTT, RLLTT, TLHTT, TLLTT

Description
l The RLHTT indicates the duration when the ODU at the local end has a receive power
lower than the upper threshold.
l The RLLTT indicates the duration when the ODU at the local end has a receive power
lower than the lower threshold.
l The TLHTT indicates the duration when the ODU at the local end has a transit power lower
than the upper threshold.
l The TLLTT indicates the duration when the ODU at the local end has a transit power lower
than the lower threshold.
Attribute
Attribute Description
Basic unit of a performance event RLHTS, RLLTS, TLHTS, and TLLTS
Unit Second
Impact on System
None.
Related Alarms
None.
10.3.17 IFBBE, IFES, IFSES, IFCSES, and IFUAS
Meanings of Performance Events

l IFBBE stands for "microwave link background block errors".
Background block error (BBE) is an errored block occurred outside the period of UAT and
SES.
l IFES stands for "microwave link errored seconds".
An errored second (ES) is a specific second with one or more errored blocks detected.

l IFSES stands for "microwave link severely errored seconds".

A severely errored second (SES) is a specific second with not less than 30% errored blocks
or at least one serious disturbance period (SDP) detected. The SDP is a period when signal
loss is detected or the error ratios of all the consecutive blocks are greater than or equal to
10-2 in at least four consecutive blocks or 1 ms (taking the longer one).
l IFCSES stands for "microwave link consecutive severely errored seconds".
Consecutive severely errored second (CSES) is a second when consecutive SES events
arise but last less than 10 seconds.
l IFUAS stands for "microwave link unavailable second".
An unavailable second (UAS) is counted from the first second of ten SESs, which are
considered to be part of the unavailable time. A new available second period starts from
the first second of ten consecutive non-SESs, which are considered to be part of the available
time.
Attributes of Performance Events

Attributes of Performance Events Description
Performance event cell IFCNT
Unit Block (IFBBE)

Second (IFES, IFSES, IFCSES, and IFUAS)

A small number of bit errors do not affect the service. Too many bit errors, however, may
interrupt the service. Generally, the BER should be less than 10-3 for voice service and less than
10-6for data service.
Relevant Alarms
MW_BER_SD or MW_BER_EXC alarm.
Probable Causes
The system detects microwave link bit errors by using the bit error detection overheads.
Procedure
Step 1 Check whether the MW_FECUNCOR and RPS_INDI alarms are generated.
If ... Then ...

Yes, See Troubleshooting Microwave Links.
No, Replace the IF Board.
----End

10.3.18 FEC_BEF_COR_ER, FEC_COR_BYTE_CNT, and

FEC_UNCOR_BLOCK_CNT

l FEC_BEF_COR_ER stands for "FEC bit error rate before correcting the errors".
This event indicates the impact of the external environment on the transmission.
l FEC_COR_BYTE_CNT stands for "FEC corrected byte count".
This event indicates the impact of the FEC.
l FEC_UNCOR_BLOCK_CNT stands for the number of frames that cannot be corrected by
FEC.This event reflects the number of bit errors after the errors are corrected by FEC.

Performance event cell FECBEFCORER (FEC_BEF_COR_ER),

FECUNCORBLOCKCNT
(FEC_COR_BYTE_CNT),
FECUNCORBLOCKCNT
(FEC_UNCOR_BLOCK_CNT)
Unit None (FEC_BEF_COR_ER)

Byte (FEC_COR_BYTE_CNT and
FEC_UNCOR_BLOCK_CNT)

If the FEC_BEF_COR_ER is too high, there will be residual bit errors in services after the FEC.
If the FEC_UNCOR_BLOCK_CNT is not zero, it indicates that uncorrectable bit errors exist
in microwave links, and bit errors exist in services.
Relevant Alarms
If any byte cannot be troubleshooted, the MW_FECUNCOR alarm occurs.
10.3.19 QPSKWS, QAMWS16, QAMWS32, QAMWS64,

QAMWS128, and QAMWS256
Description
l QPSKWS: Indicates the working time of the QPSK mode.
l QAMWS16: Indicates the working time of the 16QAM mode.


Performance Event Attributes

Basic unit of a performance event QPSKWSSECOND (QPSKWS)

QAMWS16SECOND (QAMWS16)
Unit Second
Impact on System
When the AM function is not enabled, the performance event does not affect the system.
When the AM function is enabled, normally, the seconds of the modulation mode for ensuring
capacity make up a larger percentage. In the duration set for good weather, the seconds of the
low modulation mode make up a larger percentage. The performance of the microwave link is
abnormal.
Relevant Alarms
None.

Maintenance Guide A Glossary
A Glossary
A
ACAP The Adjacent Channel Alternate Polarization (ACAP) operation provides
orthogonal polarizations between two adjacent communication channels.
Alarm A visible or an audible indication to notify the person concerned that a
failure or an emergency has occurred.
Alarm Automatic A function used for the NE to report the alarms to the NMS upon
Reporting generation of the alarms.
Alarm Filter An function used for the NMS not to display the alarms reported by the
NE.
Alarm A function used not to monitor alarms for a specific object, which may
Suppression be the networkwide equipment, a specific NE, a specific board and even
a specific function module of a specific board.
APS Automatic Protection Switching (APS) is the capability of a transmission
system to detect a failure on a working facility and to switch to a standby
facility to recover the traffic.
ATPC Automatic Transmit Power Control. A method of automatically adjusting
the transmit power at the opposite end based on the transmit signal
detected at the receiver.
ATM The asynchronous transfer mode (ATM) is designed to transfer cell in
which multiple service types (such as voice, video, or data) are conveyed
in fixed-length (53-byte) cells. Fixed-length cells allow cell processing
to occur in hardware, thereby reducing transit delays.
Attenuator A passive component used to adjust the signal attenuation.
B
Backup Backup is a method of copying data to the standby storage area to avoid
data loss when the primary storage area is damaged or crashed.
Issue 02 (2009-06-30) Huawei Proprietary and Confidential A-1

A Glossary Maintenance Guide
Bit error An error occurs on some bits in the code stream after the bits are received,
judged and regenerated, and the error impairs the quality of information
transmitted.
Bit error ratio The ratio of error bits to the transmitted bits during a specified time.
Bandwidth Amount of data that can be carried from one point to another in a given
time period (usually a second).
Bit Error Rate Percentage of bits that have errors relative to the total number of bits
received in a transmission.
Broadcast To transmit message frames to all stations in a network.
C
CCDP The co-channel dual polarization (CCDP) operation provides two parallel
communication channels over the same link with orthogonal
polarizations, thus doubling the link capacity.
CCM Continuity check message. A type of packets used to check the link status.
CES Circuit emulation service (CES) is a technology that adapts the traditional
narrowband services (that is, TDM services) to the wideband.
Channel Smallest subdivision of a circuit that provides a type of communication
service; usually a path with only one direction.
Client A terminal (computer or workstation) that sends signaling to the server
and display the result on the user interface
Clock Tracing A method used by all nodes in a network to keep synchronous with one
clock source.
Connector A device installed at the end of a fiber, optical source or receive unit. It
is used to couple the optical wave to the fiber when connected to another
device of the same type. A connector can either connect two fiber ends
or connect a fiber end and a optical source (or a detector).
Current Alarm An alarm that is not cleared or cleared but not acknowledged.
E
Ejector lever A component at the two ends of the front panel of a board, which is used
for inserting or removing the board.
Electrostatic A sudden flow of electric current through a material that is normally an
discharge insulator.
Exercise An operation to check if the protection switching protocol functions
switching normally. The protection switching is not really performed.
A-2 Huawei Proprietary and Confidential Issue 02 (2009-06-30)

Ethernet Ethernet uses a bus or star topology and supports data transfer rates of 10
Mbps.
The Ethernet specification served as the basis for the IEEE 802.3
standard, which specifies the physical and lower software layers.
Ethernet uses the CSMA/CD access method to handle simultaneous
demands. It is one of the most widely implemented LAN standards.
F
Failure A condition where a component does not function in the case of a lasting
fault.
Fault A case where a function cannot perform the specified operation. The case
where operations cannot be performed due to preventive maintenance,
lack of external resources and intended settings is not included.
FD Frequency Diversity. Two or more microwave frequencies with certain
frequency space are used to transmit/receive the same signal and selection
is then performed between the two signals to ease the impact of fading.
FEC Forward Error Correction. A bit error correction technology that adds to
the payload at the transmit end the correction information based on which
the bit errors generated during transmission are corrected at the receive
end.
Fiber jumper Fiber that is used for connections between the subrack and the ODF, and
for connections between subracks or inside a subrack.
Forced switching To forcibly switch the service to the protection board. Even though the
protection board is faulty, the switching will still occur.
Frame A cyclic set of consecutive timeslots in which the relative position of each
time slot can be identified.
I
IDU Indoor Unit. The indoor unit implements accessing, multiplexing/
demultiplexing, and IF processing for services.
IGMP Internet Group Management Protocol. The Protocol is used by IPv4
systems (hosts and routers) to report their IP multicast group
memberships to any neighboring multicast routers.
IGMP Snooping IGMP Snooping is the process of listening to IGMP traffic. IGMP
snooping, as implied by the name, is a feature that allows the switch to
"listen in" on the IGMP conversation between hosts and routers by
processing the layer 3 IGMP packets sent in a multicast network.
IMA The inverse multiplexing for ATM (IMA) technology is used to
demultiplex an ATM integrated cell flow into several lower rate links. At
the far end, the lower rate links are multiplexed to recover the original
integrated cell flow.

Inloop Loop a signal from the cross-connect board, at a physical port, back to
the cross-connect board.
J
Jitter Short waveform variation caused by vibration, voltage fluctuations, or
control system instability.
L
Laser The device that generates the directional light covering a narrow range
of wavelengths. Laser light is more coherent than ordinary light.
Semiconductor diode lasers are the used light source in fiber-optic
system.
LCAS Link Capacity Adjustment Scheme. A solution features flexible
bandwidth and dynamic adjustment. In addition, it provides a failure
tolerance mechanism, which enhances the viability of virtual
concatenations and enables the dynamic adjustment to bandwidth (non-
service affecting).
Loopback A troubleshooting technique that returns a transmitted signal to its source
so that the signal or message can be analyzed for errors.
Locked switching In the case of locked switching, when the switching condition is satisfied,
the service cannot be switched from the working path to the protection
path; when the switching occurs, the service can be restored from the
protection path to the working path.
LSP Label switch path (LSP) is an ingress and egress switched path built
through a series of label switch routers to forward the packets of a
particular FEC using a label swapping forwarding mechanism.
M
MA A part of the maintenance domain.
Manual switching A protection switching. When the protection path is normal and there is
no request of a higher level switching, the service is manually switched
from the working path to the protection path, to test whether the network
still has the protection capability.
MD Network-edge equipment that can transmit or receive multicast packets
to or from each other
MEP Maintenance association end point. An edge node of the maintenance
association.
MPLS Multiprotocol label switching (MPLS) is a versatile solution to address
the problems faced by present-day networks speed, scalability, quality-
of-service (QoS) management, and traffic engineering.

MSP Multiplex section protection. The function performed to provide

capability for switching a signal between and including two MST
functions, from a "working" to a "protection" channel.
N
N+1 protection A microwave link protection system that employs N working channels
and one protection channel.
NE Network element (NE) that contains hardware and the software that runs
on the hardware. Generally, one network element should contain one SCC
board at least, which manages and monitors the entire network element.
The NE software runs on the SCC board.
NE Explorer A main operation interface of the T2000. A expandable object tree
(function tree) is set at the lower left pane of the interface. The user can
quickly locate the operation object from the object tree and then perform
configuration, management and maintenance accordingly.
O
OAM To operate, manage and maintain a network or network equipment.
ODU Outdoor Unit. The outdoor unit implements frequency conversion and
amplification for RF signals.
Optical interface A component that connects several transmit or receive units
P
PDH Plesiosynchronous Digital Hierarchy. A multiplexing scheme of bit
stuffing and byte interleaving. It multiplexes the minimum rate 64 kit/s
into the 2 Mbit/s, 34 Mbit/s, 140 Mbit/s and 565 Mbit/s rates.
Power supply box The DC power distribution box on the top of a cabinet, providing power
supply to the subracks in the cabinet.
Protection A channel labeled with the protection attribute in the protection group.
Channel
Q
QinQ The QinQ, a Layer 2 tunnel protocol developed based on the IEEE 802.1Q
encapsulation, allows for individual VLANs with extra tag information
to traverse the backbone networks and thus provides Layer 2 VPN tunnels
for users.

RSTP Rapid Spanning Tree Protocol. The protocol is an evolution of the

Spanning Tree Protocol, providing for faster spanning tree convergence
after a topology change.
S
SD Space Diversity. Two or more antennas separated by a specific distance
transmit/receive the same signal and selection is then performed between
the two signals to ease the impact of fading. Currently, only receive SD
is used.
SDH Synchronous Digital Hierarchy. A hierarchical set of digital transport
structures, standardized for the transport of suitably adapted payloads
over physical transmission networks.
SNCP Subnetwork connection protection. A working subnetwork connection is
replaced by a protection subnetwork connection if the working
subnetwork connection fails, or if its performance falls below a required
level.
STP The Spanning Tree Protocol (STP), defined in the IEEE Standard 802.1D,
is an OSI layer-2 protocol that ensures a loop free topology for any
bridged LAN.
T
T2000 A subnet management system (SNMS). In the telecommunication
management network architecture, the T2000 is located between the NE
level and network level, which can supports all NE level functions and
part of the network level management functions.
Tunnel A secure communication path between two peers, such as two routers.
U
Unicast The process of sending data from a source to a single recipient.

Maintenance Guide B Acronyms and Abbreviations
B Acronyms and Abbreviations
A
AIS Alarm Indication Signal
APS Automatic Protection Switching
ARP Address Resolution Protocol
ATPC Automatic Transmit Power Control
ATM Asynchronous Transfer Mode
AU Administrative Unit
B
BER Bit Error Rate
BIP Bit-Interleaved Parity
BPDU Bridge Protocol Data Unit
C
CAR Committed Access Rate
CBS Committed Burst Size
CCDP Co-Channel Dual Polarization
CCM Continuity Check Message
CES Circuit Emulation Service
CF Compact Flash
CGMP Cisco Group Management Protocol
CIR Committed Information Rate
CLNP Connectionless Network Protocol
Issue 02 (2009-06-30) Huawei Proprietary and Confidential B-1

B Acronyms and Abbreviations Maintenance Guide
CLNS Connectionless Network Service

CoS Class of Service
CPU Central Processing Unit
CRC Cyclic Redundancy Check
CVLAN Customer VLAN
C-VLAN Customer VLAN
D
DC Direct Current
DCC Data Communications Channel
DCN Data Communication Network
DSCP Differentiated Services Code Point
DVMRP Distance Vector Multicast Routing Protocol
E
ECC Embedded Control Channel
EPL Ethernet Private Line
EPLAN Ethernet Private LAN
ES-IS End System to Intermediate System
EVPL Ethernet Virtual Private Line
F
FCS Frame Check Sequence
FD Frequency Diversity
FE Fast Ethernet
FEC Forward Error Correction
FIFO First In First Out
FLP Fast Link Pulse
FTP File Transfer Protocol
G
GE Gigabit Ethernet
B-2 Huawei Proprietary and Confidential Issue 02 (2009-06-30)

GFP Generic Framing Procedure

GTS Generic Traffic Shaping
GUI Graphical User Interface
H
HDLC High Level Data Link Control Procedure
HP Higher Order Path
HSB Hot Standby
HSM Hitless Switch Mode
I
ICMP Internet Control Message Protocol
IDU Indoor Unit
IEEE Institute of Electrical and Electronics
Engineers
IETF The Internet Engineering Task Force
IF Intermediate Frequency
IGMP Internet Group Management Protocol
IMA Inverse Multiplexing for ATM
IP Internet Protocol
IPv6 Internet Protocol version 6
IS-IS Intermediate System to Intermediate System
ISO International Standard Organization
ITU-T International Telecommunication Union -
Telecommunication Standardization Sector
IVL Independence VLAN Learning
L
LAN Local Area Network
LAPD Link Access Procedure on the D channel
LAPS Link Access Procedure-SDH
LCAS Link Capacity Adjustment Scheme
LMSP Linear Multiplex Section Protection

LOF Loss Of Frame

LOM Loss Of Multiframe
LOP Loss Of Pointer
LOS Loss Of Signal
LP Lower Order Path
LSP Label Switch Path
M
MA Maintenance Association
MAC Medium Access Control
MBS Maximum Burst Size
MD Maintenance Domain
MDI Medium Dependent Interface
MEP Maintenance Association End Point
MIB Management Information Base
MLM Multi-Longitudinal Mode
MPLS Multiprotocol Label Switching
MO Managed Object
MS Multiplex Section
MSP Multiplex Section Protection
MTU Maximum Transmission Unit
N
NE Network Element
NLP Normal Link Pulse
NMS Network Management System
NNI Network-to-Network Interface or Network
Node Interface
NSAP Network Service Access Point
O
OAM Operation, Administration and Maintenance
ODU Outdoor Unit

OSI Open Systems Interconnection

OSPF Open Shortest Path First
P
PCB Printed Circuit Board
PDH Plesiochronous Digital Hierarchy
PIM-DM Protocol Independent Multicast-Dense Mode
PIM-SM Protocol Independent Multicast-Sparse Mode
PPP Point-to-Point Protocol
Q
QinQ 802.1Q in 802.1Q
QoS Quality of Service
R
RDI Remote Defect Indication
REI Remote Error Indication
RF Radio Frequency
RFC Request For Comment
RIP Routing Information Protocol
RMON Remote Network Monitoring
RSL Received Signal Level
RSTP Rapid Spanning Tree Protocol
RTN Radio Transmission Node
S
SD Signal Degrade
SDH Synchronous Digital Hierarchy
SDP Serious Disturbance Period
SES Severely Errored Second
SF Signal Fail
SLM Single-Longitudinal Mode

SNC SubNetwork Connection

SNCP Sub-Network Connection Protection
SNMP Simple Network Management Protocol
SNR Signal-to-Noise Ratio
STM Synchronous Transport Module
STM-1 SDH Transport Module -1
STM-1e STM-1 Electrical Interface
STM-1o STM-1 Optical Interface
STM-4 SDH Transport Module -4
STM-N SDH Transport Module -N
STP Spanning Tree Protocol
SVL Shared VLAN Learning
T
TCI Tag Control Information
TCP Transfer Control Protocol
TIM Trace Identifier Mismatch
TPS Tributary Protection Switching
TU Tributary Unit
U
UAS Unavailable Second
UDP User Datagram Protocol
UNI User-Network Interface
UPS Uninterruptible Power Supply
V
VC Virtual Container
VC12 Virtual Container -12
VC-12 Virtual Container -12


VCG Virtual Concatenation Group
VLAN Virtual LAN
VoIP Voice over IP
VPN Virtual Private Network
W
WAN Wide Area Network
WRR Weighted Round Robin
WTR Wait to Restore Time
X
XPD Cross-Polarization Discrimination
XPIC Cross-polarization interference cancellation


Maintenance Guide (V100R001C00 02)

Enviado por

Dados do documento

Descrição original:

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Maintenance Guide (V100R001C00 02)

Enviado por

Direitos autorais:

Formatos disponíveis

OptiX RTN 950 Radio Transmission System

HUAWEI TECHNOLOGIES CO., LTD.

Trademarks and Permissions

Huawei Technologies Co., Ltd.

Issue 02 (2009-06-30) Huawei Proprietary and Confidential i

About This Document

Product Name Version

OptiX RTN 950 V100R001C00

OptiX iManager T2000 V200R007C03

Issue 02 (2009-06-30) Huawei Proprietary and Confidential iii

Table 1 Introduction to each chapter

1 Safety Precautions This chapter describes safety

2 Routine maintenance This chapter describes items,

3 Troubleshooting This chapter describes the

4 Data Backup and Restoration This chapter describes methods for

5 Replacing Components This chapter describes procedures

7 Remote Maintenance Guide This chapter describes methods and

8 Task Set This chapter describes common

9 Alarm This chapter describes how alarms

10 Performance Event This chapter describes how

A Glossary This chapter lists the glossary used

B Acronyms and Abbreviations This chapter lists the acronyms and

iv Huawei Proprietary and Confidential Issue 02 (2009-06-30)

Indicates a hazard with a high level of risk,

Indicates a hazard with a medium or low level

Indicates a potentially hazardous situation,

Indicates a tip that may help you solve a

Provides additional information to emphasize

Times New Roman Normal paragraphs are in Times New Roman.

Boldface Names of files, directories, folders, and users are in

Italic Book titles are in italics.

Issue 02 (2009-06-30) Huawei Proprietary and Confidential v

Updates in Issue 02 (2009-06-30) Based on Product Version V100R001C00

Updates in Issue 01 (2009-04-30) Based on Product Version V100R001C00

vi Huawei Proprietary and Confidential Issue 02 (2009-06-30)

About This Document...................................................................................................................iii

Issue 02 (2009-06-30) Huawei Proprietary and Confidential vii

2.3.4 Checking IF Cables..............................................................................................................................2-22

4 Data Backup and Restoration..................................................................................................4-1

viii Huawei Proprietary and Confidential Issue 02 (2009-06-30)

5.3 Replacing the Processing Boards....................................................................................................................5-5

6 Software Package Upgrade and Package Diffusion............................................................6-1

7 Remote Maintenance Guide....................................................................................................7-1

Issue 02 (2009-06-30) Huawei Proprietary and Confidential ix

8.15 Setting the State of an ODU Transmitter....................................................................................................8-18

x Huawei Proprietary and Confidential Issue 02 (2009-06-30)

Issue 02 (2009-06-30) Huawei Proprietary and Confidential xi

xii Huawei Proprietary and Confidential Issue 02 (2009-06-30)

Issue 02 (2009-06-30) Huawei Proprietary and Confidential xiii

xiv Huawei Proprietary and Confidential Issue 02 (2009-06-30)

B Acronyms and Abbreviations.................................................................................................B-1

Issue 02 (2009-06-30) Huawei Proprietary and Confidential xv

Figure 1-1 Wearing the ESD wrist strap..............................................................................................................1-7

Issue 02 (2009-06-30) Huawei Proprietary and Confidential xvii

Figure 8-16 Damaged or suspect fibers..............................................................................................................8-38

xviii Huawei Proprietary and Confidential Issue 02 (2009-06-30)

Table 1 Introduction to each chapter......................................................................................................................iv

Issue 02 (2009-06-30) Huawei Proprietary and Confidential xix

Table 10-9 SDH Performance Event List.........................................................................................................10-10

xx Huawei Proprietary and Confidential Issue 02 (2009-06-30)

About This Chapter

1.1 Warning and Safety Symbols