Handling Common Faults and Alarms for Huawei RTN Microwaves

Handling Common Faults
and Alarms on the RTN
Network
2011-5-5
A

Contents Page 2
Locating Faults of TDM Services
3
Process of Locating Common Faults
1
Locating Faults of Packet Services
4
Locating Faults of Protection Schemes
5
Locating Clock Faults
6
Locating Link Faults
2
Locating DCN Faults
7
Locating Other Faults
8
Handling Common Alarms
9
Typical Cases of Fault Locating
10
Reference Documents
11

Page 3
Check alarms.
Start
Check service flows and
locate faults.
Check black box, errlog,
debugbuf, dopra records.
Check key
configurations.
Collect data.
End
Record network configurations,
operation procedures, fault symptoms,
and time points of key events.

Page 4
1. Check the flow of services, including service add/drop nodes, network topologies, and
configuration of convergence NEs.
2. Check the time when service interruption occurs and the triggered events, the time when
services recover and the triggered events.
3. Check current and historical alarms and current and historical 15-minute and 24-hour events
reported by the NMS and NEs.
4. Check black box records, errlog records, debugbuf logs, and dopra logs.
5. Check records of manual operations, operation records on the NMS, and oplog records on
NEs. Check version information, NE configuration, and board configuration.
6. Collect fault information by using specific tools.

Contents Page 5
3
1
4
5
6
2
Locating DCN Faults
7
8
9
10
Reference Documents
11

Locating Faults of Microwave Links -
Common Locating Process
Page 6
Start
Go to the next
step.
End
Locate faults by
performing loopbacks.
Are there any
wrong
operations?
1
2
Is Tx power
normal?
Is Rx power lower
than normal?
Fading causes
abnormal Rx power?
Are links faulty
unidirectionally?
7
Faults are
rectified?
Handle the fault.
6
Handle the fault.
5
Handle the fault.
4
Handle the fault.
3
Handle alarms.
Perform rollbacks.
No
Yes
No
Yes
No
No
No
No
No
Yes
Yes
Yes
Yes
Are there any
ODU or IF board
faults?

Common Symptoms and Causes
Page 7
Fault Type Common Cause
Tx power is abnormal. The ODU is faulty.
Rx power is always lower than normal
value.
1. Antennas are not aligned.
2. Antennas have different polarization directions.
3. Transmission is blocked by mountains or buildings.
4. Antennas malfunction or the connection between antennas
and ODUs is faulty, such as wet waveguide interface and
loosely-installed flexible waveguide.
5. The ODU is faulty.
Slow up-fading causes abnormal Rx power. There is external interference.
Slow down-fading causes abnormal Rx
power.
Fading margin is insufficient.
Fast fading causes abnormal Rx power. Multipath fading is severe.
Rx power is normal, but the microwave link
is faulty unidirectionally.
There is external interference.

Handling Method
Page 8
Handling Procedure Handling Method
1. Check for incorrect
operations.
Focus on:
1.Whether the ODU is powered off
2.Whether the ODU is muted
3.Whether a loopback is performed on the IF board
4.Whether the configuration is consistent at the two ends
5.Whether the configuration matches the models of ODUs and combiners
6.Whether the E1 capacity is consistent at the two ends for the Hybrid
microwave

Handling Method
Page 9
2. Handle equipment faults. Focus on:
VOLT_LOS
CONFIG_NOSUPPORT
HARD_BAD
TEMP_ALARM
IF_INPWR_ABN
RADIO_MUTE
RADIO_TSL_HIGH
RADIO_TSL_LOW
RADIO_RSL_HIGH
IF_CABLE_OPEN
3. Handle abnormal Tx power. Replace the ODU.

Handling Method
Page 10
4. Handle lower-than-
normal Rx power.
1. If Rx power declines rapidly and remains lower than normal, check the installation of
antennas and ensure that the azimuth of antennas meets the planning requirements.
2. Check the antenna direction. Especially, check whether the received signal is from
the main lobe.
3. If antennas are not aligned, align antennas.
4. On a 1+1 HSB microwave link, if the Rx power difference between the active and
standby ODUs at one end is higher than 9 dB (for non-balanced combiners) or 5 dB
(for balanced combiners), perform 1+1 switching or replace ODUs/combiners to
determine the faulty component.
5. If the RSL difference between the two ends is higher than 10 dB, replace ODUs to
determine the faulty component.
6. Check the polarization directions of antennas and adjust the incorrect polarization
direction.
7. Replace ODUs/combiners to determine the faulty component.
8. Check whether transmission is blocked by any mountains or buildings.
9. Check the antenna gain at the two ends and replace the antennas that do not
provide required antenna gain.

Handling Method
Page 11
5. Handle fading. To handle down-fading:
•Increase the installation heights of antennas.
•Reduce the transmission distance.
•Increase the antenna gain.
•Increase Tx power.
To handle fast fading:
Contact the network planning department for appropriate plan changes, such as:
•Adjust the position of the antenna to block the reflected wave or make the reflection
point fall on the ground that has a small reflection coefficient, reducing multipath fading.
•Configure 1+1 SD for microwave links.
•For microwave links with 1+1 SD, adjust the height difference between two antennas to
make one's Rx power higher than the other's Rx power.
•Increase fading margins by using larger-diameter antennas or raising antennas' Tx
power.
To handle up-fading:
•Check for co-channel interference.
•Use a spectrum analyzer to analyze interference sources.
•Contact the spectrum management department for clearing the interference spectrum,
or change plans to minimize the interference.

Handling Method
Page 12
Handling
Procedure
Handling Method
6. Handle
interference.
1. Check for co-channel interference.
2. Check for adjacent channel interference.
3. Use a spectrum analyzer to analyze interference sources.
4. Contact the spectrum management department for clearing the
interference spectrum, or change plans to minimize the interference.
7. Locate faults by
performing
loopbacks.
1. Perform an inloop on the IF port.
2. Replace the IF board if the fault persists.
3. Check cable connectors and redo the substandard ones.
4. Check IF cables and replace those that are soggy, broken, or pressed.
5. Replace the ODU.
6. If the fault is rectified after replacement, you can infer that the ODU is
faulty.

Common Alarms
Page 13
 The CONFIG_NOSUPPORT is an alarm indicating that the configuration is not supported.
Possible Causes
 Cause 1: The model and configuration parameters of the ODU do not meet the requirements.
 Cause 2: On Hybrid microwave links, the configured ODU's Tx power is beyond the allowed range. (On
Hybrid microwave links, which are composed of IFH2 boards, the maximum Tx power of ODUs is
determined by the IF modulation mode and AM enabling status.)
Handling Procedure
Cause 1: The model and configuration parameters of the ODU do not match the requirements.
 Check the alarm parameters to determine the configuration parameters that do not meet the requirements.
 If the alarm parameter is 0x01-0x03, check whether the configuration parameters of the ODU port meet
the requirements of network planning.
 If the alarm parameter is 0x04-0x06, check whether the configuration parameters of the IF port meet the
requirements of network planning. If not, change the parameter settings.

Common Alarms
Page 14
 The RADIO_RSL_LOW is an alarm indicating that the RSL is over low.
Possible Causes
 Cause 1: Certain other alarms occur at the opposite site.
 Cause 2: The opposite Tx power is over low.
 Cause 3: Signal attenuation on the microwave link is heavy.

Common Alarms
Page 15
Handling Procedure
 Cause 1: Certain other alarms occur at the opposite site. Check whether any of the following
alarms is reported at the opposite site. If yes, clear the alarm immediately.
 RADIO_MUTE
 CONFIG_NOSUPPORT
 RADIO_TSL_LOW
 BD_STATUS
 Cause 2: The opposite Tx power is over low.
 Check whether the opposite Tx power is normal. If not, replace the opposite ODU.
 Check whether the opposite NE is powered off.

Common Alarms
Page 16
 Cause 3: Signal attenuation on the microwave link is heavy.
 Check whether the alarm is repeatedly reported among historical alarms. If the
alarm is reported occasionally, contact the network planning department for
improving anti-fading performance.
 Check whether the antennas at both ends are aligned. If not, realign the antennas.
 Check whether transmission is blocked by any mountains or buildings. If yes,
contact the network planning department for avoiding the block.
 Check whether the polarization direction is set correctly for the antennas, ODUs,
and combiners at both ends. If not, correct the polarization direction.
 Check whether the outdoor units such as antennas, combiners, ODUs, and
flexible waveguides are wet, damp, or damaged. If yes, replace the faulty
component.
 Check the antenna gain at the two ends and replace the antennas that do not
provide required antenna gain.

Common Alarms
Page 17
 The MW_LOF is an alarm indicating the loss of microwave frames.
Possible Causes
 Cause 1: The microwave link performance degrades.
 Cause 2: The IF working mode of the local site is different from that of the
opposite site.
 Cause 3: The operating frequency of the local ODU is different from that of
the opposite ODU.
 Cause 4: The transmit unit of the opposite site is faulty.
 Cause 5: The receive unit of the local site is faulty.
Handling Procedure
See "Handling Faults of Microwave Links."

Common Alarms
Page 18
 The MW_FECUNCOR is an alarm indicating that uncorrectable errors
exist in the forward error correction (FEC) coding of microwave frames.
Possible Causes
 Cause 1: The receive power of the ODU is abnormal.
 Cause 2: The transmit unit of the opposite site is faulty.
 Cause 3: The receive unit of the local site is faulty.
 Cause 4: Interference exists.
Handling Procedure
See "Handling Faults of Microwave Links."

Common Alarms
Page 19
 The HARD_BAD is an alarm indicating hardware errors.
Possible Causes
 Cause 1: Clock tracing is looped.
 Cause 2: The alarmed board has hardware errors.
Handling Procedure
Cause 1: Clock tracing is looped.
 Check the alarm parameter. The value 0x06 indicates that clock signals
are interlocked and therefore the timing loop needs to be cleared.
Cause 2: The alarmed board has hardware errors.
 Replace the alarmed board.

Common Alarms
Page 20
 The BD_STATUS is an alarm indicating that the board cannot be detected.
Possible Causes
Cause 1: If the IDU reports the alarm, the possible causes are as follows:
 The board is installed in an incorrect slot.
 The board and the backplane are connected incorrectly.
 The slot that houses the board is faulty.
 The board is faulty.
Cause 2: If the ODU reports the alarm, the possible causes are as follows:
 Check whether the IF board reports the HARD_BAD, BD_STATUS,
IF_CABLE_OPEN, or VOLT_LOS alarm. If yes, clear the alarm immediately.
 The ODU is faulty. Replace the faulty ODU.

Common Alarms
Page 21
Handling Procedure
Cause 1: If the IDU reports the alarm, handle the alarm as follows:
Check whether the physical slot and logical slot of the alarmed board are
the same.
Re-install the alarmed board.
Install the board in another slot.
Replace the alarmed board.
Cause 2: If the ODU reports the alarm, handle the alarm as follows:
Check whether the alarm is caused by other alarms.
Replace the faulty ODU.

Locating Faults of Ethernet Links -
Page 22
Start
Any
laser
alarms?
Yes
No
No No
Yes
No No
No
No
Yes
Yes Yes
Yes
Yes
Yes
No
ETH
C- STM
MLPPP
E1 MLPPP
MW
Any ETH
physical-layer
alarms?
Any
laser
alarms?
Any alarms
on SDH
ports?
Any VC-12
alarms?
Any alarms
on E1 ports?
Any alarms
on IF ports?
Types of NNI
ports
No
physical-
layer
alarms
Handle
alarms.
Compute the boards and
physical links that
services traverse.
Any alarms on
the boards?
Reset or
replace
alarmed
boards.

Checking Alarms on Ethernet Links
Page 23
BTS 1 CES
CES
BTS 2
RTN
RTN
ETH
BTS 3
RTN
MPLS
RTN
RTN
MPLS
RTN
BSC
Core
network
RTN BSC
10G/GE
GE/FE
STM-1
STM-1
10G/GE
ETH_LOS
Loss of optical signals
Possible Causes
1. Fiber cuts 2. Faulty optical modules 3. Excessive optical attenuation
ETH_LINK_DOWN
Connection fault on
the network port
Possible Causes
1. Negotiation fails due to different working modes at the two ends. 2.
Electrical cables, fiber connections, or opposite units are faulty.
MAC_FCS_EXC
Excessive bit errors
Possible Causes
1. Excessive bit errors are detected at the MAC layer. 2. Line signals
degrade. 3. Fiber performance deteriorates. 4. Optical ports are dirty.

Common Alarms on Ethernet Ports (1)
Page 24
 The ETH_LOS is an alarm indicating loss of connection on Ethernet ports.
Possible Causes
 Cause 1: The electrical cable or fiber on the Ethernet port is incorrectly connected.
 Cause 2: The electrical cable or fiber on the Ethernet port is faulty.
 Cause 3: The local Rx power is over low.
 Cause 4: The alarmed board is faulty.
Handling Procedure
Cause 1: The electrical cable or fiber on the Ethernet port is incorrectly connected.
Verify that the electrical cable or fiber on the Ethernet port is correctly connected.
Cause 2: The electrical cable or fiber on the Ethernet port is faulty.
Replace the faulty electrical cable or fiber.
Cause 3: The local Rx power is over low.
Check for the OUT_PWR_ABN alarm on the opposite NE and clear the alarm immediately if it is reported. If
the alarm persists then, clean the receive optical port and fiber connector. If the alarm persists then, verify
that the flange and optical attenuator are used correctly. If the alarm persists then, add or remove optical
attenuators to achieve normal Rx power.
Cause 4: The alarmed board is faulty.
Replace the alarmed board. If the alarm persists, replace the mapping board at the opposite end.

Page 25
 The ETH_LINK_DOWN is an alarm indicating that the connection on the network port is faulty.
Possible Causes
 Cause 1: Negotiation fails due to different working modes at the two ends.
 Cause 2: An inloop is performed on the port.
 Cause 3: The fiber is connected to an incorrect port.
 Cause 4: A certain board is faulty.
Handling Procedure
Cause 1: Negotiation fails due to different working modes at the two ends.
Verify that the working modes are the same at the two ends.
Cause 2: An inloop is performed on the port.
Check for the LOOP_ALM alarm at the two ends and clear the alarm immediately if it is reported.
Cause 3: The fiber is connected to an incorrect port.
Check whether the fiber on the alarmed port is connected to an incorrect port. If yes, connect the fiber to a
correct port.
Cause 4: A certain board is faulty.
Check for hardware-related alarms (such as HARD_BAD) at the two ends and replace the board that reports
any of these alarms.

Page 26
 The MAC_FCS_EXC is an alarm indicating that excessive bit errors are detected at the MAC layer.
Possible Causes
 Cause 1: The line signals deteriorate.
 Cause 2: The input optical power is abnormal.
 Cause 3: The fiber connector is dirty.
Handling Procedure
Cause 1: The line signals deteriorate.
Check for the LOOP_ALM alarm on the NMS and clear the alarm immediately if it is reported. If the
alarm persists then, check for DOS attacks and eradicate any sources that transmit a large amount
of invalid data. If the alarm persists then, verify that the fiber and electrical cable are normal.
Cause 2: The input optical power is abnormal.
Check whether the alarmed port also reports IN_PWR_ABN. If yes, clear the IN_PWR_ABN alarm
immediately.
Cause 3: The fiber connector is dirty.
Clean the fiber connector and the receive optical port.

Checking Alarms on SDH Links
Page 27
BTS 1 CES
CES
BTS 2
RTN
RTN
ETH
BTS 3
RTN
MPLS
RTN
RTN
MPLS
RTN
BSC
Core
network
RTN BSC
GE
GE/FE
STM-1
STM-1
GE/10GE
R_LOS
Loss of optical
signals
Possible Causes
1. Fiber cuts 2. Excessive loss on the line 3. Malfunction of opposite transmit units
R_LOC
Loss of clock
Possible Causes
1. Failure in received signals 2. Malfunction of clock extraction modules
R_LOF
Loss of frame
Possible Causes
1. Excessive attenuation of received signals 2. Unframed structure of signals from the opposite site 3.
Malfunction of local receive units

Common Alarms on SDH Ports (1)
Page 28
 The R_LOS is an alarm indicating loss of signals on the receive side of the line.
Possible Causes
 Cause 1 of lasers: The local optical port is not used but the local laser is open.
 Cause 2 of lasers: The local laser is open but the opposite laser is closed, so there is no output of optical
signals.
 Cause 1 of fibers: No pigtail is connected to the local optical port or the pigtail on the local optical port is
connected incorrectly.
 Cause 2 of fibers: Fiber cuts occur.
 Cause 3 of fibers: Rx power is over low.
 Cause 1 of boards: The local receive board is faulty.
 Cause 2 of boards: The opposite transmit board is faulty.
Handling Procedure
Cause 1 of lasers: The local optical port is not used but the local laser is open.
Check the enabling status of the local laser on the NMS and close the laser if it is open.
Cause 2 of lasers: The local laser is open but the opposite laser is closed, so there is no output of optical
signals.
Check the enabling status of the opposite laser on the NMS and open the laser if it is closed.

Page 29
Handling Procedure
Cause 1 of fibers: No pigtail is connected to the local optical port or the pigtail on the local optical port
is connected incorrectly.
Verify that the pigtail on the local optical port is correctly connected.
Cause 2 of fibers: Fiber cuts occur.
Replace broken fibers.
Cause 3 of fibers: Rx power is over low.
Check for the OUT_PWR_ABN alarm on the opposite transmit port and clear the alarm immediately if
it is reported. If the alarm persists then, clean the receive optical port and fiber connector. If the
alarm persists then, verify that the flange and optical attenuator are used correctly. If the alarm
persists then, add or remove optical attenuators to achieve normal Rx power.
Cause 1 of boards: The local receive board is faulty.
If the local Rx power is normal, set an inloop for the local receive port. If the alarm persists, the local
board is faulty and needs to be replaced.
Cause 2 of boards: The opposite transmit board is faulty.
Replace the opposite transmit board. If the alarm persists, replace the opposite
cross- connect board.

Page 30
 The R_LOF is an alarm indicating loss of frames on the receive side of the line.
Possible Causes
 Cause 1: Different types of optical modules are used at the two ends.
 Cause 2: The receive power of the ODU is abnormal.
 Cause 3: Fibers are misconnected.
 Cause 4: The signals transmitted from the opposite site do not have the frame structure.
 Cause 5: The local receive board is faulty.
Handling Procedure
Cause 1: Different types of optical modules are used at the two ends.
Verify that optical modules of one type are used at the two ends.
Cause 2: The receive power of the ODU is abnormal.
Check whether the alarmed port also reports IN_PWR_ABN. If yes, clear the IN_PWR_ABN alarm
immediately.

Page 31
Handling Procedure
Cause 3: Fibers are misconnected.
Verify that fibers are connected correctly.
Cause 4: The signals transmitted from the opposite site do not have the frame structure.
Check for the HARD_BAD alarm on the opposite transmit board and clear this alarm immediately if it
is reported.
Cause 5: The local receive board is faulty.
Check for the HARD_BAD alarm on the local receive board and clear this alarm immediately if it is
reported.

Checking Alarms on E1 Links
Page 32
BTS 1 CES
CES
BTS 2
RTN
RTN
ETH
BTS 3
RTN
MPLS
RTN
RTN
MPLS
RTN
BSC
Core
network
RTN BSC
GE/10GE
GE/FE
STM-1
STM-1
GE/10GE
T_ALOS
Loss of signals
Possible Causes
1. E1/T1 services are not received. 2. Fibers on the DDF-side E1/T1 output ports are
disconnected or loosely connected. 3. Fibers on local E1/T1 output ports are
disconnected or loosely connected. 4. A certain board is faulty. 5. The electrical cable is
faulty.
ALM_E1RAI
Far-end alarm indication
Possible Causes
Some alarms are reported on the opposite site.

Common Alarms on E1 Ports (1)
Page 33
 The T_ALOS is an alarm indicating loss of signals on E1 ports.
Possible Causes
 Cause 1: The opposite site does not transmit any E1 services.
 Cause 2: E1 cables are disconnected or loosely connected.
 Cause 3: The opposite equipment is faulty.
 Cause 4: The electrical cable is faulty.
Handling Procedure
Cause 1: The opposite site does not transmit any E1 services.
Verify that the opposite site transmits E1 services properly.
Cause 2: E1 cables are disconnected or loosely connected.
Verify that E1 cables are correctly connected.

Page 34
Handling Procedure
Cause 3: The opposite equipment is faulty.
Perform a self-loop for the alarmed channel on the DDF side. If the alarm clears, the opposite
equipment is faulty and the fault needs to be rectified.
Cause 4: The electrical cable is faulty.
Perform a self-loop for the alarmed channel on the DDF side. If the alarm persists, perform a self-loop
for the alarmed channel on the interface board side. If the alarm clears, the E1 cable is faulty and
needs to be replaced.
Perform a self-loop for the alarmed channel on the interface board side. If the alarm persists, set an
inloop for the alarmed channel on the NMS. If the alarm clears, the interface board is faulty and
needs to be replaced.

Page 35
 The UP_E1_AIS is an alarm indicating upstream E1 signals. This alarm is reported when the
upstream E1 signal is all 1s.
Possible Causes
 Cause 1: The opposite site reports the T_ALOS alarm.
 Cause 2: An inloop is set for the E1 port.
 Cause 3: Some boards are faulty.
Handling Procedure
Cause 1: The opposite site reports the T_ALOS alarm.
Check for the T_ALOS alarm on the opposite site and clear this alarm immediately if it is reported.
Cause 2: An inloop is set for the E1 port.
Check whether the E1 port reports the LOOP_ALM alarm on the NMS. If yes, release the inloop on the
E1 port.
Cause 3: Some boards are faulty.
On the NMS, check whether the local NE and the opposite NE report any hardware-related alarms
such as HARD_BAD. If yes, perform a cold reset for the boards that report hardware-related
alarms. If the alarm persists then, replace the boards that may be faulty.

Page 36
 The DOWN_E1_AIS is an alarm indication for downstream 2 Mbit/s signals. This alarm is reported
when the downstream E1 signal is all 1s.
Possible Causes
 Cause 1: The alarmed board also reports the UP_E1_AIS or T_ALOS alarm.
 Cause 2: Some boards are faulty.
Handling Procedure
Cause 1: The alarmed board also reports the UP_E1_AIS or T_ALOS alarm.
Check whether the alarmed board reports the UP_E1_AIS or T_ALOS alarm on the NMS. If yes, clear
the UP_E1_AIS or T_ALOS alarm immediately.
Cause 2: Some boards are faulty.
On the NMS, check whether the alarmed board and local cross-connect board report any hardware-
related alarms such as HARD_BAD. If yes, perform a cold reset for the boards that report
hardware-related alarms. If the alarm persists, replace the boards that may be faulty.

Common Alarms on Other Links (1)
Page 37
 The IN_PWR_ABN is an alarm indicating that the input optical power is abnormal.
Possible Causes
 Cause 1: The opposite transmit power is abnormal.
 Cause 2: The local receive power is higher than the upper threshold.
 Cause 3: The local receive power is lower than the lower threshold.
 Cause 4: The receive board is faulty.
Handling Procedure
Cause 1: The opposite transmit power is abnormal.
On the NMS, check whether the opposite site reports the OUT_PWR_ABN alarm. If yes, clear this alarm
immediately and check whether the IN_PWR_ABN is cleared. If the alarm persists, query the local
receive power and handle the alarm according to other causes.
Cause 2: The local receive power is higher than the upper threshold.
Add proper optical attenuators to the receive optical port and adjust the input optical power to a normal
value.

Page 38
Handling Procedure
Cause 3: The local receive power is lower than the lower threshold.
Verify that the bending radius of the pigtail on the local site is no smaller than 6 cm. If the alarm
persists, use proper optical attenuators and correctly connect the local optical module. If the
alarm persists, replace the optical module and clean the fiber connectors at the two ends.
Cause 4: The receive board is faulty.
Check whether the processing board and cross-connect board on the local site report any
hardware-related alarms such as HARD_BAD and TEMP_OVER. If yes, replace the boards
that report hardware-related alarms.

Page 39
 The OUT_PWR_ABN is an alarm indicating that the output optical power
is abnormal.
Possible Causes
 Cause 1: The output optical power is over high or over low.
Handling Procedure
Cause 1: The output optical power is over high or over low.
Replace the optical module of the alarmed port.
Replace the alarmed board.

Page 40
 The LOOP_ALM is an alarm of loopbacks.
Possible Causes
 Cause 1: The port is looped back.
 Cause 2: The service is looped back.
Handling Procedure
Cause 1: The port is looped back.
On the NMS, check whether the alarmed port is looped back. If yes, release the loopback.
Cause 2: The service is looped back.
On the NMS, check whether the service is looped back. If yes, release the loopback. For Ethernet
services, enable the automatic shutdown function for looped-back ports.

Page 41
 The FLOW_OVER is an alarm indicating the traffic received by the port is higher than the
threshold.
Possible Causes
 Cause 1: The traffic received by the port is higher than the preset threshold of the port.
Handling Procedure
Cause 1: The traffic received by the port is higher than the preset threshold of the port.
 Check whether the actual received traffic indicated by the alarm parameter is higher
than the port bandwidth. If yes, reduce the data transmitted by the opposite site.
 Configure the service on an unused port.

Contents Page 42
3
1
4
5
6
2
Locating DCN Faults
7
8
9
10
Reference Documents
11

Locating Faults of TDM Services -
Page 43
Start
Any equipment
alarms?
No
Yes
Yes
No
Yes
No
Yes
No
End
Yes
No
Yes
No
1
3
2
7
4
6
5
Any pointer
justifications?
Any alarms or
events related to
RS errors?
Any alarms or events
related to MS errors or
HOP errors?
Any alarms
related to LOP
errors?
Locate faults by
performing sectional
loopbacks.
Go to the
next step.
Faults are
rectified?
Handle alarms.
Handle pointer
justifications.
Handle RS errors on
SDH optical interface
boards.
Handle RS errors
on IF boards.
Handle RS errors on
STM-1 electrical
interface boards.
Handle MS errors
and HOP errors.
Handle LOP errors.
Process RS
errors on different
boards.
SDH optical
interface boards
IF boards
STM-1 electrical
boards

Page 44
Equipment faults 1. Over high board temperature causes bit errors.
2. Clock tracing fails and the upstream link clocks need to be checked.
3. The board reports the HARD_BAD alarm, and clock tracing needs to
be checked or some boards need to be replaced.
Regenerator section (RS)
errors
1. The line is faulty.
• On optical lines, optical power is abnormal, fiber performance
deteriorates, or fiber splice and fiber connectors are dirty.
• On STM-1 electrical lines, electrical cables deteriorate, grounding is
incorrect, or connectors are incorrectly connected.
• On microwave links, the MW_FEC_UNCOR or RPS_INDI alarm is
reported.
2. The line board fails.
3. The clock unit fails.
4. Clock quality deteriorates on the network.
5. Clock quality deterioration on the network causes pointer
justifications.

Page 45
There are multiplex section (MS)
errors and higher order path
(HOP) errors, but not RS errors.
1. The line board is faulty.
2. Clock quality deteriorates on the network.
3. Clock quality deterioration on the network causes pointer justifications.
4. Operating temperature on the line board is over high.
There are only lower order path
(LOP) errors.
1. The PDH service processing board or Ethernet service processing board
is faulty.
2. The cross-connect board is faulty.
3. The PDH service processing board or Ethernet service processing board
has over high working temperature.
4. The working temperature on the cross-connect board is over high.
5. Unstable power supply, incorrect grounding, or external interference exists.

Handling Method
Page 46
Procedure Handling Method
1. Handle alarms. Focus on:
TEMP_ALARM
SYN_BAD
HARD_BAD
MW_CFG_MISMATCH
2. Handle pointer
justifications.
1. Analyze and process clock alarms.
2. Ensure that the configuration is correct and fibers are correctly
connected.
3. Locate the sites with clock asynchronization by changing clock
configuration.
4. Replace the components with poor performance.

Handling Method
Page 47
4. Handle the RS errors
on the SDH optical
interface board.
1. Exchange the fiber cores in the transmit and receive directions on a
section of optical channel. If errors change after the fiber cores are
exchanged, the fibers are faulty or the equipment malfunctions at the two
ends.
2. If fibers are faulty, check whether the fiber from the equipment to the
optical distribution frame (ODF) and the fiber that is led out from the
telecommunications room are pressed, and whether any fiber connector is
dirty or damaged.
3. If the equipment at the two ends is faulty, locate the fault by performing
loopbacks on optical ports. If the fault persists after the loopback on a site,
the line board on the site is faulty.
4. If the equipment at the two ends is faulty, replace the alarmed board or
exchange the slots of the alarmed board and anther working SDH optical
interface board. If the alarm is still reported by the alarmed board, the
alarmed board is faulty.
5. Handle the RS errors
on the IF board.
1. Check for the MW_FEC_UNCOR and RPS_INDI alarms.
2. If any of these alarms is reported, clear the alarm immediately.
3. If none of these alarms is reported, replace the IF board.

Handling Method
Page 1
5. Handle the RS errors on the
STM-1 electrical interface
board.
1. Exchange the electrical cables in the receive and transmit directions. If errors
change after the exchange, the electrical cables are faulty or the equipment at
the two ends is faulty.
2. Check whether the electrical cables are grounded properly and whether the cable
connectors and cables are damaged.
3. If the equipment at the two ends is faulty, locate the fault by performing
loopbacks on electrical ports. If the fault persists after a loopback is performed on
a site, the line board on the site is faulty.
4. If the equipment at the two ends is faulty, replace the alarmed board or exchange
the slots of the alarmed board and anther working SDH electrical interface board.
If the alarm is still reported by the alarmed board, the alarmed board is faulty.
6. Handle the MS errors and
HOP errors.
1. Perform a loopback on the alarmed board.
2. If the alarm persists, replace the alarmed board.
3. If the alarm clears, replace the transmit line board, which corresponds to the
alarmed board.
4. If the alarm persists after board replacement, check for unstable power supply,
improper grounding, and external interference on the SDH electrical interface
board.

Handling Method
Page 2
7. Handle LOP
errors.
1. Replace PDH service processing boards, Ethernet
service processing boards, or cross-connect boards
along the overlapped route of errored services.
2. If the alarm persists after board replacement, check for
unstable power supply, improper grounding, and
external interference.

Common Alarms
Page 3
 The MW_CFG_MISMATCH is an alarm indicating a configuration mismatch on microwave links.
 Possible Causes
 Cause 1: The number of E1 signals is different on both ends of a microwave link (including the number of E1 signals
on the active page and the number of E1 signals on the standby page).
 Cause 2: The AM enabling is different on both ends of a microwave link.
 Cause 3: The IEEE 1588 overhead enabling is different on both ends of a microwave link.
 Cause 4: The modulation mode is different on both ends of a microwave link.
 Cause 5: The channel spacing is different on both ends of a microwave link.
 Handling Procedure
 Cause 1: The number of E1 signals is different on both ends of a microwave link.
Determine the possible cause of the alarm according to the alarm parameters. Then, check the configuration on both ends of
the microwave link. Ensure that the configuration is the same on both ends of the microwave link.

Contents Page 4
3
1
4
5
6
2
Locating DCN Faults
7
8
9
10
Reference Documents
11

Locating Faults of CES Services -
Page 5
Start
No
No
No
End
No
Yes
No
No
Yes
Yes
Yes
Yes
Yes No
No
No
HARD_BAD,
TEMP_OVER,
BUS_ERR, or
COMMUN_FAIL
occurs?
T_ALOS, R_LOS, or
LASER_MOD_ERR
occurs?
MPLS_TUNNEL_LO
CV occurs?
SYNC_C_LOS or
LTI occurs?
CES_LOSPKT_EXC or
CES_JTRUDR_EXC
occurs?
Board hardware errors
or inter-board
communication failure
Reset/Reseat/
Replace boards.
Signal loss or
degrade
Troubleshoot fibers,
optical modules, or
network cables.
Tunnel faults
Troubleshoot the
opposite equipment.
Loss of
synchronization
clock
Troubleshoot
clock faults.
Excessive errored
packets, lost
packets, or jitters
optical modules, and
connections.
Change network
configurations.
Faults are
rectified?
Contact Huawei
engineers.
Reset/Reseat/
Replace boards.
Troubleshoot the
opposite equipment.
Troubleshoot
physical links.

Locating Faults of CES Services - Common
Symptoms
Page 6
Symptom Alarm Reported
CES services are interrupted. HARD_BAD, TEMP_OVER, or BUS_ERR
COMMUN_FAIL
T_ALOS
UP_E1_AIS or DOWN_E1_AIS
R_LOS, LASER_MOD_ERR, or IN_PWR_ABN
MPLS_TUNNEL_LOCV

Locating Faults of CES Services - Common
Symptoms
Page 7
CES services have errors and the
signal quality degrades.
HARD_BAD, TEMP_OVER, or BUS_ERR
SYNC_C_LOS or LTI
CES_LOSPKT_EXC, CES_MISORDERPKT_EXC, CES_STRAYPKT_EXC,
CES_MALPKT_EXC, CES_JTRUDR_EXC, or CES_JTROVR_EXC
LSR_WILL_DIE, IN_PWR_ABN, TEM_HA, or LSR_BCM_ALM

Locating Faults of CES Services -
Common Causes
Page 8
Cause 1: The board carrying CES services cannot work properly due to hardware errors, over-
high temperature, or inter-board communication failure.
Cause 2: The signal transmitted to the processing board or interface board is lost or degrades.
Cause 3: The tunnel or PW carrying CES services is interrupted.
Cause 4: On the NE, the priority of synchronization clock source is lost, or the synchronization
clock source is lost.
Cause 5: On the PW carrying CES services, the number of lost packets, errored packets, or
jitters within a time unit crosses the threshold.

Locating Faults of CES Services - Handling
Method
Page 9
Cause 1: The board carrying CES services cannot work properly due to hardware errors, over-high temperature, or inter-board
communication failure.
Handle the HARD_BAD, TEMP_OVER, COMMUN_FAIL, or BUS_ERR alarm if any of them is reported.
Cause 2: The signal transmitted to the processing board or interface board is lost or degrades.
Handle the T_ALOS, UP_E1_AIS, DOWN_E1_AIS, R_LOS, LASER_MOD_ERR, LSR_WILL_DIE, IN_PWR_ABN,
TEM_HA, or LSR_BCM_ALM alarm if any of them is reported.
Cause 3: The tunnel or PW carrying CES services is interrupted.
Enable MPLS OAM. Handle the MPLS_TUNNEL_LOCV alarm if it is reported.
Cause 4: On the NE, the priority of synchronization clock source is lost, or the synchronization clock source is lost.
Handle the SYNC_C_LOS or LTI alarm if any of them is reported.
Cause 5: On the PW carrying CES services, the number of lost packets, errored packets, or jitters within a time unit crosses the
threshold.
Handle the CES_LOSPKT_EXC, CES_MISORDERPKT_EXC, CES_STRAYPKT_EXC, CES_JTRUDR_EXC, or
CES_JTROVR_EXC alarm if any of them is reported.

Common Alarms of CES Services (1)
Page 10
 The CES_JTROVR_EXC/CES_JTRUDR_EXC is an alarm indicating the overflow/underflow of CES jitters.
 Possible Causes
 Cause 1: Clock synchronization cannot be performed.
 Cause 2: Link quality deteriorates, causing more jitters.
 Cause 3: The size of buffer area is set to a low value.
 Cause 4: There are too many hops of microwave link on the network side, which generates a large number of jitters.
 On the NMS, check whether the LTI or other clock alarms are reported. If yes, clear these alarms.
 Cause 2: Link quality deteriorates, causing more jitters.
 Check whether the alarmed port also reports IN_PWR_ABN or TEM_HA. If yes, clear the IN_PWR_ABN or TEM_HA alarm immediately.
 Cause 3: The size of buffer area is set to a low value.
 On the NMS, increase the size of buffer area if possible.
 Cause 4: There are too many hops of microwave link on the network side, which generates a large number of jitters.
 Reduce the number of hops on the network side.

Page 11
 The CES_LOSPKT_EXC is an alarm indicating packet loss of CES services.
 Possible Causes
 Cause 2: Parameter settings are different at the two ends of CES services.
 Cause 3: The tunnel or PW carrying CES services is congested.
 Cause 4: The link signal deteriorates or is interrupted due to a fault of cables, optical fibers, or optical modules.
 Modify the parameter settings to the same.
 On the NMS, check whether the bandwidth configured for the tunnel or PW is too low and whether the QoS parameters are set properly.
If the bandwidth and QoS settings cannot meet the requirements of CES services, increase the bandwidth, replan the service trail, and
change QoS settings.
 Verify that electrical cables and fibers are correctly connected to the ports. Clean the fiber connectors and optical modules. If the alarm
persists, replace the cables, fibers, or optical modules that may be faulty.

Page 12
 The CES_MALPKT_EXC is an alarm indicating deformed packets of CES services.
 Possible Causes
 Cause 1: Parameters of CES services are set incorrectly.
 Cause 1: Parameters of CES services are set incorrectly.
 Modify the incorrect parameter settings on the NMS.
 On the NMS, check whether the bandwidth configured for the tunnel or PW is too low and whether the QoS parameters are
set properly. If the bandwidth and QoS settings cannot meet the requirements of CES services, increase the bandwidth,
replan the service trail, and change QoS settings.
 Verify that electrical cables and fibers are correctly connected to the ports. Clean the fiber connectors and optical modules.
If the alarm persists, replace the cables, fibers, or optical modules that may be faulty.

Page 13
 The CES_MISORDERPKT_EXC is an alarm indicating disordered packets of CES services.
 Possible Causes
 On the NMS, check whether the bandwidth configured for the tunnel or PW is too low and whether the QoS parameters are
set properly. If the bandwidth and QoS settings cannot meet the requirements of CES services, increase the bandwidth,
replan the service trail, and change QoS settings.
Verify that electrical cables and fibers are correctly connected to the ports. Clean the fiber connectors and optical modules.
If the alarm persists, replace the cables, fibers, or optical modules that may be faulty.

Page 14
 The CES_STRAYPKT_EXC is an alarm indicating errored packets of CES services.
 Possible Causes
 Cause 2: Fibers or cables are connected incorrectly.
 Modify the parameter settings to the same.
 Reconnect the fibers or cables correctly.

Locating Faults of ETH Services -
Page 15
Start
No
No
No
End
No
Yes
Yes
Yes
Yes
Yes
Yes
No
No
HARD_BAD,
TEMP_OVER,
BUS_ERR, or
COMMUN_FAIL
occurs?
ETH_LOS
occurs?
ETH_LINK_
DOWN
occurs?
LOOP_AL
M occurs?
FLOW_OVER
occurs?
Contact Huawei
engineers.
Faults are
rectified?
Board hardware errors
or inter-board
communication failure
Reset/Reseat/
Replace boards.
optical modules, or
network cables.
Signal loss or
degrade
Incorrect connections
on network ports, port
negotiation failure
Loopbacks on
ports
Service
configuration faults
Rectify service
configuration faults.
Release
loopbacks.
Change parameter
settings on ports.
Reset/Reseat/
Replace boards.

Locating Faults of ETH Services - Common
Symptoms
Page 16
Ethernet services are interrupted. HARD_BAD, TEMP_OVER, or BUS_ERR
COMMUN_FAIL
ETH_LOS, ETH_LINK_DOWN, ETH_AUTO_LINK_DOWN, or
LOOP_ALM
LASER_SHUT or LSR_WILL_DIE
Ethernet services have packet loss or
errored packets.
HARD_BAD, TEMP_OVER, or BUS_ERR
LSR_WILL_DIE
FLOW_OVER

Locating Faults of ETH Services -
Common Causes
Page 17
 Cause 1: The board carrying ETH services cannot work properly due to hardware errors,
over-high temperature, or inter-board communication failure.
 Cause 2: The signal is lost in the receive direction.
 Cause 3: Negotiation between Ethernet ports fails due to incorrect connections on Ethernet
ports.
 Cause 4: Loopbacks are performed for Ethernet ports.
 Cause 5: Traffic limit on Ethernet ports is set to a low value or parameter settings are
different on source and sink ports.

Locating Faults of ETH Services - Handling
Method
Page 18
Cause 1: The board carrying ETH services cannot work properly due to hardware errors, over-high temperature, or
inter-board communication failure.
Handle the HARD_BAD, TEMP_OVER, COMMUN_FAIL, or BUS_ERR alarm if any of them is reported.
Cause 2: The signal is lost in the receive direction.
Handle the ETH_LOS, R_LOS, LASER_SHUT, or LSR_WILL_DIE alarm if any of them is reported.
Cause 3: Negotiation between Ethernet ports fails due to incorrect connections on Ethernet ports.
Handle the ETH_LINK_DOWN alarm if it is reported.
Cause 4: Loopbacks are performed for Ethernet ports.
Handle the LOOP_ALM or ETH_EFM_LOOPBACK alarm if any of them is reported.
Cause 5: Traffic limit on Ethernet ports is set to a low value or parameter settings are different on source and sink
ports.
1. Handle the FLOW_OVER or ETH_CFM_UNEXPERI alarm if any of them is reported.
2. Check whether the working modes of interconnected Ethernet ports are the same.

Locating Tunnel Faults - Common
Locating Process
Page 19
Perform tunnel
ping tests.
Ping tests are
successful.
Perform
TraceRoute tests.
Locate faulty NEs and
links.
Are there incorrect
NE labels?
The chip checks tunnel labels
along the service flow.
Start link-layer
detection.
Inform users of incorrect
NE labels and suggest
modifications.
Tunnel layer is
normal.

Locating Tunnel Faults - Common
Symptoms and Causes
Page 20
Common Symptoms
 MPLS tunnels cannot be created, and therefore services cannot be provisioned.
 MPLS tunnels are faulty, causing service interruption.
 Protection switching fails, causing service interruption, packet loss, or bit errors.
Common Causes
 Cause 1: Cross-connections cannot be created.
 Cause 2: The physical links carrying the tunnels are faulty.
 Cause 3: Protection switching fails.

Locating Tunnel Faults - Handling Method
Page 21
Cause 1: Cross-connections cannot be created.
1. Check the IP address of each NE on the LSP. If the IP addresses of two NEs are on the same network
segment, change the IP addresses to values on different network segments.
2. Check whether incompatible features are configured for the tunnel.
3. Check whether the number of created tunnels reaches the maximum value. If yes, replan tunnels or
delete redundant tunnels.
Cause 2: The physical links carrying the tunnels are faulty.
1. Handle the HARD_BAD, R_LOS, ETH_LOS, MPLS_TUNNEL_BDI, MPLS_TUNNEL_Excess,
MPLS_TUNNEL_FDI, or MPLS_TUNNEL_LOCV alarm if any of them is reported.
2. Check whether any exceptions (such as board failure or NE reset) occur on the opposite equipment. If
yes, handle the exceptions.
Cause 3: Protection switching fails.
1. MPLS APS protection switching fails. Handle the failure.

Locating Tunnel Faults – Common
Alarms (1)
Page 22
 The MPLS_TUNNEL_LOCV is an alarm indicating the loss of tunnel connectivity.
 Possible Causes
 Cause 1: The ingress node on the tunnel stops transmitting CV/FFD packets.
 Cause 2: The physical link carrying the tunnel is faulty.
 Cause 3: Some boards on the ingress node are being reset.
 Cause 4: The service interface is configured incorrectly.
 Cause 5: Severe congestion occurs on the network.
 Cause 6: The CPU is highly occupied and cannot process ARP protocol packets.
 Cause 1: The ingress node on the tunnel stops transmitting CV/FFD packets.
 1. Check whether the settings of detection mode and detection packet type are consistent on the two ends. If not, make
consistent settings.
 2. Check the parameter of CV/FFD status on the ingress node. If the CV/FFD status is disabled, change it to enabled.
 Cause 2: The physical link carrying the tunnel is faulty.
 On the NMS, check whether the egress node reports the HARD_BAD, ETH_LOS, or ETH_LINK_DOWN alarm. If yes, clear
this alarm.

Alarms (1)
Page 23
Handling Procedure
Cause 3: Some boards on the ingress node are being reset.
On the NMS, check whether the ingress node reports the COMMUN_FAIL alarm. If yes, clear this
alarm.
Cause 4: The service interface is configured incorrectly.
Check whether the tunnel is configured on a proper port according to the NE planning table.
Cause 5: Severe congestion occurs on the network.
Check the bandwidth utilization of each port on the LSP. If the bandwidth of some ports is exhausted,
allocate some traffic to other links or increase the bandwidth of congested ports.
Cause 6: The CPU is highly occupied and cannot process ARP protocol packets.
Check for the CPU_BUSY alarm on the NMS and clear this alarm immediately if it is reported.

Alarms (2)
Page 24
 The MPLS_TUNNEL_BDI/MPLS_TUNNEL_FDI is an alarm indicating defects in the
forward/backward direction of a tunnel.
 Possible Causes
 Cause: The upstream NE detects that the tunnel at the physical layer is faulty
 Cause: The upstream NE detects that the tunnel at the physical layer is faulty
On the physical link between the local NE and its upstream NE, check for the faults
such as fiber cuts, failure in optical modules, and board failure. Rectify the fault if any.

Locating PW Faults - Common
Symptoms and Causes
Page 25
Common Symptoms
1. PWs cannot be created, and therefore services cannot be provisioned.
2. PWs are faulty, causing service interruption, packet loss, or bit errors.
Common Causes
Cause 1: The physical link carrying the PW is faulty.
Cause 2: Cross-connections of PWs cannot be created.
Cause 3: The tunnels carrying PWs are faulty.

Locating PW Faults - Handling Method
Page 26
Cause 1: The physical link carrying the PW is faulty.
1. Check whether the physical link between the ingress and egress nodes is normal. Handle
the HARD_BAD, LASER_MOD_ERR, R_LOS, or ETH_LOS alarm if any of them is reported.
2. Check whether any exceptions (such as board failure or NE reset) occur on the opposite
equipment. If yes, handle the exceptions.
Cause 2: Cross-connections of PWs cannot be created.
1. Check whether the number of created PWs reaches the maximum value. If yes, replan
PWs or delete redundant PWs.
Cause 3: The tunnels carrying PWs are faulty.
1. Handle the faults on tunnels.

Locating PW Faults – Common Alarms
Page 27
 The PW_DROPPKT_EXC is an alarm indicating that the number of lost
packets on the PW crosses the threshold.
 Possible Causes
 Cause: A small number of packets are lost on the PW.

 Cause 1: A small number of packets are lost on the PW.
 Check whether any service ports on the PW are congested. If yes, replan the trail of
services or increase the bandwidth of congested ports.

Contents Page 28
3
1
4
5
6
2
Locating DCN Faults
7
8
9
10
Reference Documents
11

Locating Faults of 1+1 Protection -
Common Symptoms
Page 29
Fault Symptoms
1+1 protection switching cannot be triggered.
After the working channel of a 1+1 protection group is restored, services cannot be
switched from the protection channel to the working channel.
The following hardware- and service-related alarms occur:
POWER_FAIL, VOLT_LOS, RADIO_TSL_HIGH, RADIO_TSL_LOW,
RADIO_RSL_HIGH, IF_INPWR_ABN, CONFIG_NOSUPPORT, R_LOC, R_LOF,
R_LOS, MW_LOF, HARD_BAD, MW_RDI
The packet services transmitted on the Hybrid microwave link are unavailable.
1+1 protection switching is delayed.

Common Causes
Page 30
Possible Causes
Cause 1: The 1+1 protection group is in forced switching state.
Cause 2: The 1+1 protection group works in non-revertive mode or works in RDI state.
Cause 3: Hardware-related alarms occur.
Cause 4: Connections between the IF board and the EMS6 board are incorrect, or the cable
connectors are in poor contact.
Cause 5: Switching is triggered again upon the RDI alarm; anti-jitter function is performed upon service
alarms and the RDI alarm; the NE is being reset; the switching between active and standby
SCC boards is being performed.
Cause 6: IF cables are connected incorrectly.

Handling Method
Page 31
Handling Procedure
Cause 1: The 1+1 protection group is in forced switching state.
Clear the forced switching state.
Cause 2: The 1+1 protection group works in non-revertive mode or works in RDI state.
Set the revertive mode of the protection group to revertive.
Cause 3: Hardware-related alarms occur.
Handle these alarms.
Cause 4: Connections between the IF board and the EMS6 board are incorrect, or the cable connectors are in poor
contact.
Re-connect the network cables between the IF board and the EMS6 board or use new cable connectors.
Cause 5: Switching is triggered again upon the RDI alarm; anti-jitter function is performed upon service alarms and
the RDI alarm; the NE is being reset; the switching between active and standby SCC boards is being
performed.
Perform the 1+1 switching 30 minutes later.
Cause 6: IF cables are connected incorrectly.
Connect IF cables correctly.

Common Alarms
Page 32
 The RPS_INDI is a microwave protection switching alarm indication.
Possible Causes
 Services are transmitted on the standby channel.
Handling Procedure
 Troubleshoot the working channel.
 Set the revertive mode of the 1+1 protection group to revertive.

Locating Faults of SNCP Protection -
Page 33
Fault Symptoms
 SNCP switching fails.
 The following hardware- and service-related events occur: performance events of
SDH SNCP protection switching
Possible Causes
Cause 1: SNCP switching fails because the NE software version mismatches the board
software version.
Cause 2: The working and protection channels of an SNCP protection group fail.
Cause 3: TU_AIS insertion upon E1_AIS is not provided (for OptiX RTN 600 V100R005 and
OptiX RTN 900 V100R002C01 and later versions).

Handling Method
Page 34
Handling Procedure
Cause 1: SNCP switching fails because the NE software version mismatches the board software
version.
Upgrade the NE software or board software.
Cause 2: The working and protection channels of an SNCP protection group fail.
Troubleshoot the channels.
Cause 3: TU_AIS insertion upon E1_AIS is not provided (for OptiX RTN 600 V100R005 and OptiX
RTN 900 V100R002C01 and later versions).
Set the TU_AIS insertion upon E1_AIS on the NMS.

Common Alarms
Page 35
 The PS is an alarm indicating protection switching.
Possible Causes
 Services are transmitted on the standby channel.
Handling Procedure
1. Troubleshoot the active channel.
2. Set the revertive mode of the SNCP protection group to revertive.

Locating APS Faults - Common Locating
Process
Page 36
Start
End
No
Yes
Yes
No
Yes
No
Yes
Yes
No
No
Yes
Yes
Yes
Yes
Yes
No
No
ETH_APS_PA
TH_MISMATC
H occurs?
ETH_APS_LOST
occurs?
Working and
protection channels of
an APS group differ on
the two ends.
APS frames are
lost on the
protection channel.
Configurations
differ on two
ends?
Change the
configurations
to the same.
Configurations
are the same
on two ends?
Change the
configurations
to the same.
Contact Huawei
engineers.
Faults are
rectified?
Fibers or cables
are connected
incorrectly?
Reconnect
fibers or cables.
APS protocol is
enabled on both
ends?
Enable APS
protocol on both
ends.
Hardware
alarms occur?
Rectify board
hardware faults.
Clock alarms
occur?
Troubleshoot
clocks.
Troubleshoot the
protection channel.
Tunnel-level alarms
occur on the protection
channel?

Locating APS Faults - Common
Symptoms
Page 37
The APS protection group is configured incorrectly or APS
frames cannot be received.
ETH_APS_PATH_MISMATCH
ETH_APS_LOST
ETH_APS_SWITCH_FAIL
ETH_APS_TYPE_MISMATCH
The working tunnel or protection tunnel is faulty. MPLS_TUNNEL_LOCV
MPLS_TUNNEL_MISMERGE
MPLS_TUNNEL_MISMATCH
MPLS_TUNNEL_Excess
MPLS_TUNNEL_SD
MPLS_TUNNEL_SF
MPLS_TUNNEL_UNKNOWN

Locating APS Faults - Common Causes
Page 38
 Cause 1: The settings of the APS protection group differ between the two ends.
 Cause 2: The APS protection group is deactivated.
 Cause 4: APS frames cannot be transmitted because hardware-related alarms occur
on the board that carries the protection channel.
 Cause 5: The system reports clock alarms.
 Cause 6: The working tunnel or protection tunnel is faulty.

Locating APS Faults - Handling Method
Page 39
Cause 1: The settings of the APS protection group differ between the two ends.
Check for the ETH_APS_PATH_MISMATCH and ETH_APS_TYPE_MISMATCH alarms.
If any of them is reported, handle the alarm.
Cause 2: The APS protection group is deactivated.
Check for the ETH_APS_LOST and ETH_APS_SWITCH_FAIL alarms. If any of them is
reported, handle the alarm.
Cause 3: Fibers or cables are connected incorrectly.
Reconnect the fibers or cables.

Locating APS Faults - Handling Method
Page 40
Cause 4: APS frames cannot be transmitted because hardware-related alarms occur on the board
that carries the protection channel.
Check whether any hardware-related alarms (such as HARD_BAD, COMMUN_FAIL, and
BUS_ERR) occur on the board that carries the protection channel. If yes, clear these
alarms.
Cause 5: The system reports clock alarms.
Check whether the system reports clock alarms such as TR_LOC, SYNC_C_LOS, and
LTI. If yes, clear these alarms.
Cause 6: The working tunnel or protection tunnel is faulty.
Check for tunnel-level alarms. If a tunnel reports a tunnel-level alarm, the tunnel is faulty.
Troubleshoot the tunnel.

Common APS Alarms (1)
Page 88
The ETH_APS_LOST is an alarm indicating that APS frames are lost.
Possible Causes
Cause 1: The opposite NE is not configured with APS protection.
Cause 2: The settings of the APS protection group differ between the two ends.
Cause 3: The APS protection group is deactivated.
Cause 4: The service on the protection channel is interrupted.
Handling Procedure
Cause 1: The opposite NE is not configured with APS protection.
On the NMS, check whether the opposite NE is configured with APS protection. If the opposite NE is configured
with APS protection, create a matching APS protection group on the opposite NE and activate the APS protocol.
On the NMS, check whether the settings of the APS protection group are the same at the two ends. If the settings
differ between the two ends, change them to the same.
Cause 3: The APS protection group is deactivated.
Check whether the APS protocol is activated at both ends. If the APS protocol is deactivated at one end,
deactivate the APS protocol at the other end and then activate the APS protocol at both ends.
Cause 4: The service on the protection channel is interrupted.
Check whether the protection channel reports an alarm related to signal loss or signal degrade, such as
ETH_LOS. If yes, clear the alarm immediately.

Common APS Alarms (2)
Page 89
The ETH_APS_SWITCH_FAIL is an alarm indicating a protection switching failure.
Possible Causes
Cause 1: The settings of the APS protection group differ between the two ends.
Handling Procedure
On the NMS, check whether the settings of the APS protection group are the same at the two ends. If the settings differ
between the two ends, change them to the same. Then, deactivate and activate the APS protection group at the two ends.
The ETH_APS_TYPE_MISMATCH is an alarm indicating a protection scheme mismatch.
Possible Causes
Cause 1: The switching type is different.
Cause 2: The switching mode is different.
Cause 3: The revertive mode is different.
Handling Procedure
Cause: The switching type, switching mode, or revertive mode of the protection group differs between the two ends.
On the NMS, check whether the settings of the APS protection group are the same at the two ends. If the settings differ
between the two ends, change them to the same. Then, deactivate and activate the APS protection group at the two ends.

Locating ETH LAG Faults - Common Locating Process
Page 90

Locating ETH LAG Faults - Common
Symptoms
Page 91
The LAG is invalid, all the member ports cannot
be used, and the services are interrupted.
LAG_DOWN
The member ports in the LAG cannot be used,
and the service has packet loss.
LAG_MEMBER_DOWN
LOOP_ALM
ETH_LOS
ETH_LINK_DOWN

Locating ETH LAG Faults - Common
Causes
Page 92
 Cause 1: The NEs at the two ends of the LAG are incorrectly configured.
 Cause 2: The working mode of the member ports in the LAG is set to half-
duplex.
 Cause 3: The loopback is configured on the member ports in the LAG.
 Cause 4: The connections of the member ports in the LAG are faulty or lost.

Locating ETH LAG Faults - Handling
Method
Page 93
Cause 1: The NEs at the two ends of the LAG are incorrectly configured.
(1) Query current alarms 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.
Cause 2: The working mode of the member ports in the LAG is set to half-duplex.
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 each port to full-duplex.
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. If yes, release the
loopback on each port to clear the LOOP_ALM alarm.
(2) Check whether the ETH_EFM_LOOPBACK alarm exists on each member port in the LAG. If yes,
release the remote loopback to clear the ETH_EFM_LOOPBACK alarm.
Cause 4: The connections of the member ports in the LAG are faulty or lost.
Check whether the ETH_LOS or ETH_LINK_DOWN alarm exists on each member port in the LAG. If yes,
clear the ETH_LOS or ETH_LINK_DOWN alarm.

Common ETH LAG Alarms (1)
Page 94
The LAG_DOWN is an alarm indicating that the LAG is unavailable.
Possible Causes
Cause 1: The opposite NE is not configured with any LAGs.
Cause 2: All member ports in the LAG are unavailable.
Handling Procedure
Cause 1: The opposite NE is not configured with any LAGs.
On the NMS, check whether the opposite NE is configured with a LAG. If the opposite
NE is not configured with a LAG, configure one on the opposite NE and check whether
the alarm clears.
Cause 2: All member ports in the LAG are unavailable.
When a member port in the LAG is unavailable, the system generates an ETH_LOS,
ETH_LINK_DOWN, or LAG_MEMBER_DOWN alarm. Handle and clear the alarm and
activate the member port.

Common ETH LAG Alarms (2) Page 95
The LAG_MEMBER_DOWN is an alarm indicating that a member port of a LAG is unavailable.
Possible Causes
Cause 1: The port link is unavailable.
Cause 2: The port receives no LACP packet.
Cause 3: The port works in half-duplex mode.
Cause 4: The port is looped back.
Handling Procedure
Cause 1: The port link is unavailable.
On the NMS, check whether the port in the LAG is enabled. If the port is not enabled, enable the port in the LAG and
check whether the alarm clears. If the alarm persists, check whether an ETH_AUTO_LINK_DOWN alarm occurs on the
port that reports the LAG_MEMBER_DOWN alarm. If yes, clear the LAG_MEMBER_DOWN alarm.
Cause 2: The port receives no LACP packet.
On the NMS, check whether the opposite port is added to the LAG. If the opposite port is not added to the LAG, add the
opposite port to the LAG and check whether the alarm clears. If the alarm persists, check whether an ETH_LOS or
FLOW_OVER alarm occurs on the port that reports the LAG_MEMBER_DOWN alarm. If yes, clear the
LAG_MEMBER_DOWN alarm.
Cause 3: The port works in half-duplex mode.
Change the working mode of the port to auto-negotiation or full-duplex.
Cause 4: The port is looped back.
Release the loopback on the port.

Contents Page 96
3
1
4
5
6
2
Locating DCN Faults
7
8
9
10
Reference Documents
11

Locating Clock Faults - Common Symptoms and
Causes
Page 97
Fault Symptoms
 The service has bit errors or is interrupted.
 The system control, cross-connect, and timing board reports an
EXT_SYNC_LOS/LTI/S1_SYN_CHANGE/SYNC_C_LOS/SYNC_DISABLE alarm.
Possible Causes
 Cause 1: The priority of the synchronous clock source on the service board is absent
from the priority list.
 Cause 2: The synchronous clock source is lost and the clock of the NE works improperly.
 Cause 3: The clock source is switched in SSM mode and the clock source traced by the
NE is also switched.
 Cause 4: The signals of the synchronous clock source are degraded.
 Cause 5: The external clock source is lost.
 Cause 6: The settings of clock tracing are incorrect.

Locating Clock Faults - Handling Method
Page 98
Handling Procedure
Cause 1: The priority of the synchronous clock source on the service board is absent from the priority list.
Check for the SYNC_C_LOS alarm. If the SYNC_C_LOS alarm occurs, clear the SYNC_C_LOS alarm.
Cause 2: The synchronous clock source is lost and the clock of the NE works improperly.
Check for the LTI alarm. If the LTI alarm occurs, clear the LTI alarm.
Cause 3: The clock source is switched in SSM mode and the clock source traced by the NE is also
switched.
Check for the S1_SYN_CHANGE alarm. If the S1_SYN_CHANGE alarm occurs, clear the
S1_SYN_CHANGE alarm.
Cause 4: The signals of the synchronous clock source are degraded.
Select a different clock source (by performing a clock source switchover or re-configure the clock source
priority list) and find out signal degrade causes along the clock tracing path.
Cause 5: The external clock source is lost.
Check for the EXT_SYNC_LOS alarm. If the EXT_SYNC_LOS alarm occurs, clear the EXT_SYNC_LOS
alarm.
Cause 6: The settings of clock tracing are incorrect.
Set clock tracing again according to network planning information.

Common Clock Alarms (1)
Page 99
The EXT_SYNC_LOS is an alarm indicating the loss of the external clock
source.
Possible Causes
Cause 1: The external clock source is configured in the clock source priority list, but
the external clock source cannot be detected or become invalid.
Handling Procedure
Cause 1: The external clock source is configured in the clock source priority list, but
the external clock source cannot be detected or become invalid.
Check whether the equipment that provides the external clock source is faulty, and
check whether the cable that connects the external clock source is normal.

Page 100
The LTI is an alarm indicating that the synchronous clock source is lost.
Possible Causes
Cause 1: The clock configuration is incorrect.
Cause 2: All the clock sources in the clock source priority list fail.
Handling Procedure
Cause 1: The clock configuration is incorrect.
Query the clock synchronization status and check whether the data in the clock source
priority list meets the network planning requirement.
Cause 2: All the clock sources in the clock source priority list fail.
Troubleshoot the synchronization sources based on the clock source priority list. If the
synchronization source is an external clock, handle the EXT_SYNC_LOS alarm; if the
synchronization source is a line clock, handle the alarm that occurs on the line board; if the
synchronization source is an IF clock, handle the alarm that occurs on the IF board; if the
synchronization source is a tributary clock, handle the alarm that occurs on the tributary
board; if the synchronization source is an Ethernet clock, handle the alarm that occurs on
the Ethernet board.

Page 101
The S1_SYN_CHANGE is an alarm indicating that the clock source is switched
in SSM or extended SSM mode.
Possible Causes
Cause 1: The original clock source is lost when the SSM protocol or extended SSM
protocol is enabled.
Handling Procedure
Cause 1: The original clock source is lost when the SSM protocol or extended SSM
protocol is enabled.
Handle the SYNC_C_LOS alarm that is related to the original clock source.

Page 102
The SYNC_C_LOS is an alarm indicating that the synchronization source is
lost.
Possible Causes
Cause 1: The clock source is lost.
Handling Procedure
Cause 1: The clock source is lost.
Based on the clock source priority list, determine the synchronization source
corresponding to the lost clock source.

Page 103
The SYNC_DISABLE is an alarm indicating that the automatic
synchronization of SCC boards is disabled.
Possible Causes
Cause 1: The status of the automatic synchronization of SCC boards changes from
enabled to disabled.
Handling Procedure
Cause 1: The status of the automatic synchronization of SCC boards changes from
enabled to disabled.
Change the status of the automatic synchronization of SCC boards from disabled to
enabled. Then, check whether the alarm clears. If the alarm persists, replace the
board that reports the alarm.

Contents Page 104
3
1
4
5
6
2
Locating DCN Faults
7
8
9
10
Reference Documents
11

Locating Inband DCN Faults - Common Locating Process
Page 105

Locating Inband DCN Faults - Common Symptoms and
Causes
Page 106
Common Causes
 Cause 1: On a network, the NE IDs, NE IP addresses or subnet masks conflict.
 Cause 2: The inband DCN port of the faulty NE is not enabled, or parameter settings for the
interconnected ports are inconsistent.
 Cause 3: The physical connection between the faulty NE and the NMS is interrupted.
 Cause 4: The received signals of the faulty NE are lost, or the received optical power is
excessively low, and therefore the DCN packets cannot be extracted.
 Cause 6: A DCN storm or DCN interruption occurs as the third-party network that the DCN
packets traverse is faulty.
 Cause 7: The bandwidth configured for the inband DCN channel is excessively small.
 Cause 8: The SCC board on the faulty NE is being reset or switched, and therefore the inband
DCN packets cannot be responded.
Common Symptoms
 The communication between the NMS and the NE is interrupted. The NE icon on the NMS is
gray, and the NE is unreachable to the NMS.
 The operations on the NMS are not responded. If the response interruption time lasts for more
than two minutes, the communication between the NMS and the NE is interrupted.
 When you query certain information on the NMS, the query result contains incomplete
information.

Locating Inband DCN Faults - Handling
Method
Page 107
Cause 1: On a network, the NE IDs, NE IP addresses or subnet masks conflict.
It is usually caused by the new NE on the network. According to the NE plan table, check whether the NE ID, NE IP
address and subnet mask of the new NE are correctly configured. If any parameters are incorrect or conflict with the
configuration of another NE, re-configure these parameters.
Cause 2: The inband DCN port of the faulty NE is not enabled, or parameter settings for the interconnected ports are
inconsistent.
(1) Check whether the ports, which support the DCN function by default, are connected to fibers or cables. If the fibers
or cables are not connected to the ports whose DCN function is enabled by default, change the present port to a port
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 for the ports.
(3) Check whether the configurations of the ports at the two ends are consistent, such as the working mode of the
Ethernet port. If inconsistent, modify the configurations to match each other.
Cause 3: The physical connection between the faulty NE and the NMS is interrupted.
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.
Cause 4: The received signals of the faulty NE are lost, or the received optical power is excessively low, and therefore
the DCN packets cannot be extracted.
Check whether the R_LOS, ETH_LOS, or IN_PWR_ABN alarm exists on the board configured with the inband DCN
channel. If the alarm exists, clear it.
Check whether the HARD_BAD or TEMP_OVER alarm exists on the board configured with the inband DCN channel.
If the alarm exists, replace the board that reports the alarm.

Locating Inband DCN Faults - Handling Method
(Continued)
Page 108
Cause 6: A DCN storm or DCN interruption occurs as the third-party network that the DCN packets traverse is
faulty.
If the DCN packets traverse a third-party network, check whether a port loop or physical link interruption
occurs in the third-party network. If yes, rectify the faults in the third-party network first.
Cause 7: The bandwidth configured for the inband DCN channel is excessively small.
(1) When the number of services configured on the port exceeds a certain number, part of the query
information may be lost. In this case, you should properly increase the bandwidth configured for the inband
DCN channel.
(2) If a DCN gateway manages a large number of NEs, a network congestion may occur, especially during
package loading. If a network congestion occurs, change the position of the DCN gateway and the number of
NEs that the DCN gateway manages. Generally, a DCN gateway manages a maximum of 64 NEs.
Cause 8: The SCC board on the faulty NE is being reset or switched, and therefore the inband DCN packets
cannot be responded.
(1) Observe whether the PROG indicator on the SCC board is blinking green. If the indicator is blinking green,
it indicates that the SCC board is in the reset state. After the PROG indicator is steady on (green), the reset of
the SCC board is complete and the DCN connection is automatically recovered.
(2) If the DCN connection is not recovered, check whether a protection switchover occurs on a board. A
protection switchover on a board will reroute DCN packets.
(3) If a protection switchover occurs on a board, the DCN connection is automatically recovered after
rerouting is complete.

3
1
4
5
6
2
Locating DCN Faults
7
8
9
10
Reference Documents
11

Locating NE Resets - Fault Symptoms and Possible
Causes
Page 110
Fault Symptoms
 A cold reset or warm reset occurs on an NE.
Possible Causes
 Cause 1: A manual operation causes the reset.
 Cause 2: The power supply of the NE is abnormal.
 Cause 4: Certain tasks have high CPU usage.
 Cause 5: Other reasons cause the reset.

Locating NE Resets - Handling Method
Page 111
Handling Procedure
Cause 1: A manual operation causes the reset.
Check operation records on the NMS and oplog/errlog records on the NE.
Cause 2: The power supply of the NE is abnormal.
Check for a low-voltage reset record or an exception record among errlog records on the NE
and records in the black box; check whether the voltage of the power supply is stable; check
whether the environment causes abnormal power supply.
Replace the faulty board.
Cause 4: Certain tasks have high CPU usage.
Check whether the current network has a large scale and whether the number of routes is far
greater than the recommended value.
Cause 5: Other reasons cause the reset.
Collect the current and historical alarms on the NMS and the NE, records in the black box,
oplog records, errlog records, dopra records, debugbuf records, and other information
required for fault locating, and send all the information to Huawei engineers.

Locating Package Loading Failures -
Fault Symptoms and Possible Causes
Page 112
Fault Symptoms
 Package loading fails.
Possible Causes
 Cause 1: The NE is abnormal in the process of software loading.
 Cause 2: Backing up databases fails.
 Cause 3: A rollback occurs due to a failure in package downloading.
 Cause 4: A rollback occurs due to an error in the software activation process.
 Cause 5: The upgrade task is not rolled back when an error occurs in the software
activation process.
 Cause 6: The SWDL_INPROCESS alarm persists after the upgrade is complete.
 Cause 7: User interfaces stop responding in the upgrade process.
 Cause 8: A board is reseated in the upgrade process.
 Cause 9: The PCBs of the active and standby SCC boards are of different versions.

Locating Package Loading Failures - Possible
Causes
Page 113
Possible Causes
 Cause 10: The NE is in the Undispensed state when an upgrade task is being created.
 Cause 11: The NE is in the Unactivated state when an upgrade task is being created.
 Cause 12: The NE is in the Uncommitted state when an upgrade task is being created.
 Cause 13: No CF card is installed on the SCC board or the memory in the CF card is
insufficient.
 Cause 14: Other reasons cause the failure.

Locating Package Loading Failures - Handling Method
Page 114
Cause 1: The NE is abnormal in the process of software loading.
Load software 10 minutes later because the NE is in an unstable state.
Cause 2: Backing up databases fails.
Upload the NE databases to the U2000 again; create another upgrade task and run the task.
If the backing-up fails again, perform a warm reset on the NE.
Cause 3: A rollback occurs due to a failure in package downloading.
Check whether DCN communication is normal and whether bandwidth is sufficient. If no
fault is found, check whether a correct software package is downloaded. If the downloaded
software package is correct, check whether the remaining space on the flash memory is
greater than the space required by the software package. If the remaining space on the
flash memory is sufficient, change the gateway NE.
Cause 4: A rollback occurs due to an error in the software activation process.
Check whether any board is removed or whether the NE is manually reset during the
upgrade. Then, activate the software again.

Page 115
Cause 5: The upgrade task is not rolled back when an error occurs in the software activation
process.
Select the task and click Ignore to commit the task. Then, check the version of each
board. For boards whose version information is not updated, perform a cold reset on
them. If a resetting command cannot be issued, perform a warm reset on the SCC board
if the NE has only one SCC board, or perform active/standby switching between SCC
boards if the NE has two SCC boards.
Cause 6: The SWDL_INPROCESS alarm persists after the upgrade is complete.
Check whether the NE is in a normal state. If yes, perform a warm reset on the NE.
Cause 7: User interfaces stop responding in the upgrade process.
Restart the tool and create a new task that runs directly from the NE state, which is
displayed when the task is originally created.

Page 116
Cause 8: A board is reseated in the upgrade process.
Remove the board, and then insert the board after the NE enters the normal state. If
automatic matching still fails, check whether an SWDL_INPROCESS alarm occurs. If yes,
clear the SWDL_INPROCESS alarm first.
Cause 9: The PCBs of the active and standby SCC boards are of different versions.
Run the :mon-get-dump:bid,"SWDL.ISWDL.CSWDL","" command on the Navigator
and check whether the returned values of m_byPCB for the active and standby SCC
boards are the same. If the returned values of m_byPCB for the two SCC boards are
different, replace any SCC board to ensure that the SCC boards use the same PCB.
Cause 10: The NE is in the Undispensed state when an upgrade task is being created.
Skip Load Package and create a task from the Dispense state; or enter the :swdl-dnld-
swmem command on the Navigator.

Page 117
Cause 11: The NE is in the Unactivated state when an upgrade task is being created.
Skip Load Package and Dispense and create a task from the Active state; or enter
the :mon-init-sys:0,swdl command on the Navigator. (An activation operation will interrupt
services. Therefore, check whether an activation operation is allowed.)
Cause 12: The NE is in the Uncommitted state when an upgrade task is being created.
Skip Load Package, Dispense, and Active, and create a task from the Commit state; or
enter the :swdl-commit-swmem command on the Navigator.
Cause 13: No CF card is installed on the SCC board or the memory in the CF card is
insufficient.
If no CF card is installed on the SCC board, install a CF card; if the memory in the CF card
is insufficient, delete unnecessary files in the CF card.
Cause 14: Other reasons cause the failure.
Collect data and send the data to Huawei engineers.

Common Alarms
Page 118
 The CFCARD_FAILED is an alarm indicating that the operation on the CF card
fails.
Possible Causes
 Cause 1: The CF card is faulty, resulting in an initialization failure.
 Cause 2: The SCC board is faulty, resulting in a failure to create a CF file.
Handling Procedure
Cause 1: The CF card is faulty, resulting in an initialization failure.
Replace the CF card and check whether the alarm is cleared.
Cause 2: The SCC board is faulty, resulting in a failure to create a CF file.
Check whether the HARD_BAD alarm exists on the SCC board. If yes, perform a
cold reset on the SCC board. Then, check whether the alarm is cleared. If the alarm
persists, replace the SCC board.

Common Alarms
Page 119
 The CFCARD_OFFLINE is an alarm indicating that the CF card is offline.
Possible Causes
 Cause 1: The CF card is not installed.
 Cause 2: The CF card is in poor contact with the SCC board.
 Cause 3: The SCC board is faulty.
Handling Procedure
Cause 1: The CF card is not installed.
Check whether the CF card is installed on the SCC board. If not, install a CF card.
Cause 2: The CF card is in poor contact with the SCC board.
Check whether the CF card is loosened. If yes, re-install the CF card. Then, check
whether the alarm is cleared. If the alarm persists, replace the CF card.
Cause 3: The SCC board is faulty.
Check whether the HARD_BAD alarm exists on the SCC board. If yes, perform a cold
reset on the SCC board. Then, check whether the alarm is cleared. If the alarm persists,
replace the SCC board.

3
1
4
5
6
2
Locating DCN Faults
7
8
9
10
Reference Documents
11

Handling Common Alarms (1)
Page 121
 The AM_DOWNSHIFT is an alarm indicating the downshift of the AM scheme.
Possible Causes
 Cause 1: The external factors (for example, the climate) cause the degradation of the working channels.
 Cause 2: There are interferences around the working channels.
 Cause 3: The ODU at the transmit end has abnormal transmit power.
 Cause 4: The ODU at the receive end has abnormal receive power.
 Cause 5: Multi-path fading occurs due to atmospheric and ground effects.
Handling Procedure
Cause 1: The external factors (for example, the climate) cause the degradation of the working channels.
When the external factors (for example, the climate) cause the degradation of the working channels, the
downshift of the AM scheme is normal. Therefore, no measure should be taken to handle the alarm.
Cause 2: There are interferences around the working channels.
Eliminate the interferences around the working channels.
Cause 3: The ODU at the transmit end has abnormal transmit power.
Use the NMS to check whether the transmit power of the ODU at the transmit end is normal. For details on
troubleshooting at the transmit end, see Locating Link Faults.
Cause 4: The ODU at the receive end has abnormal receive power.
Use the NMS to check whether the receive power of the ODU at the receive end is normal. For details on
troubleshooting at the receive end, see Locating Link Faults.
Cause 5: Multi-path fading occurs due to atmospheric and ground effects.
Adjust the elevation angles of the antennas; use large-diameter antennas; re-plan transmission links to
avoid areas with severe multi-path fading.

Page 122
 The BD_STATUS is an alarm indicating that the board cannot be detected.
Possible Causes
 Cause 1 of the alarm reported by a board of the IDU: The board is installed in an incorrect slot.
 Cause 2 of the alarm reported by a board of the IDU: The board and the backplane are not connected properly.
 Cause 3 of the alarm reported by a board of the IDU: The slot is faulty.
 Cause 4 of the alarm reported by a board of the IDU: The alarmed board is faulty.
 Cause 5: The ODU is faulty; the power that the IF board supplies to the ODU is abnormal; the IF cable is damaged or
is not properly connected.
Handling Procedure
Cause 1: The board is installed in an incorrect slot.
Check whether the physical slot and logical slot of the alarmed board are the same.
Cause 2: The board and the backplane are not connected properly.
Re-install the alarmed board.
Cause 3: The slot is faulty.
Check whether the slot has broken or bent pins. If yes, insert the board in a vacant slot.
Replace the board.
Cause 5: The ODU is faulty; the power that the IF board supplies to the ODU is abnormal; the IF cable is damaged or is
not properly connected.
Replace the ODU that reports the alarm; check the voltage at the RF port on the IF board; check whether the IF cable
is wet or abnormal; re-connect the IF cable.

Page 123
 The BUS_ERR is an alarm of bus errors.
Possible Causes
 Cause 1: The board and the backplane are not connected properly.
 Cause 3: The inter-board bus is faulty.
Handling Procedure
Re-install the alarmed board; check whether the backplane has broken or bent pins. If the
backplane has broken or bent pins, insert the board in a vacant slot or replace the backplane.
Perform a cold reset on the alarmed board. If the alarm persists, perform a cold reset on the
SCC board. If the alarm still persists, replace the alarmed board.
Cause 3: The inter-board bus is faulty.
On the NMS, check whether an alarm indicating loss/deterioration of a clock source is
reported. If yes, clear clock alarms and then check whether the BUS_ERR alarm clears.

Page 124
 The COMMUN_FAIL is an alarm indicating an inter-board communication failure.
Possible Causes
 Cause 1: The alarmed board is reset.
 Cause 2: The board and the backplane are not connected properly.
 Cause 4: The slot is faulty.
Handling Procedure
Cause 1: The alarmed board is reset.
Perform a reset on the alarmed board. Then, the alarm disappears automatically.
Re-install the alarmed board; check whether the backplane has broken or bent pins. If the backplane has broken or bent pins,
insert the board in a vacant slot or replace the backplane.
Replace the alarmed board.
Cause 4: The slot is faulty.
Check whether the slot has broken or bent pins. If yes, insert the board in a vacant slot.
Perform a cold reset on the SCC board. Then, check whether the alarm clears. If the alarm persists, replace the SCC board.

Page 125
 The FAN_FAIL is an alarm indicating that a fan is faulty.
Possible Causes
 Cause 1: The alarmed board and the backplane are not connected properly.
 Cause 2: A fan is faulty.
Handling Procedure
Cause 1: The alarmed board and the backplane are not connected properly.
Re-install the alarmed board; check whether the backplane has broken or bent pins. If the
backplane has broken or bent pins, insert the board in a vacant slot or replace the backplane.
Cause 2: A fan is faulty.
Remove the fan board and clean the fans. Then, install the fan board and check whether the
alarm clears. If the alarm persists, replace the fan board.

Page 126
 The HARD_BAD is an alarm indicating that the hardware is faulty.
Possible Causes
 Cause 1: The external power supply fails.
 Cause 2: The alarmed board and the backplane are not connected properly.
 Cause 3: The alarmed board has hardware errors.
Handling Procedure
Cause 1: The external power supply fails.
Check the external power supply.
Cause 2: The alarmed board and the backplane are not connected properly.
Re-install the alarmed board; check whether the backplane has broken or bent pins. If the backplane has broken or
bent pins, insert the board in a vacant slot or replace the backplane.
Cause 3: The alarmed board has hardware errors.
Perform a cold reset on the alarmed board and check whether the alarm clears. If the alarm persists, replace the
alarmed board.
Perform a cold reset on the SCC board. Then, check whether the alarm clears. If the alarm persists, replace the SCC
board.

Page 127
 The IF_CABLE_OPEN is an alarm indicating that the IF cable is open.
Possible Causes
 Cause 1: The IF cable is loose or faulty.
 Cause 2: The IF port on the IF board is damaged.
 Cause 3: The power module of the ODU is faulty.
Handling Procedure
Cause 1: The IF cable is loose or faulty.
Check whether the connector of the IF cable is damaged/wet/corroded/loose or whether the
connector is made properly. (The connectors to be checked include the connector between
the IF pigtail and the IF board, the connector between the IF pigtail and the IF cable, and the
connector between the IF cable and the ODU.)
Cause 2: The IF port on the IF board is damaged.
Replace the alarmed IF board.
Cause 3: The power module of the ODU is faulty.
Replace the ODU connected to the alarmed IF board.

Page 128
 The IF_INPWR_ABN is an alarm indicating that the power supplied by an IF board to an ODU is
abnormal.
Possible Causes
 Cause 1: The IF board is faulty.
 Cause 2: The IF cable is faulty.
 Cause 3: The ODU is faulty.
Handling Procedure
Cause 1: The IF board is faulty.
Replace the alarmed IF board.
Cause 2: The IF cable is faulty.
Check whether the connector of the IF cable is damaged/wet/corroded/loose or whether the connector is made
properly. (The connectors to be checked include the connector between the IF pigtail and the IF board, the
connector between the IF pigtail and the IF cable, and the connector between the IF cable and the ODU.)
Cause 3: The ODU is faulty.
Perform a cold reset on the ODU and check whether the alarm clears. If the alarm persists, replace the ODU.

Page 129
 The MW_CFG_MISMATCH is an alarm indicating a configuration mismatch on microwave
links.
Possible Causes
 Cause 1: The number of E1 signals is different on both ends of a microwave link (including the number of
E1 signals on the active page and the number of E1 signals on the standby page).
Handling Procedure
Cause 1: The number of E1 signals is different on both ends of a microwave link.
Cause 2: The AM enabling is different on both ends of a microwave link.
Cause 3: The IEEE 1588 overhead enabling is different on both ends of a microwave link.
Cause 4: The modulation mode is different on both ends of a microwave link.
Cause 5: The channel spacing is different on both ends of a microwave link.
Determine the possible cause of the alarm according to the alarm parameters. Then, check the
configuration on both ends of the microwave link. Ensure that the configuration is the same on both ends
of the microwave link.

Page 130
 The MW_LOF is an alarm indicating that microwave frames are lost.
Possible Causes
 Cause 1: Certain other alarms occur.
 Cause 2: The IF working mode or channel spacing at both ends of a microwave link does not match the preset modulation mode.
 Cause 3: The operating frequency of the ODU at the local site is inconsistent with the operating frequency of the ODU at the opposite
site, resulting in abnormal receive power.
 Cause 4: An IF/RF transmit/receive channel is faulty.
 Cause 5: An interference event occurs.
Handling Procedure
Cause 1: Certain other alarms occur.
Check for HARD_BAD, VOLT_LOS, IF_CABLE_OPEN, BD_STATUS, RADIO_RSL_LOW, CONFIG_NOSUPPORT, and
TEMP_ALARM alarms. If any of these alarms are reported, clear them immediately.
Cause 2: The IF working mode or channel spacing at both ends of a microwave link does not match the preset modulation mode.
Modify the settings of IF parameters according to network planning requirements to ensure a match with the preset modulation mode.
Cause 3: The operating frequency of the ODU at the local site is inconsistent with the operating frequency of the ODU at the opposite site,
resulting in abnormal receive power.
Set the transmit frequency of the local site to the same as the receive frequency of the opposite site. Then, set the receive frequency of
the local site to the same as the transmit frequency of the opposite site. In addition, ensure that the receive power of the ODU at both
ends of the microwave link meets the planned value.
Cause 4: An IF/RF transmit/receive channel is faulty.
Perform loopbacks section by section to check whether the ODU/IF transmit/receive channel is faulty. If a fault is found, replace the
ODU/IF board.
Cause 5: An interference event occurs.
Eliminate the interference source.

Handling Common Faults and Alarms for Huawei RTN Microwaves

Handling Common Faults and Alarms for Huawei RTN Microwaves

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Handling Common Faults and Alarms for Huawei RTN Microwaves

Similar to Handling Common Faults and Alarms for Huawei RTN Microwaves (20)

More from ibrahimnabil17

More from ibrahimnabil17 (20)

Recently uploaded

Recently uploaded (20)

Handling Common Faults and Alarms for Huawei RTN Microwaves