01-02 Troubleshooting Guide RTN

OptiX RTN 600 Radio Transmission System Maintenance Guide
2 Troubleshooting Guide
2
About This Chapter
Troubleshooting Guide
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 service cannot be transmitted between the equipment sets, there is an interconnection fault. 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.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 1 Record the fault phenomenon
Caused by external factors? No
Yes
Other handling procedures
Analyze fault causes and locate the fault
Is the fault cleared? 4 No Report to Huawei
Yes
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
Issue 06 (2007-12-30)
2-3
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. The protection switching fails. The transmission NE or link is faulty. 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.
l l l
Fault Locating Methods

1. 2. Check out the operations done before the service interruption. 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.
2-4
Issue 06 (2007-12-30)
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 operation? No Are service paths protected? No 3 Is there an equipment alarm? Yes Handle the alarm Yes Yes 2 Handle switching failure Cancel the operation
No 4 Is there a line alarm? No 5 Is there an HP alarm? No 6 Is there an LP alarm?
Yes
Handle the alarm
Yes
Handle the alarm
Yes
Handle the alarm 7
Are Ethernet services interrupted? No Is there an interconnection fault? No Yes
Handle the Ethernet services fault
8 Handle the interconnection fault No
Go to the next step Perform loopback operations section by section
Is the fault cleared? Yes End
Issue 06 (2007-12-30)
2-5
Table 2-2 Flow description Note 1 Description Operations that may cause a service interruption are as follows:
l l l l l
Modifying the data configuration Performing loopback operations Shutting down the laser Silencing the ODU Replacing boards/cables
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.
Pay special attention to:

l l l l l l l l l l l l
POWER_ALM FAN_FAIL HARD_BAD BD_STATUS SYN_BAD NESF_LOST TEMP_ALARM RADIO_RSL_HIGH RADIO_RSL_LOW RADIO_TSL_HIGH RADIO_TSL_LOW IF_INPWR_ABN
2-6
Issue 06 (2007-12-30)
Note 4
Description Pay special attention to:

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

l l l
HP_LOM B3_EXC HP_UNEQ

l l l l l
TU_AIS TU_LOP BIP_EXC T_ALOS LP_UNEQ
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
Issue 06 (2007-12-30) Huawei Technologies Proprietary 2-7
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 l l l l
RADIO_TSL_HIGH RADIO_TSL_LOW TSL_CUR TSL_MAX 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 l l l l
RADIO_RSL_HIGH RADIO_RSL_LOW RSL_CUR RSL_MAX 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 The transmit power is abnormal. The receive power is always lower than the ideal value. Common Fault Causes The ODU is faulty.
l l l l
The antenna direction is not properly adjusted. The antennas have different polarization directions. There is a mountain or obstacle in the transmit direction. The performance of the feeder degrades.
The receive power is abnormal due to slow upfading. The receive power is abnormal due to slow downfading. The receive power is abnormal due to fast fading.
2-8
There is an external interference.
The fading margin is not enough.
The multipath fading is severe.
Issue 06 (2007-12-30)
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.
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. Slow fading The fading duration time ranges from tens of seconds to several hours.

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

Figure 2-3 Flow of handling microwave link faults
Start
Yes Is there a wrong operation? No Cancel the operation
Is there an ODU or IF board related fault? No
Yes
Handle the alarm
No Normal transmit power? Yes The receive power always lower than the ideal value? No Yes
3 Handle the fault
4 Handle the fault
5 Abnormal receive Yes power caused by slow upfading? No 6 Abnormal receive power caused by slow down-fading? No 7 Abnormal receive power caused by fast fading? 8 No Perform loopback operations Go to the next step No Is the fault cleared? Yes End Yes Handle the fault Yes Handle the fault Handle the fault
2-10
Issue 06 (2007-12-30)
Table 2-4 Flow description Note Description Check the following points:
l l l l
Check if the ODU is powered off. Check if the ODU is silenced. Check if the IF board is looped back. Check if the data configuration at the transmit side is consistent with that at the receive side. Check if the data configuration matches the type of the ODU and the hybrid coupler.

l l l l l l l
HARD_BAD TEMP_ALARM IF_INPWR_ABN RADIO_MUTE RADIO_TSL_HIGH RADIO_TSL_LOW 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.
Issue 06 (2007-12-30)
2-11
Note
Description Contact the network planning department to make the following changes:
l l l l
Increase the installation height of the antenna. Reduce the transmission distance. Increase the antenna gain. 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. Adjust the RF configuration to make the links in the 1+1 SD configuration. 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. Increase the fading margin.
l l
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. 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:
2-12
Issue 06 (2007-12-30)

l l l l l l l l
B1_EXC B1_SD RS_CROSSTR RSBBE RSES RSSES RSCSES 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 l l l l l l l
B2_EXC B2_SD MS_CROSSTR MSBBE MSES MSSES MSCSES MSUAS
The line board detects HP bit errors by the HP overhead byte B3. Related alarms and performance events are listed below:
l l l l l l l l
B3_EXC B3_SD HP_CROSSTR HPBBE HPES HPSES HPCSES 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 l l l
B3_EXC_VC3_ B3_SD_VC3 BIP_EXC BIP_SD

Huawei Technologies Proprietary 2-13
Issue 06 (2007-12-30)
l l l l l l l l l l l
LP_CROSSTR VC3BBE VC3ES VC3SES VC3CSES VC3UAS LPBBE LPES LPSES LPCSES LPUAS
Fault Causes
Table 2-5 Causes of bit errors Fault Types There are some RS bit errors. Common Causes
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 l l
The line board is faulty. The clock unit is faulty. 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 there are MS bit errors or HP bit errors.
l l
The line board is faulty. 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.
The working temperature of the line board is excessively high. There is power surge or an external interference source, or the equipment is not properly grounded.
2-14
Issue 06 (2007-12-30)
Fault Types There are only LP bit errors.
Common Causes
l
The PDH service processing board or the Ethernet service processing board is faulty. The cross-connect unit is faulty. The working temperature of the PDH service processing board or the Ethernet service processing board is excessively high. The working temperature of the cross-connect unit is excessively high. There is power surge or an external interference source, or the equipment is not properly grounded.
l l

1. 2. 3. 4. 5. Analyze the equipment alarms and performance events that are related to bit errors. 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. When multiple paths have bit errors, first check if the overlapping part is faulty. When the fault is not located after you analyze the alarms and performance events, perform loopback operations section by section. For a possibly degraded component, replace it with a new one.
Issue 06 (2007-12-30)
2-15

Figure 2-4 Flow of handling bit errors
Start
2 1 Is there an equipment alarm? No Is there a pointer justification event? Yes Handle the pointer justification event SDH optical interface board 3 Handle the RS bit error of the SDH optical interface board 4 Is there an RS bit error alarm or a performance event? No Yes If the alarming board is IF board Handle the RS bit error of the IF board 5 Handle the RS bit error of the STM-1 electrical interface board 6 Yes Handle the MS/HP bit error Yes Handle the alarm
No
STM-1 electrical interface board
Is there an MS/HP alarm or a performance event? No Is there an LP alarm? No
7 Yes Handle the LP bit error
Go to the next step Perform loopback operations section by section
No
Is the fault cleared?
Yes End
Table 2-6 Flow description Note Description Pay special attention to:
l l l
TEMP_ALARM SYN_BAD HARD_BAD

Issue 06 (2007-12-30)
2-16
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.
Follow the steps below: 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).
Issue 06 (2007-12-30)
2-17
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 l
Take it as a routine job to check bit error performance events and handle them in time. 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 l l
AUPJCHIGH AUPJCLOW 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 l l
TUPJCHIGH TUPJCLOW 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. The optical fibers links are wrongly connected. As a result, mutual clock tracing occurs.
Huawei Technologies Proprietary Issue 06 (2007-12-30)
2-18

l
The quality of the clock source degrades. The clock unit is faulty. Or there are other clock related faults. 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 AU pointer justifications Fault Locating Methods 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.
Issue 06 (2007-12-30)
2-19

Figure 2-5 Flow of handling pointer justifications
Start
1 Is there a clock related alarm? 2 No Check the clock configuration
Yes
Handle the alarm
Wrong configuration? No
Yes
Modify the data configuration
Check the fiber connection
Wrongly connected?
Yes Re-connect the fiber
No 4 Is there an AU pointer Yes justification event? No Is there a TU pointer justification event? No Go to the next step Yes Find the NE whose clock is out of synchronization 5 Locate the faulty board
6 Find the NE whose clock is out of synchronization
7 Find the faulty board
No
Is the fault cleared?
Yes End
2-20
Issue 06 (2007-12-30)
l l l l l l l
TEMP_ALARM SYN_BAD HARD_BAD LTI SYNC_C_LOS S1_SYN_CHANGE EXT_SYNC_LOS
Check the following points:

l l
Check if there are two clock reference sources in the entire network. 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. Follow the steps below: 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.
Issue 06 (2007-12-30)
2-21
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 service cannot be transmitted between the equipment sets, there is an interconnection fault.
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 l
The overhead bytes at the two sides are inconsistent. The indexes of SDH interfaces do not meet requirements.
Huawei Technologies Proprietary Issue 06 (2007-12-30)
2-22

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.
Issue 06 (2007-12-30)
2-23

Figure 2-6 Flow of troubleshooting the interconnection with the SDH equipment
Start
Is the interconnected equipment the ATM/IP equipment? No Query the VC-12 numbering method of the interconnected equipment
Yes
Set the interconnection service to be the VC-4 pass-through service
Is the numbering mode the line numbering? No 1 Is there an overhead setting related alarm? No
Yes
Modify the data configuration. Use the line numbering method to set the VC-12
Yes
Handle the alarm
2 Yes Check the grounding
Is the interface the STM1 electrical interface? 3 No Test the indexes of interfaces
Do the interfaces meet relevant standards?
No
Handle the faults of the interconnected equipment
Yes
Go to the next step Handle the faults of the local equipment
No
Is the fault cleared? Yes
End
2-24
Issue 06 (2007-12-30)
l l l l l l l l l
J0_MM HP_TIM LP_TIM LP_TIM_VC12 LP_TIM_VC3 HP_SLM LP_SLM LP_SLM_VC12 LP_SLM_VC3

l
Check if all the equipment and the DDF in the equipment room are jointly grounded. Check if the shielding layer of the coaxial cable connector on the DDF is connected to the protection ground. 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 l l l l l l l
Mean launched optical power Extinction ratio Operating wavelength of the laser Receiver sensitivity Overload optical power Permitted frequency deviation of the input interface Output jitter Jitter and wander tolerance Permitted frequency deviation of the input interface Allowed attenuation of the input interface Input jitter and wander tolerance Output jitter
Common indexes of the electrical interfaces:

l l l l
Issue 06 (2007-12-30)
2-25

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 service cannot be transmitted between the equipment sets, there is an interconnection fault.
Fault Causes
l l l l
There is an impedance mismatch between interfaces. The equipment is not properly grounded. The cable performance degrades. The indexes of PDH interfaces do not meet requirements.

Analyze the fault phenomenon and alarms. Check the possible fault causes one by one.
2-26
Issue 06 (2007-12-30)

Figure 2-7 Flow of troubleshooting the interconnection with the PDH equipment
Start 1 Check the impedance of the interfaces
Is there an Yes impedance mismatch? No Is the cable the coaxial cable? 3 No Check the cables Yes
Replace the cable or the tributary board 2 Check the grounding
Is in good conditions? 4 Yes Test the indexes of interfaces
No
Adjust the cables
Do the interfaces meet standards? Yes
No
Handle the faults of the interconnected equipment Go to the next step No Is the fault cleared? Yes Handle the faults of the local equipment End
Issue 06 (2007-12-30)
2-27
Table 2-9 Flow description Note Description Check if the type of the tributary board matches the type of the cable. Check the following points:
l
Check if all the equipment and the DDF in the equipment room are jointly grounded. Check if the shielding layer of the coaxial cable connector on the DDF is connected to the protection ground. 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.

l l l l
Check if the wires of the cable are correctly connected. Check if the cable is too long (for example, longer than 50 meters). Check if the cable is broken or pressed. 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 l l l l l
Input jitter tolerance Permitted input frequency deviation Input reflection attenuation Output jitter Output frequency deviation 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
2-28 Huawei Technologies Proprietary Issue 06 (2007-12-30)
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 l l l l
Equipment faults are as follows: The line board is faulty or has bit errors. The interconnected equipment is faulty. The network cable is faulty. The external electromagnetic interference is severe.

1. 2. 3. Clear the human factors such as a loopback and data configuration error. Locate the fault cause according to the equipment alarm. Locate the fault cause according to the RMON performance event and alarm.
Issue 06 (2007-12-30)
2-29

Figure 2-8 Flow of handling Ethernet service faults
Start
1 Incorrect operation? No 2 Equipment or line alarm? No 3 Ethernet interface alarm? No 4 Ethernet protocol alarm? No 5 Collisions or fragements? No Fault of the opposite equipment? No
Yes
Roll back this operation.
Yes
Handle the alarm.
Yes
Handle the alarm.
Yes
Handle the alarm.
Yes
Troubleshoot according to the flow of handling the RMON performance event.
Yes
Troubleshoot faults of the opposite equipment.
Troubleshoot equipment faults by performing loopbacks section by section or replacing boards.
Proceed with the next step.
No
Are faults cleared? Yes End
2-30
Issue 06 (2007-12-30)
l l l
Whether a loopback is set for the Ethernet board Whether a loopback is set for the transmission line 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 Whether the configuration of the encapsulation/mapping protocol or the LCAS protocol is the same as that of the opposite equipment Whether the VCTRUNK-bound timeslot is the same as that of the opposite equipment
Check the following equipment alarms:

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

l l l l l l l l l
Check the following:

l l
ETH_LOS ALM_GFP_dCSF
Issue 06 (2007-12-30)
2-31
Note
Description Check the following:

l l l l l l l l
ALM_GFP_dLFD FCS_ERR LCAS_PLCT LCAS_TLCT LCAS_PLCR LCAS_TLCR LCAS_FOPT LCAS_FOPR
For RMON performance events, refer to C Ethernet RMON Performance List.
2-32
Issue 06 (2007-12-30)
Figure 2-9 Flow of handling RMON abnormal performance events

Start 1 Analyze the RMON performance.
FCS errors? No
Yes
2 Troubleshoot bit errors on the line.
Collisions or fragements? No PAUSE frame? No Test with a meter.
Yes
3 Check the working mode of a port.
Yes
Handle the flow control problem or add bandwidths.
Pass the test? No 5 MTU setting errors? No Troubleshoot equipment faults by performing loopbacks section by section or replacing boards.
Yes
Troubleshoot faults of the opposite equipment.
Yes Modify the MTU value.
Proceed with the next step.
No
Are faults cleared? Yes
End
Table 2-11 Flow description Note Description Refer to C Ethernet RMON Performance List. Refer to section 2.4 Troubleshooting Bit Errors.
Issue 06 (2007-12-30)
2-33
Note
Description Check the following points:

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

l
Whether the flow control mode of this equipment is the same as that of its interconnected equipment 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 l l l l
The phone set is incorrectly set. The phone line is wrongly connected. The orderwire is incorrectly configured. The SCC board is faulty. 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. Replace a possibly faulty board to check it out.
2-34
Issue 06 (2007-12-30)

Figure 2-10 Flow of handling orderwire faults
Start 1 Check the phone setting
Is the phone correctly set? Yes Is the phone line correctly connected? Yes 2 Check the orderwire configuration
No
Modify the phone setting
No
Re-connect the phone line
Is the configuration correct? Yes 3 Replace the possibly faulty board
No
Modify the configuration
Go to the next step
No
Is the fault cleared? Yes
End
Issue 06 (2007-12-30)
2-35
l l
Check if the ring current switch "RING" on the phone set is set to "ON". Check if the dialing mode switch is set to "T", that is, the dual tone multifrequency mode. 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 offhook state all the time and the orderwire call from other NEs cannot get through.

l l l l
Check if all orderwire phone numbers in a subnet are of the same length. Check if all orderwire phone numbers in a subnet are unique. Check if the overhead bytes of all NEs in a subnet are the same. 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.
2-36
Issue 06 (2007-12-30)

01-02 Troubleshooting Guide RTN

Uploaded by

Document Information

Original Description:

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

01-02 Troubleshooting Guide RTN

Uploaded by

Copyright:

Available Formats

OptiX RTN 600 Radio Transmission System Maintenance Guide

OptiX RTN 600 Radio Transmission System Maintenance Guide

2.1 General Fault Locating Procedures

Huawei Technologies Proprietary

OptiX RTN 600 Radio Transmission System Maintenance Guide

Figure 2-1 General fault locating procedures

Caused by external factors? No

Other handling procedures

Analyze fault causes and locate the fault

Is the fault cleared? 4 No Report to Huawei

Make a solution together

Attempt to clear the fault

Is the service restored? Yes Observe the operating

Is the fault cleared? Yes Fill in the fault handling report

Huawei Technologies Proprietary

OptiX RTN 600 Radio Transmission System Maintenance Guide

2.2 Troubleshooting Service Interruptions

Fault Locating Methods

Huawei Technologies Proprietary

OptiX RTN 600 Radio Transmission System Maintenance Guide

Fault Locating Procedures

No 4 Is there a line alarm? No 5 Is there an HP alarm? No 6 Is there an LP alarm?

Handle the alarm

Handle the alarm

Handle the alarm 7

Are Ethernet services interrupted? No Is there an interconnection fault? No Yes

Handle the Ethernet services fault

8 Handle the interconnection fault No

Go to the next step Perform loopback operations section by section

Is the fault cleared? Yes End

Huawei Technologies Proprietary

OptiX RTN 600 Radio Transmission System Maintenance Guide

Pay special attention to:

Huawei Technologies Proprietary

OptiX RTN 600 Radio Transmission System Maintenance Guide

Description Pay special attention to:

MW_LIM MW_LOF R_LOS R_LOF MS_AIS AU_AIS AU_LOP B1_EXC B2_EXC

Pay special attention to:

HP_LOM B3_EXC HP_UNEQ

Pay special attention to:

TU_AIS TU_LOP BIP_EXC T_ALOS LP_UNEQ

Experience and Summary

2.3 Troubleshooting Microwave Links

OptiX RTN 600 Radio Transmission System Maintenance Guide

RADIO_TSL_HIGH RADIO_TSL_LOW TSL_CUR TSL_MAX TSL_MIN

RADIO_RSL_HIGH RADIO_RSL_LOW RSL_CUR RSL_MAX RSL_MIN

There is an external interference.

The fading margin is not enough.

The multipath fading is severe.

Huawei Technologies Proprietary

OptiX RTN 600 Radio Transmission System Maintenance Guide

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

Fault Locating Methods

Huawei Technologies Proprietary

OptiX RTN 600 Radio Transmission System Maintenance Guide

Fault Locating Procedures

Yes Is there a wrong operation? No Cancel the operation

Is there an ODU or IF board related fault? No

Handle the alarm

3 Handle the fault

4 Handle the fault

Huawei Technologies Proprietary

OptiX RTN 600 Radio Transmission System Maintenance Guide