Method of Fault Locating

Huawei Transport Network Maintenance
Reference (Volume 5)
RTN Microwave

Issue 01
Date 2011-12-30

HUAWEI TECHNOLOGIES CO., LTD.

Copyright Huawei Technologies Co., Ltd. 2011. All rights reserved.
No part of this document may be reproduced or transmitted in any form or by any means without prior
written consent of Huawei Technologies Co., Ltd.

Trademarks and Permissions
and other Huawei trademarks are trademarks of Huawei Technologies Co., Ltd.
All other trademarks and trade names mentioned in this document are the property of their respective
holders.

Notice
The purchased products, services and features are stipulated by the contract made between Huawei and
the customer. All or part of the products, services and features described in this document may not be
within the purchase scope or the usage scope. Unless otherwise specified in the contract, all statements,
information, and recommendations in this document are provided "AS IS" without warranties, guarantees or
representations of any kind, either express or implied.
The information in this document is subject to change without notice. Every effort has been made in the
preparation of this document to ensure accuracy of the contents, but all statements, information, and
recommendations in this document do not constitute a warranty of any kind, express or implied.

Huawei Technologies Co., Ltd.
Address: Huawei Industrial Base
Bantian, Longgang
Shenzhen 518129
People's Republic of China
Website: http://www.huawei.com
Email: support@huawei.com

Huawei Transport Network Maintenance Reference
(Volume 5)
RTN Microwave About This Document

Issue 01 (2011-12-30) Huawei Proprietary and Confidential
Copyright Huawei Technologies Co., Ltd.
i

About This Document
Overview
For assisting maintenance engineers in troubleshooting, this document describes how to
troubleshoot OptiX RTN products, and is organized as follows:
Basic principles and common methods for locating faults
This chapter describes basic principles and common methods for locating faults. Each
method is illustrated using an example.
Troubleshooting process and guide
This chapter describes the general troubleshooting process, fault categories, and how to
diagnose each category of faults.
Equipment interworking guide
This chapter provides criteria for correct interworking between OptiX RTN products and
other products, and methods used for locating interworking faults.
Typical cases
This chapter provides typical troubleshooting cases for helping maintenance personnel
improve their fault diagnosis capabilities.
Appendix
This chapter provides references.
Intended Audience
This document is intended for:
Technical support engineers
Maintenance engineers
Symbol Conventions
The symbols that may be found in this document are defined as follows.
Symbol Description

Indicates a hazard with a high level of risk, which if not
avoided, will result in death or serious injury.
(Volume 5)
RTN Microwave About This Document

ii

Symbol Description

Indicates a hazard with a medium or low level of risk, which if
not avoided, could result in minor or moderate injury.

Indicates a potentially hazardous situation, which if not
avoided, could result in equipment damage, data loss,
performance degradation, or unexpected results.

Indicates a tip that may help you solve a problem or save time.

Provides additional information to emphasize or supplement
important points of the main text.

General Conventions
The general conventions that may be found in this document are defined as follows.
Convention Description
Times New Roman Normal paragraphs are in Times New Roman.
Boldface Names of files, directories, folders, and users are in
boldface. For example, log in as user root.
Italic Book titles are in italics.
Courier New Examples of information displayed on the screen are in
Courier New.

Change History
Updates between document issues are cumulative. Therefore, the latest document issue
contains all updates made in previous issues.
Updates in Issue 01 (2011-12-30)
This issue is the first formal release.

(Volume 5)
RTN Microwave Contents

iii

Contents
About This Document ........................................................................................................ i
1 Basic Principles and Common Methods for Locating Faults.......................................... 1
1.1 Basic Principles for Locating Faults ......................................................................................................... 1
1.2 Common Methods for Locating Faults ..................................................................................................... 2
1.3 Signal Flow Analysis .............................................................................................................................. 3
1.3.1 Application Scenarios..................................................................................................................... 3
1.3.2 Method Description........................................................................................................................ 3
1.3.3 Application Example ...................................................................................................................... 3
1.4 Alarm and Performance Analysis ............................................................................................................. 4
1.5 Receive and Transmit Power Analysis ...................................................................................................... 6
1.6 Loopback ............................................................................................................................................... 7
1.7 Replacement......................................................................................................................................... 10
1.7.1 Application Scenarios................................................................................................................... 10
1.7.2 Method Description...................................................................................................................... 10
1.7.3 Application Example .................................................................................................................... 11
1.8 Configuration Data Analysis.................................................................................................................. 12
1.9 Tests Using Instruments and Tools ......................................................................................................... 13
(Volume 5)

iv

1.10 RMON Performance Analysis.............................................................................................................. 15
1.10.1 Application Scenarios ................................................................................................................. 15
1.10.2 Method Description.................................................................................................................... 15
1.10.3 Application Example .................................................................................................................. 16
1.11 Network Planning Analysis.................................................................................................................. 17
1.11.1 Application Scenarios ................................................................................................................. 17
1.11.2 Method Description .................................................................................................................... 17
1.11.3 Application Example .................................................................................................................. 18
2 Troubleshooting Process and Guide ............................................................................ 21
2.1 Troubleshooting Process Overview ........................................................................................................ 21
2.2 Fault Categories.................................................................................................................................... 23
2.3 Troubleshooting Radio Links................................................................................................................. 23
2.3.1 Radio Link Faults......................................................................................................................... 23
2.3.2 Signal Propagation Faults ............................................................................................................. 26
2.4 Troubleshooting TDM Services ............................................................................................................. 27
2.5 Troubleshooting Data Services .............................................................................................................. 28
2.5.1 Services at All Base Stations on an Entire Network or in an Area Are Interrupted............................. 28
2.5.2 Services at All Base Stations on an Entire Network or in an Area Experience Packet Loss ................ 30
2.5.3 Services at Some Base Stations in an Area Are Interrupted ............................................................. 32
2.5.4 Services at Some Base Stations in an Area Experience Packet Loss ................................................. 35
2.6 Troubleshooting Microwave Protection .................................................................................................. 37
2.6.1 Switchover Failure or Delay in Microwave 1+1 Protection ............................................................. 37
2.6.2 Failure to Switch to the Main Unit in Microwave 1+1 Protection .................................................... 38
2.6.3 Switchover Failure or Delay in SNCP Protection ........................................................................... 38
2.7 Troubleshooting Clocks......................................................................................................................... 39
2.7.1 Analyzing Clock Faults ................................................................................................................ 39
2.7.2 Handling Common Clock Alarms ................................................................................................. 40
2.8 Troubleshooting DCN Communication .................................................................................................. 42
2.8.1 Fault Symptoms and Possible Causes ............................................................................................ 42
2.8.2 DCN Troubleshooting Process ...................................................................................................... 45
3 Equipment Interworking Guide ................................................................................... 48
3.1 Interworking Criteria ............................................................................................................................ 48
3.1.1 Interworking Through Ethernet Ports ............................................................................................ 48
3.1.2 Interworking Through SDH Ports.................................................................................................. 49
3.1.3 Interworking Through PDH Ports.................................................................................................. 50
3.2 Methods for Locating Interworking Faults.............................................................................................. 51
4 Typical Cases ................................................................................................................ 52
4.1 List of Cases......................................................................................................................................... 52
4.2 Radio Link Faults ................................................................................................................................. 53
4.2.1 Radio Link Interruptions Due to Multipath Fading ......................................................................... 53
4.2.2 Service Bit Errors Due to Interference to Radio Links .................................................................... 54
(Volume 5)

v

4.3 Data Service Faults ............................................................................................................................... 55
4.3.1 Broadcast Storms Due to Incorrect Configurations ......................................................................... 55
4.3.2 Data Service Interruptions Due to Incorrect IF Modes .................................................................... 56
4.4 Protection Faults ................................................................................................................................... 57
4.4.1 Service Interruptions Due to 1+1 Protection Switchover Failures .................................................... 57
4.5 Clock Faults ......................................................................................................................................... 58
4.5.1 Abnormal Base Station Services Due to Clock Interlocking ............................................................ 58
4.6 Equipment Interworking Faults.............................................................................................................. 60
4.6.1 External Clock Synchronization Faults Due to Incorrect Cable Connections .................................... 60
A Appendix ..................................................................................................................... 62
A.1 Distribution of Rain Zones ................................................................................................................... 62
A.2 Refractivity Gradient............................................................................................................................ 63

(Volume 5)
RTN Microwave
1 Basic Principles and Common Methods for Locating
Faults

1

1 Basic Principles and Common Methods
for Locating Faults
This chapter describes basic principles and common methods for locating faults. Each method
is illustrated using an example.
1.1 Basic Principles for Locating Faults
Purpose
To locate a fault to a radio site or a radio hop.
Description
Fault locating aims to narrow down the most likely areas for faults, since transmission
equipment faults affect services in a large area.
Table 1-1 lists the basic principles for locating faults. These principles are summarized based
on characteristics of transmission equipment.
Table 1-1 Basic principles for locating faults
Basic Principle Description
External first, transmission
next
Rule out external faults, for example, faults on power
supply equipment or interconnected equipment, or cable
damage.
Network first, NE next Locate a fault to a radio site or a radio based on fault
symptoms.
High-speed section first,
low-speed section next
Alarms of high-speed signals generally cause alarms of
low-speed signals. Therefore, clear faults in the high-speed
section first.
High-severity alarms first,
low-severity alarms next
First handle high-severity alarms, such as critical alarms
and major alarms. Then handle low-severity alarms, such
as minor alarms and warnings.
(Volume 5)
RTN Microwave
Faults

2

1.2 Common Methods for Locating Faults
Table 1-2 lists common methods for locating faults. Network faults can be located quickly by
using a combination of these methods. In actual applications, maintenance engineers are
expected to locate and rectify faults quickly by using various fault locating methods.
Figure 1-1 Common methods for locating faults

Table 1-2 Common methods for locating faults
Method Applicable Scope Brief Introduction
Signal flow analysis All scenarios This method helps locate a fault to a radio site or radio
hop. Familiarity with service signal flows, cable
connections, and air-interface link connections helps
analyze fault symptoms and locate possibly faulty points.
Alarm analysis All scenarios Alarms well illustrate fault information. Handle alarms
reported by faulty points immediately after analyzing
service signal flows.
Receive and transmit
power analysis
Locating radio link
faults
By analyzing the current and historical receive and
transmit power on a radio link, determine whether any
errors, for example, interference and fading, exist on the
radio link.
Loopback Locating a fault to a
component or site
section by section
This method is fast and independent of alarm and
performance event analysis. It, however, affects embedded
control channels (ECCs) and normal service running.
Replacement Locating a fault to a
component or board,
or identifying
external faults
This method does not require sound theoretical knowledge
or skills but requires spare parts. It applies to nearly sites.
(Volume 5)
RTN Microwave
Faults

3

Method Applicable Scope Brief Introduction
Configuration data
analysis
Locating service
faults when both
hardware and radio
links work normally
This method covers configuration data analysis,
configuration data modification, and modification
verification, and therefore has high requirements for
maintenance personnel.
Tests using instruments
and tools
Isolating external
faults and addressing
interworking issues
This method provides accurate results. Before using this
method, interrupt services.
RMON performance
analysis
Locating faults in
data services
Statistics are collected routinely to analyze Ethernet board
information, for example, service performance.
Network planning analysis Diagnosing
performance
deterioration and
frequent interruption
of radio links
This method addresses availability issues of radio links. It
requires analysis of planned parameters such as fading
margin and of measures against multipath fading.
Experience-based fault
handling
Special scenarios With rich troubleshooting experience, you can locate
faults quickly by analyzing fault symptoms and network
architecture.

1.3 Signal Flow Analysis
1.3.1 Application Scenarios
Signal flow analysis is commonly used to locate faults. It helps much in scenarios where
multiple network elements (NEs) become unreachable to the network management system
(NMS) or multiple points are faulty in base station services.
1.3.2 Method Description
Based on network connection diagrams, logical service relationships, and system functional
block diagrams, this method allows you to analyze service flow directions to obtain possibly
faulty points and locate those faulty ones.
Use this method if you need to locate a fault to a site or link on a network or locate a fault to a
module.
1.3.3 Application Example
Fault Symptoms
As shown in Figure 1-2, a microwave chain network was set up, and all 2G and 3G base
station services in an area were interrupted for approximately 10 minutes.
(Volume 5)
RTN Microwave
Faults

4

Figure 1-2 Network example for signal flow analysis
Area where services were interrupted
Backhaul signal flow
NE1701 NE1702 NE1703
NE1704
NE1709 NE1710 NE1711 NE1712
NE1708 NE1707 NE1706 NE1705

Cause Analysis and Handling Procedure
Step 1 Checked the distribution of the NEs on which services were interrupted and the service flow
direction.
NE1704 converged the interrupted services, so the service interruption was related to
NE1704.
Step 2 Checked alarms and operation records on NE1704.
NE1704 reported an MW_CFG_MISMATCH alarm, and the Hybrid radio E1 capacity was
changed on NE1704 right before the services were interrupted. It was inferred that the
services were interrupted due to an E1 capacity mismatch between NE1704 and NE1705.
Step 3 Corrected the Hybrid radio E1 capacity on NE1704.
The fault was rectified.
----End
Conclusions and Suggestions
If services are interrupted at multiple points, signal flow analysis generally proves that their
convergence point is faulty.
1.4 Alarm and Performance Analysis
Alarms well illustrate fault information. When a fault occurs, first check the alarms reported
by possibly faulty equipment.
Checking current and historical alarms, fault symptoms, and fault time helps narrow down the
most likely areas for faults, and helps locate a fault to a hop, site, or module.
(Volume 5)
RTN Microwave
Faults

5

The alarm and performance analysis method entails capabilities in using the NMS and
analyzing service signal flows.
Step 1 Use the NMS to obtain information about equipment alarms and performance events on an
entire network.
Step 2 Sort the alarms by severity and handle the alarms in the following sequence:
1. Hardware alarms, such as HARD_BAD, BD_STATUS, and VOLT_LOS
2. Link alarms, such as IF_CABLE_OPEN, MW_LOF, RADIO_RSL_LOW, R_LOC,
R_LOF, and R_LOS
3. Service alarms
4. Protection alarms, such as HSB_INDI, RPS_INDI, XCP_INDI, and APS_INDI
----End
Fault Symptoms
An OptiX RTN 620 NE on a network reported a HARD_BAD alarm and an XCP_INDI
alarm.
Step 1 Checked alarms.
Boards in slots 1, 5, 6, and 7 reported the HARD_BAD alarm.
The PXC board in slot 1 reported a HARD_BAD alarm, whose parameters indicated that
the 38M clock was lost and the analog phase-locked loop (PLL) was unlocked.
The boards in slots 5, 6, and 7 reported the HARD_BAD alarm, whose parameters
indicated that the 38M clock was lost and the PXC board in slot 1 was faulty. The fault
caused loss of the first 38M clock.
Step 2 Checked the XCP_INDI alarm.
The HARD_BAD alarm reported by the board in slot 1 triggered a switchover, causing the
SCC board to report an XCP_INDI alarm.
Step 3 Replaced the PXC board in slot 1.
The alarms cleared.
----End
If an NE simultaneously reports multiple alarms, analyze their severities, correlations, and
parameters so you can quickly locate the fault to a board or port.
(Volume 5)
RTN Microwave
Faults

6

1.5 Receive and Transmit Power Analysis
Receive and transmit power analysis is crucial to radio link analysis. This method allows you
to determine whether any faults, for example, radio link blocking, fading, and outdoor unit
(ODU) faults, occur on a link by analyzing current and historical receive and transmit power
on the link, thereby quickly locating the fault.
This method allows you to check the receive and transmit power on a link, as well as their
changes using the NMS.
By periodically updating the receive and transmit power table based on radio link directions
and network design, you can identify the links whose receive power or transmit power is more
than 3 dB higher or lower than the designed value, and then take appropriate measures in a
timely manner.
Fault Symptoms
On an OptiX RTN 600, a 20 km long cross -ocean 1+1 hot standby (HSB) radio link was
interrupted intermittently, and alarms such as B1_SD, HSB_INDI, MW_LOF, and R_LOF,
were reported and lasted several seconds to dozens of seconds.
Step 1 Checked the ODU receive power that was recorded during the alarm period.

(Volume 5)
RTN Microwave
Faults

7

The difference between the maximum receive power and the minimum receive power was
more than 40 dB, and the minimum receive power was close to or less than the receiver
sensitivity. Therefore, it was inferred that the fault was caused by spatial fading.
Step 2 Checked the network planning design.
The ODU operated at the 8 GHz band, which was less prone to rain fading, and therefore
multipath fading caused intermittent link interruptions. In addition, 1+1 HSB protection does
not well protect radio links against multipath fading.
Step 3 Replaced 1+1 HSB protection with 1+1 space diversity (SD) protection.
----End
Routinely check whether the receive power reaches the designed value. If not, it is
recommended that you check the configuration, adjust antennas, or replace ODUs so the
receive power reaches the designed value.
Minimize the impact of multipath fading by using one of the following methods,
depending on the actual conditions:
Use low capacity, low-order modulation schemes, and low bandwidths.
Increase the height difference between antennas at both ends providing that
line-of-sight (LOS) is guaranteed.
Add two antennas and configure an SD protection group.
1.6 Loopback
After a loopback is enabled at a point, signals that should be forwarded in normal cases are
routed to the signal source. If services are interrupted, loopbacks can be performed to narrow
down fault areas by checking whether each network section is in good condition.
Loopbacks can be software loopbacks or hardware loopbacks. Software loopbacks can be
inloops or outloops. For detailed loopback definitions, operation methods, and usage
restrictions, see the Maintenance Guide.
This method allows you to narrow down fault areas by performing loopbacks at different
points and testing services.
Narrowing Down Fault Areas
As shown in Figure 1-3, point A failed to pass a loopback test, and point B passed a loopback
test. Then, the fault existed between point B and point A.
(Volume 5)
RTN Microwave
Faults

8

Figure 1-3 Loopbacks helping narrow down fault areas
A
B
Faulty section
Test result
ERR
OK
ERR
A B
Test meter
Equipment/
Board 1
Equipment/
Board 2
Equipment/
Board 3
Equipment/
Board 4
Equipment/
Board 5

Diagnosing Equipment Interworking Faults
If all sections on the entire network pass loopback tests but the entire network fails in the test,
an equipment interworking fault may occur. See Figure 1-4.
Figure 1-4 Loopbacks for diagnose equipment interworking faults
Test result
ERR
OK
Test meter
OK
Check for an equipment interworking fault.
Test meter
Equipment 1 Equipment 2 Equipment 3 Equipment 4 Equipment 5

(Volume 5)
RTN Microwave
Faults

9

Fault Symptoms
Figure 1-5 shows a network, where an E1 tributary between the radio network controller
(RNC) and third-party equipment reported an alarm.
Figure 1-5 Loopbacks for locating faults
OSN
Third-party
SDH E1 BER tester
7 IFH2
1 PXC
3 PXC
5 IFH2
8
2 SCC
4
6 SD1
7 IFH2
1 PXC
3 PXC
5 IFH2
8
2 SCC
4 PH1
6 SD1
NE1
ODU
ODU
ODU
ODU
NE2
2
RNC
1
A
B

Step 1 Analyzed the service signal flow.
The alarmed E1 signal was received from NE2.
Step 2 Checked alarms reported by NE2.
NE2 did not report any hardware alarms or service alarms.
Step 3 Set an inloop at the tributary board (point 1) on NE2, and connected an E1 bit error rate (BER)
tester to point A (third-party SDH equipment).
The service had bit errors.
Step 4 Set an outloop at the SD1 board (point 2) on NE1.
The E1 BER tester at point A read no bit error. It was suspected that the radio link between
NE1 and NE2 was faulty.
Step 5 Tested the radio link performance by setting an inloop at the tributary board (point 1) on NE2
and connecting an E1 BER tester to point B (OptiX OSN equipment).
The E1 BER tester at point B read no bit error.
(Volume 5)
RTN Microwave
Faults

10

NOTE

The E1 BER tester was connected to the OptiX OSN equipment and the corresponding E1
cross-connections were modified, because NE1 had no E1 tributary port.
Step 6 Checked the configuration data on the OptiX RTN equipment, OptiX OSN equipment, and
third-party SDH equipment.
The preceding equipment used their own clock sources, and the clocks were not synchronized.
Step 7 Enabled the preceding equipment to trace their upstream clocks.
Clock synchronization was achieved across the entire network.
Step 8 Performed tests again using the E1 BER testers.
No bit error occurred.
NOTE

All equipment on an SDH network must trace the reference clock. In the preceding example, the OptiX
RTN equipment, OptiX OSN equipment, and third-party SDH equipment are interconnected through
SDH ports. After E1 services are encapsulated and mapped several times, serious jitter may be generated
and results in bit errors. To resolve similar issues, plan and implement clock solutions when building
SDH or microwave transmission networks.
----End
Loopbacks help quickly locate faulty points. As shown in the preceding example, a
combination of loopbacks at multiple points, tests by section, and configuration data analysis
makes it possible to find the root cause.
1.7 Replacement
The replacement method applies to the following scenarios:
Locating passive faulty points
Locating faulty links
Locating faulty points that are not identified by alarm, performance event, or link
analysis
Scenarios in which no appropriate instrument or tool is available
This method allows you to determine whether a possibly faulty part is faulty by replacing it
with a functional one of the same type. This method applies to IF cables, optical fibers ,
network cables, boards, ODUs, hybrid couplers, and antennas.
(Volume 5)
RTN Microwave
Faults

11

Fault Symptoms
See the following figure. Two sites, site A and site B, were interconnected using 2+0 radio
links. At each site, ODUs of the same type (with the same sub-band but different working
frequencies) were used. NE B-2 at site B frequently reported services alarms such as R_LOC
and R_LOF.
Figure 1-6 Replacement for locating faults
NE A-1
NE A-2
ODU
A-1
ODU
A-2
NE B-1
NE B-2
ODU
B-1
ODU
B-2
Site A Site B
R_LOC/ R_LOF

Step 1 Checked historical performance events and the receive power within the period of alarm
reporting.
The receive power was normal.
Step 2 Interchanged the IF cables at site B and checked for alarms for two days.
NE B-2 still reported service alarms. Therefore, site B was not faulty, and site A was possibly
faulty.
NE A-1
NE A-2
ODU
A-1
ODU
A-2
NE B-1
NE B-2
ODU
B-1
ODU
B-2
Site A Site B
R_LOC/ R_LOF

Step 3 Restored the IF cable connections at site B, interchanged the IF cables at site A, and checked
for alarms for two days.
NE B-1 reported service alarms. Therefore, the IF cable connecting NE A-2 and ODU A-2
was faulty.
(Volume 5)
RTN Microwave
Faults

12

NE A-1
NE A-2
ODU
A-1
ODU
A-2
NE B-1
NE B-2
ODU
A-1
ODU
A-2
Site A Site B
R_LOC/ R_LOF

Step 4 Replaced the faulty IF cable. The fault was rectified.
----End
If common methods fail to locate the causes of similar problems, you can replace involved
parts one by one.
1.8 Configuration Data Analysis
Incorrect operations or inherent characteristics (for example, at a micro level) of electronic
equipment may corrupt or change equipment's configuration data (for example, NE data and
board data), leading to faults like service interruptions. After locating faults to boards, you can
analyze configuration data to further locate the faults.
This method allows you to query equipment's configuration data, compare the data with
planned data, and analyze the data based on networking topologies and equipment
interconnections.
Radio hop configurations must comply with the following rules:
Each of the following parameters must be consistently set at both ends of a radio hop:
microwave working modes of IF boards (channel spacing, IF bandwidth, and modulation
scheme), number of E1s for Hybrid radio, and IEEE 1588 timeslots.
The transmit and receive frequencies of ODUs must be set correctly. To be specific, there
is a T/R spacing between the transmit frequencies of the Tx high and Tx low sites for a
radio hop. That is, for a radio hop, the transmit frequency of the Tx high site must be
equal to the receive frequency of the Tx low site, and the transmit frequency of the Tx
low site must be equal to the receive frequency of the Tx high site.
Fault Symptoms
After an OptiX RTN 600 NE was configured, it operated normally. Its services, however,
were interrupted after it restarted after a power failure.
(Volume 5)
RTN Microwave
Faults

13

Step 1 Checked alarms.
The CONIFG_NOSUPPORT alarm indicating an incorrect frequency caused the
RADIO_MUTE alarm.

Step 2 Checked the parameter setting.
The preset Tx frequency was out of the Tx frequency range.

NOTE

If an incorrect Tx frequency value is applied to an unmuted ODU, the ODU reports a
CONFIG_NOSUPPORT alarm but remains in the unmute state, so its services are not interrupted. After
the Tx frequency is changed to a correct one, the CONFIG_NOSUPPORT alarm automatically clears.
However, if an incorrect Tx frequency value is applied to an ODU after the ODU is reset or powered off
or the NE is reset, the ODU remains in the mute state and so its services cannot be restored.
Step 3 Changed the Tx frequency to a correct value based on the network planning information.
----End
If services are interrupted due to incorrect operations, check whether the configuration data is
correct. In addition, analyzing alarms and their parameters help locate configuration errors.
1.9 Tests Using Instruments and Tools
This method is used to locate equipment interworking faults and to test performance
indicators.
Tools such as multimeters, SDH analyzers, SmartBits, and data service packet sniffers are
used to test equipment on live networks and to check whether faults are caused by equipment
faults or external factors.
(Volume 5)
RTN Microwave
Faults

14

Fault Symptoms
In the network shown in following figure, the NMS set up data communication network
(DCN) communication with NE1 and NE2 through the multiprotocol label switching (MPLS)
network. NE1 was connected to the MPLS network using a hub and communicated with the
MPLS network through the Open Shortest Path First (OSPF) protocol. The NMS pinged NE1
successfully but failed to ping NE2. Therefore, NMS could not reach NE2. The routing table
of NE1 indicated that NE1 did not learn routes to upstream NEs. The MPLS network had
multiple radio hops at its edge, but the fault occurred only between NE1 and NE2.
Figure 1-7 Fault example
NE1 NE2
MPLS
HUB

NOTE

NE1 and NE2 formed a radio hop.
Step 1 Connected the hub to a PC and used the data service packet sniffer to analyze the OSPF
packets received by NE1.
The designated router (DR) IP addresses in the OSPF packets were xx. xx.xx. 1, but the IP
address of the NE that sent the DR packets was xx.xx. xx. 2. Therefore, NE1 did not receive
any DD packets sent by the DR elected on the OSPF subnet. As a result, NE1 could not create
an adjacency with the DR and could not learn OSPF routes.
Step 2 Sniffed and analyzed OSPF packets at another OptiX RTN NE that was connected to the
MPLS network and was operating normally.
The OptiX RTN NE received OSPF packets from the DR. Therefore, an OptiX RTN NE fault
was ruled out.
Step 3 Increased the priority of NE1's gateway (IP address: xx. xx. xx.2) so the gateway became the
DR on the subnet.
NE1 learned OSPF routes, and NE2 was reachable to the NMS.
----End
(Volume 5)
RTN Microwave
Faults

15

This method helps to locate equipment interworking faults or data service faults.
1.10 RMON Performance Analysis
If remote monitoring (RMON) is enabled on the NMS, you can perform Ethernet OAM
functions, loopbacks, and ping tests to locate service interruptions or performance
deterioration.
RMON can be used to transfer network monitoring data between network segments. RMON
achieves the following functions:
Storing all the statistics on the agent side and supporting offline manager operations
Storing historical data to facilitate fault diagnosis
Supporting error detection and reporting
Supporting multiple manager sites
The OptiX RTN equipment achieves RMON using the following management groups:
Ethernet statistics group
The Ethernet statistics group queries real-time Ethernet port performance statistics of.
Ethernet history group
The Ethernet history group stores historical Ethernet performance statistics so users can
obtain Ethernet performance of a specific Ethernet port within a historical period. The
Ethernet history group supports the same items as the Ethernet statistics group.
Ethernet history control group
The Ethernet history control group specifies how to obtain historical Ethernet port
performance data.
Ethernet alarm group
The Ethernet alarm group reports an alarm if the value of a monitored item crosses the
preset threshold.
RMON covers the following statistical items:
Number of transmitted packets
Number of transmitted bytes
Number of received packets
Number of received bytes
Number of each type of bad packets
Number of discarded packets
(Volume 5)
RTN Microwave
Faults

16

Fault Symptoms
Figure 1-8 shows a mobile network, where OptiX RTN 600 V100R003s provided backhaul
transmission. Packet loss occurred when BTS1 at site 1 and BTS2 at site 2 were pinged from
the RNC, but did not occur when BTS3 at site 3 was pinged.
Figure 1-8 Network example for RMON performance analysis
1-001 2-001 2-002 3-001 3-002 4-001
Site 1 Site 2 Site 3
RNC
BTS1 BTS2
BTS3

Step 1 Analyzed the RMON data of NE 3-002 to check whether packet loss was caused by
insufficient radio bandwidth between site 2 and site 3.
The maximum traffic volume of NE 3-001 already reached its maximum air interface
bandwidth (25 Mbit/s). Therefore, packet loss was caused by congestion. For details, see the
following figure.

Step 2 Changed the air interface capacity of NE 3-001 as required.
Step 3 Performed a ping test.
No packet was lost.
(Volume 5)
RTN Microwave
Faults

17

----End
RMON shows data traffic and air interface bandwidth usage graphically.
1.11 Network Planning Analysis
Network planning is crucial to radio link performance. To address availability issues not
caused by equipment faults, such as bit errors on radio links and frequent interruptions of
radio links, check whether correct methods are used during network planning or whether
network planning is based on actual link conditions.
Based on terrains and rain falling of areas that radio links cover, network planning generally
determines operating frequencies, T/R spacing, transmit power, antenna heights, and
protection/diversity modes. Based on the preceding information, radio link indicators such as
normal receive power, fading margin, and system availability can be obtained.
The following items are often checked:
Availability: Check whether actual link availability meets customers' requirements. For
rain zones (zones L, M, N, P, and Q specified by ITU-T), it is recommended that you use
low frequency bands and polarization direction V. For a radio link subject to severe
multipath fading, it is recommended that you increase the height difference between the
antennas at both ends or use 1+1 SD protection as long as LOS is guaranteed.

Multipath fading prediction methods. Generally, the following methods are available:
ITU-R-P. 530-7/8 method: It is globally applicable.
(Volume 5)
RTN Microwave
Faults

18

ITU-R-P. 530-9 method: It is applicable to areas with high reflection gradients, for
example, the Middle East, the Mediterranean sea, and West Africa. It works with the
ITU-R-P. 530-7/8 method. During the prediction, a low availability is used as the
calculation result.
KQ factor method: It is applicable to China (seldom used).
Vigants-Barnett method: It is applicable to North America.
Rain fading prediction methods. Generally, the following methods are available:
ITU-7: It is globally applicable.
R.K. Crane: It is applicable to North America.
For a link covering several rain zones, it is recommended that you select the zone
with the heaviest rainfall for calculation.
Fault Symptoms
A radio link frequently but intermittently reported MW_RDI, R_LOC, and RPS_INDI alarms,
and HSB switchovers were triggered.
Table 1-3 Link information
Protection 1+1 HSB
IF board IF1B boards
IF mode IF mode 7 (28M/128QAM/STM-1)
ODU type SPA ODUs operating at the 8 GHz frequency band
Receiver sensitivity 70. 5 dBm
Transmit power 20 dBm
Receive power 39. 5 dBm
Planned availability 99. 994%
Predicted annual interruption time 1877 seconds

Step 1 Queried historical receive power values of the radio link.
The receive power decreased to a value close to the receiver sensitivity when an alarm was
reported. Most alarms were reported during the night or in the early morning. When the
weather was favorable at noon, the receive power was normal. Therefore, intermittent radio
link interruptions were caused by multipath fading.
Step 2 Checked annual interruption time predicted for the radio link.
The actual annual interruption time was longer than the predicted time of 1877 seconds.
Therefore, the fading margin was insufficient.
Step 3 Checked the network planning methods.
(Volume 5)
RTN Microwave
Faults

19

The ITU-R-P. 530-7/8 method was used. The area covered by the radio link was in the Middle
East, and therefore the ITU-R-P. 530-9 method should be used.
Step 4 Used the ITU-R-P.530-9 method to predict annual interruption time without changing other
conditions.
The obtained value was about 175833 seconds, which was longer than the value obtained
using the ITU-R-P.530-7/8 method.
Figure 1-9 Using the ITU-R-P.530-7/8 method

Figure 1-10 Using the ITU-R-P.530-9 method

Step 5 Deleted 1+1 HSB protection settings and configured 1+1 SD protection. The link availability
met service requirements.
(Volume 5)
RTN Microwave
Faults

20

----End
Network planning is crucial to radio link performance. For radio links that are frequently
interrupted due to fading, it is recommended that you first check their network planning
information.
(Volume 5)
RTN Microwave 2 Troubleshooting Process and Guide

21

2 Troubleshooting Process and Guide
This chapter describes the general troubleshooting process, fault categories, and how to
diagnose each category of faults.
2.1 Troubleshooting Process Overview
Figure 2-1 Troubleshooting flowchart
Start
Record fault symptoms
Diagnose the fault
Is the fault rectified?
Report to Huawei
Work out solutions
together
Is the fault rectified?
Write a troubleshooting
report
End
Rectify external faults
1
3
4
No
Yes
Yes
No
No
Caused by
external factors?
2
Yes

(Volume 5)

22

Table 2-1 Remarks about the troubleshooting process
Mark Explanation
1 When recording fault symptoms, record them as detailed as possible.
Record other important information too, for example, exact time when the
fault occurs, operations performed before and after the fault occurs, alarms,
and performance events.
You can collect fault data using the Data Collector (DC) tool that is
integrated with the U2000.
2 External factors include power supply, fibers/cables, environment, and
terminal equipment (such as switches).
3 Find causes of a fault with reference to section 1. 2 "Common Methods for
Locating Faults", determine the category of the fault with reference to
section 2. 2 "Fault Categories", and rectify the fault as instructed in the
corresponding section listed below:

2.3 Troubleshooting Radio Links

2.4 Troubleshooting TDM Services

2.5 Troubleshooting Data Services

2.6 Troubleshooting Microwave Protection

2.7 Troubleshooting Clocks

2.8 Troubleshooting DCN Communication
4 Contact Huawei local office or dial Huawei technical service hotline for
problem reporting and technical support.

CAUTION

When handling critical problems such as a service interruption, exercise the following
precautions:
Restore services as soon as possible.
Analyze fault symptoms, find causes, and then handle faults. If causes are unknown,
exercise precautions when you perform operations in case the problems become severer.
If a fault persists, contact Huawei engineers and coordinate with them to handle the fault
promptly.
Record the operations performed during fault handling and save the original data related to
the fault.
(Volume 5)

23

2.2 Fault Categories
Table 2-2 Fault categories
Fault Category Typical Symptom
Hardware fault Equipment reports hardware alarms such as BD_STATUS
and HARD_BAD.
Radio link fault Radio links report link-related alarms such as MW_LOF and
RADIO_RSL_LOW, or have bit errors.
Time division
multiplexing (TDM)
service fault
Radio links work normally but their carried TDM services are
interrupted or deteriorate.
Data service fault Radio links work normally but their carried data services
have packet loss or are unavailable.
Protection fault Protected radio links or their carried services are faulty, or
protection switching fails (no switchover is performed or
services are unavailable after switching is complete).
Clock fault NEs report clock alarms.
DCN fault NEs fail to be managed by the NMS or do not respond to
commands from the NMS.

2.3 Troubleshooting Radio Links
2.3.1 Radio Link Faults
Fault Causes
Causes of radio link faults are classified into the following categories:
Equipment faults, including indoor unit (IDU) faults, outdoor (ODU) faults, and power
faults
Propagation faults, including fading, interference, and poor LOS
Poor construction quality, including poor antenna/component installation, poor
grounding, and poor waterproofing
(Volume 5)

24

Figure 2-2 Causes of radio link faults
Causes of radio
link faults
Propagation faults
Interference Fading Poor LOS
External
interference
Over-reach
interference
Rain fading
Multipath
fading
Reflection
LOS not
achieved
Near-field
blocking
Poor construction
quality
Antenna
installation
Cables
Antennas not
aligned
Antennas
loosened or offset
Poor grounding
Poor
waterproofing
Equipment faults
IDU faults
ODU or outdoor
component faults
Power faults
Damaged cable
components

(Volume 5)

25

Troubleshooting Process
Figure 2-3 illustrates the process for diagnosing a radio link fault.
Figure 2-3 Process for diagnosing a radio link fault
Start
Hardware alarms exist?
RSL less than the designed
value if no fading occurs?
RSL greater than the receiver
sensitivity?
Raining when the fault occurs?
The fault occurs regularly?
Rectify equipment faults.
Link interruption time
greater than the
designed value?
Co-channel or adjacent-channel
interference occurs.
Large-delay, multipath reflection occurs.
The link is blocked.
The antennas are offset.
Passive components like hybrid couplers
or flexible waveguides are faulty.
Rain fading
Multipath fading
Terrain reflection
The link reports link-related
alarms like MW_LOF or bit error
events like UAS/SES?
Handle the fault accordingly.
Yes
No
Yes
No
No
Yes
Yes
No
Yes
No
Yes
No
Check whether the designed value is
appropriate.
Yes
Analyze the configuration data and
replace components that are suspected
to be faulty.
No

(Volume 5)

26

2.3.2 Signal Propagation Faults
For causes of radio link faults, faults caused by active equipment are easily located because
they generally occur with alarms, whereas signal propagation faults (including faults caused
by unaligned antennas), which occur frequently, are difficult to locate.
Table 2-3 provides typical symptoms of and solutions to signal propagation faults.
Table 2-3 Typical symptoms of and solutions to signal propagation faults
Fault
Type
Typical Symptom Solution
Multipath
fading

The receive power changes greatly and
quickly (generally from 10 dB to dozens of
dB within seconds). The changes occur
periodically, especially during the transition
between day and night.

A typical symptom of duct-type fading is
that the receive power undergoes substantial
up-fading and down-fading.

Increase the path inclination by adjusting the
antenna mount heights at both ends,
therefore increasing height differences
between the antennas at both ends.

Reduce surface reflection. For apparent
strong reflection surfaces, for example, large
areas of water, flat lands, and bold mountain
tops, adjust antennas to move reflection
points out of the strong reflection areas or
mask the reflection by using landforms.

Reduce the path clearance. With LOS
conditions guaranteed, lower antenna mount
heights as much as possible.

Use space diversity or increase the fading
margin. In normal conditions, space diversity
is the most efficient method for decreasing
multipath fading.
Interference

A link's receive power is greater than the
receiver sensitivity, but the link is
interrupted or has bit errors.

When no fading occurs, an IF board reports a
radio link alarm, especially when
interference is strong.

When interference occurs at the local end
(interference signal power greater than 90
dBm), the local receive power is greater than
90 dBm after the peer ODU is muted.

A frequency scanner can detect interference
signal power when being tuned to the
operating band of an ODU.

Plan frequencies or polarization directions
properly. In theory, a large spacing between
the operating frequency of target signals and
the operating frequency of interference
signals reduces interference. Meanwhile,
note issues such as frequency resources and
network-wide planning.

Plan Tx high and Tx low sites properly. If
multiple ODUs provide multiple microwave
directions at a site, plan the site as a Tx high
site or Tx low site for all microwave
directions, if possible.

Plan microwave routes properly. Generally,
adopt Z-shaped radio link distribution to
prevent over-reach interference.
(Volume 5)

27

Fault
Type
Typical Symptom Solution
Rain fading When it rains, a link may be interrupted or
deteriorate.
Increase link fading margin, use low frequency
bands, or use vertical polarization.

Increase link fading margin for rain zones L,
M, N, P, and Q.

Rain fading impairs radio links that operate
at high frequency bands, especially
frequency bands higher than 18 GHz. Radio
links operating at frequency bands lower
than 10 GHz are not affected. If rain fading
is severe, change radio links' operating
frequency bands, if necessary.

Rain fading in horizontal polarization is
severer than that in vertical polarization.
Poor LOS The receive power is always lower than the
designed power.

If radio links or antennas are blocked, adjust
antenna mount heights or positions to bypass
obstacles.

Adjust deviated antennas.

2.4 Troubleshooting TDM Services
Fault Symptoms
TDM services are interrupted or have bit errors.
No. Possible Cause Handling Procedure
Cause 1 The hardware is faulty. Analyze alarms and perform loopbacks to check whether board
hardware is faulty. If a board is faulty, replace the board.
Cause 2 A radio link is faulty. On the NMS, find the occurrence period of the fault and check whether
any service alarm is generated on the radio link. If a radio link alarm is
generated, first rectify radio link faults.
Cause 3 Services are incorrectly
configured.
Check whether an MW_CFG_MISMATCH alarm is generated on the
link. Verify that the number of E1s is the same at both ends of the link.
Cause 4 The temperature of a
board is very high.
On the NMS, query the temperatures of components setting up the
faulty link, and check whether any temperature alarm is generated. If
the ODU temperature is very high, take temperature control measures,
for example, installing a sunshade. If the IDU temperature is very high,
verify that temperature control devices, for example, air conditioners,
work normally, and verify that the exhaust vents of the IDU are covered
or obstructed.
(Volume 5)

28

Cause 5 Power supply voltage
fluctuates, the grounding
is improper, or external
interference exists.
Check whether the voltage of the external input power supply fluctuates
or whether the equipment is grounded improperly.

2.5 Troubleshooting Data Services
This section describes how to diagnose data service faults with different symptoms and
affected scopes.
2.5.1 Services at All Base Stations on an Entire Network or in an
Area Are Interrupted
Fault Symptoms
On a network, services at all base stations, which are converged at level 1 or level 2
convergence nodes and then transmitted to base station controllers (BSCs)/RNCs, are
interrupted. To be specific, all voice services, Internet access services, and video services are
interrupted.
Cause Analysis
If services at all base stations on an entire network or in an area are interrupted, faults
probably occur at the convergence nodes that are interconnected with BSCs/RNCs. Therefore,
check for the following faults at convergence nodes:
Board hardware fault
Port fault
Configuration error
Equipment interconnection fault
If this type of faults occurs, contact the maintenance personnel for the interconnected
equipment.
Fault Locating Measures
NOTE

Before locating faults, collect data of all NEs that are possibly faulty, if possible.
Step 1 Rule out hardware faults and radio link faults with reference to section 2. 2 "Fault Categories"
and 2. 3 "Troubleshooting Radio Links. "
Step 2 Check whether upstream convergence ports at the convergence nodes report equipment
alarms.
If Then
These ports report any of the Clear the alarms as instructed in "Alarms and
(Volume 5)

29

If Then
following equipment alarms:

ETH_LOS

LASER_MOD_ERR

LASER_NOT_FITED

ETH_NO_FLOW
Handling Procedures" in the Maintenance Guide.
These ports do not report
equipment alarms
Go to the next step.

Step 3 Check RMON statistics about upstream convergence ports at the convergence nodes.
If Then
The ports receive data but do not
transmit data
The boards where the ports locate may be faulty. In
this case, go to the next step.
The ports do not receive data The interconnected equipment is faulty. In this case,
rectify the fault by following instructions in chapter 3
"Equipment Interworking Guide".
The ports receive and transmit data Go to the next step.

Step 4 Check the Ethernet bandwidths provided by radio links at the convergence nodes.
If Then
The Ethernet bandwidths provided
by radio links are insufficient
Expand capacities of the radio links to increase
Ethernet bandwidths.
The Ethernet bandwidths provided
by radio links are sufficient

Step 5 Check service configurations.
1. Check Ethernet service configurations at the convergence nodes.
If Then
No Ethernet service is configured,
or source/sink ports are incorrectly
set
Re-configure Ethernet services and check whether
the services recover. If not, go to the next step.
Ethernet services are configured as
planned

(Volume 5)

30

2. Check attributes of service ports at the convergence nodes.
If Then
Attributes of the service ports are
incorrectly set
Set attributes for the service ports again (including
port enabled/disabled, tag attribute, and default
VLAN) and check whether the services recover. If
not, go to the next step.
correctly set

3. Check service VLANs at the convergence nodes.
If Then
VLAN settings are inconsistent
with actual services
Re-set VLANs for the services and check whether
the services recover. If not, go t o the next step.
VLAN settings are consistent with
actual services

Step 6 Reset the NEs at the convergence nodes.
NOTE

If the fault persists after all the preceding steps are performed, dial Huawei technical service hotline or
contact Huawei local office.
----End
2.5.2 Services at All Base Stations on an Entire Network or in an
Area Experience Packet Loss
Fault Symptoms
Services at all base stations on an entire network or in an area experience packet loss. For
example, all Internet service users experience a low access rate, calls are delayed, ping
packets between BSCs/RNCs and base stations are lost, or artifacts appear in video services.
Cause Analysis
If services at all base stations on an entire network or in an area experience packet loss, faults
probably occur at convergence nodes (possibly OptiX PTN 1900 or OptiX RTN 950) that are
interconnected with BSCs/RNCs. Therefore, check for the following faults at the convergence
nodes (the possibility of service configuration errors is eliminated because the services are not
interrupted):
Incorrect parameter setting (for example, mismatched working modes) for Ethernet ports
Network cable or fiber fault
Service traffic exceeding preset bandwidth
Member link fault in link aggregation groups (LAGs)
(Volume 5)

31

Oversized burst traffic
Broadcast storm
Inappropriate quality of service (QoS) parameter setting
NOTE

Step 1 Check whether the convergence nodes report alarms.
If Then
The convergence nodes report alarms
like ETH_LOS or experience alarm
jitters
Clear the alarms as instructed in "Alarms and
Handling Procedures" in the Maintenance Guide.
If the alarms clear, check whether the fault is
rectified. If the alarms persist, go to the next step.
The convergence nodes do not report
an alarm

Step 2 At the convergence nodes, check whether the ports used for interconnection and their peer
ports at the interconnected equipment are consistently set.
If Then
The ports' working modes are
inconsistent with their peer ports'
working modes
Change their working modes to the same and
check whether the fault is rectified. If not, check
the next item.
The ports' physical states are
different from the settings
Verify fiber connections or network cable
connections at the ports. Then, enable the ports
again and check whether the fault is rectified. If
not, check the next item.
The ports' maximum transmission
unit (MTU) settings are different
from actual packet lengths
Change the value of the MTU parameter to 9600
bytes and check whether the fault is rectified. If
not, check the next item.
The ports are physically normal Go to the next step.

(Volume 5)

32

Step 3 Check the traffic volume at each convergence port and each convergence node.
If Then
The total volume of traffic
converged to a convergence node
exceeds the maximum bandwidth
configured for the convergence
node
Split the traffic or increase the maximum bandwidth
configured for the convergence node. If only a few
service packets are lost (generally due to oversized
burst traffic), check for historical threshold-crossing
events.
Check whether the fault is rectified. If not, check the
next item.
The burst traffic volumes at the
convergence nodes exceed the
maximum bandwidths configured
for the convergence nodes
Enable traffic shaping at the convergence ports that are
interconnected with BSCs/RNCs, and check whether
the fault is rectified. If not, check the next item.
The traffic volumes at the
convergence nodes are normal

Step 4 Check whether QoS settings are appropriate if QoS policies are configured for the
convergence nodes or BSCs.
If Then
The rates preset for QoS control
are lower than actual bound
bandwidths
Modify QoS settings.
QoS settings are appropriate Go to the next step.

Step 5 Verify that the wireless equipment operates normally.
NOTE

----End
2.5.3 Services at Some Base Stations in an Area Are Interrupted
Fault Symptoms
Services at some base stations in an area are interrupted. For example, all data, voice, and
video services at a base station or at a node that converges services from several base stations
are interrupted, or all ping packets between a BSC and its subordinate base stations are lost.
(Volume 5)

33

Cause Analysis
If services at some base stations are interrupted, certain equipment on the transmission link is
faulty. To diagnose the fault, check service continuity on the link and RMON counts of
service ports, determine the fault scope, and check for the following faults at those possibly
faulty nodes:
Board hardware fault
Boards not installed
Abnormal physical ports (used for interconnection)
Service configuration error
NOTE

Step 1 Check service continuity on each branch of the faulty link to determine the fault scope.
If Then
The services from base stations
or OptiX RTN NEs to an NE on
the faulty link are available, but
the services from the faulty link
to the NE are interrupted
The NE or its next-hop NE on the faulty link is faulty.
In this case, go to the next step.
An NE on the faulty link receives
data but does not transmit data,
or transmits data but does not
receive data
If an NE on the faulty link transmits data but does not
receive data, check the traffic counts of its next -hop
NE. Repeat this operation until you locate the NE that
does not transmit data. The located NE is considered a
faulty NE. Then, go to the next step.

Step 2 Check whether the faulty NE reports alarms.
If Then
The NE reports alarms Clear the alarms as instructed in "Alarms and Handling
Procedures" in the Maintenance Guide. If the alarms
clear, check whether the fault is rectified. If not, go to
the next step.
The NE does not report an alarm Go to the next step.

(Volume 5)

34

Step 3 At the faulty NE, check whether the port used for interconnection and its peer port at the
interconnected equipment are consistently set.
If Then
The port's working mode is
inconsistent with its peer port's
working mode
Change the working mode to the same and check
whether the fault is rectified. If not, check the next
item.
The port's physical state is
different from the setting
Verify fiber connection or network cable connection at
the port. Then, enable the port again and check
item.
The port's MTU setting is
different from the actual packet
length
Change the value of the MTU parameter to 9216 bytes
and check whether the fault is rectified. If not, go to
the next step.
The port is physically normal Go to the next step.

Step 4 Check service configurations at the faulty NE.
1. Check whether services are correctly configured.
If Then
The services are not configured
or are incorrectly configured
Re-configure the services and check whether the
services recover. If not, go to the next step.
The services are correctly
configured

2. Check attributes of the service ports.
If Then
incorrectly set
Set attributes for the service ports again (including port
enabled/disabled, tag attribute, Layer 2/Layer 3
attribute, and default VLAN) and check whether the
services recover. If not, go to the next step.
correctly set

3. Check the service VLAN. If the service VLAN is incorrectly set, re-set it.
NOTE

----End
(Volume 5)

35

2.5.4 Services at Some Base Stations in an Area Experience Packet
Loss
Fault Symptoms
Services at some base stations in an area experience packet loss. For example, some users
experience a low Internet access rate, calls are delayed, some ping packets between a BSC
and its subordinate base stations are lost, or artifacts appear in video services.
Cause Analysis
If services at some base stations experience packet loss, certain equipment on the transmission
link is faulty. To diagnose the fault, check service continuity on the link and RMON counts of
service ports, determine the fault scope, and check for the following faults at those possibly
faulty nodes:
Abnormal physical ports (used for interconnection)
Service traffic exceeding preset bandwidth
Oversized burst traffic
Broadcast storm
Inappropriate QoS parameter setting
NOTE

Step 1 Check RMON counts of ports on the faulty link, and determine the fault scope by comparing
traffic volumes at involved NEs.
If Then
The volume of traffic received by
an NE is greater than the volume
of traffic transmitted by the NE
Consider the NE as a faulty NE and go to the next
step.
The volume of traffic received by
an NE is equal to the volume of
traffic transmitted by the NE, but
both volumes are too low
Check the traffic volume at the next -hop NE. Repeat
this operation until you locate the NE whose volume
of received traffic is largely different from its volume
of transmitted traffic. The located NE is considered a
faulty NE. Then, go to the next step.

(Volume 5)

36

Step 2 Check whether the faulty NE reports alarms.
If Then
The NE reports alarms like
ETH_LOS or experiences alarm
jitters
Clear the alarms as instructed in "Alarms and
Handling Procedures" in the Maintenance Guide. If
the alarms clear, check whether the fault is rectified.
If not, go to the next step.
The NE does not report an alarm Go to the next step.

Step 3 At the faulty NE, check whether the port used for interconnection and its peer port at the
interconnected equipment are consistently set.
If Then
The port's working mode is
inconsistent with its peer port's
working mode
Change the working mode to the same and check
item.
The port's physical state is
different from the setting
Verify fiber connection or network cable connection
at the port. Then, enable the port again and check
item.
The port's MTU setting is different
from the actual packet length
Change the value of the MTU parameter to 9600
bytes and check whether the fault is rectified. If not,
check the next item.
The port is physically normal Go to the next step.

Step 4 Check RMON counts of each port on the faulty NE.
If Then
The total volume of traffic
converged to an upstream service
port exceeds the maximum
bandwidth configured for the port
Split the traffic or increase the maximum bandwidth
configured for the port. Then check whether the fault
is rectified. If not, check the next item.
The burst traffic volume at an
upstream service port exceeds the
maximum bandwidth configured
for the port
Enable traffic shaping for the port, and check whether
the fault is rectified. If not, check the next item.
The traffic volume at the faulty
NE is normal

(Volume 5)

37

Step 5 Check whether QoS settings are appropriate if QoS policies are configured for the faulty NE.
If Then
The rates preset for QoS control
are lower than actual bound
bandwidths
Modify QoS settings.

NOTE

----End
2.6 Troubleshooting Microwave Protection
2.6.1 Switchover Failure or Delay in Microwave 1+1 Protection
Fault Symptoms
A switchover in microwave 1+1 protection, triggered by a radio link fault or an equipment
fault, fails or is delayed.
Cause 1 The microwave 1+1 protection group is in the
forced or lockout switching state, causing a
switchover failure.
Check the current switching state and
switching records of the microwave 1+1
protection group.
Cause 2 In the microwave 1+1 protection group, both the
main and standby links are interrupted or both the
main and standby units are faulty, resulting in a
switchover failure.
Check the alarms reported by boards in the
microwave 1+1 protection group, and the
current switching state of the microwave 1+1
protection group.
Cause 3 The NE is being reset or a switchover between the
main and standby system control boards just
happens, resulting in a switchover failure or a
delayed switchover.
Check the alarms reported by the NE,
switchover records of the main and standby
system control boards (OptiX RTN 950/980
NEs support main and standby system control
boards), and the current switching state of the
microwave 1+1 protection group.
Cause 4 An RDI-caused switchover is triggered
immediately after a switchover is complete. As the
RDI-caused switchover needs to wait for the
expiration of the wait-to-restore (WTR) timer (in
revertive mode, the waiting time is the preset WTR
time; in non-revertive mode, the waiting time is
300s), the switchover is delayed.
Check the alarms reported by the NE, and
parameter settings, current switching state,
and switching records of the microwave 1+1
protection group.
(Volume 5)

38

Cause 5 In OptiX RTN 600 V100R005/OptiX RTN 900
V100R002C02 and later versions, anti-jitter is
provided for switchovers triggered by RDIs and
service alarms, to prevent repeated microwave 1+1
protection switchovers caused by deep and fast
fading. As a result, some switchovers are delayed.
Check the alarms reported by the NE, and the
current switching state and switching records
of the microwave 1+1 protection group.
Cause 6 The NE is incorrectly configured or installed, for
example, IFH2 and EMS6 boards on OptiX RTN
620 NEs are incorrectly connected.
Check the NE configuration and installation
according to the microwave 1+1 configuration
standards.

2.6.2 Failure to Switch to the Main Unit in Microwave 1+1
Protection
Fault Symptoms
A microwave 1+1 protection group fails to switch services back to its main unit although its
main link or unit recovers.
Cause 1 The microwave 1+1 protection group works in
non-revertive mode.
Check whether the revertive mode is enabled
for the microwave 1+1 protection group. If
not, enable it.
Cause 2 The current switching state of the microwave 1+1
protection group is RDI, so an automatic revertive
switchover cannot take place.
Check whether the current switching state of
the microwave 1+1 protection group is RDI.
If yes, manually clear the RDI state.
Cause 3 When the microwave 1+1 protection group is in
the WTR state, the microwave 1+1 protocol
detects that the main unit is faulty. As a result,
revertive switchover to the main unit fails.
Check whether boards in the microwave 1+1
protection group report hardware alarms. If
yes, handle the alarms.

2.6.3 Switchover Failure or Delay in SNCP Protection
Fault Symptoms
After the working channel of a subnetwork connection protection (SNCP) protection group
becomes faulty, an SNCP switchover fails or is delayed.
(Volume 5)

39

Cause 1 The SNCP protection group is in the forced or
lockout switching state, causing a switchover
failure.
Check the current switching state and
switching records of the SNCP protection
group.
Cause 2 Both the working and protection channels in the
SNCP protection group are unavailable, resulting
in a switchover failure.
Check the alarms reported by boards in the
SNCP protection group, and the current
switching state of the SNCP protection group.
Cause 3 The NE is being reset or a switchover between the
main and standby system control boards just
happens, resulting in a switchover failure or a
delayed switchover.
Check the alarms reported by the NE, the
records of switchovers between the main and
standby system control boards, and the current
switching state of the SNCP protection group.
Cause 4 On an SNCP ring formed by NEs using both SDH
and Hybrid boards, some NEs use the NE software
earlier than OptiX RTN 600 V10R005 or OptiX
RTN 900 V100R002C02, or E1_AIS insertion is
disabled for some NEs.
Find the NEs whose NE software versions are
earlier than OptiX RTN 600 V10R005 or
OptiX RTN 900 V100R002C02, and the NEs
for which E1_AIS insertion is disabled.

2.7 Troubleshooting Clocks
2.7.1 Analyzing Clock Faults
Fault Symptoms
Fault
Symptom
Alarm Impact on System
Bit errors
occur in
services.

CLK_NO_TRACE_MODE or EXT_SYNC_LOS

EXT_TIME_LOC

HARD_BAD or SYN_BAD

LTI

S1_SYN_CHANGE

SYNC_C_LOS
If a clock source is lost or its
quality deteriorates, the quality of
services tracing the clock source
is affected. As a result, pointer
justifications occur and the bit
error rate increases.

(Volume 5)

40

Possible Causes
Possible causes of clock faults are as follows:
A clock source in the system clock source priority list is lost.
All external clock sources of an NE are lost. As a result, the NE's clock enters an
abnormal state.
In synchronization status message (SSM) mode, clock sources are switched so the clock
source that an NE traces is switched.
The clock source that an NE traces deteriorates.
The clock source that an external clock port traces is lost.
The system clock does not work in locked mode.
The clock source that an external time port traces is lost.
2.7.2 Handling Common Clock Alarms
The OptiX RTN equipment provides various clock alarms to help locate clock faults. When a
clock system becomes faulty, rectify the fault based on reported alarms.
EXT_SYNC_LOS
Cause 1 The clock input mode (2 Mbit/s
or 2 MHz) configured for an
external clock source is
different from the actual clock
input mode.
On the NMS, check whether the clock input mode configured for
the external clock source is the same as the actual clock input
mode.
If not, change the clock input mode for the external clock source.
Then, check whether the alarm clears.
Cause 2 A system control, switching,
and timing board is faulty.
On the NMS, check whether the system control, switching, and
timing board reports hardware alarms like HARD_BAD.
If yes, clear the hardware alarms and then check whether the
EXT_SYNC_LOS alarm clears.
Cause 3 A clock input cable is
connected incorrectly.
Verify that the clock input cable is correctly connected.
Verify that the port impedance of the equipment providing the
clock source is the same as the impedance of the clock input
port. If not, for example, a 75-ohm port is connected to a
120-ohm port, install an impedance coupler between the two
ports.
Verify that the clock input cable is disconnected or damaged.
Cause 4 The equipment providing a
clock source is faulty.
Check whether the equipment providing the clock source is
working correctly.
If not, use another equipment to provide a clock source and then
check whether the alarm clears.

(Volume 5)

41

SYNC_C_LOS
Cause 1 An external clock source is lost. On the NMS, check whether an EXT_SYNC_LOS alarm is
reported.
If yes, clear the EXT_SYNC_LOS alarm and then check whether
the SYNC_C_LOS alarm clears.
Cause 2 Service signals tracing a clock
source are lost.
On the NMS, check whether any signal loss alarms like
ETH_LOS, MW_LOF, R_LOC, and T_ALOS are reported.
If yes, clear these alarms and then check whether the
SYNC_C_LOS alarm clears.

LTI
Cause 1 The external clock source that
an external clock port on a
system control, switching, and
timing board traces is lost.
On the NMS, check whether an EXT_SYNC_LOS alarm is
reported.
If yes, clear the EXT_SYNC_LOS alarm and then check whether
the LTI alarm clears.
Cause 2 A line/tributary/link clock
source is lost.
On the NMS, check whether any signal loss alarms like
ETH_LOS, MW_LOF, R_LOC, and T_ALOS are reported.
If yes, clear these alarms and then check whether the LTI alarm
clears.
Cause 3 Clock sources are set to work in
non-revertive or locked mode.
As a result, after the currently
traced clock source is lost,
automatic switchover to a
normal clock source fails.
On the NMS, check whether clock sources are set to work in
non-revertive mode. If yes, change the mode to revertive and
then check whether the LTI alarm clears.
On the NMS, check whether an SYNC_LOCKOFF alarm is
reported. If yes, clear the SYNC_LOCKOFF alarm and then
check whether the LTI alarm clears.

SYN_BAD
Cause 1 The quality of the traced clock
source deteriorates or clock
sources are interlocked.
Replace the currently traced clock source and then c heck
whether the alarm clears.
If the alarm persists, check whether the input clock is correctly
configured. If the configuration is incorrect, correct the clock
configuration and then check whether the alarm clears.
Cause 2 The alarmed board is faulty. On the NMS, check whether the alarmed board also reports
hardware alarms like HARD_BAD and TEMP_OVER.
If yes, clear the hardware alarms and then check whether the
SYN_BAD alarm clears.
(Volume 5)

42

CLK_NO_TRACE_MODE
Cause 1 No system clock source priority
list is configured, and the NE
uses its default system clock
source priority list.
On the NMS, check whether a system clock source priority list is
configured.
If not, configure a system clock source priority list and add
available clock sources to the list.

2.8 Troubleshooting DCN Communication
If an NMS cannot communicate with its subordinate NEs or their communication is unstable,
a DCN fault occurs. As a result, the NMS cannot reach its subordinate NEs.
DCN communication may also be interrupted if lines or links carrying DCN channels are
faulty. In this case, rectify the fault.
DCN faults described in this section refer only to DCN communication interruption or
unstable DCN communication while services are normal. These DCN faults do not affect
services but will result in failure to check NE information, obtain NE alarms, or modify NE
settings on the NMS once services are faulty. Therefore, DCN faults need to be rectified in a
timely manner.
2.8.1 Fault Symptoms and Possible Causes
Table 2-4 NEs connected through service ports are unreachable to their NMS
Item Description
Fault symptoms NEs connected through their service ports like air interfaces, Ethernet ports, and SDH
ports are unreachable to their NMS.
Illustration Area where included NEs are
unreachable to their NMS
Upstream NE

Possible causes

Cause 1: Services are interrupted.

Cause 2: DCN parameters are incorrectly set.

Cause 3: System control boards are faulty.
(Volume 5)

43

Item Description
Handling measures

For cause 1, rectify service faults including hardware faults and radio link faults.

For cause 2, check whether the IDs, IP addresses, DCC channel attributes, and inband
DCN attributes of the NEs are modified before they become unreachable to their NMS.

For cause 3, replace the faulty system control boards.

Table 2-5 NEs connected through NMS/COM ports are unreachable to their NMS
Item Description
Fault symptoms NEs connected through NMS/COM ports are unreachable to their NMS.
Illustration
Area where included NEs are
unreachable to their NMS
Upstream NE

Possible causes

Cause 1: The network cable of the NMS is disconnected or damaged.


Cause 3: System control boards are faulty.
Handling measures

For cause 1, check the network cable of the NMS. If it is faulty, replace it.

For cause 2, check whether the IDs, IP addresses, DCC channel attributes, and inband
DCN attributes of the NEs are modified before they become unreachable to their NMS.

For cause 3, replace the faulty system control boards.

Table 2-6 A single NE is unreachable to its NMS or their communication is unstable
Item Description
Fault symptoms A single NE is unreachable to its NMS or their communication is unstable.
Illustration
NE that is unreachable
to its NMS

(Volume 5)

44

Item Description
Possible causes


Cause 2: An NE ID or NE IP address conflict occurs between NEs on the DCN subnet.

Cause 3: The ECC subnet is oversized.

Cause 4: A system control board of the NE is faulty.
Handling measures

For cause 1, check whether the ID, IP address, DCC channel attributes, and inband
DCN attributes of the NE are modified before it becomes unreachable to its NMS.

For cause 2, verify that each NE on the DCN subnet has a unique ID and IP address.

For cause 3, check the routing table of the gateway NE. If the gateway NE manages
more than the recommended number of NEs, divide the ECC subnet into several
smaller ones.

For cause 4, replace the faulty system control board.

(Volume 5)

45

2.8.2 DCN Troubleshooting Process
Figure 2-4 DCN troubleshooting flowchart
Start
Icon of the
faulty NE in
gray?
Fault rectified?
End
Contact Huawei technical
service engineers
No
Yes
SCC boards are
being reset
The NMS cannot
reach the NE
Yes
Check settings or
undo modifications
No
Information
loss?
No response to
commands from
the NMS?
Hardware
fault?
Check for hardware
alarms and check
cable connections
Settings
incorrectly
modified?
Large ECC
subnet?
Yes
No
No
Link fault?
Rectify link faults
No
Divide the ECC
subnet
Too low DCN
channel bandwidth
No
Increase the DCN
channel bandwidth
Wait for the completion
of SCC resetting
2
3
4
5
6
Locate a
faulty NE
1
7
Yes
Yes
Yes
Yes
No

(Volume 5)

46

Table 2-7 Remarks about the DCN troubleshooting process
Mark Explanation Handling Measure
1 Locate the faulty NE based on a
DCN networking diagram.

If all NEs within an area are
unreachable to their NMS, the
unreachable NE closest to a
normal NE is probably the faulty
NE.

If only one NE is unreachable to
its NMS, the NE is the faulty NE.

If the faulty NE has a service fault, rectify the service
fault first.

If an unreachable NE connects to its NMS through an
external DCN, verify that the external DCN equipment
or the cable used for DCN connection is working
correctly.
2

The faulty NE reports hardware
alarms like HARD_BAD and
BD_STATUS.

Check whether the NMS/COM
port on the faulty NE is connected
to a correct cable or whether the
network cable of the faulty NE is
damaged.

Handle hardware alarms based on the maintenance and
fault management procedure.

Remove and then install, or replace the network cable
and optical fibers.
3 The following operations are
performed before a faulty NE
becomes unreachable to its NMS:

Modifying NE attributes or NE
communication settings

Adding a new NE to the network,
or replacing the faulty NE or its
system control board

Check for unplanned NE IDs and NE IP addresses in the
ECC routing table of the faulty NE's upstream NE. If
there is an unplanned NE ID or IP address in the ECC
routing table, the faulty NE is incorrectly configured. To
rectify the fault, log in to the faulty NE using the
unplanned NE ID and NE IP address on the NMS and
correct the settings.

Change the DCC settings or inband DCN settings of the
faulty NE to interrupt the DCN channel between the
faulty NE and its upstream NE. Then, check for the ID
and IP address of the faulty NE in the ECC routing table
of the upstream NE. If the ID and IP address of the faulty
NE exist in the ECC routing table of the upstream NE,
another NE on the ECC subnet has the same ID and IP
address as the faulty NE. In this case, correct the settings
to ensure that each NE on the ECC subnet has a unique
ID and IP address.

If inband DCN is enabled for the faulty NE and its
upstream NE, verify that the VLAN ID is correctly set on
the upstream NE.

Verify that static routes are correctly set on the faulty
NE's upstream NE.

Verify that OSPF parameters are correctly set on the
faulty NE's upstream NE. OSPF parameter settings must
be consistent for all NEs on the same ECC subnet.
(Volume 5)

47

Mark Explanation Handling Measure
4 Check the number of NEs in the
routing table of the faulty NE's
upstream NE.
If there is a large number of NEs in the routing table, the
ECC subnet is too large in size and some NEs on the ECC
subnet may occasionally become unreachable to their
NMS. It is recommended that an ECC subnet consist of no
more than 64 NEs, if a 192 kbit/s bandwidth is provided.
For the maximum number of NEs that an ECC subnet can
accommodate, see the Feature Description.
5 The faulty NE reports link alarms
like MW_LOF and MW_RDI.
Handle the alarms by following instructions in section 2. 3
"Troubleshooting Radio Links. "
6 Some NEs may occasionally
become unreachable to their NMS.
Verify that a minimum of 192 kbit/s bandwidth is allocated
to inband DCN. If the allocated bandwidth is lower than
192 kbit/s, packets from the NMS may be lost.
7 Direct connection from the faulty
NE to its NMS fails.
Search for the IP address of the faulty NE on the NMS. If
the IP address is not found, or if the IP address is found but
the NMS still cannot reach the faulty NE, press the reset
button on the system control board of the faulty NE.
(Volume 5)
RTN Microwave 3 Equipment Interworking Guide

48

3 Equipment Interworking Guide
3.1 Interworking Criteria
3.1.1 Interworking Through Ethernet Ports
Table 3-1 Criteria for interworking through Ethernet ports
Port
Type
Item Criterion Description
Ethernet
electrical
port
Working
mode
If an OptiX RTN NE interworks
with another NE that supports
auto-negotiation, set the working
mode to auto-negotiation for the
interworking ports at both ends.

Of the two ports at both ends of a radio
hop, if one works in auto-negotiation
mode and the works in
non-auto-negotiation mode, the working
mode of the radio link is uncertain,
possibly leading to service interruption or
packet loss.

If the ports at both ends of a radio hop
work in different modes, data services
may be unavailable or severe packet loss
may occur.
If an OptiX RTN NE interworks
with another NE that does not
support auto-negotiation,
configure an identical working
mode (full-duplex or half-duplex)
and an identical rate for the
interworking ports at both ends.
Ethernet
optical
port
Optical
module type
Optical modules of the same type
must be installed on the ports at
the two ends of a radio hop.
Optical module specifications
include laser type (single-mode or
multi-mode laser), operating
wavelength, and laser safety class.

Single-mode lasers cannot interwork with
multi-mode lasers.

Optical modules with different operating
wavelengths cannot interwork. For
example, optical modules with an
operating wavelength of 1310 nm cannot
interwork with optical modules with an
operating wavelength of 1550 nm.

Interworking between high-power lasers
and low-power lasers results in too high or
too low receive power and results in bit
errors or even damage to optical modules.
(Volume 5)

49

Port
Type
Item Criterion Description
Fiber type The fiber type depends on the laser
type.

Connect multi-mode fibers to optical
modules with an operating wavelength of
850 nm.

Connect single-mode fibers to optical
1310 nm or 1550 nm.
Ethernet
service
VLAN
attributes
The tag attributes of interworking
Ethernet ports must match those of
service frames carried on the
Ethernet ports.

Ethernet ports whose tag attribute is set to
Access discard Ethernet frames with
VLAN IDs.

Ethernet ports whose tag attribute is set to
Tag Aware discard Ethernet frames
without VLAN IDs.
MTU The MTU preset for an Ethernet
port must be greater than the
possibly maximum frame length.

An Ethernet port discards Ethernet frames
whose lengths are greater than the MTU
preset for the Ethernet port.

3.1.2 Interworking Through SDH Ports
Table 3-2 Criteria for interworking through SDH ports
Port Type Item Criterion Description
SDH optical
port
Optical
module
type
Optical modules of the same type
must be installed on the ports at
the two ends of a radio hop.
Optical module specifications
include laser type (single-mode or
multi-mode laser), operating
wavelength, and laser safety class.

Single-mode lasers cannot interwork with
multi-mode lasers.

Optical modules with different operating
wavelengths cannot interwork. For
example, optical modules with an
operating wavelength of 1310 nm cannot
interwork with optical modules with an
operating wavelength of 1550 nm.

Interworking between high-power lasers
and low-power lasers results in too high or
too low receive power and results in bit
errors or even damage to optical modules.
Fiber type The fiber type depends on the
laser type.

Connect multi-mode fibers to optical
850 nm.

Connect single-mode fibers to optical
1310 nm or 1550 nm.
(Volume 5)

50

Clock
tracing
A downstream NE traces the clock
of its upstream NE.

A large difference between the clocks of
interworking NEs results in bit errors.

A downstream NE traces the clock of its
upstream NE through its optical port or
external clock port.
SDH
optical/electr
ical port
VC-12
numbering
SDH ports on interworking NEs
must use the same VC-12
numbering scheme.

The OptiX equipment uses sequential
numbering, which is defined as follows:
VC-12 number = TUG-3 number +
(TUG-2 number 1) x 3 + (TU-12 number
1) x 21.

Certain equipment uses interleaved
numbering, which is defined as follows:
VC-12 number = (TUG-3 number 1) x
21 + (TUG-2 number 1) x 3 + TU-12
number.

A mismatch between numbering schemes
may lead to service connection errors.

3.1.3 Interworking Through PDH Ports
Table 3-3 Criteria for interworking through PDH ports
E1 port Port impedance The impedance of the ports at
the two ends of a radio hop
must be the same (75 ohms or
120 ohms).
75-ohm ports are connected to coaxial cables,
and 120-ohm ports are connected to twisted
pairs.
Cable
connection
Connection between Tx and
Rx ports and connection of
twisted pairs must be correct.

The Tx port at the local end is connected to
the Rx port at the opposite end, and the Rx
port at the local end is connected to the Tx
port at the opposite end.

If two ports are connected using a twisted
pair, the positive end of the local port is
connected to the positive end of the
opposite port, and the negative end of the
local port is connected to the negative end
of the opposite port.
E1/E3 port Cable
grounding
The shield layer of the
coaxial cable connecting two
75-ohm ports must be
grounded in the same mode at
the two ends.
If the coaxial cable is grounded in different
modes at the two ends, electric potential
difference and bit errors may occur.

(Volume 5)

51

3.2 Methods for Locating Interworking Faults
Perform loopbacks at the ports at both ends of a radio hop. If both ports pass the loopback test,
an interworking fault occurs.
To rectify the fault, check cable connections at the two ports and parameter settings at both
ends of the radio hop as specified in section 3. 1 "Interworking Criteria. "

(Volume 5)
RTN Microwave 4 Typical Cases

52

4 Typical Cases
4.1 List of Cases
Efficient troubleshooting for microwave equipment entails experience accumulation and
typical case learning.
Table 4-1 lists the typical cases provided in this chapter.
Table 4-1 List of cases
Fault Type Case Description Key Fault Locating Method
Radio link faults Radio link interruptions due to
multipath fading
1.11 Network Planning Analysis
Service bit errors due to interference to
radio links
Data service
faults
Broadcast storms due to incorrect
configurations
Data service interruptions due to
incorrect IF modes
Protection faults Service interruptions due to 1+1
protection switchover failures
Clock faults Abnormal base station services due to
clock interlocking
Equipment
interworking
faults
External clock synchronization faults
due to incorrect cable connections
3 Equipment Interworking Guide

(Volume 5)

53

4.2 Radio Link Faults
4.2.1 Radio Link Interruptions Due to Multipath Fading
Fault Symptoms
The received signal levels (RSLs) at both ends of a 1+1 SD cross-ocean radio link fluctuated
dramatically, leading to bit errors or even link interruptions.
Step 1 Checked the alarms reported by NEs at both ends of the radio link.
The NEs did not report any hardware alarms but frequently reported radio link alarms and
service interruption alarms.
Step 2 Checked the RSLs of the main and standby ODUs at each end.
The RSLs of the main and standby ODUs at each end fluctuated dramatically, with a
fluctuation range over 30 dB. Therefore, the fault was possibly caused by multipath fading.
Step 3 Checked the network plans and the mounting height difference between the main and standby
antennas at each end.
The mounting height difference between the main and standby antennas at each end was only
4 meters, so space diversity performance was poor.
NOTE

To protect long-distance cross-ocean radio links against multipath fading, take the following measures
during network planning:
Ensure that the fading margin is greater than or equal to 30 dB.
Increase the mounting height difference between the main and standby antennas at both ends of a
1+1 SD radio link.
Step 4 Adjusted the mounting heights of the main antennas to 24 meters and those of the standby
antennas to 10 meters.
The following figure shows the simulation result and illustrates satisfactory diversity
compensation.
(Volume 5)

54

NOTE

The value of K generally ranges from 0.67 to 1.33. In this case, the RSLs of the main and standby
antennas are not correlated with each other. When designing mounting heights for main and standby
antennas, keep appropriate antenna spacing for minimizing the impact of reflection on radio links. When
reflect ion causes high attenuation on the main path, the attenuation on the standby path is low.
When planning cross-ocean radio links, especially long-distance cross-ocean radio links, take
measures to minimize the impact of multipath fading. 1+1 SD protection is recommended for
these radio links. When mounting the main and standby antennas at one end, keep an
appropriate mounting height difference between them so attenuation has no impact on RSLs.
In addition, the main and standby antennas can be tilted slightly upwards providing that RSLs
be not affected.
4.2.2 Service Bit Errors Due to Interference to Radio Links
Fault Symptoms
Bit errors occurred in the services carried by a 2.5 km long radio link between NE A and NE
B. Both NEs used antennas with a diameter of 0. 6 meters and 15 GHz ODUs. The IF1 boards
on both NEs worked in mode 5 (28 MHz/QPSK).
Step 1 Checked the alarms and logs of the two NEs.
The NEs did not report any hardware alarm. NE A reported an MW_FEC_UNCOR alarm, but
NE B did not.
Step 2 Checked the RSLs at the two NEs.
The RSL at NE A was 62 dBm and that at NE B was 70 dBm. These two values were
greater than the receiver sensitivity (85 dBm) in mode 5.
Step 3 Checked for interference signals by muting the ODU at NE B.
(Volume 5)

55

The RSL at NE A was 80 dBm. Therefore, interference signals existed.
Step 4 Used one of the following methods for eliminating interference signals:
Using frequencies that are not affected by interference signals (tests showed that the
sub-bands supported by the ODU were all interfered)
Using antennas with a diameter greater than 0.6 meters (the workload is heavy and
interference signals are also amplified)
Changing a polarization direction (cross-polarization discrimination of 30 dB can be
achieved)
Step 5 Changed the polarization direction of the radio link.
----End
If the RSL of an ODU is normal or apparently greater than the receiver sensitivity, frequent
and intermittent radio link interruptions or bit errors are generally caused by interference
signals.
4.3 Data Service Faults
4.3.1 Broadcast Storms Due to Incorrect Configurations
Fault Symptoms
Figure 4-1 shows the network topology, where two OptiX PTN 3900s transmitted services to
each other through radio links set up by five OptiX RTN 620s. After a broadcast storm
occurred on the network, NE A became unreachable to its NMS and its converged services
were interrupted.
Figure 4-1 Networking diagram
NE A NE B
OptiX PTN 3900
NE1
OptiX RTN 620
NE2
OptiX RTN 620
NE3
OptiX RTN 620
NE4
OptiX RTN 620
NE5
OptiX RTN 620
GE GE
Hybrid Hybrid Hybrid Hybrid
OptiX PTN 3900

Step 1 Checked for equipment alarms and radio link alarms on the NEs.
No equipment alarm or radio link alarm was found. Therefore, it was suspected that NE data
was incorrectly configured.
(Volume 5)

56

Step 2 Checked operation logs of the OptiX RTN 620s on the U2000.
On NE5, a bridge service was configured between the EMS6 board in slot 4 and the EMS6
board in slot 8 when the fault occurred. Ports 1 and 2 on the two EMS6 boards were mounted
to the bridge.
Step 3 Checked the cable connection between the four ports and the service configuration data of
NE5.
Port 1 and port 2 on the EMS6 board in slot 4 were respectively connected to port 1 and port 2
on the EMS6 board in slot 8 using network cables. Parameter Hub/Spoke, however, was
incorrectly set for the four ports. As a result, a loop formed among the four ports and packets
were forwarded among the four ports, leading to the broadcast storm. For the cable
connection between the four ports, see the following figure.
Slot 1 PXC
Slot 3 Not used
Slot 5 IFH2
Slot 7 Not used
Slot 2 SCC
Slot 4 EMS6
Slot 6 Not used
Slot 8 EMS6
1 2 3 4 5 6
1 2 3 4 5 6

Step 4 Corrected the Hub/Spoke setting for the four ports.
----End
Service interruptions without equipment alarms are generally due to incorrect
configurations.
A loop in an E-LAN, Ethernet private local area network (EPLAN), Ethernet virtual
private local area network (EVPLAN), or other bridge service will result in a broadcast
storm. If Ethernet services need to be provided with path protection using rings, enable
Spanning Tree Protocol (STP)/Rapid STP (RSTP) or Ethernet ring protection switching
(ERPS) for the Ethernet services.
4.3.2 Data Service Interruptions Due to Incorrect IF Modes
Fault Symptoms
Figure 4-2 shows the network topology, where an OptiX RTN 605 1F and an OptiX RTN 620
set up a radio link. Each NE was configured with EPLAN services and connected to a
computer. The NEs did not pass a ping test but did not report an alarm.
(Volume 5)

57

Figure 4-2 Networking diagram
OptiX RTN 620
V100R003
(IFH2 and EMS6)
OptiX RTN 605 1F
(IFH1)

Step 1 Checked for equipment alarms and radio link alarms on the NEs.
No equipment alarm or radio link alarm was found. Therefore, it was suspected that NE data
was incorrectly configured.
Step 2 Checked the working mode parameters for the IF boards at both ends of the radio link.
The E1 capacity was set to different values, resulting in different bandwidths for data services
and finally service interruptions. No alarm indicating E1 capacity inconsistency was provided.
Step 3 Changed E1 capacities to ensure that both NEs had the same E1 capacity.
----End
4.4 Protection Faults
4.4.1 Service Interruptions Due to 1+1 Protection Switchover
Failures
Fault Symptoms
The radio link in 1+1 protection between NE549 and NE606 became faulty, resulting in a
service interruption. The faulty radio link automatically recovered 5 minutes later.
Networking Diagram
7 IF1A
1 PXC
5 IF1A
2 SCC
4 PD1
6 SD1
NE549 NE606
15
ODU
17
ODU
7 IF1B
1 PXC
5 IF1B
2 SCC
4 PD1
6 SL1 15
ODU
17
ODU

(Volume 5)

58

Step 1 Checked historical alarms of the two NEs.
NE549 reported a RADIO_MUTE alarm when the radio link was interrupted.
Step 2 Checked the operation logs of NE549.
A command of muting an ODU was executed before the radio link was interrupted.
Step 3 Checked the switching state of the 1+1 protection group because a RADIO_MUTE alarm
should have triggered a 1+1 protection switchover.
The 1+1 protection group on NE549 was in the forced switching state and was kept working
on the main channel, so the RADIO_MUTE alarm could not trigger a 1+1 protection
switchover.
NOTE

An NE automatically unmutes its ODU 5 minutes (the default time) after the ODU is muted. This
explains why the radio link between NE549 and NE606 automat ically recovered 5 minutes after the link
interruption.
Step 4 Cleared the forced switching state of the 1+1 protection group on NE549 so the protection
group entered the automatic switching state.
----End
The forced switching and lockout switching states of microwave 1+1 protection groups
are generally caused by misoperations and must be cleared in a timely manner.
Exercise precautions before applying any settings to an NE.
4.5 Clock Faults
4.5.1 Abnormal Base Station Services Due to Clock Interlocking
Fault Symptoms
See the following networking diagram. An OptiX RTN 620 (NE A) was deployed at site A and
an OptiX RTN 605 1F (NE B) was deployed at site B. The board in slot 5 on NE A
interworked with the board in slot 8 on NE B through an air interface. Certain base stations
traced clock signals from NE A and NE B, and the clock signals became abnormal.
(Volume 5)

59

Networking Diagram
ODU
ODU
ODU
PW48B SCC EOW PH1 EMS4
IFH1
Slot 1 Slot 2 Slot 3 Slot 4 Slot 5 Slot 8
IFH2
PXC SCC
EMS6
IFH2
Slot 1 Slot 2
Slot 4
Slot 6 Slot 5
Site B Site A

Step 1 Checked the alarms of the NEs.
NE A reported HARD_BAD alarms from February 28 to April 11 and SYN_BAD alarms
in May. The value of the first parameter of HARD_BAD alarms was 6, indicating that
the digital phase-locked loop (PLL) was abnormal. The SYN_BAD alarms indicated that
the traced clock source deteriorated.
NE B reported an RP_LOC alarm, indicating that the clock signals received from the
PLL were lost.
The clocks of the two NEs were abnormal.
Step 2 Analyzed the clock configuration data.
Checked the system clock source priority list of NE A and the clock source that NE A
was tracing.
Priority 1: 5-IFH2-(SDH) air-interface link clock
Priority 2: internal clock source
Clock source that NE A was tracing: 5-IFH2-(SDH) air-interface link clock
Checked the clock configuration data of NE B.
Synchronous Ethernet was not enabled for NE B. In that case, NE B traced the
air-interface link clock of NE A by default. If two OptiX RTN 605 1F/2F NEs are
interworking, the Tx low NE traces the clock of the Tx high NE by default.
The preceding information showed that NE A traced the link clock from its IF board in slot 5
and NE B traced the link clock from its IF board in slot 8. The two IF boards interworked
with each other through an air interface so the two NEs traced each other's clock. In the case
of clock interlocking, a small frequency deviation is gradually enlarged and finally falls out of
the permitted range.
Step 3 Changed the clock configuration NE A so that NE A traces the link clock from its IF board in
slot 6.
----End
(Volume 5)

60

The near-end NE and far-end NE on a radio hop must not trace clock sources that
interwork with each other through an air interface.
Downstream NEs must trace their upstream NEs' clocks.
Alarms must be cleared in a timely manner.
4.6 Equipment Interworking Faults
4.6.1 External Clock Synchronization Faults Due to Incorrect
Cable Connections
Fault Symptoms
See the following networking diagram. NodeB 1 was connected to NE B through an FE port,
NE B and NE A set up a radio link, and NE A was connected to the OptiX PTN 1900 through
a GE optical port. As the FE port on NodeB 1 does not support synchronous Ethernet, NodeB
1 traced clock signals from the external clock port of NE B, which traced clock signals from
NE A through the radio link. NE A traced clock signals from the GE optical port on the OptiX
PTN 1900. When services on NodeB 1 were cut over, clock synchronization failed.
Networking Diagram
Clock cable
FE
NE B NE A
NodeB 1
OptiX PTN 1900
OptiX RTN 910 OptiX RTN 910
Clock Clock Clock

Step 1 Checked cable connection at NodeB 1 because it reported an alarm indicating the loss of
clock signals from an external clock port.
The external clock port on NodeB 1 was a 75-ohm coaxial port and the external clock port on
NE B was a 120-ohm twisted-pair port. To connect the external clock port on NE B to the
external clock port on NodeB 1, an impedance converter box (Balun-box) was installed on the
external clock port of NE B.
(Volume 5)

61

The wire connection diagram of the converter box shows that the Tx wire from NE B was
connected to the Rx end of the converter box and the Rx wire from NE B was connected to
the Tx end of the converter box. Cable connection examination showed that the Tx wire from
the converter box was connected to the Rx end of NodeB 1 and the Rx wire from the
converter box was connected to the Tx end of NodeB 1. As a result, the Tx wire from NE B
was connected to the Tx end of NodeB 1 and the Rx wire from NE B was connected to the Rx
end of NodeB 1, so signals were unavailable.
4/5Tx
1/2Rx
4/5
1/2
Rx
Tx
Rx
Tx
External clock
port of NE B
Converter box
External clock
port of NodeB 1
Correct
connection
Incorrect
connection

Step 2 Corrected the cable connection. NodeB 1 could trace clock signals normally.
----End
Cable connection between interworking equipment must meet the following requirements:
The Tx port at the local end is connected to the Rx port at the opposite end, and the Rx
port at the local end is connected to the Tx port at the opposite end.
If two ports are connected using a twisted pair, the positive end of the local port is
connected to the positive end of the opposite port, and the negative end of the local port
is connected to the negative end of the opposite port.

(Volume 5)
RTN Microwave A Appendix

62

A Appendix
A.1 Distribution of Rain Zones
Based on collected statistics, the ITU divides the globe into 15 rain climatic zones (A to Q)
according to rainfall rates, as shown in Figure A-1. Table A-1 provides the rainfall rates of
each rain zone corresponding to the occurrence probability p% which ranges from to 0. 001%
to 1%. You can view the rain zone distribution figure and rainfall rate table in
Recommendation ITU-R P. 837-1. Wherever possible, use the local rainfall rate to calculate
rain attenuation. If the local rainfall rate is unavailable, you can obtain accurate data from the
ITU-R data bank. Generally, you can use the data provided in the rain zone distribution figure
and rainfall rate table to roughly estimate rain attenuation.
Figure A-1 Distribution of global rain zones

(Volume 5)
RTN Microwave A Appendix

63

Table A-1 Rainfall rate table
Probability Rainfall (Zone)
P (%) A B C D E F G H J K L M N P Q
1 0.1 0.5 0.7 2.1 0.6 1.7 3 2 8 1.5 2 4 5 12 24
0.3 0.8 2 2.8 4.5 2.4 4.5 7 4 13 4.2 7 11 15 34 49
0.1 2 3 5 8 6 8 12 10 20 12 15 22 35 65 72
0.03 5 6 9 13 12 15 20 18 28 23 33 40 65 105 96
0.01 8 12 15 19 22 28 30 32 35 42 60 63 95 145 115
0.003 14 21 26 29 41 54 45 55 45 70 105 95 140 200 142
0.001 22 32 42 42 70 78 65 83 55 100 150 120 180 250 170

A.2 Refractivity Gradient
In ITU-R P.530-12, the refractivity gradient in the lowest 65 m of the atmosphere not
exceeded 1% the year is used to predict radio link performance. Figure A-2 provides the
global refractivity gradients specified in ITU-R P453-9.
Figure A-2 Refractivity Gradient

Method of Fault Locating

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Method of Fault Locating

Hochgeladen von

Copyright:

Verfügbare Formate

Huawei Transport Network Maintenance

Das könnte Ihnen auch gefallen