V100R001C00
Maintenance Guide
Issue 02
Date 2009-06-30
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.
Website: http://www.huawei.com
Email: support@huawei.com
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.
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:
6 Software Package Upgrade and Package Diffusion This chapter describes methods and
procedures for performing the
package loading and package
diffusion.
Conventions
Symbol Conventions
The symbols that may be found in this document are defined as follows.
Symbol Description
General Conventions
The general conventions that may be found in this document are defined as follows.
Convention Description
GUI Conventions
The GUI conventions that may be found in this document are defined as follows.
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.
Contents
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
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
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
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
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
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
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
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
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
Figures
Tables
1 Safety Precautions
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.
! 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.
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.
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.
Table 1-2 lists the levels and meanings of the safety symbols.
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.
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
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.
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.
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.
WARNING
When working at a height, prevent objects from falling down.
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.
WARNING
Do not stand or walk under heavy objects when they are being lifted.
WARNING
When carrying the device, wear protection gloves to prevent injuries that can be caused by sharp
objects.
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.
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.
2 Routine maintenance
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.
T2000 NMS center Checking the status of the NE and boards Daily
operator
Browsing network-wide alarms Daily
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
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
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
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.
When the indicator is surrounded by a square frame and the square frame flashes, it indicates
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.
When the indicator is surrounded by a square frame and the square frame flashes, it indicates
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
Prerequisite
l The T2000 must be started in the NMS center.
l The NE must be configured and the data must be uploaded to the T2000.
l You must be a T2000 user with the "NE Monitor" authority or higher.
Maintenance Period
Daily
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
Prerequisite
l The T2000 must be started in the NMS center.
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
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.
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.
After the performance register is reset, the current performance data of this type is cleared. Then, a new
performance monitoring period is started.
Step 6 Optional: Click Print or Save As to output the performance event data.
----End
Prerequisite
l The T2000 must be started in the NMS center.
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 OptiX iManager T2000 Online Help.
l You must be a T2000 user with the "NE and network monitor" authority or higher.
Maintenance Period
Daily
Operation Criteria
No packet loss and error packets occur.
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 the 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 >
RMON 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. Right-click the tunnel to choose
Browse Performance to display the Performance Management
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
Browse Performance to display the Performance Management
window.
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.
----End
Prerequisite
l The T2000 must be started in the NMS center.
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 OptiX iManager T2000 Online Help.
l You must be a T2000 user with the "NE and network monitor" authority or higher.
Maintenance Period
Daily
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 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 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.
5. Restore the fiber connection at the tested optical interface.
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.
5. Restore the fiber connection at the tested optical interface.
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
Prerequisite
l The T2000 must be started in the NMS center.
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
Monthly
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 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
Physical port/ Select the corresponding board, and then choose Performance >
board History 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 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.
After the resetting, the history performance data is deleted and a new performance monitoring period is
beginning.
Step 6 Optional: Click Print or Save As to output the performance event data.
----End
Prerequisite
l The T2000 must be started in the NMS center.
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 OptiX iManager T2000 Online Help.
l You must be a T2000 user with the "NE and network monitor" authority or higher.
Maintenance Period
Monthly
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 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 the 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 >
RMON 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. Right-click the tunnel to choose
Browse Performance to display the Performance 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
Browse Performance to display the Performance Management
window.
When Display Mode is set to Graphics, the number of the selected performance events cannot exceed 10.
----End
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
Maintenance Period
Monthly
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.
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
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
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
Prerequisite
l The T2000 is in normal communication with the NE.
l The NE user has the authority of maintenance level or higher.
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
Pending problems:
Verification:
Prerequisite
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
Prerequisite
None.
Procedure
Step 1 Ensure that the coupler 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 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
Prerequisite
None.
Procedure
Step 1 Ensure that the antenna 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 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
Prerequisite
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.
----End
Pending problems:
Verification:
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
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.
Pending problems:
Verification:
3 Troubleshooting
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
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.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
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
causes, tools required for troubleshooting, troubleshooting procedure, and precautions that
should be taken during the troubleshooting.
3.10 ML-PPP Troubleshooting
This section describes the ML-PPP faults such as service interruption, packet loss, or bit error
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.11 IMA Troubleshooting
This section describes the IMA 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.12 FRR Troubleshooting
This section describes the FRR 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.13 MPLS APS Troubleshooting
This section describes the MPLS APS 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.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.
Flow Diagram
Figure 3-1 shows the general flow diagram for handling faults.
Start
External Yes
Other handling flow
anomalies?
No
Rectify fault
Yes
End
You can also save the important data such as the alarm and performance event information stored
on the T2000.
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.
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.
NOTE
After confirming a cause, analyze the result to check whether the fault is rectified and whether
any new fault occurs.
l If new faults occur, refer to the fault handling flow and try to rectify them.
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.
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.
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.
Start
T2000
No
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
No
No
Yes
Reset/re-insert
Check fiber and use
faulty board, disable
standby route
protection protocol
No
No
Fault ratified?
No
Yes
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.
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
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
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 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
Start
1 Yes
Is there a wrong
Cancel the operation
operation?
No
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
Abnormal receive Yes
power caused by slow Handle the fault
down-fading?
No
7
Abnormal receive Yes
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
Note Description
⑥ 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.
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.
COMMUN_FAIL CXPR
MPLS_TUNNEL_LOCV CXPR
PW_DOWN
Troubleshooting Flowchart
Figure 3-4 shows the flowchart for troubleshooting CES service faults.
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
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
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.
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
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.
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.
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.
COMMUN_FAIL CXPR
Troubleshooting Flowchart
Figure 3-5 shows the flowchart for troubleshooting Ethernet service faults.
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
No
No
Whether Yes
Service configuration Modify service
FLOW_OVER alarm
is incorrect configuration
exists?
No Whether fault
is rectified?
Yes
Possible Causes
As shown in the troubleshooting flowchart, an Ethernet 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 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.
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
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.
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
troubleshooting, troubleshooting procedure, and precautions that should be taken during the
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.
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
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.
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.
l If any problems occur during the troubleshooting, contact Huawei engineers. For the
contact information, see 3.15 Fault Notification and Technical Support.
----End
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.
Troubleshooting Flowchart
Figure 3-6 shows the flowchart for troubleshooting the QoS faults.
Start
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
Possible Causes
As shown in the troubleshooting flowchart, the QoS faults may be due to the following causes:
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.
l If any problems occur during the troubleshooting, contact Huawei engineers. For the
contact information, see 3.15 Fault Notification and Technical Support.
----End
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.
Troubleshooting Flowchart
Figure 3-7 shows the flowchart for troubleshooting the inband DCN faults.
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
No
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
Contact Huawei technical
End
engineers
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.
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.
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.
l If any problems occur during the troubleshooting, contact Huawei engineers. For the
contact information, see 3.15 Fault Notification and Technical Support.
----End
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.
ETH_LOS
ETH_LINK_DOWN
Troubleshooting Flowchart
Figure 3-8 shows the flowchart for troubleshooting the LAG faults.
No
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
No
No
Whether fault
is rectified
Yes
Contact Huawei technical
End
engineers
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.
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.
l If any problems occur during the troubleshooting, contact Huawei engineers. For the
contact information, see 3.15 Fault Notification and Technical Support.
----End
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.
Troubleshooting Flowchart
Figure 3-9 shows the flowchart for troubleshooting the ML-PPP faults.
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
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
No Whether fault
is rectified
Yes
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.
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.
l If any problems occur during the troubleshooting, contact Huawei engineers. For the
contact information, see 3.15 Fault Notification and Technical Support.
----End
Symptoms
Table 3-11 lists the symptoms of the IMA faults. If the alarms reported by the equipment are
cleared, the faults are rectified.
ALM_IMA_RE_TX_UNUS
ABLE
Troubleshooting Flowchart
Figure 3-10 shows the flowchart for troubleshooting the IMA faults.
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
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
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.
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.
l If any problems occur during the troubleshooting, contact Huawei engineers. For the
contact information, see 3.15 Fault Notification and Technical Support.
----End
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.
Troubleshooting Flowchart
Figure 3-11 shows the flowchart for troubleshooting the FRR faults.
Start
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
No Whether fault
is rectified
Yes
Contact Huawei technical
End
engineers
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.
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.
l If any problems occur during the troubleshooting, contact Huawei engineers. For the
contact information, see 3.15 Fault Notification and Technical Support.
----End
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.
ETH_APS_TYPE_MISMA
TCH
MPLS_TUNNEL_MISMA
TCH
MPLS_TUNNEL_Excess
MPLS_TUNNEL_SD
MPLS_TUNNEL_SF
MPLS_TUNNEL_UNKNO
WN
Troubleshooting Flowchart
Figure 3-12 shows the flowchart for troubleshooting the MPLS APS faults.
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
Yes
Whether
Yes
the hardware alarm Rectify the board
such as HARD_BAD hardware fault
exists
No
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
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.
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.
l If any problems occur during the troubleshooting, contact Huawei engineers. For the
contact information, see 3.15 Fault Notification and Technical Support.
----End
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.
NOTE
The latest technical documents are available on the support website, which may help to analyze and solve
problems.
Website: http://support.huawei.com/
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.
NOTE
NOTE
Table 4-2 Features and application scenarios of the three methods of maintaining data
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.
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 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
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 3 In the dialog box displayed, enter the password of user sa.
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 7 When the backup is complete, click OK in the displayed indication dialog box and return to the
database management tool interface.
----End
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.
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.
----End
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
operating system. The MS SQL server database must be started.
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".
l On the Windows platform, open Windows Explorer. In the \T2000\server\database
directory, run "T2000DM.exe".
Step 2 In the Database Server List on the left, select T2000DBServer.
Step 3 In the displayed dialog box, enter the password of user sa.
NOTE
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
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
operating system. The MS SQL server database must be started.
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".
l On the Windows platform, open Windows Explorer. In the \T2000\server\database
directory, run "T2000DM.exe".
Step 3 In the displayed dialog box, enter the password of user sa.
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
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.
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
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
operation of the NE. This section describes certain methods of backing up and restoring NE data.
Select a proper method as required.
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.
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.
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 3 Select one or more NEs from Configuration Data Management List.
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
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 1 Choose Configuration > Configuration Data Management from the Main Menu.
Step 3 Select one or more NEs from Configuration Data Management List.
Step 4 Click Back Up NE Data > Manually back up database to CF Card . Click OK to start the
backup.
----End
Prerequisite
l The T2000 user must log in and display the Main Topology interface.
l You must be a T2000 user with "NE and Network Maintainer" authority or higher.
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.
Prerequisite
l You must log in to the NE as an NE user with "system level" authority.
l You must be a T2000 user with "NE and Network Operator" authority or higher.
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
Prerequisite
l You must log in to the NE as an NE user with "system level" authority.
l You must be a T2000 user with "NE and Network Operator" authority or higher.
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 1 Choose Configuration > Configuration Data Management from the Main Menu.
----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.
Prerequisite
l The T2000 user must log in and display the Main Topology interface.
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 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.
5 Replacing Components
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,
impact on system, precautions, tools, and operation procedure.
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.
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 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.
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.
----End
Prerequisite
l The T2000 user must log in and display the Main Topology interface.
l You must be a T2000 user with "NE and Network Maintainer" authority or higher.
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 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 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
Prerequisite
l The T2000 user must log in and display the Main Topology interface.
l You must be a T2000 user with "NE and Network Maintainer" authority or higher.
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.
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 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
operations, see 8.19 Replacing Boards on Site.
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..
Step 5 Check whether the original alarms are cleared and no alarms are generated. If yes, it indicates
that the board replacement is successful.
----End
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.
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 5 After the board starts to work, observe the indicators on the board.
The STAT indicator should be lit green.
Step 8 Optional: If you have performed forced switching earlier between the radio links, release the
switching through the T2000.
----End
Prerequisite
l The T2000 user must log in and display the Main Topology interface.
l You must be a T2000 user with "NE and Network Maintainer" authority or higher.
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.
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 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
operations, see 8.2 Querying Current Alarms of a Board.
Step 3 Ask the on-site maintenance personnel to remove the faulty FAN board. For specific operations,
see 8.19 Replacing Boards on Site.
----End
Prerequisite
l The T2000 user must log in and display the Main Topology interface.
l You must be a T2000 user with "NE and Network Maintainer" authority or higher.
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.
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 and record the current alarms of the system. 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 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
Prerequisite
l The T2000 user must log in and display the Main Topology interface.
l You must be a T2000 user with "NE and Network Maintainer" authority or higher.
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 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 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
operations, see 8.19 Replacing Boards on Site.
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.
Step 5 Check whether the original alarms are cleared and no alarms are generated. If yes, it indicates
that the board replacement is successful.
----End
Prerequisite
l The T2000 user must log in and display the Main Topology interface.
l You must be a T2000 user with "NE and Network Maintainer" authority or higher.
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.
l The cable connectors must be properly sealed to prevent short circuit.
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
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 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.
----End
Prerequisite
l The T2000 user must log in and display the Main Topology interface.
l You must be a T2000 user with "NE and Network Maintainer" authority or higher.
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.
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.
1
optical port
2 safety latch spare part
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
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.
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.
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 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.
----End
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 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 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.
There should be no new alarms.
----End
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.
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
----End
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.
Start
Rollback
Yes
Whether dispensing No
the software succeeds
Yes
Whether activating No
the software succeeds
Yes
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
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.
Context
Figure 6-2 shows the flow for upgrading a software package.
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.
----End
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.
DBMS_ERROR - -
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
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
displayed in the device tree area.
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
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.
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.
Background Information
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.
Setting No
information Suspension state
succeeds?
Yes
Initialization state
Receives No
software-ready
information?
Yes
Pending state
Yes
Transmission state
Receiving No
software
succeeds?
Yes
Completion state
No
All the NEs are in
Package upgrade
completion state
End
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.
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.
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.
DBMS_ERROR - -
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
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
displayed in the device tree area.
l Click , and the physical location, device name and IP address of the selected device will be
displayed in the device tree area.
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 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.
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 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.
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
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.
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.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
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
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
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 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
8 Task Set
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
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
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 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
Prerequisite
l The T2000 user must log in to the T2000 and enter the Main Topology.
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
Step 3 After the alarm query is complete, the Operation Result dialog box is displayed. Click Close.
Prerequisite
l The T2000 user must log in to the T2000 and enter the Main Topology.
l You must be a T2000 user with "NE and Network Operator" authority or higher.
l The board must be created.
Procedure
Step 1 Choose Report > Board Information Report from the Main Menu.
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.
----End
Prerequisite
l The T2000 user must log in to the T2000 and enter the Main Topology.
l You must be a T2000 user with "NE and Network Operator" authority or higher.
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.
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
Prerequisite
l The T2000 user must log in to the T2000 and enter the Main Topology.
l You must be a T2000 user with "NE and Network Operator" authority or higher.
l An MPLS tunnel must be created.
Procedure
Step 1 Select and right-click the target NE. Choose NE Explorer.
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 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
Prerequisite
l The T2000 user must log in to the T2000 and enter the Main Topology.
l You must be a T2000 user with "NE and Network Operator" authority or higher.
l An MPLS tunnel must be created.
Procedure
Step 1 Select and right-click the target NE. Choose NE Explorer.
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 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
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
l The T2000 user must log in to the T2000 and enter the Main Topology.
l You must be a T2000 user with "NE and Network Operator" authority or higher.
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 1 Choose Configuration > Configuration Data Management from the Main Menu.
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
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:
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.
----End
Prerequisite
l The T2000 user must log in to the T2000 and enter the Main Topology.
l You must be a T2000 user with "NE and Network Operator" authority or higher.
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 1 Choose Configuration > Configuration Data Management from the Main Menu.
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
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:
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.
----End
Prerequisite
l The T2000 user must log in to the T2000 and enter the Main Topology.
l You must be a T2000 user with "NE and Network Operator" authority or higher.
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 1 Select and right-click the target NE. Choose NE Explorer.
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.
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
Prerequisite
l The T2000 user must log in to the T2000 and enter the Main Topology.
l You must be a T2000 user with "NE and Network Operator" authority or higher.
Background Information
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 6 The Operation Result dialog box is displayed. ClickClose. The protection switching is
complete.
----End
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.
Background Information
Board 1+1 protection switching includes working/protection switching, and restore working/
protection.
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
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 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.
----End
Prerequisite
l An IF 1+1 protection group must be configured.
l The user must have the system level authority.
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 3 Click Query, and then check the working status of the IF 1+1 protection group in the Slot
Mapping Relation area.
----End
Prerequisite
l The communication between the T2000 and the NE must be normal.
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.
----End
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 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.
----End
Prerequisite
l The T2000 user must log in to the T2000 and enter the Main Topology.
l You must be a T2000 user with "NE and Network Operator" authority or higher.
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
Prerequisite
l The T2000 user must log in to the T2000 and enter the Main Topology.
l You must be a T2000 user with "NE and Network Operator" authority or higher.
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.
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
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.
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
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 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 9 Repeat the previous steps to test the receive optical power at all the optical interfaces of the
equipment one by one.
----End
Prerequisite
A new board must be available.
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.
l The cable connectors must be properly sealed to prevent short circuit.
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.
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.
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.
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.
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
Prerequisite
The external power supply must be provided.
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
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
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
Step 5 Click Apply and click Yes in the displayed Warning dialog box. The working mode of the
Ethernet interface is set.
----End
Prerequisite
You must be an NM user with "NE and Network Operator" authority or higher.
Background Information
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.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.
Cleaning optical components is to remove dust or other dirt to avoid performance degradation
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.
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"
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.
Figure 8-13 Cleaning stick for the SC and FC optical interface (just for reference)
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.
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.
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.
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".
----End
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.
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.
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 1 Turn off the lasers before the inspection. Disconnect both ends of the fiber to be inspected.
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.
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 9 Turn on the lasers after you connect the fiber to the board.
----End
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 compressed gas
l Special cleaning roll
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.
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 1 Turn off the lasers before the inspection. Disconnect both ends of the fiber to be inspected.
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,
repeat the Step 1 to Step 6.
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
Step 9 Turn on the lasers after you connect the fiber to the board.
----End
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.
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.
CAUTION
The electrostatic discharge may damage the equipment. Before touching the equipment, board
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,
repeat the Step 1 to Step 6.
Step 8 Connect the fiber to the board, or put a protective cap on the interface.
Step 9 Turn on the lasers after you connect the fiber to the board.
----End
9 Alarm
This chapter describes basic concepts related to alarms and how to handle related alarms of the
equipment.
No
The alarm is saved in the alarm
database of the system control
board
No
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
Whether
No
to set the alarm
reporting?
Yes
NOTE
For details on the alarm suppression, alarm synchronization, alarm automatic reporting, alarm filtering and
alarm notification, see the OptiX iManager T2000 Online Help.
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
ETH_LINK_DOWN
Data-Link MPLS_TUNNEL_FDI
ETH_EFM_EVENT
MPLS_TUNNEL_ MPLS_TUNNEL_
FDI MISMERGE
Tunnel
MPLS_TUNNEL_
MISMATCH
MPLS_TUNNEL_SD
MPLS_PW_FDI MPLS_PW_MISM
PW ERGE
MPLS_PW_BDI MPLS_PW_MISM
ATCH
MPLS_PW_LOCV MPLS_PW_BDI
ETH_CFM_LOC ETH_CFM_RDI
FDBSIZEALM_ ETH_CFM_SF
ELAN
ETH_CFM_SD
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.
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.
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.
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.
RELAY_ALARM_IGNOR WRG_BD_TYPE
LAG_DOWN E
LAG_MEMBER_DOWN RELAY_ALARM_MAJOR -
CES_STRAYPKT_EXC - -
POWER_ABNORMAL - -
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
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.
Start
Yes
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
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.
No Proceed to next step.
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".
No Proceed to next step.
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
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
Alarm ID Alarm Severity Alarm Type
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.
l Cause 2: The physical link is interrupted.
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
Alarm ID Alarm Severity Alarm Type
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
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
l Cause 1: The IMA protocols at the two ends fail to negotiate with each other.
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.
l Cause 2: The physical link for the IMA link becomes faulty.
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
Alarm ID Alarm Severity Alarm Type
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
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
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_LODS alarm is cleared, the IMA link automatically becomes
available.
Possible Causes
The possible causes of the ALM_IMA_LODS 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
l Cause 1: The IMA protocols at the two ends fail to negotiate with each other.
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.
l Cause 2: The physical link for the IMA link becomes faulty.
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
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
Alarm ID Alarm Severity Alarm Type
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
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:
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
l Cause 1: The IMA protocols at the two ends fail to negotiate with each other.
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.
l Cause 2: The physical link for the IMA link becomes faulty.
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
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
Alarm ID Alarm Severity Alarm Type
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
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:
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
l Cause 1: The IMA protocols at the two ends fail to negotiate with each other.
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.
l Cause 2: The physical link for the IMA link becomes faulty.
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
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
Alarm ID Alarm Severity Alarm Type
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
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
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_RFI alarm is cleared, the IMA link automatically becomes available.
Possible Causes
The possible causes of the ALM_IMA_RFI 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
l Cause 1: The IMA protocols at the two ends fail to negotiate with each other.
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.
l Cause 2: The physical link for the IMA link becomes faulty.
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.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
Alarm ID Alarm Severity Alarm Type
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
Alarm ID Alarm Severity Alarm Type
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:
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.
For details, refer to 8.2 Querying Current Alarms of a Board.
----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
Alarm ID Alarm Severity Alarm Type
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:
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
Alarm ID Alarm Severity Alarm Type
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
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:
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.
l Cause 2: The board is faulty.
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
Alarm ID Alarm Severity Alarm Type
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
l Cause 1: The clocks may be not synchronous.
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.
l Cause 2: The set buffer area is too small.
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
Alarm ID Alarm Severity Alarm Type
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
l Cause 1: The clocks may be not synchronous.
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.
l Cause 2: The set buffer area is too small.
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.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
Alarm ID Alarm Severity Alarm Type
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
l Cause 1: The bandwidth configured to the tunnel or PW is so low that the link is baffled.
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
the alarm is cleared.
l Cause 2: The cable, fiber or optical module is faulty and the signals on the link degrades.
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
Alarm ID Alarm Severity Alarm Type
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.
l Cause 2: The bandwidth configured to the tunnel or PW is so low that the link is baffled.
l Cause 3: The cable, fiber or optical module is faulty and the signals on the link degrades.
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.
l Cause 2: The bandwidth configured to the tunnel or PW is so low that the link is baffled.
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
the alarm is cleared.
l Cause 3: The cable, fiber or optical module is faulty and the signals on the link degrades.
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.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
Alarm ID Alarm Severity Alarm Type
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:
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
l Cause 1: The bandwidth configured to the tunnel or PW is so low that the link is baffled.
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
the alarm is cleared.
l Cause 2: The cable, fiber or optical module is faulty and the signals on the link degrades.
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.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
Alarm ID Alarm Severity Alarm Type
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.
Possible Causes
The possible causes of the CES_STRAYPKT_EXC alarm are as follows:
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
Alarm ID Alarm Severity Alarm Type
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:
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,
refer to 5 Replacing Components.
----End
Related Information
None.
9.3.21 CFCARD_OFFLINE
Description
The CFCARD_OFFLINE alarm indicates that the CF card is out of service.
Attribute
Alarm ID Alarm Severity Alarm Type
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.
l Cause 3: The system control board is faulty.
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,
refer to 5 Replacing Components.
----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
Alarm ID Alarm Severity Alarm Type
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 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:
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
Alarm ID Alarm Severity Alarm Type
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 Indicates the slot number of the board which fails in communicating with the
system control board.
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
Alarm ID Alarm Severity Alarm Type
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 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
Alarm ID Alarm Severity Alarm Type
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 Indicates the alarm type, which indicates the error code that causes the alarm.
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.
l Cause 2: The CXPR board is faulty.
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
Alarm ID Alarm Severity Alarm Type
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:
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
Alarm ID Alarm Severity Alarm Type
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.
l Cause 2: The board is faulty.
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.
l Cause 2: The board is faulty.
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
Alarm ID Alarm Severity Alarm Type
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
Alarm ID Alarm Severity Alarm Type
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
Alarm ID Alarm Severity Alarm Type
Parameters
None.
None.
Impact on System
l In the case of the ETH_APS_SWITCH_FAIL alarm, the services cannot be protected.
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
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 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:
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
Alarm ID Alarm Severity Alarm Type
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.
l Cause 3: The board is faulty.
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.
For details, refer to 8.2 Querying Current Alarms of a Board.
2. If yes, clear the LOOP_ALM alarm first and then check whether the
ETH_LINK_DOWN alarm is cleared.
l Cause 3: The board is faulty.
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
Alarm ID Alarm Severity Alarm Type
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.
l Cause 4: The board is faulty.
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
Parameters
Name Meaning
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 2: The CXPR board is faulty.
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.
l Cause 2: The CXPR board is faulty.
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
Alarm ID Alarm Severity Alarm Type
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
Alarm ID Alarm Severity Alarm Type
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
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:
Handling Procedure
l Cause: One or more fans on the fan board are faulty.
----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
Alarm ID Alarm Severity Alarm Type
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 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.
– If yes, go to step 4.
– If not, go to step 2.
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.
– If yes, go to step 4.
– If not, go to step 3.
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
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
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:
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
950 Radio Transmission System Configuration Guide manual.
NOTE
----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
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
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:
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
the alarm is cleared.
----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
Alarm ID Alarm Severity Alarm Type
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
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:
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
Transmission System Configuration Guide manual.
2. If not, re-enable the RSVP protocol and check whether the GSP_RSVP_NB_DOWN
alarm is cleared.
l Cause 2: The physical link is faulty.
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.
l Cause 3: The board is faulty.
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
Alarm ID Alarm Severity Alarm Type
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:
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.
l Cause 2: The physical link is faulty.
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.
l Cause 3: The board is faulty.
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
Alarm ID Alarm Severity Alarm Type
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 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 0x24: The 66M clock fails.
l 0x25: The 25M 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
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:
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.
l Cause 3: The board is faulty.
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,
refer to 5 Replacing Components.
----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
Alarm ID Alarm Severity Alarm Type
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:
Handling Procedure
l Cause 1: The IMA protocol is not enabled on the local NE.
1. Check the configuration of the IMA group at the two ends and ensure that the IMA
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
minimum number of the enabled links in the IMA group.
1. On the T2000, check whether there is the ALM_IMA_LIF alarm. For details, refer to
8.2 Querying Current Alarms of a Board.
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
----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
Alarm ID Alarm Severity Alarm Type
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:
Handling Procedure
l Cause 1: The IMA protocol is not enabled on the remote NE.
1. Check the configuration of the IMA group at the two ends and ensure that the IMA
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
minimum number of the enabled links in the IMA group.
1. On the T2000, check whether there is the ALM_IMA_RIF alarm. For details, refer to
8.2 Querying Current Alarms of a Board.
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
Alarm ID Alarm Severity Alarm Type
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:
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
Alarm ID Alarm Severity Alarm Type
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
whether the alarm is cleared.
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
Alarm ID Alarm Severity Alarm Type
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
Alarm ID Alarm Severity Alarm Type
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
Name Meaning
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
Querying Current Alarms of a Board.
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.
l Cause 4: Loopback is set on the port.
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
Alarm ID Alarm Severity Alarm Type
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
Alarm ID Alarm Severity Alarm Type
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:
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
services are interrupted.
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
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.
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.
l Cause 2: The equipment is faulty.
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.
2. If yes, cold-reset the board that reports the hardware-related alarm and check whether
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
Alarm ID Alarm Severity Alarm Type
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 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.
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.
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.
----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
Alarm ID Alarm Severity Alarm Type
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 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.
No Go to the next step.
If... Then...
Yes Replace the IF cables.
No Go to the next step.
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
replaced is complete.
The alarm persists after the board is Go to the next step.
replaced
----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
Alarm ID Alarm Severity Alarm Type
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
services are interrupted.
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:
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
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.
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 LMFA alarm is cleared.
l Cause 2: The equipment is faulty.
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.
2. If yes, cold-reset the board that reports the hardware-related alarm and check whether
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
Alarm ID Alarm Severity Alarm Type
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
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 1: Loopback is set on the port.
l Cause 2: Loops exists in the service.
Handling Procedure
l Cause 1: Loopback is set on the port.
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.
----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
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
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
l Cause 1: The laser is aged.
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
Alarm ID Alarm Severity Alarm Type
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.
For details, refer to 5.9 Replacing the Pluggable Optical Module.
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
Alarm ID Alarm Severity Alarm Type
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 1: The laser is aged.
l Cause 2: The detection circuit of the board is faulty.
Handling Procedure
l Cause 1: The laser is aged.
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
Alarm ID Alarm Severity Alarm Type
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
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
Configuration Guide manual.
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
Alarm ID Alarm Severity Alarm Type
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:
Handling Procedure
l Cause 1: The line signals degrade.
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
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
Name Meaning
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:
Handling Procedure
l Cause 1: The line signals degrade.
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
RTN 950 Radio Transmission System Configuration Guide manual.
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
Transmission System Configuration Guide manual.
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
Alarm ID Alarm Severity Alarm Type
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.
l Cause 4: The physical link is interrupted.
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.
l Cause 4: The physical link is interrupted.
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
Alarm ID Alarm Severity Alarm Type
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
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:
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
Alarm ID Alarm Severity Alarm Type
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
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.
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.
l Cause 3: The misconnection occurs on the physical link.
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
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
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:
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
Alarm ID Alarm Severity Alarm Type
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
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:
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.
l Cause 3: The physical link is faulty.
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.
l Cause 4: The network is severely congested.
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
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
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.
l Cause 2: The misconnection occurs on the physical link.
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.
l Cause 2: The misconnection occurs on the physical link.
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.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
Alarm ID Alarm Severity Alarm Type
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
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.
l Cause 2: The misconnection occurs on the physical link.
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
whether the alarm is cleared.
l Cause 2: The misconnection occurs on the physical link.
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.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
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
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:
Handling Procedure
l Cause 1: The service bit error ratio is excessively high.
1. On the T2000, check whether the MAC_FCS_EXC alarm occurs. For details, refer to
8.2 Querying Current Alarms of a Board.
2. If yes, clear the MAC_FCS_EXC first, and then check whether the
MPLS_TUNNEL_SD alarm is cleared.
l Cause 2: No bandwidth is available.
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.
l Cause 3: Other anomalies occur on the carrier layer.
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
Alarm ID Alarm Severity Alarm Type
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
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:
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
l Cause 1: The service bit error ratio is excessively high.
1. On the T2000, check whether the MAC_FCS_EXC alarm occurs. For details, refer to
8.2 Querying Current Alarms of a Board.
2. If yes, clear the MAC_FCS_EXC first, and then check whether the
MPLS_TUNNEL_SD alarm is cleared.
l Cause 2: No bandwidth is available.
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.
l Cause 3: Other anomalies occur on the carrier layer.
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
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
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
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 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.
No Go to the next step.
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
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 Indicates the ID of the IF 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 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.
No Go to the next step.
----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
Alarm ID Alarm Severity Alarm Type
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 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.
Step 3 Check whether the receive/transmit frequencies at the local end are consistent with those at the
remote end.
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
Alarm ID Alarm Severity Alarm Type
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 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 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
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 Indicates the IF port that reports the alarm. For example, 0x01 indicates that the
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
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 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
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
Alarm ID Alarm Severity Alarm Type
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 2, Parameter 3 Indicates the number of the inconsistent file on the system control
boards.
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.
l Cause 3: 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.
Handling Procedure
l Cause 1: The versions of the files in the working and the protection areas of a single system
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.
2. Reload the correct software. For details, refer to 6 Software Package Upgrade and
Package Diffusion.
3. If the alarm persists, replace the board with the incorrect software version. For details,
refer to 5 Replacing Components.
l Cause 3: 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.
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.
2. Reload the correct software. For details, refer to 6 Software Package Upgrade and
Package Diffusion.
3. If the alarm persists, replace the board with the incorrect software version. For details,
refer to 5 Replacing Components.
----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
Alarm ID Alarm Severity Alarm Type
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 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
Alarm ID Alarm Severity Alarm Type
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.
l Cause 2: The CXPR board is faulty.
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
the alarm is cleared.
l Cause 2: The CXPR board is faulty.
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
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:
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.
l Cause 2: The board is faulty.
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
Alarm ID Alarm Severity Alarm Type
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
Alarm ID Alarm Severity Alarm Type
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
Alarm ID Alarm Severity Alarm Type
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
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:
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
Alarm ID Alarm Severity Alarm Type
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
Parameters
Name Meaning
Name Meaning
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
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 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.
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
Alarm ID Alarm Severity Alarm Type
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
Configuration Guide manual.
2. If not, modify the configuration to make it consistent at the two ends. Then, check
whether the alarm is cleared.
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
Configuration Guide manual.
2. If yes, re-configure the tunnel with a bigger bandwidth. Then, check whether the alarm
is cleared.
l Cause 3: the physical link is interrupted.
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
Alarm ID Alarm Severity Alarm Type
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.
l Cause 3: the physical link is interrupted.
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
Configuration Guide manual.
2. If yes, re-configure the tunnel with a bigger bandwidth. Then, check whether the alarm
is cleared.
l Cause 3: the physical link is interrupted.
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
Alarm ID Alarm Severity Alarm Type
Parameters
ID Name
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 2: The network is severely congested.
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.
l Cause 5: The board 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.
l Cause 2: The network is severely congested.
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.
l Cause 4: The optical module is faulty.
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
Querying Current Alarms of a Board.
2. If yes, replace the faulty optical module. For details, refer to 5.9 Replacing the
Pluggable Optical Module.
l Cause 5: The board is faulty.
1. On the T2000, check whether the hardware-related alarms occur on the board of the
two NEs, 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.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
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 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 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.
If... Then...
The alarm persists Replace the local board that reports the R_LOC alarm.
The alarm disappears Go to the next step.
If... Then...
The alarm disappears after the board is The fault is rectified, and the alarm handling
replaced is complete.
The alarm persists after the board is Go to the next step.
replaced
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
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 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.
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.
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
Alarm ID Alarm Severity Alarm Type
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 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.
Yes Go to the next step.
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.
Yes Go to the next step.
Step 4 Check whether the polarization direction of the antenna, ODU, and hybrid coupler is correctly
set.
If... Then...
No Correct the polarization direction.
Yes Go to the next step.
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.
No Go to the next step.
Step 6 Check whether the antenna gain at both the transmit and receive sides meets the requirement.
If... Then...
No Replace the antenna.
Yes Go to the next step.
If... Then...
Yes Contact the network planning department to change the design to avoid mountain or
building interference.
No Go to the next step.
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
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 Indicates the RF port that reports the alarm.
Impact on System
The service transmission is affected. If the system is configured with 1+1 protection, protection
switching may be triggered.
Possible Causes
l The ODU is faulty.
l There is a strong interference source nearby.
Handling Procedure
Step 1 Replace the ODU.
If... Then...
The alarm disappears after the ODU is The fault is rectified, and the alarm handling
replaced is complete.
The alarm persists after the ODU is replaced Go to the next step.
----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
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 Indicates the RF port that reports the alarm.
Impact on System
The service transmission is affected. If the system is configured with 1+1 protection, protection
switching may be triggered.
Possible Causes
The ODU is faulty.
Handling Procedure
Step 1 Replace the ODU.
----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
Alarm ID Alarm Severity Alarm Type
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 Indicates the RF port that reports the alarm.
Impact on System
The service transmission is affected. If the system is configured with 1+1 protection, protection
switching may be triggered.
Possible Causes
The ODU is faulty.
Handling Procedure
Step 1 Replace the ODU.
----End
Related Information
None.
9.3.99 RADIO_MUTE
Description
The RADIO_MUTE is an alarm indicating that radio transmitter is muted.
Attribute
Alarm ID Alarm Severity Alarm Type
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 Indicates the RF port that reports the alarm.
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.
No Go to the next step.
If... Then...
Yes Handle the CONFIG_NOSUPPORT alarm.
No Go to the next step.
----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
Alarm ID Alarm Severity Alarm Type
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
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
Alarm ID Alarm Severity Alarm Type
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
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
alarm will be cleared automatically.
Possible Causes
The cause of the RELAY_ALARM_MAJOR alarm is as follows:
Handling Procedure
l Cause: There is a major 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_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
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
Impact on System
l When the RELAY_ALARM_MINOR 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 minor alarm on the equipment, this
alarm will be cleared automatically.
Possible Causes
The cause of the RELAY_ALARM_MINOR alarm is as follows:
Handling Procedure
l Cause: There is a minor 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_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
Alarm ID Alarm Severity Alarm Type
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
Impact on System
l When the RELAY_ALARM_IGNORE 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 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.
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_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
Alarm ID Alarm Severity Alarm Type
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 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
Alarm ID Alarm Severity Alarm Type
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
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:
Handling Procedure
l Cause 1: The external BITS clock 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 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
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 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
Alarm ID Alarm Severity Alarm Type
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
Alarm ID Alarm Severity Alarm Type
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:
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
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.
l Cause 2: The system control board is faulty.
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.
l Cause 2: The system control board is faulty.
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
Alarm ID Alarm Severity Alarm Type
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:
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
Alarm ID Alarm Severity Alarm Type
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:
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
Alarm ID Alarm Severity Alarm Type
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
Software Package Upgrade and Package Diffusion.
----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
Alarm ID Alarm Severity Alarm Type
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
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
Alarm ID Alarm Severity Alarm Type
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
Alarm ID Alarm Severity Alarm Type
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:
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
RTN 950 Radio Transmission System Configuration Guide manual.
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
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:
Handling Procedure
l Cause 1: The external clock 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 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
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:
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
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
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
Alarm ID Alarm Severity Alarm Type
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
Querying Current Alarms of a Board.
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
Alarm ID Alarm Severity Alarm Type
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.
Possible Causes
The cause of the SYNC_LOCKOFF alarm is as follows:
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
Alarm ID Alarm Severity Alarm Type
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
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
Alarm ID Alarm Severity Alarm Type
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:
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
Alarm ID Alarm Severity Alarm Type
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
services are interrupted.
Possible Causes
The possible causes of the TEM_HA alarm are as follows:
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.
l Cause 2: The optical module is faulty.
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,
refer to 5 Replacing Components.
----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
Alarm ID Alarm Severity Alarm Type
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
services are interrupted.
Possible Causes
The possible causes of the TEM_LA alarm are as follows:
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.
l Cause 2: The optical module is faulty.
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,
refer to 5 Replacing Components.
----End
Related Information
None.
9.3.125 TEMP_ALARM
Description
The TEMP_ALARM is an alarm indicating that the temperature crosses the threshold.
Attribute
Alarm ID Alarm Severity Alarm Type
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 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.
Yes Go to the next step.
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
Alarm ID Alarm Severity Alarm Type
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
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.
l Cause 4: The board is faulty.
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
Alarm ID Alarm Severity Alarm Type
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:
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.
l Cause 2: The board is faulty.
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
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 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.
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
Alarm ID Alarm Severity Alarm Type
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:
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.
l Cause 3: The board is faulty.
1. On the T2000, check whether there is any hardware-related alarm on the two NEs,
such as the HARD_BAD alarm.
2. If yes, cold-reset the board that reports the hardware-related alarm and check whether
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
Alarm ID Alarm Severity Alarm Type
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
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.
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.
l Cause 2: The board on the local NE is faulty.
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,
refer to 5 Replacing Components.
----End
Related Information
Unidirectional connection
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.
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
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
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.
l Cause 2: The board on the local NE is faulty.
Handling Procedure
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.
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
the alarm is cleared.
l Cause 3: The board on the local NE is faulty.
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
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
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
Querying Current Alarms of a Board.
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.
l Cause 2: The ATM processing chip of the board is faulty.
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,
refer to 5 Replacing Components.
----End
Related Information
Unidirectional connection
A complete bidirectional connection is divided into a forward unidirectional connection and a
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
entire virtual connection.
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
Alarm ID Alarm Severity Alarm Type
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 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 lightning alarm Contact the engineers to provide power
supply and to check whether lightning
protection is provided.
Step 4 Check the IF jumper, IF cable, or ODU section by section for a short circuit.
If... Then...
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
Alarm ID Alarm Severity Alarm Type
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
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.
l Cause 2: The board on the local NE is faulty.
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,
refer to 5 Replacing Components.
----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.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
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
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 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.
l Cause 2: No bandwidth is available on the local NE and thus the CC cells cannot be received.
l Cause 3: The board on the local NE is faulty.
Handling Procedure
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.
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
the alarm is cleared.
l Cause 2: No bandwidth is available on the local NE and thus the CC cells cannot be received.
1. On the T2000, check whether the bandwidth configured to the tunnel is fully used.
For details, refer to the OptiX RTN 950 Radio Transmission System Configuration
Guide manual.
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.
l Cause 3: The board on the local NE is faulty.
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
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
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.
l Cause 2: The ATM processing chip of the board is faulty.
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
Querying Current Alarms of a Board.
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.
l Cause 2: The ATM processing chip of the board is faulty.
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,
refer to 5 Replacing Components.
----End
Related Information
Unidirectional connection
An end point refers to the termination point in the chain network, and it is used to monitor the
entire virtual connection.
The segment point is, generally, used to monitor a segment of the whole link.
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.
l Cause 2: The board is faulty.
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.
l Cause 2: The board is faulty.
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.
10 Performance Event
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).
Whether to No
enable the performance End
monitoring?
Yes
No
Whether to
enable the automatic
reporting?
Yes
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
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.
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.
l PW performance event
l MP performance event
l PPP performance event
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.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
Impact on System
None.
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
Performance Event ID Performance Event Type
Impact on System
None.
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
Performance Event ID Performance Event Type
Impact on System
None.
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
Performance Event ID Performance Event Type
Impact on System
None.
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
Performance Event ID Performance Event Type
Impact on System
None.
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
Performance Event ID Performance Event Type
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.
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
Performance Event ID Performance Event Type
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.
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 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
Performance Event ID Performance Event Type
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.
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 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
Performance Event ID Performance Event Type
Impact on System
None
Related Alarms
None
Procedure
None
Related Information
None
10.3.10 MEMUSAGEMAX
Description
The MEMUSAGEMAX performance event indicates the maximum memory usage ratio.
Attribute
Performance Event ID Performance Event Type
Impact on System
None
Related Alarms
None
Procedure
None
Related Information
None
10.3.11 MEMUSAGEMIN
Description
The MEMUSAGEMIN performance event indicates the minimum memory usage ratio.
Attribute
Performance Event ID Performance Event Type
Impact on System
None
Related Alarms
None
Procedure
None
Related Information
None
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
Unit -
Impact on System
None.
Related Alarms
None.
Unit 0.1ºC
Relevant Alarm
If the board temperature crosses the threshold, the TEMP_ALARM alarm occurs.
Relevant Alarm
If the receive power crosses the threshold, the RADIO_RSL_HIGH or RADIO_RSL_LOW
alarm occurs.
Relevant Alarm
If the transmit power crosses the threshold, the RADIO_TSL_HIGH or
RADIO_TSL_LOW alarm can occur.
Attribute
Attribute Description
Unit Second
Impact on System
None.
Related Alarms
None.
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.
----End
Relevant Alarms
If any byte cannot be troubleshooted, the MW_FECUNCOR alarm occurs.
Description
l QPSKWS: Indicates the working time of the QPSK mode.
l QAMWS16: Indicates the working time of the 16QAM mode.
l QAMWS32: Indicates the working time of the 32QAM mode.
l QAMWS64: Indicates the working time of the 64QAM mode.
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.
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.
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.
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.
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.
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.
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
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
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
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
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
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
VC3 Virtual Container -3
VC-3 Virtual Container -3
W
WAN Wide Area Network
WRR Weighted Round Robin
WTR Wait to Restore Time
X
XPD Cross-Polarization Discrimination
XPIC Cross-polarization interference cancellation