Troubleshooting Guide RTN PDF

OptiX RTN 600 Radio Transmission System
Maintenance Guide 2 Troubleshooting Guide
2 Troubleshooting Guide
About This Chapter
This guide describes the general troubleshooting procedures for the OptiX RTN 600 and provides
troubleshooting methods for common faults.
2.1 General Fault Locating Procedures

When handling a fault, make a detailed record of the fault phenomenon. Contact Huawei
engineers to report problems and obtain technical support.
2.2 Troubleshooting Service Interruptions
When services cannot be transmitted due to an equipment failure or link failure, the services are
interrupted.
2.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.
2.4 Troubleshooting Bit Errors
When an NE reports an alarm or performance event on the regenerator section (RS), multiplex
section (MS), higher order path (HP), or lower order path (LP), there are bit errors in services.
2.5 Troubleshooting Pointer Justifications
When an NE reports a large amount of justification events of the administrative unit (AU) pointer
or the tributary unit (TU) pointer, there are pointer justification faults.
2.6 Troubleshooting the Interconnection with the SDH Equipment
In the case that the OptiX RTN 600 is interconnected with the SDH equipment, if the SDH
service cannot be transmitted between the equipment sets, there is an interconnection fault.
2.7 Troubleshooting the Interconnection with the PDH Equipment
In the case that the OptiX RTN 600 is interconnected with the PDH equipment, if the PDH
2.8 Troubleshooting Ethernet Service Faults
An Ethernet service fault might be Ethernet service interruption or Ethernet service degradation.
2.9 Troubleshooting the Orderwire
If orderwire calls cannot get through when services are normal, there is an orderwire fault.
Issue 06 (2007-12-30) Huawei Technologies Proprietary 2-1

2 Troubleshooting Guide Maintenance Guide
2.1 General Fault Locating Procedures

When handling a fault, make a detailed record of the fault phenomenon. Contact Huawei
engineers to report problems and obtain technical support.
2-2 Huawei Technologies Proprietary Issue 06 (2007-12-30)

Figure 2-1 General fault locating procedures
Start
Record the fault phenomenon
2 Yes
Caused by external factors? Other handling procedures
3 No
Analyze fault causes and locate
the fault
Is the fault cleared? Yes
4 No
Report to Huawei
Make a solution together
Attempt to clear the fault
No
Is the service restored?
Yes
Observe the operating
No
Is the fault cleared?
Yes
Fill in the fault handling report
End

Table 2-1 Flow description
Note Description
① When recording the fault phenomenon, make a true and detailed record of the
entire process of the fault. Record the exact time when the fault occurs, and
the operations done before and after the occurrence of the fault. Save the
alarms, performance events, and other important information.
② Faults that are caused by external factors include power failures, fiber faults,
environmental faults, and terminal equipment (like switching equipment)
faults.
③ If the fault is caused by the equipment, refer to 2.2 Troubleshooting Service

Interruptions.
④ Contact Huawei engineers to report problems and obtain technical support.
2.2 Troubleshooting Service Interruptions

When services cannot be transmitted due to an equipment failure or link failure, the services are
interrupted.
Fault Causes
l There are misoperations.
The data is wrongly modified. A board/cable is looped back or replaced.
l The protection switching fails.
l The transmission NE or link is faulty.
l There is an interconnection fault.
If the transmission equipment and connections are working normally, check if there is a
fault in the interconnection between the transmission equipment and the switching
equipment.
Fault Locating Methods

1. Check out the operations done before the service interruption.
2. Analyze alarms.
If several NEs report alarms, analyze the alarms in the following sequence: switching failure
alarms, equipment alarms, line alarms, HP alarms, and LP alarms.
3. Perform loopback operations section by section. Or replace components.
CAUTION
If the fault cannot be removed in a short time, first restore services. Adjust service routes
or perform a forced switching operation to restore services.

Fault Locating Procedures
Figure 2-2 Flow of handling service interruptions
Start
1
Check out the operations
done before the service
interruption
Is there a wrong Yes Cancel the operation

operation?
No
2
Are service Yes
Handle switching failure
paths protected?
No
3 Yes
Is there an
equipment alarm? Handle the alarm
No
4
Yes
Is there a line alarm? Handle the alarm
No
5 Yes
Is there an HP alarm? Handle the alarm
No
6 Yes
Is there an LP alarm? Handle the alarm
7
Are Ethernet Handle the Ethernet
services interrupted? services fault
No
8
Is there an Yes Handle the interconnection
interconnection fault? fault
No
No
Go to the next step Is the fault cleared?
Perform loopback operations
section by section Yes
End


Note Description
1 Operations that may cause a service interruption are as follows:

l Modifying the data configuration
l Performing loopback operations
l Shutting down the laser
l Silencing the ODU
l Replacing boards/cables
2 Follow the steps below:

1. Check if there are the protection switching alarms such as HSB_INDI,
HSM_INDI, or PS, APS_INDI, or SNCP switching abnormities.
If there are no relevant protection switching alarms, anomalies, or
APS_FAIL, it indicates that the switching fails.
2. Check if the configuration data of the protection is correct.
3. Check if the status of the standby path is normal.
3 Pay special attention to:

l POWER_ALM
l FAN_FAIL
l HARD_BAD
l BD_STATUS
l SYN_BAD
l NESF_LOST
l TEMP_ALARM
l RADIO_RSL_HIGH
l RADIO_RSL_LOW
l RADIO_TSL_HIGH
l RADIO_TSL_LOW
l IF_INPWR_ABN

Note Description

l MW_LIM
l MW_LOF
l R_LOS
l R_LOF
l MS_AIS
l AU_AIS
l AU_LOP
l B1_EXC
l B2_EXC

l HP_LOM
l B3_EXC
l HP_UNEQ

l TU_AIS
l TU_LOP
l BIP_EXC
l T_ALOS
l LP_UNEQ
7 Refer to section 2.8 Troubleshooting Ethernet Service Faults.
⑧ Refer to section 2.6 Troubleshooting the Interconnection with the SDH

Equipment or section 2.7 Troubleshooting the Interconnection with the
PDH Equipment.
Experience and Summary

Carry out routine maintenance to reduce the probability that the equipment becomes faulty. Solve
problems before services are affected.
2.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.
The key to locate a microwave link fault is to check if the transmit power and the receive power
are abnormal.
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 the range of the transmit power, refer to the OptiX RTN 600 Radio Transmission System Product
Description.
In the following two cases, the receive power is abnormal. The first case is that the receive power
always fails to reach the ideal value (free space receive power > theoretical value - 6 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 the receiver sensitivity, refer to the OptiX RTN 600 Radio Transmission System Product Description.
Fault Causes
Table 2-3 Causes of microwave link faults
Fault Common Fault Causes
The transmit power is The ODU is faulty.

abnormal.
The receive power is always l The antenna direction is not properly adjusted.
lower than the ideal value. l The antennas have different polarization directions.
l There is a mountain or obstacle in the transmit direction.
l The performance of the feeder degrades.
The receive power is There is an external interference.

abnormal due to slow up-
fading.
The receive power is The fading margin is not enough.

abnormal due to slow down-
fading.
The receive power is The multipath fading is severe.

abnormal due to fast fading.

NOTE
Depending on the received level, there is up-fading and down-fading.

l Up-fading
The received level is higher than the value after free space fading. The difference can be 10-odd
decibels.
l Down-fading
The received level is lower than the value after free space fading. The difference can be tens of decibels.
Depending on the fading time, there is fast fading and slow fading.
l Fast fading
The fading duration time ranges from several milliseconds to tens of seconds.
l Slow fading
The fading duration time ranges from tens of seconds to several hours.

1. Check if the ODU is silenced, powered off, or looped back. Check if the data configuration
is correct.
2. Check if the ODU and the IF board are faulty.
3. If the transmit power is abnormal, replace the ODU.
4. If the receive power is abnormal, check out the possible causes based on the fading type.
5. If the transmit/receive power is normal, perform loopback operations.

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

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


Note Description
① Check the following points:

l Check if the ODU is powered off.
l Check if the ODU is silenced.
l Check if the IF board is looped back.
l Check if the data configuration at the transmit side is consistent with that
at the receive side.
l Check if the data configuration matches the type of the ODU and the hybrid
coupler.
② Pay special attention to:

l HARD_BAD
l TEMP_ALARM
l IF_INPWR_ABN
l RADIO_MUTE
l RADIO_TSL_HIGH
l RADIO_TSL_LOW
l RADIO_RSL_HIGH
③ Replace the ODU.
④ Follow the steps below:

1. Check the installation of the antenna. Check if the azimuth angle of the
antenna meets the requirement.
2. Check the antenna direction. Check if the received signal is from the main
lobe.
If the antenna direction does not meet the requirement, adjust the antenna
in a wide range.
3. Check if the setting of the polarization direction of the antenna is correct.
Adjust wrong polarization direction.
4. Check if the antenna gain at both the transmit and receive sides meets the
indexes. Replace unqualified antennas.
5. Check if there is a mountain or obstacle in the transmit direction.
⑤ Follow the steps below:

1. Use a spectrum analyzer to analyze the interference source.
2. Contact the spectrum management department to clear the interference
spectrum. Or change plans to reduce the interference.

Note Description
⑥ Contact the network planning department to make the following changes:

l Increase the installation height of the antenna.
l Reduce the transmission distance.
l Increase the antenna gain.
l Increase the transmit power.
⑦ Contact the network planning department to make the following changes:

l 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,
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.
⑧ Follow the steps below:

1. Loop back the IF ports.
If the fault is not cleared after the loopback, replace the IF board.
2. Check if the IF cable is soggy, broken or pressed. Replace the unqualified
cable.
3. Check if the cable connector is made in accordance with specifications.
Remake unqualified ones.
4. Replace the ODU.
If the fault is cleared after the replacement, the original ODU is faulty.
5. Replace the IF cable.
If the fault is cleared after the replacement, the original IF cable is faulty.

l During a commissioning process, make sure that the antenna direction is correctly adjusted
to avoid possible incipient faults.
l Periodically collect the change data of the transmit power and receive power, and analyze
the change data to remove incipient faults in time.
2.4 Troubleshooting Bit Errors

When an NE reports an alarm or performance event on the regenerator section (RS), multiplex
section (MS), higher order path (HP), or lower order path (LP), there are bit errors in services.
The line board detects RS bit errors by the RS overhead byte B1. Related alarms and performance
events are listed below:

l B1_EXC
l B1_SD
l RS_CROSSTR
l RSBBE
l RSES
l RSSES
l RSCSES
l RSUAS
NOTE
When the IF board works in the PDH mode, the above RS bit error alarms and performance events may
also be reported. Such alarms and performance events are detected by the B1 that is defined in the PDH
microwave frame.
The line board detects MS bit errors by the MS overhead byte B2. Related alarms and
performance events are listed below:
l B2_EXC
l B2_SD
l MS_CROSSTR
l MSBBE
l MSES
l MSSES
l MSCSES
l MSUAS
The line board detects HP bit errors by the HP overhead byte B3. Related alarms and performance
events are listed below:
l B3_EXC
l B3_SD
l HP_CROSSTR
l HPBBE
l HPES
l HPSES
l HPCSES
l HPUAS
LP bit errors are detected by PDH service processing boards or Ethernet service processing
boards using the VC-3 overhead byte B3 or VC-12 overhead byte V5. Related alarms and
performance events are listed below:
l B3_EXC_VC3_
l B3_SD_VC3
l BIP_EXC
l BIP_SD

l LP_CROSSTR
l VC3BBE
l VC3ES
l VC3SES
l VC3CSES
l VC3UAS
l LPBBE
l LPES
l LPSES
l LPCSES
l LPUAS
Fault Causes
Table 2-5 Causes of bit errors

Fault Types Common Causes
There are some RS bit errors. l The line is faulty.

– For the optical fiber line, the optical power is abnormal,
the fiber performance degrades, or the fiber connector
is not clean.
– For the STM-1 cable line, the cable performance
degrades, the cable is not properly grounded, or the cable
connector is not in good contact.
– For the microwave line, check if there is an
MW_FECUNCOR alarm or an HSB_INDI alarm.
l The line board is faulty.
l The clock unit is faulty.
l The quality of the clock over the network degrades.
When the quality of the clock over the network degrades,
there will be a pointer justification event.
There is no RS bit error, but l The line board is faulty.

there are MS bit errors or HP l The quality of the clock over the network degrades.
bit errors.
When the quality of the clock over the network degrades,
there will be a pointer justification event.
l The working temperature of the line board is excessively
high.
l There is power surge or an external interference source, or
the equipment is not properly grounded.

Fault Types Common Causes
There are only LP bit errors. l The PDH service processing board or the Ethernet service
processing board is faulty.
l The cross-connect unit is faulty.
l The working temperature of the PDH service processing
board or the Ethernet service processing board is
excessively high.
l The working temperature of the cross-connect unit is
excessively high.
l There is power surge or an external interference source, or
the equipment is not properly grounded.

1. Analyze the equipment alarms and performance events that are related to bit errors.
2. When there are many types of alarms and performance events, first analyze RS bit errors,
then MS bit errors, HP bit errors, and finally LP bit errors.
3. When multiple paths have bit errors, first check if the overlapping part is faulty.
4. When the fault is not located after you analyze the alarms and performance events, perform
loopback operations section by section.
5. For a possibly degraded component, replace it with a new one.

Figure 2-4 Flow of handling bit errors
Start
2
1
Is there an Yes
Handle the alarm
equipment alarm?
No
Is there a pointer Yes Handle the pointer

justification event? justification event
SDH optical 3
No interface board Handle the RS bit error of the
SDH optical interface board
4
Is there an If the IF board Handle the RS bit error of the
RS bit error alarm or a Yes
alarming IF board
performance event? board is
5
STM-1 electrical
No Handle the RS bit error of the
interface board
STM-1 electrical interface
board
6
Is there an
Yes
MS/HP alarm or a Handle the MS/HP bit error
performance event?
No
7
Yes
Is there an LP alarm? Handle the LP bit error
No
Go to the next No
step
Perform loopback operations

section by section Yes
End

Note Description
① Pay special attention to:

l TEMP_ALARM
l SYN_BAD
l HARD_BAD

Note Description
② Refer to section 2.5 Troubleshooting Pointer Justifications.
③ Follow the steps below:

1. Make an exchange between the Tx fiber core and the Rx fiber core at both
ends of the path. If bit errors change after the exchange, the fiber is faulty.
Otherwise, the equipment at the two ends is faulty.
2. In the case that the fiber is faulty, check if the fiber between the equipment
and the ODF and the section of the fiber that is led out of the equipment
room are pressed. Also check if the fiber connector is clean.
3. In the case that the equipment at the two ends is faulty, use a fiber jumper
to loop back the optical ports. After the loopback, if the fault is not cleared,
the line board is most likely faulty.
4. For the case that the equipment at the two ends is faulty, to locate the fault,
you can also replace the board or make an exchange between the board and
another board of the same type that is working normally. If the alarm
changes after the exchange, the board is faulty.

1. Check if there is an MW_FECUNCOR alarm or an HSB_INDI alarm.
2. If yes, refer to section 2.3 Troubleshooting Microwave Links.
3. If no, replace the IF board.
⑤ Follow the steps below:

1. Make an exchange between the Tx cable and the Rx cable at both ends of
the path. If bit errors change after the exchange, the cable is faulty.
Otherwise, the equipment at the two ends is faulty.
2. In the case that the cable is faulty, check the cable connector. Also check
if the cable is properly grounded and if the cable is broken.
3. In the case that the equipment at the two ends is faulty, use a cable to loop
back the electrical ports. After the loopback, if the fault is not cleared, the
line board is most likely faulty.
4. For the case that the equipment at the two ends is faulty, to locate the fault,
you can also replace the board or make an exchange between the board and
another board of the same type that is working normally. If the alarm
changes after the exchange, the board is faulty.
⑥ Follow the steps below:

1. Loop back the alarming line board.
If the fault is not cleared, replace the line board.
If the fault is cleared, replace the line board at the transmit side.
2. If the fault is still not cleared, check if there is power surge or an external
interference source, or if the equipment is not properly grounded (primarily
for the SDH electrical interface board).

Note Description
⑦ Follow the steps below:

1. Based on how the service paths that have bit errors overlap each other,
replace the PDH service processing board or the Ethernet service
processing board or the crocss-connect board.
2. If the fault is not cleared, check if there is power surge or an external
interference source, or if the equipment is properly grounded.

l Take it as a routine job to check bit error performance events and handle them in time.
l To locate a fault, primarily use the method of analyzing alarms and performance events.
Take the loopback method and the replacement method as a supplement.
2.5 Troubleshooting Pointer Justifications

When an NE reports a large amount of justification events of the administrative unit (AU) pointer
or the tributary unit (TU) pointer, there are pointer justification faults.
When the position of the first byte of the VC-4 in the AU-4 payload changes, the AU pointer
makes a justification accordingly. The performance events of the AU pointer justification are as
follows:
l AUPJCHIGH
l AUPJCLOW
l AUPJCNEW
NOTE
The AU pointer justification is generated at an upstream NE but is detected and reported at a downstream
NE.
When the service is configured to be at the VC-12 level, apply the re-framing process to terminate
the AU pointer justification. The terminating method is to transform the AU pointer justification
into the TU pointer justification. The performance events of the TU pointer justification are as
follows:
l TUPJCHIGH
l TUPJCLOW
l TUPJCNEW
NOTE
The TU pointer justification is generated at the NE where the AU pointer is transformed into the TU pointer,
but is detected and reported by the tributary board of the NE where services are terminated.
Fault Causes
l The clock sources or the clock source levels are wrongly configured. As a result, there are
two clock sources in the same network or mutual clock tracing occurs.
l The optical fibers links are wrongly connected. As a result, mutual clock tracing occurs.

l The quality of the clock source degrades. The clock unit is faulty. Or there are other clock
related faults.
l The tributary board is faulty (only for the TU pointer justification).

When there are both AU pointer justifications and TU pointer justifications in a service path,
first handle AU pointer justifications and then TU pointer justifications.
Fault Types Fault Locating Methods
AU pointer justifications 1. Analyze and clear clock alarms.

2. Correct wrong data configurations and wrong fiber
connections.
3. Change the clock and service configurations to find the
stations whose clock is asynchronous with the entire
network.
4. Replace the components whose performance is possibly
poor or degraded to locate a fault.
TU pointer justifications 1. Analyze and clear clock alarms.

2. Correct wrong data configurations and wrong fiber
connections.
3. Change the clock and service configurations to find the
stations whose clock is asynchronous with the entire
network.
4. Replace the components whose performance is possibly
poor or degraded to locate a fault.

Figure 2-5 Flow of handling pointer justifications
Start
1 Is there a clock related Yes

Handle the alarm
alarm?
No
2
Check the clock
configuration
Yes Modify the data

Wrong configuration?
configuration
No
3
Check the fiber connection
Yes
Wrongly connected? Re-connect the fiber
No
4 5
Is there an AU pointer Yes Find the NE whose clock is
out of synchronization Locate the faulty board
justification event?
No
6 7
Is there a TU pointer Yes Find the NE whose clock is

Find the faulty board
justification event? out of synchronization
No
No
Go to the next step Is the fault cleared?
Yes
End


Note Description

l TEMP_ALARM
l SYN_BAD
l HARD_BAD
l LTI
l SYNC_C_LOS
l S1_SYN_CHANGE
l EXT_SYNC_LOS
② Check the following points:

l Check if there are two clock reference sources in the entire network.
l Check if mutual clock tracing occurs.
③ Query ECC routes to check if the fibers are correctly connected. Check the fiber
connection in the east and west directions of the NE that reports the pointer
justification event.

1. Find a VC-4 channel that reports an AU pointer justification event.
2. Along the service source direction of the VC-4 channel, find the source NE of
the entire VC-4 service (not the source NE of a timeslot in the VC-4).
3. Set the clock of the source NE to free-run. Set other NEs to trace the clock of
the source NE along the direction of the VC-4 service.
4. Along the clock tracing direction, find the line board that is the first to report
the AU pointer justification of the VC-4 channel.
The clock of the remote NE to which the line board is connected is
asynchronous with the reference clock. Hence, the line board in the remote NE
that receives the clock signal, the line board that sends the clock signal to the
remote NE, and the clock unit of the remote NE, may be faulty.
5. Set the clock of the sink NE of the VC-4 service to free-run. Set other NEs to
trace the clock of the sink NE along the direction of the VC-4 service.
6. Along the clock tracing direction, find the line board that is the first to report
the AU pointer justification of the VC-4 channel.
The clock of the remote NE to which the line board is connected is
asynchronous with the reference clock. Hence, the line board in the remote NE
that receives the clock signal, the line board that sends the clock signal to the
remote NE, and the clock unit of the remote NE, may be faulty.
7. Compare the results and find out the common points.
⑤ Replace the possibly faulty boards.

Note Description
⑥ Follow the steps below:

1. Modify the service configuration to make the NE where the clock reference
source is as the central NE. Other NEs has the E1 service of the central NE.
2. Along the clock tracing direction, find the NE that is the first to report the TU
pointer justification.
The clock of the NE is asynchronous with the reference clock. Hence, the line
board in the NE that receives the clock signal, the line board that sends the
clock signal to the NE, and the clock unit of the NE, may be faulty.
3. Modify the configuration data to make all NEs trace the clock in another
direction.
4. Along the clock tracing direction, find the NE that is the first to report the TU
pointer justification.
The clock of the NE is asynchronous with the reference clock. Hence, the line
board in the NE that receives the clock signal, the line board that sends the
clock signal to the NE, and the clock unit of the NE, may be faulty.
5. Compare the results and find out the common points.
NOTE
This method is also applicable in locating an AU pointer justification event.
⑦ Replace the possibly faulty boards. For a TU pointer justification, check the line
board, the clock board, and the tributary board.

In a well synchronized network, there are few pointer justifications (less than six per day). Hence,
monitoring the pointer of an SDH transmission system is an effective way to check the
synchronization of the system.
2.6 Troubleshooting the Interconnection with the SDH

Equipment
In the case that the OptiX RTN 600 is interconnected with the SDH equipment, if the SDH
Fault Causes
l The VC-12 numbering method of Huawei equipment is different from that of some vendors'
equipment.
The OptiX equipment applies the timeslot numbering method. The numbering formula is:
VC-12 number = TUG-3 number + (TUG-2 number - 1) x 3 + (TU-12 number - 1) x 21
Some equipment applies the line numbering method. The numbering formula is: VC-12
number = (TUG-3 number - 1) x 21 + (TUG-2 number - 1) x 3 + TU-12 number
l The overhead bytes at the two sides are inconsistent.
l The indexes of SDH interfaces do not meet requirements.

l The equipment is not properly grounded (only for the STM-1 electrical interface).
NOTE
When the interconnected equipment is the ATM or Ethernet equipment, the common cause for the
interconnection fault is that the service is not set to the VC-4 pass-through service. As a result, the overheads
are processed in the terminating mode instead of the pass-through mode.

Analyze the fault phenomenon and alarms. Check the possible fault causes one by one.

Figure 2-6 Flow of troubleshooting the interconnection with the SDH equipment
Start
Is the
Yes Set the interconnection service
interconnected equipment
to be the VC-4 pass-through
the ATM/IP equipment?
service
No
Query the VC-12 numbering
method of the interconnected
equipment
Is the Modify the data configuration.

Yes
numbering mode the line Use the line numbering method
numbering? to set the VC-12
No
1 Is there an overhead Yes

setting related alarm? Handle the alarm
No
2
Yes
Is the interface the STM- Check the grounding
1 electrical interface?
3 No
Test the indexes of interfaces
No Handle the faults of the

Do the interfaces meet
relevant standards? interconnected equipment
Yes Go to the next No

step Is the fault cleared?
Handle the faults of the local Yes

equipment
End


Note Description

l J0_MM
l HP_TIM
l LP_TIM
l LP_TIM_VC12
l LP_TIM_VC3
l HP_SLM
l LP_SLM
l LP_SLM_VC12
l LP_SLM_VC3

l Check if all the equipment and the DDF in the equipment room are jointly
grounded.
l Check if the shielding layer of the coaxial cable connector on the DDF is
connected to the protection ground.
l Check if the shielding layers of coaxial cables are grounded in the same
way.
NOTE
Disconnect all the signal cables between the interconnecting equipment. Use a
multimeter to measure the level between the shielding layers of the coaxial cables at the
receive and transmit ends of the SDH equipment. Also measure the level between the
shielding layers of the coaxial cables at the receive and transmit ends of the opposite
equipment. If the potential difference is large (about 0.5 V), the fault may be caused by
the grounding.
③ Common indexes of the optical interfaces:

l Mean launched optical power
l Extinction ratio
l Operating wavelength of the laser
l Receiver sensitivity
l Overload optical power
l Permitted frequency deviation of the input interface
l Output jitter
l Jitter and wander tolerance
Common indexes of the electrical interfaces:
l Permitted frequency deviation of the input interface
l Allowed attenuation of the input interface
l Input jitter and wander tolerance
l Output jitter


To clear any interconnection fault, it is a must to have a sound knowledge of the characteristics
of the interfaces of the interconnected equipment.
2.7 Troubleshooting the Interconnection with the PDH

Equipment
In the case that the OptiX RTN 600 is interconnected with the PDH equipment, if the PDH
Fault Causes
l There is an impedance mismatch between interfaces.
l The equipment is not properly grounded.
l The cable performance degrades.
l The indexes of PDH interfaces do not meet requirements.

Analyze the fault phenomenon and alarms. Check the possible fault causes one by one.

Figure 2-7 Flow of troubleshooting the interconnection with the PDH equipment
Start
1
Check the impedance of
the interfaces
Is there an Yes Replace the cable or the

impedance mismatch?
tributary board
No
2
Is the cable the Yes
Check the grounding
coaxial cable?
No
3
Check the cables
Is in good No
Adjust the cables
conditions?
4 Yes
Test the indexes of
interfaces
Do the interfaces No Handle the faults of the

meet standards? interconnected equipment
Yes Go to the next No

step
Yes
Handle the faults of the
local equipment
End


Note Description
① Check if the type of the tributary board matches the type of the cable.

l Check if all the equipment and the DDF in the equipment room are jointly
grounded.
l Check if the shielding layer of the coaxial cable connector on the DDF is
connected to the protection ground.
l Check if the shielding layers of coaxial cables are grounded in the same
way.
NOTE
Disconnect all the signal cables between the interconnecting equipment. Use a
multimeter to measure the level between the shielding layers of the coaxial cables at the
receive and transmit ends of the PDH equipment. Also measure the level between the
shielding layers of the coaxial cables at the receive and transmit ends of the opposite
equipment. If the potential difference is large (about 0.5 V), the fault may be caused by
the grounding.
③ Check the following points:

l Check if the wires of the cable are correctly connected.
l Check if the cable is too long (for example, longer than 50 meters).
l Check if the cable is broken or pressed.
l Check if the cable signal is interfered (for example, when the trunk cable
is bound with the power cable, the cable signal is interfered by the power
signal).
④ Check the following indexes:

l Input jitter tolerance
l Permitted input frequency deviation
l Input reflection attenuation
l Output jitter
l Output frequency deviation
l Output waveform

Grounding problems are the most common reasons that cause an interconnection failure when
the OptiX RTN 600 is interconnected with the PDH equipment.
2.8 Troubleshooting Ethernet Service Faults

An Ethernet service fault might be Ethernet service interruption or Ethernet service degradation.
Ethernet service interruption indicates that the Ethernet service is completely interrupted.
Ethernet service degradation indicates that the Ethernet service is abnormal. For example, the

network speed is low, the equipment delay is long, loss of packets occurs, or incorrect packets
exist in the received or transmitted data.
Fault Causes
l Human factors are as follows:
– An Ethernet board loopback or a transmission line loopback occurs.
– The settings of parameters of an Ethernet port such as port enabled, working mode, and
flow control are different from those of its interconnected equipment.
– The configuration of the encapsulation/mapping protocol or the LCAS protocol is
different from that of the opposite equipment.
– The VCTRUNK-bound timeslot is different from that of the opposite equipment.
l Equipment faults are as follows:
l The line board is faulty or has bit errors.
l The interconnected equipment is faulty.
l The network cable is faulty.
l The external electromagnetic interference is severe.

1. Clear the human factors such as a loopback and data configuration error.
2. Locate the fault cause according to the equipment alarm.
3. Locate the fault cause according to the RMON performance event and alarm.

Figure 2-8 Flow of handling Ethernet service faults
Start
1
Yes
Incorrect operation? Roll back this operation.
No
2
Equipment Yes
or line alarm? Handle the alarm.
No
3
Yes
Ethernet interface Handle the alarm.
alarm?
No
4
Yes
Ethernet protocol Handle the alarm.
alarm?
No
5 Collisions or Yes Troubleshoot according to

fragements? the flow of handling the
RMON performance event.
No
Fault of the Yes

Troubleshoot faults of the
opposite equipment?
opposite equipment.
No
Troubleshoot equipment
Proceed No Are faults
faults by performing
with the cleared?
loopbacks section by
next step.
section or replacing boards.
Yes
End


Note Description

l Whether a loopback is set for the Ethernet board
l Whether a loopback is set for the transmission line
l Whether the settings of parameters of an Ethernet port such as port enabled,
working mode, and flow control are the same as those of its interconnected
equipment
l Whether the configuration of the encapsulation/mapping protocol or the
LCAS protocol is the same as that of the opposite equipment
l Whether the VCTRUNK-bound timeslot is the same as that of the opposite
equipment
② Check the following equipment alarms:

l POWER_ALM
l FAN_FAIL
l HARD_BAD
l BD_STATUS
l SYN_BAD
l NESF_LOST
l TEMP_ALARM
l RADIO_RSL_HIGH
l RADIO_RSL_LOW
l RADIO_TSL_HIGH
l RADIO_TSL_LOW
l IF_INPWR_ABN
Check the following line alarms:
l MW_LIM
l MW_LOF
l R_LOS
l R_LOF
l MS_AIS
l AU_AIS
l AU_LOP
l B1_EXC
l B2_EXC
③ Check the following:

l ETH_LOS
l ALM_GFP_dCSF

Note Description
④ Check the following:

l ALM_GFP_dLFD
l FCS_ERR
l LCAS_PLCT
l LCAS_TLCT
l LCAS_PLCR
l LCAS_TLCR
l LCAS_FOPT
l LCAS_FOPR
⑤ For RMON performance events, refer to C Ethernet RMON Performance

List.

Figure 2-9 Flow of handling RMON abnormal performance events
Start
1
Analyze the RMON
performance.
2
Yes Troubleshoot bit errors
FCS errors?
on the line.
No
3
Yes Check the working
Collisions or fragements?
mode of a port.
No
4
Yes Handle the flow
PAUSE frame? control problem or
add bandwidths.
No
Test with a meter.
Yes Troubleshoot faults of

Pass the test?
the opposite equipment.
No
5
Yes
MTU setting
Modify the MTU value.
errors?
No
Proceed No Are faults
Troubleshoot equipment
with the cleared?
faults by performing
next step.
loopbacks section by
section or replacing boards. Yes
End

Note Description
① Refer to C Ethernet RMON Performance List.
② Refer to section 2.4 Troubleshooting Bit Errors.

Note Description
③ Check the following points:

l Whether the port operating rate of this equipment is the same as that of its
l Whether the duplex/half-duplex mode of ports on this equipment is the
same as that on its interconnected equipment
④ Check the following points:

l Whether the flow control mode of this equipment is the same as that of its
l Whether the Ethernet service volume is larger that the configured
VCTRUNK bandwidth
⑤ The Maximum Transmission Unit (MTU) of a network can be tested by a test

meter. The maximum frame length that is set for a port must be longer than
this maximum network MTU.

Learn the features, working mode, and configured protocols of interfaces on Ethernet equipment,
which is a must to troubleshoot Ethernet faults.
2.9 Troubleshooting the Orderwire

If orderwire calls cannot get through when services are normal, there is an orderwire fault.
Fault Causes
l The phone set is incorrectly set.
l The phone line is wrongly connected.
l The orderwire is incorrectly configured.
l The SCC board is faulty.
l The line board is faulty.

l Check if the phone set is correctly set, if the phone line is correctly connected, and if the
orderwire is correctly configured.
l Replace a possibly faulty board to check it out.

Figure 2-10 Flow of handling orderwire faults
Start
Check the phone setting
Is the phone No
Modify the phone setting
correctly set?
Yes
Is the phone line No

Re-connect the phone line
correctly connected?
Yes
2
Check the orderwire
configuration
Is the configuration No
Modify the configuration
correct?
3 Yes
Replace the possibly faulty
board
Go to the next No
step
Yes
End


Note Description

l Check if the ring current switch "RING" on the phone set is set to "ON".
l Check if the dialing mode switch is set to "T", that is, the dual tone multi-
frequency mode.
l An orderwire phone set should be on-hook when it is not in communication,
and the upper-right red indicator in the front view of the orderwire phone
set should be off.
If the red indicator is on, it indicates that the phone set is in the off-hook
state. Press the "TALK" button in the front of phone set to hook it up. In
some occasions the "TALK" button is pressed by the maintenance
personnel due to carelessness. This makes the phone set stay in the off-
hook state all the time and the orderwire call from other NEs cannot get
through.

l Check if all orderwire phone numbers in a subnet are of the same length.
l Check if all orderwire phone numbers in a subnet are unique.
l Check if the overhead bytes of all NEs in a subnet are the same.
l Check if the orderwire port is correctly set.
③ Replace the SCC board and the line board that extracts the orderwire byte to
locate the faulty board.

It is necessary to periodically check the orderwire phone set.

Troubleshooting Guide RTN PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Troubleshooting Guide RTN PDF

Uploaded by

Copyright:

Available Formats

OptiX RTN 600 Radio Transmission System

Maintenance Guide 2 Troubleshooting Guide

About This Chapter

2.1 General Fault Locating Procedures

Issue 06 (2007-12-30) Huawei Technologies Proprietary 2-1

2.1 General Fault Locating Procedures

2-2 Huawei Technologies Proprietary Issue 06 (2007-12-30)

Figure 2-1 General fault locating procedures

Record the fault phenomenon

Is the fault cleared? Yes

Make a solution together

Attempt to clear the fault

Observe the operating

Fill in the fault handling report

Issue 06 (2007-12-30) Huawei Technologies Proprietary 2-3

Table 2-1 Flow description

③ If the fault is caused by the equipment, refer to 2.2 Troubleshooting Service

④ Contact Huawei engineers to report problems and obtain technical support.

2.2 Troubleshooting Service Interruptions

Fault Locating Methods

2-4 Huawei Technologies Proprietary Issue 06 (2007-12-30)

Fault Locating Procedures

Figure 2-2 Flow of handling service interruptions

Is there a wrong Yes Cancel the operation

Issue 06 (2007-12-30) Huawei Technologies Proprietary 2-5

Table 2-2 Flow description

1 Operations that may cause a service interruption are as follows:

2 Follow the steps below:

3 Pay special attention to:

2-6 Huawei Technologies Proprietary Issue 06 (2007-12-30)

4 Pay special attention to:

5 Pay special attention to:

6 Pay special attention to:

7 Refer to section 2.8 Troubleshooting Ethernet Service Faults.

⑧ Refer to section 2.6 Troubleshooting the Interconnection with the SDH

Experience and Summary

2.3 Troubleshooting Microwave Links

Issue 06 (2007-12-30) Huawei Technologies Proprietary 2-7

Table 2-3 Causes of microwave link faults

Fault Common Fault Causes

The transmit power is The ODU is faulty.

The receive power is There is an external interference.

The receive power is The fading margin is not enough.

The receive power is The multipath fading is severe.

2-8 Huawei Technologies Proprietary Issue 06 (2007-12-30)

Depending on the received level, there is up-fading and down-fading.

Fault Locating Methods

Issue 06 (2007-12-30) Huawei Technologies Proprietary 2-9

Fault Locating Procedures

Figure 2-3 Flow of handling microwave link faults

2 Is there an ODU or IF Yes

2-10 Huawei Technologies Proprietary Issue 06 (2007-12-30)

Table 2-4 Flow description

① Check the following points:

② Pay special attention to:

③ Replace the ODU.

④ Follow the steps below:

⑤ Follow the steps below:

Issue 06 (2007-12-30) Huawei Technologies Proprietary 2-11

⑥ Contact the network planning department to make the following changes:

⑦ Contact the network planning department to make the following changes:

⑧ Follow the steps below:

Experience and Summary