Troubleshooting PDF

CDMA WLL10.
Troubleshooting Guide
Issue
01
Date
2014-05-31
HUAWEI TECHNOLOGIES CO., LTD.
Copyright Huawei Technologies Co., Ltd. 2014 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
Issue 01 (2014-05-31)
Huawei Proprietary and Confidential

Copyright Huawei Technologies Co., Ltd
CDMA WLL10.0 Troubleshooting Guide
Preface
Preface
Overview
This document describes how to troubleshoot common faults that occur after the RASYS is
operational. Common faults include faults detected during routine maintenance, faults
detected during alarm handling, emergency faults, and faults reported by customers.
Intended Audience
This document is intended for:
System engineers
Field engineers
Change History
Issue
Description
01 (2014-05-31)
This is the first official release. Compared with CDMA

WLL10.0 Draft A (2013-10-30), this issue does not
include any new information.
Draft A (2013-10-30)
Draft A release for CDMA WLL10.0.
Issue 01 (2014-05-31)

ii
Content
Content
Preface ............................................................................................................................................... ii
1 Safety Precautions ......................................................................................................................... 1
1.1 General Safety Precautions .............................................................................................................................. 1
1.1.1 All Safety Precautions ............................................................................................................................. 1
1.1.2 Symbols .................................................................................................................................................. 1
1.1.3 Local Safety Regulations ........................................................................................................................ 2
1.1.4 General Installation Requirements .......................................................................................................... 2
1.1.5 Grounding Requirements ........................................................................................................................ 2
1.1.6 Human Safety.......................................................................................................................................... 2
1.1.7 Equipment Safety .................................................................................................................................... 2
1.2 Electrical Safety ............................................................................................................................................... 3
1.2.1 High Voltage ........................................................................................................................................... 3
1.2.2 Thunderstorm .......................................................................................................................................... 3
1.2.3 High Electrical Leakage .......................................................................................................................... 3
1.2.4 Power Cable ............................................................................................................................................ 4
1.2.5 Fuse ......................................................................................................................................................... 4
1.2.6 Electrostatic Discharge............................................................................................................................ 4
1.3 Inflammable Environment ................................................................................................................................ 5
1.4 Batteries ........................................................................................................................................................... 5
1.4.1 Storage Batteries ..................................................................................................................................... 5
1.4.2 Lithium Batteries .................................................................................................................................... 7
1.5 Radiation .......................................................................................................................................................... 8
1.5.1 Electromagnetic Field Exposure ............................................................................................................. 8
1.5.2 Laser Hazards.......................................................................................................................................... 8
1.6 Working at Heights ........................................................................................................................................... 9
1.6.1 Hoisting Heavy Objects .......................................................................................................................... 9
1.6.2 Using Ladders ....................................................................................................................................... 10
1.7 Mechanical Safety .......................................................................................................................................... 12
1.7.1 Drilling Holes........................................................................................................................................ 12
1.7.2 Handling Sharp Objects ........................................................................................................................ 12
1.7.3 Handling Fans ....................................................................................................................................... 12
1.7.4 Moving Heavy Objects ......................................................................................................................... 12
Issue 01 (2014-05-31)

iii
Content
1.8 Others ............................................................................................................................................................. 13
2 RAC Troubleshooting Process and Methods ........................................................................ 14

2.1 Troubleshooting Process ................................................................................................................................ 14
2.2 Troubleshooting Methods ............................................................................................................................... 18
2.3 Troubleshooting Tools .................................................................................................................................... 24
2.4 Collecting the Fault Localization Information ............................................................................................... 25
2.4.1 Collecting the RAC Fault Localization Information ............................................................................. 25
2.4.2 Collecting the BTS Fault Localization Information .............................................................................. 27
2.5 Obtaining Technical Support .......................................................................................................................... 28
3 Single Point of Failure ............................................................................................................... 29

3.1 Introduction to the Single Point of Failure ..................................................................................................... 29
3.2 RACSingle Point of Failure and Troubleshooting Method ............................................................................ 29
3.2.1 Interface Board Failure ......................................................................................................................... 29
3.2.2 Subrack Backplane Failure ................................................................................................................... 30
3.2.3 Y-Shaped Clock Cable Failure .............................................................................................................. 30
3.2.4 Power Distribution System Failure ....................................................................................................... 31
3.2.5 Fan Box Failure..................................................................................................................................... 31
3.3 BTS Single Point of Failure and Troubleshooting Method ............................................................................ 32
3.3.1 Power Failure ........................................................................................................................................ 32
4 Troubleshooting Emergencies .................................................................................................. 33

4.1 Introduction to Emergencies .......................................................................................................................... 33
4.2 Troubleshooting Call Setup Failures .............................................................................................................. 33
4.2.1 Troubleshooting Call Setup Failures When All Cells Configured in a RAC Are Normal ..................... 35
4.2.2 Troubleshooting Call Setup Failures When Boards in All RACSubracks Are Unavailable .................. 36
4.2.3 Troubleshooting Call Setup Failures When Cells Configured in Some RAC Subracks Are Abnormal 38
4.2.4 Troubleshooting Call Setup Failures When Cells Configured in All RAC Subracks Are Abnormal .... 40
4.3 Troubleshooting Wide Voice Call Drops ........................................................................................................ 42
4.3.1 Introduction to Call Drop Control Mechanism ..................................................................................... 42
4.3.2 Troubleshooting Call Drops .................................................................................................................. 43
4.4 Troubleshooting Poor Voice Quality .............................................................................................................. 46
4.4.1 Voice Service Procedures and Encoding/Decoding Principles .............................................................. 46
4.4.2 Troubleshooting Voice Faults ................................................................................................................ 47
4.5 Troubleshooting Unavailable 1X/EV-DO Data Services................................................................................ 50
4.6 Troubleshooting Call Setup Failures in the Coverage Area of a BTS ............................................................ 53
4.7 Troubleshooting Call Setup Failures in the Coverage Area of an ODU ......................................................... 61
4.8 Troubleshooting Call Setup Failures in the Coverage Area of an RRU ......................................................... 66
5 Troubleshooting MS Access Failures ...................................................................................... 71

5.1 Introduction to MS Access Process ................................................................................................................ 71
5.2 Troubleshooting the Network Access Failure Upon Power Up of MSs ......................................................... 72
5.3 Troubleshooting the Network Access Failure of Some MSs .......................................................................... 73
Issue 01 (2014-05-31)

iv
Content
6 Troubleshooting 1X MOC Failures ......................................................................................... 75

6.1 Introduction to the MOC Process ................................................................................................................... 75
6.2 Troubleshooting MOC Failure Due to Unavailable Radio Resource on the Interface ................................... 76
6.3 Troubleshooting MOC Failure on A Interface ................................................................................................ 78
6.4 Troubleshooting MOC Failure Due to Unavailable Terrestrial Links ............................................................ 80
7 Troubleshooting MTC Failures ................................................................................................ 83

7.1 Introduction to the MTC Process ................................................................................................................... 83
7.2 Troubleshooting the Failure to Receive the Paging Request .......................................................................... 85
7.3 Troubleshooting MTC Failures Due to Other Causes .................................................................................... 86
8 Troubleshooting Handoff Failures .......................................................................................... 87

8.1 Introduction to Handoffs ................................................................................................................................ 87
8.2 Troubleshooting Failures When MSs Fail to Trigger HHOs .......................................................................... 88
8.3 Troubleshooting Inter-frequency HHO Failures............................................................................................. 91
8.4 Troubleshooting SHO Failures ....................................................................................................................... 94
8.5 Troubleshooting Inter-AN HHO Failures for Dormant ATs ........................................................................... 98
8.6 Troubleshooting Inter-AN HHO Failures for Active ATs ............................................................................. 101
8.7 Troubleshooting Inter-AN SHO Failures for Active ATs.............................................................................. 106
9 Troubleshooting Registration Failures ................................................................................. 111

9.1 Introduction to Registration ......................................................................................................................... 111
9.2 Troubleshooting Registration Initiation Failure ........................................................................................... 112
9.3 Troubleshooting MS-Initiated Registration Failure (over V5 Interface) ...................................................... 116
9.4 Troubleshooting Location Update Failure Due to 1X/EV-DO Interoperability ........................................... 117
10 Troubleshooting Authentication Failures .......................................................................... 119

10.1 Introduction to Authentication.................................................................................................................... 119
10.1.1 1X Service Authentication ................................................................................................................ 119
10.1.2 EV-DO Service Authentication ......................................................................................................... 122
10.2 Troubleshooting Broadcast Authentication Failure .................................................................................... 125
10.3 Troubleshooting Unique Challenge Failure (V5 Interface) ........................................................................ 127
10.4 SSD Update Failures of an MS (over the V5 Interface) ............................................................................. 130
10.5 Authentication Initiation Failures (over the V5 Interface) ......................................................................... 131
10.6 Troubleshooting EV-DO Service Authentication Failure ........................................................................... 134
11 Troubleshooting 1X Data Service Failures ......................................................................... 139

11.1 Introduction to 1X Data Service ................................................................................................................. 139
11.2 Troubleshooting 1X Data Call Failure........................................................................................................ 142
11.2.1 Messages are Not Tracked on the A9/A11 Interface ......................................................................... 142
11.2.2 Troubleshooting the Data Call Failure Due to Only the Reverse Messages Received on the A11
Interface ....................................................................................................................................................... 144
11.2.3 Troubleshooting the Release of Data Calls Right After Dial-Up Connection ................................... 145
11.3 Troubleshooting 1X Data Service Handoff Failure .................................................................................... 146
11.4 Troubleshooting Low Transmission Rate for 1X Data Service .................................................................. 147
Issue 01 (2014-05-31)

Content
12 Troubleshooting EV-DO Data Service Failures ................................................................ 151

12.1 Introduction to EV-DO Services ................................................................................................................ 151
12.2 Troubleshooting EV-DO UATI Assignment Failure ................................................................................... 152
12.3 Troubleshooting EV-DO Configuration Negotiation Failure ..................................................................... 155
12.4 Troubleshooting EV-DO Connection Setup Failure ................................................................................... 157
12.5 Troubleshooting Low Forward Rate for EV-DO Services.......................................................................... 159
12.6 Troubleshooting EV-DO Forward Rate Fluctuation ................................................................................... 161
12.7 Troubleshooting Low Reverse Rate for EV-DO Services .......................................................................... 163
13 Troubleshooting License Failures........................................................................................ 169

13.1 Introduction to License ............................................................................................................................... 169
13.2 Troubleshooting Failure to Load License ................................................................................................... 169
13.3 Troubleshooting Call Access Failure in the RAC Due to Restriction on License ...................................... 172
13.1 Troubleshooting Call Access Failure in a Single Module Due to Restriction on License .......................... 174
13.2 Troubleshooting Call Access Failure in a Single BTS Due to Restriction on License ............................... 175
14 Troubleshooting Clock Failures ........................................................................................... 177

14.1 Introduction to RAC Clock System ............................................................................................................ 177
14.1.1 Background Information for the RAC Clock System ....................................................................... 177
14.1.2 Logical Structure of the Clock Synchronization System................................................................... 177
14.1.3 Transmission Synchronization .......................................................................................................... 178
14.1.4 Time Synchronization ....................................................................................................................... 179
14.2 Introduction to BTS Clock System ............................................................................................................ 180
14.3 Troubleshooting High FER in Markov Calls .............................................................................................. 183
14.4 Troubleshooting Incorrect Time Displayed on ATs/MSs ............................................................................ 184
15 Troubleshooting Transmission Failures ............................................................................ 187

15.1 Introduction to Transmission ...................................................................................................................... 187
15.1.1 Introduction to Links ......................................................................................................................... 187
15.1.2 Troubleshooting Principles of Transmission Failures ....................................................................... 188
15.2 Troubleshooting Abis Interface Link Failures ............................................................................................ 190
15.2.1 Troubleshooting Abis Transmission Link Failure ............................................................................. 190
15.2.2 Troubleshooting Abis Maintenance Link Failure .............................................................................. 192
15.2.3 Troubleshooting Abis Signaling Link Failure ................................................................................... 193
15.2.4 Troubleshooting Abis Traffic Link Failure ........................................................................................ 194
15.3 Troubleshooting A3 Interface Failure ......................................................................................................... 195
15.4 Troubleshooting A7 Interface Failure ......................................................................................................... 196
15.5 Troubleshooting A10/A11 Link Failure ..................................................................................................... 197
15.6 Troubleshooting A12 Link Failure ............................................................................................................. 197
15.7 Troubleshooting A13/A16 Link Failure ..................................................................................................... 197
15.8 Troubleshooting A17 Interface Failure ....................................................................................................... 197
15.9 Troubleshooting A18 Interface Failure ....................................................................................................... 198
15.10 Troubleshooting E1 Connection Failure ................................................................................................... 199
Issue 01 (2014-05-31)

vi
Content
15.11 Troubleshooting V5 Link Failure ............................................................................................................. 201

15.12 Troubleshooting V5 Interface Failure....................................................................................................... 203
15.13 Troubleshooting A+ Interface Failures ..................................................................................................... 205
16 Troubleshooting OM Failures .............................................................................................. 209

16.1 Introduction to the BAM OM ..................................................................................................................... 209
16.2 Troubleshooting the Unavailability of BTS Carriers .................................................................................. 209
16.3 Troubleshooting BTS Ping Failures ........................................................................................................... 210
16.4 Troubleshooting BTS Remote OM Failures ............................................................................................... 214
17 Troubleshooting Power Supply Failures ........................................................................... 218

17.1 Introduction to the BTS Power Supply ...................................................................................................... 218
17.1.1 Power Modules of the BBU3900, RRU3606, and ODU3601CE ...................................................... 218
17.1.2 AC/DC Power Equipment of the DBS3900 ...................................................................................... 218
17.2 BBU Power Module Failures ..................................................................................................................... 219
17.2.1 Troubleshooting BBU Power Module Failures ................................................................................. 219
17.2.2 Troubleshooting ODU3601CE Power Module Failures.................................................................... 221
17.3 Troubleshooting ODU3601CE Power Module Failures ............................................................................. 224
18 Troubleshooting BTS Environment Monitoring Failures .............................................. 227

18.1 Introduction to BTS Environment Monitoring ........................................................................................... 227
18.1.1 Terminology ...................................................................................................................................... 227
18.1.2 Environment Monitoring Equipment ................................................................................................ 228
18.1.3 Environment Monitoring Equipment Functions................................................................................ 228
18.1.4 Specifications .................................................................................................................................... 229
18.2 BTS Environment Monitoring Failures ...................................................................................................... 230
19 Troubleshooting BTS Startup Failures ............................................................................... 234

19.1 Introduction to the BTS Startup Process .................................................................................................... 234
19.2 BTS Startup Failures .................................................................................................................................. 237
20 Troubleshooting BTS RF Failures ....................................................................................... 247

20.1 Introduction to the BTS RF ........................................................................................................................ 247
20.2 Test and Analysis of the BTS Reverse RSSI .............................................................................................. 248
20.2.1 Testing the Reverse RSSI .................................................................................................................. 248
20.2.2 Analyzing Reverse RSSI Test Results ............................................................................................... 249
20.3 BTS Reverse RSSI Exception .................................................................................................................... 250
20.4 Troubleshooting BTS VSWR Failures ....................................................................................................... 259
21 Subscriber Data Resource Failures ...................................................................................... 263

21.1 Introduction to the Subscriber Data Resources .......................................................................................... 263
21.2 Defining a Subscriber Fails ........................................................................................................................ 264
21.3 Deleting a Subscriber Fails ........................................................................................................................ 267
21.4 Modifying an IMSI Fails ............................................................................................................................ 269
21.5 Modifying a PN Fails ................................................................................................................................. 271
Issue 01 (2014-05-31)

vii
Content
22 Roaming Billing Failures ....................................................................................................... 275

22.1 Introduction to the Roaming....................................................................................................................... 275
22.2 LE Does Not Receive Any Roaming Billing Information .......................................................................... 276
Issue 01 (2014-05-31)

viii
1 Safety Precautions
Safety Precautions
1.1 General Safety Precautions

This section presents personal health and safety information that applies when you install,
operate, and maintain Huawei equipment. This section also provides guidance for choosing
measurement and test instruments.
1.1.1 All Safety Precautions

To minimize risk of personal injury and equipment damage, read and follow all safety
instructions on equipment and safety precautions in this document before performing
installation or maintenance. The Danger, Caution, and Note symbols in this document do not
cover all safety precautions that must be followed. They only provide generic safety
precautions for operations.
1.1.2 Symbols
This symbol indicates that a hazard with a high level of risk, which if not avoided, will result
in death or serious injury.
This symbol indicates a potentially hazardous situation, which if not avoided, could result in
equipment damage, data loss, performance degradation, or unexpected results.
This symbol indicates additional information provided to emphasize or supplement important points of
an operation.
Issue 01 (2014-05-31)

1.1.3 Local Safety Regulations

When operating equipment, follow local safety regulations. The safety precautions provided
in this document should be regarded as supplemental information.
1.1.4 General Installation Requirements
Only well-trained and qualified personnel are allowed to install and maintain Huawei
equipment.
Only trained personnel are allowed to operate the equipment.
Only qualified professional personnel are allowed to remove safety facilitates and repair
the equipment.
Only personnel authorized by Huawei are allowed to replace equipment or components,

including software.
Operators must immediately report faults or errors that may cause safety problems.
1.1.5 Grounding Requirements

The following requirements only apply to equipment that needs to be grounded:
When installing equipment, ground it first. When removing equipment, disconnect

ground cables last.
Do not damage grounding conductors.
Do not operate the equipment without a grounding conductor.
Equipment must be permanently connected to safety protection. Before operation, check

electrical connections and ensure that equipment is securely grounded.
1.1.6 Human Safety
Do not operate equipment and cables during lightning strikes.
Remove the AC power connector when there is lightning. Do not use fixed or touch
terminals or antenna connectors when there is lightning.
The preceding instructions apply to wireless fixed terminals.
To prevent electric shock, do not connect a safety extra-low voltage (SELV) circuit to a
telecommunication network voltage (TNV) circuit.
To prevent laser radiation from injuring your eyes, never look into the optical fiber outlet
without eye protection.
To prevent electric shock and burns, wear electrostatic discharge (ESD) clothing, gloves,
and wrist strap. Remove conductors such as jewelry and watches before operating
equipment.
In the event of a fire, evacuate the building or equipment site. Raise a fire alarm at the
closest alarm point, or call the emergency number. Do not re-enter a burning building
under any circumstances.
1.1.7 Equipment Safety
Before operation, securely fix equipment on the floor or to other immovable objects such
as walls and mounting racks.
Do not block the ventilation opening while the system is operating.
Issue 01 (2014-05-31)

When installing panels, use a proper tool to tighten screws.
After installing the equipment, clear packaging materials from the equipment site.
1.2 Electrical Safety

1.2.1 High Voltage
Only qualified and authorized electricians are allowed to install the AC facility and
perform high voltage and AC operations.
AC mains installation must be carried out according local safety regulations.
AC operations must be performed according to local safety regulations.
Use dedicated tools when performing high voltage and AC operations.
When an operation is performed in a damp environment, make sure that the equipment is
dry. When water is found in a cabinet or the cabinet is damp, power off the cabinet
immediately.
High-voltage power supply provides power for the system in operation. Direct or indirect
contact with high voltage through damp objects can be fatal.
Improper high voltage operations may cause accidents, such as fire and electrical shock.
1.2.2 Thunderstorm
Do not perform any operations, including high voltage and AC operations, on steel towers or
mast during a thunderstorm.
The preceding requirements only apply to BTSs and devices equipped with an antenna or
GPS antenna.
1.2.3 High Electrical Leakage

If a "high electrical leakage" tag is attached to the power terminal of a device, you must
ground the device before powering it on.
Ground a device before powering it on. Otherwise, personal injury or equipment damage may
be caused by high leakage current.
Issue 01 (2014-05-31)

1.2.4 Power Cable
Before installing or removing a power cable, turn off the power switch.
Before connecting a power cable, ensure that the labels of the power cables are correct.
Do not install or remove power cables when a device is in power-on state. Transient contact
between the core of the power cable and the conductor may generate electric arcs or sparks,
which may cause fire or harm human eyes.
1.2.5 Fuse
If a fuse is replaced, the new fuse must be of the same type and specifications.
1.2.6 Electrostatic Discharge
The static electricity generated by human bodies may damage the electrostatic-sensitive
components, such as the large-scale integrated (LIS) circuits on boards.
Body movement, friction between bodies and clothes, friction between shoes and floors,
or handling of plastic articles can cause static electromagnetic fields on human bodies.
These static electromagnetic fields cannot be eliminated until the static is discharged.
To prevent electrostatic-sensitive components from being damaged by static from on

human bodies, wear a well-grounded ESD wrist strap when touching the device, or
handling boards or application-specific integrated circuits (ASICs).
Figure 1-1 shows how to wear an ESD wrist strap.
Issue 01 (2014-05-31)

Figure 1-1 Wearing an ESD wrist strap
1.3 Inflammable Environment
Do not store a device or perform any operation in an environment that has inflammable and
explosives air or gas.
Operating electrical devices in an inflammable environment can be fatal.
1.4 Batteries
1.4.1 Storage Batteries
Before handling storage batteries, carefully read safety precautions for battery handling and
connection.
Issue 01 (2014-05-31)

Improper handling of storage batteries causes hazards. Avoid short circuits or electrolyte
overflows, or leakages when handling storage batteries.
An electrolyte overflow may damage equipment. It can corrode metal parts and circuit
boards, and ultimately cause short circuits of boards and damage equipment.
Storage batteries store high energy. Improper operations can result in short circuits and
cause severe personal harm.
General Precautions
Before installing and maintaining a storage battery, observe the following precautions:
Use dedicated insulation tools.
Take proper safety measures to protect eyes.
Wear rubber gloves and a protection coat in case of electrolyte overflow.
When handling a storage battery, ensure that its electrodes are upward. Leaning or
reversing the storage battery is prohibited.
Disconnect the charger power supply until the work is complete.
Short Circuit
A battery short circuit may cause injuries. Although the voltage of ordinary batteries is low,
the instantaneous high current caused by the short circuit releases a great deal of energy.
Keep metal objects, which may cause a battery short circuit, away from batteries. If metal
objects must be used, disconnect the battery in use before performing operations.
Hazardous Gas
Do not use unsealed lead-acid storage batteries. Lead-acid storage batteries must be stable and
placed horizontally to prevent the batteries from releasing flammable gas, which may cause
fire or erode the device.
When in use, lead-acid storage batteries emit flammable gas. Therefore, ventilation and
fireproofing measures must be taken at the sites where lead-acid storage batteries are used.
Issue 01 (2014-05-31)

Battery Temperature
Excessive heat can cause the battery casing to soften and warp, potentially resulting in
electrolyte overflow.
When the temperature of a battery is higher than 60C, check the battery for electrolyte
overflow. If the electrolyte overflows, immediately absorb and counteract the electrolyte. You
can use the following substances to absorb and counteract the leaking electrolyte:
Sodium bicarbonate (baking soda): NaHCO3
Sodium carbonate (soda): Na2CO3
Choose a substance to counteract and absorb the leaking electrolyte according to the
instructions provided by the battery manufacturer.
Battery Leakage
When there is electrolyte leakage, immediately absorb and counteract the electrolyte.
When moving or handling a battery that has electrolyte leakage, note that electrolyte in
contact with skin or eyes can cause injury. In the event of electrolyte injuries, rinse the
affected area with water and seek medical attention immediately.
1.4.2 Lithium Batteries
There is danger of explosion if a battery is incorrectly replaced.

Replace the lithium battery only with the same or equivalent type recommended by the
manufacturer.
Dispose of exhausted lithium batteries according to instructions provided by the

manufacturer.
Do not throw lithium batteries into a fire.
Issue 01 (2014-05-31)

1.5 Radiation
1.5.1 Electromagnetic Field Exposure
Radio frequency signals with high intensity are harmful to the human body.
Before installing or maintaining an antenna on a steel tower or mast with a large number of
transmitter antennas, coordinate with parties concerned to switch off the transmitter antennas.
The Base Transceiver Station (BTS) emits radio frequency (RF) radiation (radiation hazard).
Before installing or operating BTSs, be aware of RF safety instructions. Follow local
regulations when installing BTSs.
Exclusion Zones
Antennas must be properly located to prevent the public from accessing areas where RF
exposure levels exceed safety limits.
If RF exposure level exceeds safety limits, ensure that transmitter antennas are switched
off when working with or near antennas. Areas with excessive RF exposure levels must
be confined within a distance of 10 m from antennas.
Each exclusion zone must be defined by a physical barrier and by recognizable sign
warning the public and workers.
1.5.2 Laser Hazards
When handling optical fibers, do not stand close to, or look into the optical fiber outlet
without eye protection.
Laser transceivers or transmitters are used in the optical transmission system and associated
test tools. The laser transmitted through optical fibers has very high power density and is
invisible to human eyes. A beam of light can cause damage to the retina.
Generally, staring into the end of an exposed optical fiber or broken optical fiber without eye
protection from a distance of more than 150 mm [5.91 in.] will not cause eye injury. However,
eyes may be damaged if an optical tool such as a microscope, magnifying glass, or eye loupe
is used to view a bare optical fiber end.
To prevent laser radiation, observe the following precautions:
Only trained and authorized personnel are allowed to perform later-related operations.
Wear eye-protective glasses when handling lasers or optical fibers.
Switch off units producing laser signals before disconnecting an optical fiber connector.
Never look into the end of an exposed optical fiber or open connector if you are not sure
whether the optical source is switched off.
Issue 01 (2014-05-31)

Use an optical power meter to check that the optical source is switched off.
Before opening the front door of an optical transmission system, ensure that you are not
exposed to laser radiation.
Do not use an optical tool such as a microscope, magnifying glass, or eye loupe to view
optical fiber connectors or ends.
Observe the following instructions before handling optical fibers:
Only trained and qualified personnel are allowed to cut and splice optical fibers.
Before cutting or splicing an optical fiber, ensure that the optical fiber is disconnected
from the optical source. After disconnecting the optical fiber, use protecting caps to
protect all optical connectors.
1.6 Working at Heights
Avoid objects falling when you work at heights.

When working at heights, observe the following precautions:
Only trained personnel are allowed to work at heights.
Prevent the devices and tools that you carry from falling down.
Take safety and protection measures, such as wear a helmet and safety belt.
Ensure that adequate protective clothing, essential in cold and wet weather, is available.
Ensure all lifting devices are tested and approved, and ready for use.
1.6.1 Hoisting Heavy Objects
Do not walk below the cantilever or lifted object when heavy objects are being hoisted.
Only trained and qualified personnel are allowed to perform hoisting operations.
Ensure the hoisting tools are tested and approved, and ready for use.
Before hoisting heavy objects, ensure that the hoisting tools are fixed to a secure object
or wall with good weight capacity.
Issue orders with short and explicit words to avoid misoperation.
Ensure that the angle formed by two lifting straps is not larger than 90 degrees. See
Figure 1-2.
Issue 01 (2014-05-31)

Figure 1-2 Hoisting heavy objects
1.6.2 Using Ladders

Checking a Ladder
Before using a ladder, check whether it is damaged. Only use ladders in good condition.
Check the maximum weight capacity of the ladder. Avoid overweighting the ladder.
Placing a Ladder
The recommended gradient of ladders is 75 degrees. You can measure the gradient of the
ladder with a right angle or your arms, as shown in Figure 1-3.
When using a ladder, ensure that it is securely placed. Ensure the wider feet of the ladder are
downward, and take preventive measures to protect the ladder from sliding.
Issue 01 (2014-05-31)

10
Figure 1-3 Gradient of a ladder
When climbing up a ladder, observe the following precautions:
Ensure that your bodys center of gravity does not deviate from the edges of the two long
sides.
To reduce the risk of falling, hold your balance on the ladder before performing an
operation.
Do not climb higher than the fourth rung of the ladder counted from up to down. If you
need to climb a roof, ensure that the ladder top is at least one meter higher than the roof,
as shown in Figure 1-4.
Figure 1-4 Ladder with its top one meter higher than the roof
Issue 01 (2014-05-31)

11
1.7 Mechanical Safety

1.7.1 Drilling Holes
Do not drill holes in cabinets without permission. Drilling holes without complying with
requirements may affect the electromagnetic shielding performance of the cabinet and
damage cables inside. In addition, if scraps caused by drilling enter the cabinet, the printed
circuit boards (PCBs) may be short circuited.
Before drilling a hole in a cabinet, remove internal cables.
Wear an eye protection when drilling holes to prevent your eyes from being injured by
splashing metal scraps.
Wear protective gloves when drilling holes.
Ensure that the scraps caused by drilling do not enter the cabinet. After drilling, clear the
metal scraps immediately.
1.7.2 Handling Sharp Objects
Before you hold or carry a device, wear protective gloves to avoid getting injured by sharp
edges of the device.
1.7.3 Handling Fans
When replacing a component, place the component, screws, and tools in a safe place. If
these objects fall into operating fans, the fans may be damaged.
Do not insert your fingers or boards into operating fans until the fans are switched off
and stop running.
1.7.4 Moving Heavy Objects

Wear protective gloves when moving heavy objects.
When moving heavy objects, take proper measures to prevent injury.
When a chassis is being moved out of a cabinet, unsecured or heavy objects may tip over
if not properly secured, causing personal injury.
Issue 01 (2014-05-31)

12
Generally, two persons are required to carry a chassis. When moving a chassis, keep
your back straight and move carefully to prevent a sprain.
When moving or lifting a chassis, hold the handles or bottom of the chassis. Do not hold
the handles of components installed in the chassis, such as power modules, fan boxes,
and boards.
1.8 Others
Installing or Removing a Board
Before installing a board, wear an ESD wrist strap or gloves. Use proper force to prevent the
pins on the backplane from being bent.
When installing or removing a board, observe the following precautions:
Insert or remove the board along the guide rails.
Prevent the surface of a board from contacting the surface of another board. This
prevents the boards from being short-circuited or scratched.
To prevent electrostatic-sensitive devices from being damaged by ESD, do not touch the
circuits, components, connectors, or connection slots on boards.
Bundling Signal Cables
Do not bundle signal cables along with high current cables or high voltage cables.
Laying out Cables

When the temperature is very low, violent strike or vibration may damage the cable sheathing.
To ensure safety, observe the following precautions:
Cables can be laid or installed only when the temperature is higher than 0C.
Before laying out cables that have been stored at a temperature lower than 0C, move the
cables to an environment of the ambient temperature and store them at the ambient
temperature for at least 24 hours.
Handle cables with care, especially in low temperatures. Do not drop cables directly
from the vehicle.
Issue 01 (2014-05-31)

13
2 RAC Troubleshooting Process and Methods
RAC Troubleshooting Process and

Methods
2.1 Troubleshooting Process

This section describes the process for troubleshooting the RAC.
Figure 2-1 shows the troubleshooting process.
Issue 01 (2014-05-31)

14
Figure 2-1 Troubleshooting flowchart

Start
Back up data
Collect and record

information
Are the scope

and type of the
fault clear?
No
Yes
Determine the scope and
type of the fault
Perform emergency
maintenance
Yes
Is the fault
an emergency
fault?
No
Locate the fault
Rectify the fault
Is the fault
rectified?
No
Contact Huawei technical

support
Yes
Record the troubleshooting
process
End
Backing Up Data
When a fault occurs, save the data and back up the relevant database, alarm information, and
log files. For more information about backing up contents and backup methods, refer to the
RASYS Routine Maintenance Guide.
Collecting and Recording Information

The information related to a fault is essential when troubleshooting.
When a fault occurs, collect the following information for analysis:
Symptom of the fault
Time, place, and frequency of the fault
Scope and impact of the fault
Issue 01 (2014-05-31)

15
Running status of the equipment before the fault occurs
Operations performed on the equipment before the fault occurs
Measures taken to handle the fault.
Alarms and any associated alarms generated when the fault occurs
Status of the board indicators
Collect the information about a fault in the following ways:
Consult the personnel who reported the fault to learn about the fault symptoms and when,
where, and how often the fault occurs.
Consult the maintenance engineers about the running status of the equipment, fault
symptoms, operations performed before the fault occurs, and measures taken after the
fault occurs.
Check the board indicators for hardware or software errors.
Evaluate the scope and impact of the fault by demonstrating the service, testing the
performance, and tracing interfaces or signaling messages.
When collecting fault information:
Do not rush the handling of a fault Collect as much information as possible before you
rectify it.
Maintain effective communication with other maintenance engineers and contact them for
assistance as needed.
Determining the Scope, Category, and Severity of a Fault

After collecting information about a fault, analyze the information and determine the scope,
category, and severity of the fault.
Faults described in this document are classified based on the symptoms of the BSS-related
faults are classified into the following categories:
Voice call failure
Packet data call failure
Handoff failure
Registration, authentication, and encryption failures
Service function failure
Equipment failure
Operation and maintenance failure
Table 2-1 lists the fault categories.
Issue 01 (2014-05-31)

16
Table 2-1 Fault categories

Category
Fault
Voice call failure
Access failure, call failure, MOC failure, MTC failure, and

voice quality problem
Packet data call failure
Packet data service failure
Handoff failure
Handoff failure
Registration, authentication,
and encryption failures
Registration failure, and authentication failure
Service function failure
Quasi-concurrent service failure, BTS failure, license

failure, user data failure, and roam billing failure
Equipment failure
Clock fault, link and circuit fault
Operation and maintenance

failure
Operation and maintenance failure
Some faults cannot be clearly classified. For example, a voice call failure may result from a
clock failure. When this occurs, refer to the sections related to clock failures.
The severity of a fault is determined based on its symptoms. The symptoms and related
scopes for emergency faults are listed in Table 2-2.
Table 2-2 Symptoms and related scopes for emergency faults
Symptoms
Scope
MSs fail to initiate calls
All areas in the coverage of the RAC, areas in the coverage

of a certain module of the RAC, and areas in the coverage of
certain BTSs
Call drops or voice quality

problems occur
All areas in the coverage of the RAC, areas in the coverage

of a certain module of the RAC, and areas in the coverage of
certain BTSs
Subscribers cannot use data

services
Subscribers in CDMA2000 1X networks can use the voice

service but not the data service.
Subscribers in CDMA2000 EV-DO networks cannot use

the data service.
Locating a Fault
A fault may result from several events. Eliminate possible causes and determine the root
cause of the fault.
Issue 01 (2014-05-31)

17
Rectifying a Fault
After locating a fault, rectify the fault and restore the RAC by taking the necessary measures,
such as fixing circuit problems, replacing boards, modifying configuration data, switching
over boards, and resetting boards.
Determining If a Fault Is Rectified

After you rectify a fault, check equipment running status, board indicators, and alarms.
Conduct tests to verify that the fault is rectified.
Recording the Troubleshooting Process

To avoid the occurrence of similar faults, record the cause of the fault and the troubleshooting
process taken to provide preventive and corrective measures.
Contacting Huawei Technical Support

If you encounter any problems, refer to section 0to contact Huawei technical support.
2.2 Troubleshooting Methods

This section describes the methods for locating and troubleshooting faults.
Analyzing Raw Data

Function
Application
Scenarios
Usage
Issue 01 (2014-05-31)
Raw information is essential for fault analysis and contains the

following:
User-reported faults
Fault notifications from other sites
Exceptions detected during maintenance
All other information collected after a fault occurs
Used to determine the scope and type of a fault. The collected

information helps to efficiently locate the fault.
Used for troubleshooting faults in trunks. It is essential for

signaling exchange and interconnection with transmission
systems. For example, this method is used for checking the
running status of transmission systems, data change at the peer
office, and definitions of some signaling parameters.
None.

18
Subscriber Signaling Tracing

Function
After a subscriber signaling tracing task is started, the signaling

messages over standard interfaces and internal interfaces are tracked
by IMSI or ESN/MEID. The signaling messages and the message
status are displayed in time sequence on the Service Maintenance
System. The subscriber signaling tracing function provides the
following benefits:
Displays tracing results in real time
Provides signaling messages over all standard interfaces
Applies to heavy traffic scenarios
Applies to various scenarios such as analyzing call procedures and

tracing signaling messages of VIP subscribers.
Application
Scenario
Used for locating a recurring call failure.
Usage
For details about how to use the subscriber signaling tracing tool, see
the RAC6690 Operation Guide and RASYS RAC6690 Service
Maintenance System Help.
Interface Tracing
Function
Application
Scenario
Usage
Issue 01 (2014-05-31)
After a signaling message tracing task is started, the signaling

messages and the message status display in time sequence on the
Service Maintenance System. Tracing standard interfaces brings the
following benefits:
Displays tracing results in real time
Traces all signaling messages over a specific interface within a

specific time.
Traces link management messages.
Used for:
Locating a call fault that is unknown to users.
Locating link problems, such as link setup, link deletion, and link
modification.
For details about how to use the interface tracing tool, see the CDMA
WLL LMT User Guide and RASYS CDMA Alarm Management
System Help.

19
Alarm Information
Function
Alarm information is an important indication of a fault or an event.

Therefore, checking alarms is an effective method for
troubleshooting faults. If a fault occurs in the RAC, an alarm
displays on the Alarm Management System. Rectify the fault
according to the alarm handling procedures corresponding to each
alarm on the Alarm Management System.
Set audible or visible alarms on the alarm box so that maintenance
engineers are notified when a fault occurs.
Application
Scenario
Used for:
Usage
Troubleshooting equipment failures
Troubleshooting service failures.
For details about how to use the Alarm Management System, see the
CDMA WLL LMT User Guide and Airbridge RASYS CDMA Alarm
Management System Help.
Analyzing Indicator Status

Function
Indicators provide the running status of boards, circuits, links,

optical paths, nodes, channels, and active/standby devices. They are
essential for analyzing and locating faults.
Application
Scenario
Used for identifying the exceptions in boards, circuits, links, and

active/standby devices.
Each board in a RAC6690 is configured with a running indicator and
an alarm indicator. Some boards are configured with function
indicators or feature indicators.
Usage
Issue 01 (2014-05-31)
For more information about the meaning of the indicator status, refer
to the Indicators on RACBoards section of the RAC6690 Hardware
Description.

20
Analyzing Operation Logs

Function
Faults may occur after the configuration data of a RAC6690 is

modified. When a fault occurs, query and analyze logs to learn about
the operations performed on the BAM when the configuration data
was modified.
Application
Scenario
Used for troubleshooting faults caused when modifying

configuration data.
Usage
Run the LST LOG command to query logs.
Run this command to view which modification commands were

executed by maintenance engineers in a given period.
Troubleshoot faults based on the results.
In addition to reviewing the local office logs, review the data

changes of the peer office if necessary.
Checking Data
Function
Data checking usually involves:
Signaling messages
Locate faults by analyzing subscriber signaling messages over

subscriber interfaces and standard interfaces.
Data of the BAM and FAM
Run the STR CRC command to verify the consistency of data

between the BAM and the FAM.
Application
Scenario
Used for analyzing common faults.
Usage
For more information about how to verify data consistency between

the BAM and the FAM, see section "Execute CRC Verify" in
"Database Management" of "System Management" in the
RAC6690RAC MML Command Reference.
Issue 01 (2014-05-31)

21
Conducting Call Tests

Function
Voice services comprise the majority of all services provided by the

RAC6690. If a fault related to the RAC6690 occurs, voice services
may be affected. Conduct call tests to check the call processing
capability of the RAC6690 and the running status of the related
modules.
Application
Scenario
Used when the call processing capability of the RAC6690

deteriorates or the related modules operate abnormally. This method
is usually used with the dynamic connection tracing function, and is
widely used for testing various functions, such as call processing
capability, calling identity delivery, and charging.
Usage
None.
Testing Specific Resources

Function
Instruments, meters, and software test tools are a common way for
testing specific resources, such as transcoders (TCs), and Service
Delivery Units (SDUs). Measured data is used for determining
whether a device is faulty, or if its performance sharply declines.
Application
Scenario
Used for troubleshooting the following faults:

Faults in TC resources
Faults in SDUs
Usage
Conduct a call test for specific TC timeslots by running the OCP

IMSITCTS command.
Conduct a call test for specific SDUs by running the OCP SDUDSP
command.
Analyzing Performance Statistics

Function
Collect statistics on call performance events, such as access failures,

call drops, and handoff failures. The performance results reflect the
overall call situation for a single carrier, a single BTS, or the entire
BSS. The KPIs include CS call setup success rate, CS call drop rate,
PS call setup success rate, PS call drop rate, HRPD session setup
success rate, EV-DO connection establishment success rate, and
EV-DO call drop rate.
Application
Scenario
Used for analyzing performance and KPIs.
Usage
For more information about how to perform the performance

measurement, refer to the RAC6690 Performance Counter Reference
and BTS. Performance Counter Reference.
Issue 01 (2014-05-31)

22
Comparing and Interchanging

Function
Compare a faulty component with a working component to

determine the cause of a fault. Performing a comparison is used
for locating simple faults.
If a fault cannot be located on the suspected component after

replacing a board or an optical fiber with a spare, replace the
suspected component with one that works properly. Observe any
changes. Interchanging is used for locating complex faults.
Application
Scenario
Used for locating a hardware fault, specifically faults in equipment

hardware or cable connections.
Usage
For more information about how to replace a component, refer to

the RASYS Routine Maintenance Guide.
Performing an Active/Standby Switchover or Resetting

Function
After an active/standby switchover is complete, all the services in an

active device are switched over to a standby device. By comparing the
status of the system before and after the switchover, you can
determine whether the active device is faulty or whether the
active/standby configuration is correct.
Through resetting, you can manually restart a device. This operation
helps you determine whether the software is running properly or
whether resource deadlock has occurred in the software.
Application
Scenario
Use this method to rectify a service fault on a board.
Usage
Resetting a device interrupts ongoing services because part of the

device or the entire device must be restarted manually. Use caution
when performing this operation.
Issue 01 (2014-05-31)

23
Performing Remote Maintenance and Analysis

Function
The Remote Maintenance System is a platform for maintenance

engineers to remotely access and maintain RAC6690. After a local PC
is connected to the remote server, either a BAM or emergency
workstation, through the PSTN using a modem, maintenance
engineers can monitor and maintain network equipment remotely
through the remote access service provided by the Windows 2000
Server.
Application
Scenario
Use this method to query, modify, add, and delete files of the
maintained devices, and to upload and download files.
Usage
The method of running the LMT software on a remote PC is the same

as running it on a local PC.
For details about how to configure the remote maintenance function,
see the Configuring the RMS in Dial-Up Mode section in the
Common Operations on System Software chapter of the
RAC6690RAC BAM Management Guide.
2.3 Troubleshooting Tools

This section describes the tools used to troubleshoot RASYS faults. The tools are classified
into general tools, special-purpose tools, meters, and MAINEX.
Tool List
Table 2-3 describes the tools used for troubleshooting RASYS faults.
Table 2-3 Troubleshooting tools
Category
Name
Function
Reference
General
tool
LMT
Troubleshoot a single NE. When a RASYS fault is

detected on the U2000 client, log in to the faulty
BSS through the LMT to locate and analyze the
cause of the fault.
For details, see the

Airbridge RASYS CDMA
Service Maintenance
System Help.
Monitor the RASYS status in real time, query

parameters, and start message tracing on the LMT
to locate faults.
Special
tools
Alarm
Management
System
Query information about real-time alarms reported

to the U2000, and query information about
historical alarms under different conditions. Alarm
information helps you analyze basic problems.
For details, see the

Airbridge RASYS CDMA
Alarm Management
System Help.
U2000 client
View performance counters.
For details, see the U2000

Help.
Cait
Locate radio link status.
See the Cait Help.
QXDM
Locate radio link status.
See the QXDM Help.
Issue 01 (2014-05-31)

24
Category
Meter
Name
Function
Reference
Iperf
Locate wired link status.
See the Iperf Help.
DSLA
The Digital Speech Level Analyser (DSLA),

produced by Malden, tests end-to-end voice
quality.
See the DSLA user

manuals.
LMT
The LMT is a PC that has maintenance system software installed, and is connected to the
RAC for maintaining the RASYS.
For details about how to start the LMT, see the RASYS LMT User Manual.
Remote Access
For the principles and methods of remote access, see the RAC6690 BAM Management Guide.
2.4 Collecting the Fault Localization Information

If a troubleshooting method is not available in the RASYS Troubleshooting Guide, contact
Huawei technical support for assistance. To facilitate fault localization and troubleshooting,
provide relevant information to Huawei technical support engineers. The required fault
localization information varies according to the actual situation. The following sections
provide guidelines for collecting fault localization information.
2.4.1 Collecting the RAC Fault Localization Information

Item
Procedure
RAC version
information
Run the LST BAMVER command on the RAC LMT. Then obtain the RAC version
information from the result of the command.
RAC configuration
script
Run the GET MMLSCRIPT command on the RAC LMT.
Running logs of
RAC boards or
subsystems
The existing running logs for RAC boards or subsystems are saved in
D:\SysExpdat\runlog on the BAM. Historical logs for the RAC boards or subsystems
are saved in D:\CDMA2000\Backup\FamRunLog on the BAM. The logs are saved by
date. Obtain the required running logs for boards based on the date. When the size of
data reaches 10 MB, the running log is generated and is named by date.
After the command executes successfully, obtain the exported script file from
D:\cdma2000\backup\mmlscript on the BAM.
The *.dat.bz2 file in the directory is the process file of the running log and cannot be
decompressed.
To view the current running log of boards or subsystems, run the COL FAMLOG
command.
Running logs of
specific RAC boards
Issue 01 (2014-05-31)
The existing running logs for RAC boards or subsystems are saved in
D:\SysExpdat\runlog on the BAM. Historical logs for the RAC boards or subsystems
are saved in D:\CDMA2000\Backup\FamRunLog on the BAM. The logs are saved by

25
Item
Procedure
or subsystems
date. The name of a board log file or a subsystem log file contains the actual board
name or subsystem name. Obtain the running logs for a specific board or subsystem.
BAM software logs
BAM software logs are named by software name and saved in

D:\Airbridge\services\Log on the BAM. Obtain all files in this directory.
Information about
existing alarms
1. Perform message redirection on the LMT.

2. Run the LST ALMFE command.
3. After the command is executed, the message redirection is complete.
4. The message redirection result is display.
Information about
historical alarms

2. Run the LST ALMLOG command.
3. After the command is executed, the message redirection is complete.
4. The message redirection result displays.
Raw traffic statistics

file
Raw traffic statistics files are saved by date in D:\cdma2000 on the BAM. Obtain the
raw traffic statistics file based on the date.
Call log tracing file

on the SysExplorer
Create and start a task for tracing call logs by using the SysExplorer. The tracing file is
saved in D:\SysExpDat\Clt\.
Packet capture file

on the SysExplorer
Create and start a task for capturing packets by using the SysExplorer. The packet
capture file is saved in D:\SysExpDat\UserPacketCatch\.
Single-subscriber
traffic tracing file
Start a task for tracing the single-subscriber traffic on the Service Maintenance System.
The tracing file is saved in D:\Airbridge\OutputFile\RMON\USERTP_RESOURCE on
the BAM.
RAC operation logs
The RAC operation logs are saved by date in D:\cdma2000\Backup\OperLog\backup on

the BAM. Obtain the RAC operation logs for the specified day.
Radio resource
monitoring file
Start a task for monitoring radio resources on the Service Maintenance System. The
monitoring file is saved in D:\Airbridge\OutputFile\RMON\RADIO_RESOURCE on
the BAM.
Raw CDR file
1. Run the MOD CDRFILTER command on the LMT to enable the CDR filter switch.
2. Add the corresponding CDR carrier, subscriber, and subsystem based on the CDR
trace type.
3. Start the CDR tracing. After a raw CDR file is generated, it is automatically saved in
D:\SysExtDat\CDR on the BAM.
4. After the CDR tracing is started for a specific period, obtain the raw CDR file in this
directory.
Raw license file
Issue 01 (2014-05-31)
The raw license file is saved in D:\cdma2000\loaddata on the BAM. The raw license file
name is raclicense.dat.

26
Item
Procedure
License information
2. Run the DSP LICENSEFILEINFO command on the LMT to query the license
information about the FAM and BAM.
3.Run the following commands:
DSP RACLICENSECFG
DSP SYSESN
DSP RACLICENSECFG
4. The message redirection result displays.
2.4.2 Collecting the BTS Fault Localization Information

Item
Procedure
Alarm information
Run the following command to query current alarms and historical alarms.
LST NEALMLOG: ALMTP=ALL, SD=2009&&10&11, ED=2009&&10&12,
STAT=NORMAL;
This command enables you to query alarms that are generated within a set time period.
In the above example, the information in red represents the start and end date of that
time period. If the start and end date are not specified, the number of alarms you query
at a time may exceed the maximum of 1,000. If this happens, query results cannot be
exported. Huawei recommends you use this command to specify the start and end date
when querying historical alarms. If the date information is not specified, the date when
the command is executed is considered the start date and end date by default, and all
the alarms that are generated from 00:00:00 to the current time of the day are queried,
including alarms that are not cleared.
Run the LST CURALM command to query existing alarms and run the LST
HISALM command to query historical alarms through the Telnet.
BTS running log
1. Run the RPT CBTSLOG command to enable the BTS to report running logs. After
this command is successfully executed, the BTS takes about 10 minutes to upload the
log file because of its large size.
2. The BTS logs are classified into running logs and operation logs, which are saved as
files in D:\Airbridge\Services\BTSLog. Each file name contains the BTS ID. The .bak
file containing running logs is a historical log file.
BAM log
The existing logs are saved in D:\Airbridge\Services\Log.

The historical logs are saved in D:\cdma2000\Backup\BamLog.
Configuration script
1. Run the SAV CBTSCFG: BTSID=XXX; command to save the BTS configuration
scripts on the Service Maintenance System.
2. The BTS configuration scripts are saved in D:\cdma2000\BTSLoad\cfg.
Upgrade tool logs
1.The logs of the upgrade wizard client are saved in the following path:
C:\Program Files\HuaWei\VerUpgrade\CBTS\Log
The logs are saved in the default path C:\Program Files\ or the installation directory
HuaWei\VerUpgrade\CBTS\Log.
2.The logs of the upgrade wizard server are saved in the following paths on the active
Issue 01 (2014-05-31)

27
Item
Procedure
and standby BAMs:
C:\WINDOWS\BTSVutServer\Log
D:\cdma2000\VerUpgrade\Log\BTSVutServer
If disk F exists, the logs are saved in F:\cdma2000\VerUpgrade\Log\BTSVutServer.
Statistics on link error

codes
1. Run the LST CBTSLNKERRCNT: BTSID=XXX; command.
(Received Signal
Strength Indicator)
RSSI tracing
1. Start the RSSI tracing for the BTS on the Service Maintenance System.
2. The file containing statistics on the error codes of BTS links is saved in
D:\Airbridge\services\LinkErrCnt. The file name is BTSXXXXLinkErrorCount.txt,
where XXXX indicates the BTS ID.
2. The tracing results are saved in \outputfile\RMON\RMON_RSSI\sub-directory of

the LMT installation directory. For example:
D:\Airbridge\CBTS LMT\CDMA
BTS-OMCV400R007ENGC00SPC300\outputfile\RMON\RMON_RSSI\
2.5 Obtaining Technical Support

If you encounter any problems, contact Huawei technical support.
Issue 01 (2014-05-31)

28
3 Single Point of Failure
Single Point of Failure
3.1 Introduction to the Single Point of Failure

To ensure system reliability, the RAC6690 uses redundancy design, such as patented Ptrunk
technology, O&M dual-plane design, system clock synchronization, and twisted-pair cable
connections for key components. The boards for the RAC6690 also adopt redundancy design.
For example, IP interface boards use 1:1 or N:1 backup, signaling processing boards and
SCUs use 1:1 backup, and service processing boards use resource pool mode. Single point of
failure, however, may occur in scenarios where redundancy design is not available. If a single
point of failure occurs, the RAC cannot run properly.
This chapter describes all the single point of failures that may occur in the RASYS, and the
corresponding troubleshooting methods. If a single point of failure occurs, perform an
active/standby switchover or replace the faulty hardware to quickly restore service.
3.2 RACSingle Point of Failure and Troubleshooting

Method
3.2.1 Interface Board Failure
The A interface boards and Abis interface boards for the RAC6690 use 1+1 and N:1 hot
backup. Some interface boards at certain sites in the live network, however, are configured
independently to reduce hardware costs or save transmission resources, or because the peer
devices do not support active/standby configuration. If a board becomes faulty and does not
have a backup, the services and functions on the board become unavailable.
Possible Cause
The possible causes for the failure are as follows:
An interface board is faulty.
The transmission link on an interface board is faulty.
Replace the faulty interface board.
Restore the faulty transmission link on an interface board.
Workaround
Issue 01 (2014-05-31)

29
For more information about how to replace an interface board, see "Replacing RAC Boards"
in the RAC6690 Site Maintenance Guide.
Troubleshooting Method
To handle the single point of failure on an interface board in independent mode,

configure the faulty interface board in active/standby mode or 1:N mode. After the
interface board is configured in 1+1 or N:1 hot backup mode, the system runs properly
even if this type of single point of failure occurs.
At sites where interface boards are configured independently, back up the interface
boards using the same type of board.
3.2.2 Subrack Backplane Failure

A backplane is located in a subrack of the RAC6690. It is used for bus arbitration and signal
transmission between boards in a subrack.
Possible Cause
A board in a subrack is short-circuited with the ground.
The pins on the backplane connector are bent, which causes a short circuit or open signal
circuit on the backplane.
The DIP switches of a backplane are faulty.
Workaround
Replace the faulty backplane.
For more information about how to replace a subrack backplane, see "Maintaining RAC
Subracks" in the RAC6690 Site Maintenance Guide.
Back up the subrack backplane based on actual configurations of the live network.
3.2.3 Y-Shaped Clock Cable Failure

The RAC clock subsystem implements transmission synchronization and clock
synchronization for the entire RAC. The RAC clock subsystem consists of two GCUOs,
which provide clock signals for the RAC. The GCUOs are installed in slots 12 and 13 in the
CDMA Main Processing Subrack (CMPS). The GCUOs transmit clock signals to the
SCUO in the CMPS through the backplane, and then to the SCUO in the CSPS through the
Y-shaped clock cable.
Possible Cause
The Y-shaped clock cable is faulty.
Workaround
Replace the damaged Y-shaped clock cable.
Issue 01 (2014-05-31)

30
For more information about how to replace the Y-shaped clock cable, see "Replacing RAC
Cables" in the RAC6690 Site Maintenance Guide.
Back up the Y-shaped clock cable based on actual configurations of the live network.
3.2.4 Power Distribution System Failure

Each RAC cabinet is configured with a power distribution box (PDB), which provides two
power inputs (A1, A3 or B1, B3). The PDB supports 48 V DC input rated voltage and a
maximum of one-path 100 A current. After the power supply is processed for lightning
protection and overcurrent protection purposes, the PDB provides ten 48 V DC power
outputs and supports a maximum of one-path 50 A current. For the onsite configuration, two
power inputs of the PDB are provided by one power distribution cabinet. In this configuration,
the whole subrack will be powered off or reset if the power distribution cabinet is faulty.
Possible Cause
Two power inputs of the PDB are provided by one power distribution box. The failure of the
power distribution box results in the failure of the power distribution system.
Workaround
Rectify the fault on the input power.
For more information about how to maintain the power distribution system, see "Maintaining
the Power Supply System of the RAC" in the RAC6690 Site Maintenance Guide.
Check that two power inputs are provided by two power distribution cabinets. This
ensures that the power distribution system works properly when one power input fails.
Check the power distribution system thoroughly. If two power inputs are provided by
one power distribution cabinet, change the power distribution system based on
information in the RAC6690 Site Maintenance Guide.
3.2.5 Fan Box Failure

The fan box is used to dissipate heat in the system. One fan box is configured for each CMPS
or CSPS. If the fan box stops running for over one minute, the board may overheat and be
damaged.
Possible Cause
The fan box is faulty.
Workaround
Replace the faulty fan box.
For more information about how to replace a fan box, see "Maintaining RAC Subracks" in the
RAC6690 Site Maintenance Guide.
Issue 01 (2014-05-31)

31
Back up the fan box based on actual configurations of the live network.
3.3 BTS Single Point of Failure and Troubleshooting

Method
3.3.1 Power Failure
When the BTS power module is faulty, the BTS may fail to start or may restart frequently
Possible Cause
The power module is installed improperly. As a result, the power supply between the
power distribution frame (PDF) and the cabinet fails.
The circuit breaker (or fuses) on the BTS is disconnected from the PDF or is
deteriorating. The circuit breaker deterioration may lead to unstable power supply.
The EMI filter or power module of the BTS is faulty
The cable is disconnected.
The power supply of the BTS deteriorates because the wiring terminals are oxidized.
Consequently, the power module or the RF module is faulty.
Check that the screws are securely connected to the wiring posts on the top of the RAC
cabinet and check that the RAC cabinet is grounded properly. Improper grounding of the
RAC cabinet may cause high BER, resulting in frequent restarting of the BTS
Check that the power cable is securely connected to the PDF. In addition, check that lugs
are correctly installed if there are overlaid lugs
Check the power supply system.
Workaround
Check whether the voltage of power supply at the top of the RAC cabinet is normal
and stable.
Set the multimeter to the DC voltage mode, and connect the positive and negative
poles of the multimeter to the positive and negative power supply terminals at the top
of the RAC cabinet respectively. The positive terminal is a GND terminal, and the
negative terminal is a 48 V terminal. The voltage of the terminals ranges from 40 V
DC to 60 V DC
If the power supply at the top of the RAC cabinet is abnormal or unstable, request
power supply maintenance engineers to rectify the faults. The abnormal or unstable
power supply may be caused by insecure wiring, cable deterioration, or fuse
disconnection (for example, fuse wires or circuit breakers are disconnected).
Check the power module installation, cable connections, and power supply system by using
tools and referring to the preceding handling suggestions.
Issue 01 (2014-05-31)

32
4 Troubleshooting Emergencies
Troubleshooting Emergencies
4.1 Introduction to Emergencies

Emergency maintenance is required when emergencies occur during the operation of RASYS
equipment. This section describes possible emergencies that may occur on Huawei CDMA
equipment, and relevant maintenance procedures.
Emergencies may include:
Call setup failures for a large number of voice subscribers
Call drops for a large number of voice subscribers during conversation
Poor voice quality
Call setup failures in the coverage area of a single BTS
Call setup failures in the coverage area of a single ODU
Call setup failures in the coverage area of a single RRU
4.2 Troubleshooting Call Setup Failures

When all subscribers in a RAC coverage area fail to set up calls, check whether the fault is
caused by network elements (NE) in the core network (CN). If the NEs in the CN function
properly, perform emergency maintenance for the RAC.
Symptom
In the coverage area of a RAC, a RAC module, or several BTSs, call setups for mobile
stations (MSs) fail.
Troubleshooting Process Flow

Figure 4-1 shows the process flow for troubleshooting call setup failures in the RAC coverage
area.
Issue 01 (2014-05-31)

33
Figure 4-1 Flowchart for troubleshooting call setup failures in the RAC coverage area
Start
Check alarms
Is the software
automatically loaded
to the faulty board
successfully?
Yes
Is there a Board
Not in Position
alarm?
No
Yes
No
Query the board status
Replace the board
Yes
Are all boards
unavailable?
See section 4.2.2
No
4
Query the cell status
Are all cells

of the BSC working
properly?
If all cells are working

improperly, see section
4.2.4
If some cells are working

improperly, see section
4.2.3
If all cells are working

properly, see section 4.2.1

support
End
Issue 01 (2014-05-31)

34
Troubleshooting Procedure
1. Check alarms.
On the Alarm Management System, choose Browse > Fault Alarm. The Fault
Alarm Browse window is displayed.
Check whether any Board Not in Position alarm is reported.
On the Service Maintenance System, run the LST ALMLOG command to query information about all
alarms generated before a specified time.
2. Query the board status.

On the Service Maintenance System, click the Maintenance tab. Then expand the
Equipment Panel node to query the board status.
If a board is displayed in red, the board is unavailable.
If a board is displayed in green, the board is available and in active state.
If a board is displayed in blue, the board is available and in standby state.

On the Service Maintenance System, you can run the DSP FRMINFO and DSP BRDINFO commands to
query board status.
3. Replace the boards.

After a Board Not in Position alarm is reported, the software of a faulty board is loaded
automatically. If the loading is successful, the system clears the alarm. If the loading is not
successful, replace the faulty board.
4. Query the cell status.
On the Service Maintenance System, run the DSP RES command to query the status of all the
sector carriers configured in the RAC. The status of a normal carrier meets the following
requirements:
Operating Status is Enabled
Administrative Status is Unlocked
Usage Status is Active or Idle
If all the cells configured in the RAC are normal, see section 4.2.1 .
If some cells configured in the RAC are abnormal, see section 4.2.3 .
If all cells configured in the RAC are abnormal, see section 4.2.4 .
---End
4.2.1 Troubleshooting Call Setup Failures When All Cells

Configured in a RAC Are Normal
A call setup in the coverage of a RAC fails. If all the cells in a RAC are normal, the BTS and
the Abis interface function properly. In this case, check the RAC and other external ports to
locate and clear the fault.
Issue 01 (2014-05-31)

35
4.2.2 Troubleshooting Call Setup Failures When Boards in All

RACSubracks Are Unavailable
When all subscribers in the coverage area of a RAC fail to set up calls, check the status and
alarms of all boards in the subracks. The RAC internal switching system may malfunction if:
All boards are unavailable.
A Board Not in Position alarm exists.
In this case, perform the following procedure to rectify the fault.
Symptom
Call setups in a large coverage area fail, and all boards are unavailable. Additionally, the
following symptoms appear.
On the Alarm Management System, a Board Not in Position alarms exists.
On the Service Maintenance System, the equipment panel status shows boards in all
subrack are faulty.
On the Service Maintenance System, run the DSP BRDINFO command to query the
status of the specific board. The returned result shows the board status is unavailable.

Figure 4-2 shows the process flow for troubleshooting call setup failures when boards in all
RAC subracks are unavailable.
Issue 01 (2014-05-31)

36
Figure 4-2 Flowchart for troubleshooting call setup failures when boards in all RAC subracks are
unavailable
Start
1
Ping the IP address of the

SCUOa in the CMPS
2
Is the ping
operation
successful?
No
Ensure that the Ethernet

cable is properly
connected and the IP
address and subnet mask
are correct
Yes
3
Check the status of the

SCUOa in the CMPS
Is the status of the

SCUOa normal?
No
Switch over or replace the

abnormal SCUOa in the
CMPS
Yes
Is the BSC
faulty?
No
Yes
5
Collect data before

resetting the BSC
6
Reset the BSC

support
End
1. On the BAM, ping the IP address of the SCUOa in the CMPS subrack.
In the Windows operating system, choose Start > Running and then run the cmd
command to open the MS-DOS window
Ping the IP address of the SCUOa in the CMPS to check whether the communication
between the BAM and the SCUOa is normal. For example, run the ping 80.130.16.192
command. The following message is displayed:
Pinging 80.130.16.192 with 32 bytes of data: Reply from 80.130.16.192: bytes=32
time<10ms TTL=255 Reply from 80.130.16.192: bytes=32 time<10ms TTL=255 Reply from
80.130.16.192: bytes=32 time<10ms TTL=255 Reply from 80.130.16.192: bytes=32
time<10ms TTL=255
Issue 01 (2014-05-31)

37
If a reply message similar to the preceding one is received, communication between the
BAM and the SCUOa in the CMPS subrack is normal.
2. Check whether the Ethernet cable is properly connected and that the settings of the IP address
and subnet mask are correct.
Check whether the internal virtual IP address of the BAM is 80.0.0.255 and the subnet
mask is 255.0.0.0.
Check whether the Ethernet adapter group configuration for the BAM is correct.
Check whether all processes in the BAM manager are in the running state.
3. Check the status of the SCUOa in the CMPS.

On the Service Maintenance System, run the DSP BRDINFO command to check whether the
status of the SCUOa in the CMPS is normal.
4. Switch over or replace the abnormal SCUOa in the CMPS.
On the Service Maintenance System, run the STR MANUALSWITCHING command to
switch over the SCUOa in the CMPS. If the service is not restored after the switchover,
replace the SCUOa in the CMPS.
5. Collect data before resetting the RAC.
Before resetting the RAC, collect and send necessary data to Huawei for further analysis.
6. Reset the RAC.
Run the RST FRM command to reset the RAC CSPS, and then reset the CMPS. After the
RAC is reset, if the software of a board cannot be loaded, replace the board.
---End
4.2.3 Troubleshooting Call Setup Failures When Cells Configured

in Some RAC Subracks Are Abnormal
When calls fail to be set up in cells configured in some RAC subracks, check the boards, the
transmission lines between the RAC and the BTS, and the BTS that provides coverage to the
abnormal cells.
Symptom
When calls fail to be set up in the coverage area of a RAC, check the status of the cells
configured in each subrack. The symptoms are as follows:
Cells configured in some RAC subracks are abnormal, and calls fail to be set up in these
cells.
Cells configured in other RAC subracks are normal, and calls can be set up in these cells.

Figure 4-3 shows the process flow for troubleshooting call setup failures when cells
configured in some RAC subracks are abnormal.
Issue 01 (2014-05-31)

38
Figure 4-3 Flowchart for troubleshooting call setup failures when cells configured in some RAC
subracks are abnormal
Start
Query the SPUO subsystem

associated with the abnormal cell
2
Are all
cells associated with
the SPUO subsystem
abnormal?
Yes

XPUOa or APUOc to which
the SPUO subsystem is
loaded
No
3
Query the Abis interface boards

associated with the abnormal cells
Are
all abnormal cells
associated with the
same Abis interface
board?
No
Rectify faults in the BTS
Yes
Are all abnormal cells
associated with the same
port of the Abis interface
board?
Yes
Rectify faults in the port

connection and transmission
No
4
Reset the Abis interface board
Contact Huawei technical support
End
1. Query the SPUO subsystem associated with the abnormal cell.
Issue 01 (2014-05-31)
On the Service Maintenance System, run the DSP RES command to query the status of
all sector carriers. Record all abnormal cells.

39
On the Service Maintenance System, run the LST CELL command to check the cell
information. Record the mapping between the cells and the SPUO subsystems.
Locate the SPUO subsystems associated with the abnormal cells according to the
preceding query results.
2. Switch over or replace the APUOc onto which the SPUO subsystem is loaded.
switch over the APUOc. If the service is not restored after the switchover, replace the APUOc.
3. Query the Abis interface boards associated with the abnormal cells.
On the Service Maintenance System, run the DSP RES command to query the status of
all RAC sector carriers. The status of a normal carrier meets the following requirements:
Operating Status is Enabled
Administrative Status is Unlocked
Usage Status is Active or Idle
On the Service Maintenance System, run the LST BTSLNK command to check the
mapping between the abnormal cells and the RAC Abis interface boards.
4. Reset the Abis interface boards.

On the Service Maintenance System, run the RST BRD command to reset the Abis interface
boards.
---End
4.2.4 Troubleshooting Call Setup Failures When Cells Configured

in All RAC Subracks Are Abnormal
When calls fail to be set up in the coverage area of a RAC and all cells are in abnormal status,
switch over or reset the APUOc, or reset RAC subracks to locate and rectify the fault.
Symptom
Call setups in the coverage area of a RAC fail, and all the RAC cells are in abnormal status.

Figure 4-4 shows the process flow for troubleshooting call setup failures when cells
configured in all RAC subracks are abnormal.
Issue 01 (2014-05-31)

40
Figure 4-4 Flowchart for troubleshooting call setup failures when cells configured in all RAC
subracks are abnormal
Start
Is the APUOc
faulty?
Yes

APUOc
No
Collect data before

resetting the RAC
Is the RAC
faulty?
No
Yes
3
Reset the RAC

support
End
1. Switch over or replace the APUOc.
switch over the APUOc. If the service is not restored after the switchover, replace the APUOc.
2. Collect data before resetting the RAC.
Before resetting the RAC, collect and send the necessary data to Huawei for further analysis.
3. Reset the RAC.
Run the RST FRM command to reset the RAC CSPS, and then reset the CMPS. Check
whether the fault is rectified by making a call in the problem area.
---End
Issue 01 (2014-05-31)

41
4.3 Troubleshooting Wide Voice Call Drops

This section describes the causes of wide voice call drops and provides relevant maintenance
procedures.
4.3.1 Introduction to Call Drop Control Mechanism

The call drop control mechanism is applied both to the forward and reverse links of the
CDMA system, and it helps control link release when the quality of radio link is poor. The
forward call drop control mechanism is controlled by MSs and cannot be adjusted in actual
application. The reverse call drop control mechanism is controlled by the RAC and is
generally adjustable. The forward and reverse call drop control mechanisms function together.
The forward call drop control mechanism is described as follows:
The Fade Timer times out. If an MS receives over 12 (N2m) bad frames, the MS disables
its transmitter but continues to receive signals in the reverse link. If the MS receives two
continuous good frames (N3m) in 5 seconds, the MS enables its transmitter again. If the
MS fails to receive two continuous good frames in 5 seconds, the MS is reinitialized.
The maximum number of signaling re-transmissions is achieved. If an MS fails to

receive a response message after N1m times of transmissions, the MS is reinitialized.
The reverse call drop control mechanism may differ when different devices are configured.
The BSS call drop mechanism of the Huawei CDMA2000 1X device is described as follows:
A RAC receives 300 continuous idle frames from the reverse link. During a soft handoff,
because of a long transmission delay between legs, the frames on different legs fail to be
aligned when being combined. In this case, the RAC identifies the frames that fail to be
aligned as idle frames, resulting in call drops.
After legs are combined, there are over 270 Erasure frames, or bad frames, among 300
reverse frames. This results in call drops.
The markov frame error rate (FER) is excessively high. The markov FER refers to the
proportion of bad frames to all frames that a RAC receives. If a received frame is
different from the frame generated in the RAC, the received frame is counted as a bad
frame. Additionally, lost frames are also counted as bad frames. When bad frames make
up 95% per of 500 frames, call drops occur.
In addition to monitoring radio link performance, the RAC also monitors the transmission on
the Abis and A interfaces, and running status of equipment. When a fault is detected, call
drops occur.
Table 4-1 lists the different causes of CS call drops.
Table 4-1 List of difference causes of CS call drops
Measurement
Unit
Type
Definition
Unit
CS Call Drop
Cause Categories
Call drop due to

excessive Erasure
frames.
Number of call drops caused by

excessive Erasure frames
Times
Call drop because the

RAC cannot receive
reverse frames.
Number of call drops caused

when no reverse frames are
received by the RAC.
Times
Issue 01 (2014-05-31)

42
Measurement
Unit
Type
Definition
Unit
Call drop due to faults

on the Abis interfaces.

Abis interface faults including
BTS and SDU resource faults,
and resource faults on other
RAC equipment.
Times
Call drop due to faults

on the A2 interface.

A2 interface faults.
Times
Call drop due to other

reasons.

other reasons
Times
Call drop due to hard

handoff failure in
IS95/IS2000 CS
service.

MS ACK ORD message
timeout in IS95/IS2000 CS
service after the RAC performs
hard handoff
Times
4.3.2 Troubleshooting Call Drops

Symptom
Call drops occur during conversations of a large number of subscribers. That is, the
proportion of abnormal call releases during normal conversation is high, indicating a high call
drop rate.

Figure 4-5 shows the process flow for troubleshooting call drops for a large number of voice
subscribers during conversation.
Issue 01 (2014-05-31)

43
Figure 4-5 Flowchart for troubleshooting call drops for a large number of voice subscribers during
conversation
Start
1
Check the Alarm

Management System
Is the transmission
link alarm or BTS
alarm generated?
Yes
Cause value is
Abis interface
No
3
Handle alarms
Check causes of call

releases
Check BTSs
Other cause
values
10
Are any faults

in the BTS
resource?
Check and handle the

radio coverage quality
problem
Yes
Rectify BTS
resource faults
11
Check and correct the

neighbor cell configuration
No
6
Check the Abis link
Are any faults

on the Abis
link?
No
12
Check and correct the

configuration of search
window
Yes
Rectify Abis link faults

support
End
1. Check the Alarm Management System.
Log in to the Alarm Management System to check alarms.
2. Handle alarms.
If the transmission link alarm exists, see chapter 15 "Troubleshooting Transmission Failures."
Issue 01 (2014-05-31)

44
3. Check causes of call releases.

Review RAC performance counters on the U2000 to identify the causes of call releases.
4. Check BTSs.
Contact BTS engineers to check whether faults occur on the BTS resources.
5. Rectify the BTS resource faults.
Contact BTS engineers to rectify faults.
6. Check the Abis link.
If the Abis interface is configured with E1/T1 links, monitor the E1/T1 link status to
check whether faults occur on the physical link.
Run the LOP E1T1 and STR CBTSLNKDATALP commands to start the E1/T1 link
loopback test to locate the fault.
If the Abis interface is configured with Ethernet links, run the ADD ARPPRT command
to start the ARP check. If alarms are generated on the Alarm Management System, the
communication between the two ends is faulty. If no alarms are generated on the Alarm
Management System and the peer end can respond to the ARP check, communication
between the FG1B/FG2B and the peer end is normal.
7. Rectify Abis link faults.

To troubleshoot cause and resolve the problem, see section 15.2 "Troubleshooting Abis
Interface Link Failures."
8. Check the radio coverage quality and rectify faults.
The radio coverage quality check involves the receive power, transmit power, Ec/Io, and FER
of the pilot. Poor radio coverage results in call drops or call access failures. Radio coverage
quality is subject to forward and reverse link coverage quality and satisfied when the coverage
of forward and reverse links meets the following requirements:
If the receive power is over 94 dBm while the Ec/Io is less than 15 dBm, radio
interference or pilot pollution may exist or the size of the forward search window is set
smaller than the minimum value.
If the receive power is less than 95 dBm, radio coverage quality is poor. The problem
can be resolved by adjusting the downtilt angle or azimuth angle of the antenna, or by
increasing the antenna height or the transmit power. New BTSs are required in scenarios
where the radio coverage is not sufficient.
If the receive power is normal but the transmit power is excessively high during calls, it
may be caused by reverse interference, system overload, or not sufficient reverse
coverage. If the problem is caused by reverse interference, the RSSI and electromagnetic
interference test helps locate the source of the interference. If the problem is caused by
not sufficient reverse coverage, new BTSs are required.
9. Check the neighboring cell configuration and rectify faults.

If an MS uses PN A before call drop and camps on PN B after initialization, the call drop may
be due to missed neighboring cell configuration between PN A and PN B. Alternatively, the
call drop may be caused by slow handoff due to the excessively low priority of the
neighboring cell or excessively high handoff parameters.
10. Check and rectify the configuration of the search window.
Issue 01 (2014-05-31)

45
The default size of the search window can satisfy the seamless coverage networking. The
sizes of forward and reverse search windows need to be enlarged only for the wide coverage
networking, or when repeaters are installed in the network.
----End
4.4 Troubleshooting Poor Voice Quality

This section describes the voice service procedures and encoding\decoding principles, and
provides relevant maintenance procedures.
4.4.1 Voice Service Procedures and Encoding/Decoding Principles

Figure 4-6 shows the CDMA voice service procedure.
Figure 4-6 CDMA voice service procedure
C
O
D
E
C
E
C
E
C
Public network
Original voice
Modulated radio signal
Frame data
PCM data
In the CDMA network, the most basic elements for voice data processing are the
coder/decoder (codec) and the echo canceler (EC). In CDMA voice services, signal flows are
described as follows:
Original voice: Refers to the human voice.
Modulated radio signal: Refers to signals that are processed through channel encoding.
The MS sends signals to the air interface after the original voice and channel are
encoded.
Frame data: Channel decoding, a basic function provided by BTSs, converts original
voice data from PCM data to voice data frames after the original voice data is encoded
by the codec on the MSs.
PCM data: After receiving data frames sent from the BTS, the RAC decodes the data
frames into PCM data by using the codec, and then sends the PCM data to the MSC for
data exchange.
Issue 01 (2014-05-31)

46
The codec functions as a voice data compressor with certain compression loss which
decreases voice quality. The CDMA2000 system supports four encoding/decoding algorithms:
QCELP13K, QCELP8K, EVRC, and EVRC-B.
4.4.2 Troubleshooting Voice Faults

Symptom
The voice quality is poor, and subscribers cannot hear the voice clearly. There is obvious
interference, or strange sounds, during conversations.

Figure 4-7 shows the emergency maintenance process flow for the poor voice quality.
Issue 01 (2014-05-31)

47
Figure 4-7 Flowchart for troubleshooting the poor voice quality

Start
1
Check the MS
Is the quality of the

MS poor?
Yes
Replace the MS
Yes
Check the radio environment
Yes
Is the radio
environment poor?
Optimize the network
No
Check the encoding and
transmission of the voice signal
source
Are there any bit

errors in the BTS
transmission?
Yes
Handle the problem on bit errors
No
7
Check the FER on the Um

interface
Is the
FER on the Um
interface
excessively
high?
9
Yes
Modify the FER
No
Check and handle data switching
or transmission problems in the
core network
10
Check the voice coding and

decoding algorithm
Is the
voice coding and
decoding algorithm set
properly?
11
No
Modify the voice coding and

decoding algorithm
Yes
Contact Huawei technical support
End
Issue 01 (2014-05-31)

48
1. Check the MS.
Use different types of MSs for test.
2. Replace the MS.
Use higher-performance MSs.
3. Check the radio environment.
Contact network optimization personnel to check the radio environment.
4. Optimize the network.
Contact network optimization personnel to optimize the network.
5. Check the encoding and transmission of the voice signal source.
Run the STR CBTSLNKTST command to start a BTS link test on the bit error rate (BER) to
check whether the performance of the physical link transmission is normal.
6. Handle the BER problem.
Contact BTS engineers to handle the BER problem.
7. Check the frame error rate (FER) on the air interface.
On the Service Maintenance System, start the Markov Test Call State Monitoring on a
Markov-enabled MS to check whether the FER on the air interface is high.
8. Modify the FER.
Run the MOD FER command on the Service Maintenance System to decrease the FER on
the air interface.
Adjusting the target FER notably affects the voice quality of the entire network and the
system capacity. Relevant parameters are often set to general values that are widely used
in the telecom industry. Huawei recommends that you retain these values, and change
them only when necessary.
Increasing the target FER deteriorates voice quality or increases the FER in data services,
but expands the system capacity.
Decreasing the target FER increases voice quality and decreases the FER, but reduces
the system capacity.
9. Resolve data switching or transmission problems in the core network.

Contact core network engineers to check whether data switching or link transmission of the
MSC is faulty. If faults exist, ask core network engineers to resolve the faults.
10. Check the voice coding and decoding algorithm.
Check the voice coding and decoding algorithm of an MS. The algorithm is configured
before the MS is delivered. Contact the MS manufacturer.
Check the called-party assignment algorithm by querying soft parameters.
Issue 01 (2014-05-31)

49
The EVRC algorithm provides better voice quality than the Q8K algorithm. Huawei recommends the
EVRC algorithm be set as the called-party assignment algorithm for the RAC and the initial algorithm
for the MS.
11. Modify the voice coding and decoding algorithm.
Check the voice coding and decoding algorithm of an MS. If the Q8K algorithm is used,
change Q8K to EVRC.
Check the called-party assignment algorithm of the RAC. If the Q8K algorithm is used,
change Q8K to EVRC.
---End
4.5 Troubleshooting Unavailable 1X/EV-DO Data Services

When 1X/EV-DO subscribers in the coverage area of a RAC fail to access data services,
perform the following operations:
Check the subscription information for the subscribers in the HLR.
Check the board status.
Trace the subscriber interface messages.
Check the connection between the RAC and the PDSN.
In the CDMA2000 1X network, the data services are unavailable but voice services are
normal.
In the CDMA2000 1X EV-DO network, the data services are unavailable.
Symptom

Figure 4-8 shows the process flow for troubleshooting unavailable data services.
Issue 01 (2014-05-31)

50
Figure 4-8 Flowchart for troubleshooting unavailable data services

Start
No
Do all the MSs fail to

perform data
services?
Is the registration
information
correct?
Yes
Yes
Replace the MS
registration
Modify the
information
Check PCF interface boards
Are all PCF interface

boards faulty?
Check the registration

information of the MS that
cannot perform data services
3
Yes
Replace PCF interface boards
No
4
Start user interface tracing
Is A9-Setup-A8 in the tracing No

messages?
6
APUOc
Yes
7
Is A11-Registration Reply
in the tracing messages?
No
Yes
Is the
communication
proper?
9
10
Is the value of code is

accepted (0)?
Check the communication

between the PCF and the
PDSN
No
Yes
Resolve the PDSN problem
Correct the connection between

the PCF interface board and
the PDSN
11
Configure the parameters
between the PCF and PDSN
Yes
support
End
Issue 01 (2014-05-31)

51
1. Check the subscription information about the Mobile Station (MS) that fails to access the data
services.
Check the subscription information about 1X subscribers on the Authentication,

Authorization and Accounting (AAA) server as follows:
In the HDB database, check whether the subscription information is correct and
whether the subscriber has been assigned the appropriate permissions to access the
data service. If the subscription information is incorrect, or the subscriber lacks the
appropriate permissions, the MSC does not send the assign req message to the RAC
after receiving a CM Service Request message from the RAC.
On the AAA server, check the subscription information about the subscriber. If the
subscription information is correct but the call is immediately released after setup
(that is, the MS fails to pass the AAA authentication), the MS is faulty or the identity
code written for the MS is incorrect. Replace the faulty MS with a new MS of the
same type or re-write the identity codes for the MS.
Check the subscription information about the EV-DO subscribers on the AN-AAA
server. If the subscription information is correct but the call is immediately released after
being set up (that is, the MS fails to pass the AN-AAA authentication), the MS is faulty
and needs to be replaced with a new MS of the same type.
2. Check the status of PCF interface boards.

On the alarm management system, check whether there are alarms indicating faulty PCF
interface boards and faulty A10 link. Then, on the service maintenance system, choose
Maintenance > Control Panel, and view the status of PCF interface boards and check
whether there are faulty boards.
If a board is displayed in red, the board is unavailable.
If a board is displayed in green, the board is available and in active state.
If a board is displayed in blue, the board is available and in standby state.

You can also check board status by running the DSP FRMINFO and the DSP BRDINFO commands on
the Service Maintenance System.
3. Replace the PCF interface board.

4. Start subscriber interface tracing.
On the Service Maintenance System, click the Maintenance tab, expand the Trace node, and
then double-click Subscriber interface Tracing.
5. Check whether the A9-Setup-A8 message exists among the traced messages.
During a data service call, observe whether an A9-Setup-A8 message is displayed in the
output window on the Service Maintenance System.
6. Switch over or replace the APUOc.
switch over the APUOc. If services on the board are not restored after the switchover, replace
the APUOc.
7. Check whether an A11-Registration Reply message exists among the traced messages.
Issue 01 (2014-05-31)

52
During a data service call, check whether an A11-Registration Reply message is displayed in
the output window on the Service Maintenance System.
8. Check the communication between the PCF and the PDSN.
Run the ping command to check whether the communication between the PCF and the PDSN
is normal. For example, run the ping 129.11.17.230 command to check the communication of
the PDSN with the IP address of 129.11.17.230.
If the returned message is "Reply from 129.11.17.230: byte=32 time<10ms TTL=128",

the communication is normal.
If the time in the returned message is excessively long or the Request timed out message
is returned, the communication is abnormal.
9. Check the cable connection between the PCF interface board and the PDSN.
Check whether the Ethernet cables are securely connected to corresponding ports.
10. Check whether the value of code is accepted (0).
In the output window of the Service Maintenance System, check whether the value of code of
the A11-Registration Reply message is accepted (0), which indicates that the PDSN receives
the A11-Registration Request message.
11. Reconfigure the parameters related to the interconnection between the PCF and the PDSN.
Check whether the interconnection parameter settings on the PCF and the PDSN are
consistent. If they are not consistent, contact RAC and PDSN data configuration engineers to
modify the parameter settings.
---End
4.6 Troubleshooting Call Setup Failures in the Coverage

Area of a BTS
This section describes the troubleshooting procedure when all MSs in a BTS coverage area
experience call setup failures.
Symptom
Table 4-2 lists the symptoms of call setup failures in the coverage area of a BTS.
Table 4-2 List of symptoms of call setup failures in the coverage area of a BTS
Item
Symptom
Service
All MSs in the coverage area of a BTS fail to set up calls.
Board status
The RUN/ALM indicator of a board blinks fast or the board is in the

offline state.
On the Service Maintenance System, the OM IP address of the BTS can
be pinged from the RAC but the signaling link between the RAC and the
BTS is not set up.
Issue 01 (2014-05-31)

53
Alarm
The BTS may report the following alarms.
Alarms related to the physical transmission: E1/T1 Loss of Signal;

Receiving Signal of FE Link Lost; E1/T1 Loss of Frame Alignment;
and Transmission of FE Link Incorrect.
Alarms related to the OML: OML Interrupted and OML Between

Board and Main Processing Module Disconnected.
Alarms related to the GPS clock: Insufficient Number of Satellites

Locked by the USCU Satellite Card; Short Circuit in Antenna of the
USCU Satellite Card, and Open Circuit in Antenna of the USCU
Satellite Card.
The alarm related to the configuration file loading is Contents of

Configuration File Incorrect.
Alarms related to the signaling/service links: Number of Activated

Links in Near-End IMA Link Group Insufficient and Abis Signaling
Link Interrupted.
Alarms related to the frequency resources: No Subscriber Access of

Sector-Carrier for a Long Time; and Sector Carrier Channel Number
Incorrect.
Analysis
When calls fail to be set up in the coverage area of a BTS, determine whether the failure
occurs on a single BTS or multiple BTSs controlled by one RAC. If the failure occurs on
multiple BTSs controlled by a RAC, contact the RAC engineers.
Table 4-3 lists the possible causes and cause analysis of call setup failures in the coverage
area of a BTS.
Table 4-3 List of possible causes and cause analysis of call setup failures in the coverage area of a
BTS
Possible Cause
Cause Analysis
Recent maloperations
Maloperations performed during component replacement, configuration data

modification, or Abis transmission link changing.
Faults in the BTS

boards
The CMPT board or the slot of the

CMPT board is damaged.
Alarms related to E1/T1 or FE transmission

are reported.
The connection between the GPS

clock signal cable and the
CMPT/USCU is not secure.
Alarms about out-of-lock satellites, or

open-circuited satellite card are generated, or
the OML faults occur.
HCPM/HECM boards or the slots

of the boards are damaged.
The RF modules are displayed as offline on

the panel of the Service Maintenance System.
If the CSM chip is faulty, the ACT indicator
of the HCPM/HECM blinks at 0.25 Hz, and
the status of the HCPM/HECM displayed on
the panel of the Service Maintenance System
is offline or faulty.
Issue 01 (2014-05-31)

54
Possible Cause
Cause Analysis
Faults in the power

module
The AC/DC power equipment has

no output or the output power is
abnormal.
The switch of the AC/DC power equipment

is turned off.
The AC/DC power equipment has no input or
the input power is abnormal.
The AC/DC power equipment is faulty.
Faults in the
transmission system
Faults in the RRU3606

or the ODU3601CE, or
in the antenna system
The power module of the

BBU3606 is faulty.
If the power module of the BBU3606 is

faulty, the indicator on the UPEU panel is
off. Replace the UPEU.
The cable connection between the

power module and each part is not
secure.
If the output power of the power module is

normal but the indicators on the panel of
parts are off, the cable connection between
the power module and each part is faulty or
the backplane circuits are faulty.
The link layer is faulty.
If alarms are generated only on the link layer,

such as IMA/UNI/FRAC/PPP links, the
physical transmission is unnecessary to be
checked. Troubleshoot the faults by checking
the configurations and rectifying the
incorrect data.
The physical layer is faulty.
If alarms are generated both on physical layer

and link layer, such as E1/T1 links and the
FE link, check the physical layer first.
Troubleshoot faults by performing a
loopback by segments, checking the DIP
settings, and checking the configuration.
The RRU3606/ODU3601CE is
faulty
This fault causes no output power on the

forward link and MSs fail to search for a
network. As a result, calls fail to be set up.
The antenna resistance and the

feeder resistance are mismatched
or there is trace of water leakage
on the connectors.
These faults cause high VSWR, unstable

power output, and reduced coverage. In
severe cases, calls fail to be set up in the
coverage area of the BTS.
The RF antenna parameters are set

incorrectly.
The reverse sensitivity and capacity of a BTS

are reduced. In severe cases, calls fail to be
set up in the coverage area of the BTS.
The OML is faulty.
If the OML fails, a red cross is displayed on the navigation tree on the Service
Maintenance System.
The configuration data

is incorrect.
Incorrect BTS/RAC configuration data is a common cause of call setup failures in

the coverage area of a BTS. If configuration data is modified before the fault
occurrence, try to restore the data before modification.
Faults occur in the

RAC/MSC.
Call setup faults exist in the

coverage area of a single BTS.
Issue 01 (2014-05-31)
Check the data for the interconnection

between the BTS and the RAC or the boards
and ports that connected the BTS to the
RAC.

55
Possible Cause
Cause Analysis
coverage area of all BTSs
controlled by a subrack of a RAC.
Check whether the basic information of the

subrack is modified.

coverage area of all the BTSs
controlled by a RAC.
Check whether the RAC basic information

(such as the PLMN) and the data for the
interconnection between the MSC and RAC
are correct, and check whether the RAC and
the MSC hardware equipment function
properly.

Figure 4-9 shows the process flow for troubleshooting call setup failures in the coverage area
of a BTS.
Issue 01 (2014-05-31)

56
Figure 4-9 Flowchart for troubleshooting call setup failures in the coverage area of a BTS
Issue 01 (2014-05-31)

57
1. Check the power supply system.
Check whether the call setup failures are caused by the power supply system.
If the BTS has proper input power but alarms related to the power module exist on the Alarm
Management System, the power module is faulty. Alarms related to the power module
include:
Power Module Abnormal
Power Module Not in Position
DC Over-Voltage Alarm
DC Under-Voltage Alarm
Fan Blocked Temperature of Power Supply Module Too High
a.
Run the LST ALMFE command to query the current alarms.
b.
According to the alarm information, check the status of corresponding power module.
Issue 01 (2014-05-31)

58
Check whether the output of the external AC/DC power supply equipment is proper.
Check whether the cable connection between the external AC/DC power supply
equipment and the BTS is secure.
Check whether the internal cable connections in the BTS are secure.
If no fault is included in the preceding checking results but alarms related to the power
module still exist in the BTS, the boards or slots of the BTS are faulty.
2. Check the transmission system.
Check whether the fault is caused by the transmission system.
Run the LST ALMFE command to query the current alarms.
If alarm related to the E1/T1 link, FE link, and IMA/UNI/FRAC/PPP link status is generated
on the Alarm Management System, the transmission system is faulty.
According to the alarms, locate and rectify the transmission faults.
For the troubleshooting procedures, see chapter 15 .

3. Check the recent OM operations.
Check whether the fault is caused by recent maloperations.
OM operations include the hardware maintenance and the modification of the configuration
data. If a fault occurs during recent hardware maintenance or configuration data modification,
restore the hardware or configuration data to the state before the OM operation.
During the configuration data modification, the following maloperations easily occur:
The BTSID and BTSTP of the BTS which are set by running the SET CBTSINFO
command are not consistent with those set on the RAC. In that case, the RAC fails to
identify the BTS and therefore calls fail to be set up in the coverage area of the BTS.
The modified transmission link data of the BTS, such as IP address, is not consistent
with that in the RAC. The inconsistency results in the connection failure of transmission
link.
Changed thresholds and the bandwidth settings are not proper.
Changed RF parameters are not proper.
Run the LST LOG command to query the commands sent recently to the BTS. For example,
if a fault occurs on March 1, 2007, run the following command to query all the commands
sent from the client before that day. (By default, a maximum of 1000 commands can be
returned.)
LST LOG: ETIME=2007&03&01;
4. Check the boards of the BTS.

Check whether the fault is caused by the boards of the BTS.
a.
b.
Issue 01 (2014-05-31)
Check whether the boards are faulty at the remote end or the local end.
At the local end, observe the indicators on the panel. The ALM indicator is on or
blinks if a board is faulty.
At the remote end, observe the status of each board on the Service Maintenance
System. A faulty board is displayed in red on the panel of the Service Maintenance
System.
If a board is faulty, replace it.

59
If calls fail to be set up in the coverage area of a BTS, restore the services first, and then troubleshoot.
If a board is faulty, replace the board in an attempt to restore the services first. Then, locate the fault.
Use the alarms displayed on the Alarm Management System to locate the faulty board.
If a transmission alarm is generated, replace the CMPT/UTRP.
If an RF alarm is generated, replace the

STDM/SPAM/CRFU/RRU3606/MDFU/OMTR/OMPA before replacing the
HCPM/HECM.
If a power supply alarm is generated, replace the power module.
After replacing the boards, if the fault persists, replace the slot. If the services are not restored
after the board and the slot are replaced, the fault is not on the board or in the slot.
To replace the parts of BBU3900, see the Airbridge BBU3900 User Guide.
To replace an RRU3606, see the Airbridge RRU3606 User Guide.
To replace the parts of an ODU3601CE, see the Airbridge ODU3601CE User Guide.
To replace the parts of a BTS3900, see the BTS3900 Site Maintenance Guide.
To replace the parts of a BTS3900A, see the BTS3900A Site Maintenance Guide.
To replace the parts of a BTS3900C, see the BTS3900C Site Maintenance Guide.
To replace the parts of a BTS3600AC, see the BTS3600AC Site Maintenance Guide.
To replace the parts of a BTS3600CE, see the BTS3600CE Site Maintenance Guide.
5. Check RF antenna system.

Check whether the fault is caused by the RF antenna system.
Run the LST ALMFE command to query the current alarms. If a critical alarm related to the
RF module or the antenna standing wave is generated in the Alarm Management System, the
RF antenna system is faulty.
Locate and rectify the faults in the RF antenna system, see chapter 20 "Troubleshooting BTS
RF Failures."
6. Check the configuration data of the BTS and the RAC.
When calls fail to be set up in the coverage area of a BTS, check the configuration of the
signaling link and the service link first. For details on the specific MML commands related to
configuration items, see the DBS3900 Initial Configuration Guide and the BTS Initial
Configuration Guide. For information related to MML commands, see the MML Online Help.
On the Service Maintenance System, run the LST RACBTSINF and LST
BTSBTPINFO commands to query the BTS basic information and BOOTP information
configured in the RAC. Run the LST BTS and LST BTSBTPINFO commands to query
the BTS basic information and BOOTP information configured in the BTS.
If the BTS basic information configured in the RAC is not consistent with the
information configured in the BTS, run the MOD BTS command to modify the BTS
basic information.
If the BOOTP information configured in the RAC is not consistent with the information
configured in the BTS, run relevant MML commands to modify the BTS basic
information.
Issue 01 (2014-05-31)
For ATM over E1/T1 or IP over E1/T1 transmission, run the MOD BTSBTPINFO
command to modify the BOOTP information.

60
For IP over FE transmission, run the SET CBTSOAMIP command to set the OM IP
address of the BTS.
---End

Area of an ODU
This section describes troubleshooting procedures for call setup failures in the coverage area
of an ODU3601CE connected to a BTS.
Symptom
Calls can be set up in the coverage area of the BTS when connected to the ODU3601CE.
However, calls fail to be set up in the coverage area of the ODU3601CE
Analysis
Before handling call setup failures in the coverage area of an ODU3601CE, check whether
the BTS is faulty. If an alarm is generated on the upper-level BTS, rectify the fault first.
Table 4-4 describes of the possible causes and further analysis of call setup failures in the
coverage area of an ODU3601CE
Table 4-4 Possible causes and further analysis of call setup failures in the coverage area of an
ODU3601CE
Possible Cause
Cause Analysis
Faults in the
upper-level BTS
If an alarm is generated on the upper-level BTS, rectify the fault

first. For details regarding troubleshooting faults in the upper-level
BTS, see section 4.6 "Troubleshooting Call Setup Failures in the
Coverage Area of a BTS."
Recent
maloperations
Maloperations performed during the replacement of components,

and incorrect modification of configuration data or Abis
transmission links, may lead to call setup failures.
Hardware faults in
ODU3601CE
Hardware devices of an ODU3601CE include a cabinet, OMTR,

MDFU, OMPA, MAPM/MDPM boards, and FAN module.
Faults in the OMTR, MDFU, or OMPA may result in call setup
failures. If a board does not function properly, replace it with a
new one.
If other components are faulty, they will not cause call setup
failures in the coverage area of the ODU3601CEAlarms are
generated.
Issue 01 (2014-05-31)

61
Possible Cause
Cause Analysis
Cable connection
faults
ODU3601CE is connected to the upper-level BTS through the SFP

port on the OMTR board. Ensure the optical fiber port is free from
dust, and the cable is securely connected to the port.
The SFP cable is generally short. Therefore, when multiple
ODU3601CEs are connected to a BTS, the ODU3601CEs are
connected to the pluggable optical modules on the BTS through
optical fiber. The upper-level ODU3601CE can be connected to
the lower-level ODU3601CE through an SPF cable, or by optical
fiber.
When an SPF cable is used, the pluggable optical module cannot
be used. When optical fiber is used, the pluggable optical module
must be used.
Incorrect
configuration data
In the BTS configuration script, errors in the following

configuration items may result in call setup failures in the coverage
area of an ODU3601CE:
Cells or sectors added by running the ADD CBTSCELL

command
Resource pool added by running the ADD CBTSCPL command
HCPM boards added by running the ADD CBTSCPM

command
HECM boards added by running the ADD CBTSECM

command
Terrestrial service links added by running the ADD

CBTSTERTRFLNK or ADD CBTSIPTERTRFLNK
commands.
ODU3601CEs added by running the ADD CBTSTRM

command
Carriers added by running the ADD CBTSSECTORCARRIER

command
BTS sector parameters set by running the SET

CBTSCDMA1XSECTORPARA or SET
CBTSCDMADOSECTORPARA command, based on the
network planning requirements.
The RF parameters set by running the SET CBTSRFPARA

command, based on the network planning requirements.

Figure 4-10 shows the process flow for handling call setup failures in the coverage area of an
ODU3601CE.
Issue 01 (2014-05-31)

62
Figure 4-10 Flowchart for troubleshooting call setup failures in the coverage area of an
ODU3601CE
Issue 01 (2014-05-31)

63
1. Clear faults in the upper-level BTS.
Check whether call setup failures are caused by faults in the upper-level BTS.
If a faulty ODU3601CE is directly connected to the BTS, query the alarms generated on
the BTS. Identify alarms related to the ODU3601CE, and rectify faults according to the
alarm handling suggestions. For details regarding troubleshooting of a fault in the
upper-level BTS, see section 4.6 "Troubleshooting Call Setup Failures in the Coverage
Area of a BTS."
If a faulty ODU3601CE is connected to the BTS through another ODU3601CE, rectify

faults in both the BTS and the upper-level ODU3601CE.
2. Check recent OM operations.

Check whether call setup failures are caused by recent maloperations.
OM operations include hardware maintenance, and modification of configuration data. If a
fault occurred during recent operations, restore hardware or configuration data to its state
before the operation.
Run the LST LOG command to query commands recently sent to the BTS. For example, if a
fault occurred on March 1, 2010, run the following command to query commands sent from
the client before that day.
3. Check the optical fiber transmission.
Check whether call setup failures are caused by faulty fiber connection.
Issue 01 (2014-05-31)

64
Check whether the optical fiber connection between the upper-level BTS and
ODU3601CE is working properly.
Check whether the optical fiber between the HCPM/HECM and OMTR is damaged.
Check whether the optical ports on the HCPM/HECM and OMTR are damaged.
Check the power supply of the ODU3601CE.
4. Check the RF parameters.

Trace the transmit power of the ODU3601CE.
If the output power of the OMTR is abnormal, replace the OMTR.
If the output power of the OMTR is normal, but the output power of the OMPA is
abnormal, check the cable connection between the OMTR and OMPA. If the cable
connection is secure, the OMPA is faulty. Replace the OMPA.
Check whether an antenna VSWR alarm is generated. If an alarm exists, check the
antenna system. If there is no alarm, go to 5.
5. Check the ODU3601CE hardware.

Check whether call setup failures are caused by hardware faults in the ODU3601CE that is
connected to a BTS.
Log in to the Service Maintenance System, and click the Maintenance tab.
Locate the faulty ODU3601CE on the navigation tree, and click Device Panel under the
ODU3601CE.
Select the ODU3601CE, and observe the ODU3601CE devices displayed on the right
panel.
If ODU3601CE modules are displayed in green, the modules are functioning

properly.
If some ODU3601CE modules are displayed in red, the modules are functioning
improperly.
If all the modules of the ODU3601CE are displayed in gray, the modules are offline
because of faulty optical fiber transmission.
If some ODU3601CE modules are displayed in gray, the modules are not properly
installed.
Check whether a major alarm related to the RF module, power amplifier module, or
power modules is generated. If such an alarm is generated, handle the alarm as
suggested.
For information regarding the replacement of the ODU3601CE RF module, see the
Airbridge ODU3601CE User Guide.
Check the connections of feeders.

When installing the antenna system, ensure feeders are connected to the correct RF
output port and that they are properly connected. Feeder connection faults are often
found in BTSs that serve multiple sectors.
Check the installation of feeders and jumpers.

Pay attention to the quality and waterproof treatment of feeder connectors. Check
whether connectors or cables are damaged due to a water leakage.
Feeder connectors must be in good condition and properly waterproofed. There must be
no water leakage on connectors, and cables must be intact.
If a feeder or jumper is defective, replace it with a feeder or jumper of the same type.
Issue 01 (2014-05-31)
Check the antenna quality.

65
Check whether the antenna is damaged, and whether the connectors of the feeders and
antenna are damaged due to a water leakage. The antenna must be intact, and there must
be no water leaks on the connectors or jumpers.
If the antenna is defective, contact Huawei technical support.
If call setup failures persist after the preceding operations are performed, replace the MDFU.
----End

Area of an RRU
This section describes the troubleshooting procedures for the call setup failures in the
coverage area of an RRU, which creates a soft base station in the area.
Symptom
Calls can be set up in the coverage areas of the BTS when connected to the RRU. However,
calls fail to be set up in the coverage area of the RRU
Analysis
Before handling call setup failures in the coverage area of an RRU, check whether the BTS is
faulty. If an alarm is generated on the BTS, rectify the fault first.
Figure 4-5 describes the possible causes and further analysis of call setup failures in the
coverage area of an RRU
Table 4-5 Possible causes and further analysis of call setup failures in the coverage area of an
RRU
Possible Cause
Cause Analysis
Faults in the
upper-level BTS
If an alarm is generated on the upper-level BTS, rectify the fault

first. For details regarding the troubleshooting of faults in the
upper-level BTS, see section 4.6 "Troubleshooting Call Setup
Failures in the Coverage Area of a BTS."
Recent
maloperations
Maloperations performed during the replacement of components,

and the modification on configuration data or Abis transmission
links, may lead to call setup failures.
Hardware faults
in RRU3606
Replace the RRU3606 to check whether the problem is caused by

the hardware faults.
Cable connection
faults
The RRU3606 is connected to the upper-level BTS through the SFP

port. Ensure the optical fiber port is free from dust, and the optical
fiber is securely connected.
Incorrect
configuration data
In the BTS configuration script, errors in the following

configuration items may result in a call setup failure in the coverage
area of an RRU3606:
Issue 01 (2014-05-31)
Cells or sector added by running the ADD CBTSCELL

66
Possible Cause
Cause Analysis
command
Resource pool added by running the ADD CBTSCPL command
HCPM added by running the ADD CBTSCPM command
HECM added by running the ADD CBTSECM command.
Terrestrial service links added by running the ADD

CBTSTERTRFLNK or ADD CBTSIPTERTRFLNK
commands
ODU3601CEs added by running the ADD CBTSTRM command.
Carriers added by running the ADD CBTSSECTORCARRIER

command
BTS sector parameters set by running the SET

CBTSCDMA1XSECTORPARA or SET
CBTSCDMADOSECTORPARA command, based on the
network planning requirements
The RF parameters set by running the SET CBTSRFPARA

command, based on the network planning requirements

Figure 4-11 shows the troubleshooting process flow for handling call setup failures in the
coverage area of an RRU.
Issue 01 (2014-05-31)

67
Figure 4-11 Flowchart for troubleshooting call setup failures in the coverage area of an RRU
Issue 01 (2014-05-31)

68
1. Rectify faults in the upper-level BTS.
Check whether call setup failures are caused by faults in the upper-level BTS.
If a faulty RRU is directly connected to the BTS, query the alarms generated in the BTS.
Identify alarms related to the RRU, and rectify the faults according to the alarm handling
suggestions. For details about the troubleshooting of faults in the upper-level BTS, see
section 4.6 "Troubleshooting Call Setup Failures in the Coverage Area of a BTS."
If a faulty RRU is connected to the BTS through another RRU, rectify the faults in both
the BTS and the upper-level RRU.
2. Check recent OM operations.

Check whether call setup failures are caused by recent maloperations.
OM operations include hardware maintenance, and modification of configuration data. If a
fault occurred during recent operations, restore the hardware or configuration data to its state
before the OM operation.
Run the LST LOG command to query the commands recently sent to the BTS. For example,
if a fault occurs on March 1, 2010, run the following command to query commands sent from
the client before that day.
3. Check optical fiber transmission.
Check whether call setup failures are caused by faulty fiber connection.
Issue 01 (2014-05-31)

69
Check whether the optical fiber connection between the upper-level BTS and RRU is
working properly.
Check whether the fiber between the HCPM/HECM and RRU is damaged.
Check whether the optical ports of HCPM/HECM and the RRU are damaged.
Check the power supply of the RRU.
4. Check the RF parameters.
Trace the transmit power of the RRU3606.
If the output power of the RRU3606 is abnormal, replace the RRU3606.
Check whether an antenna VSWR alarm is generated. If an alarm exists, check the
antenna system. If no alarm exists, go to 5.
5. Check the RRU hardware.

Check whether call setup failures are caused by hardware faults in the RRU that is connected
to the BTS.
Log in to the Service Maintenance System, and click the Maintenance tab.
Locate the faulty RRU on the navigation tree, and click Device Panel under the RRU.
Select the RRU, and observe RRU devices displayed in the right panel.
If the RRU modules are displayed in green, the modules are functioning properly.
If all the modules of the RRU are displayed in gray, the existing optical fiber
connection is faulty and the modules of the RRU are offline.
Check whether a major alarm related to the RF module, power amplifier module, or
power modules is generated. If such an alarm is generated, handle the alarm as
suggested.
For the more information regarding the replacement of the RRU3606, see the Airbridge
RRU3606 User Guide.

When installing the antenna system, ensure the feeders are properly correctly connected
to the RF output. Feeder connection faults are often found in BTSs that serve multiple
sectors.

Pay attention to the quality and waterproof treatment of feeder connectors. Check
whether connectors or cables are damaged due to a water leakage.
Feeder connectors must be in good condition and properly waterproofed. There must be
no water leakage on the connectors, and cables must be intact.
If a feeder or jumper is defective, replace it with a feeder or jumper of the same type.
Check the antenna quality.

Check whether the antenna is damaged, and whether the connectors of feeders and
antenna are damaged due to a water leakage. The antenna must be intact, and there must
be no water leakage on the connectors or jumpers.
If the antenna is defective, contact Huawei technical support.

----End
Issue 01 (2014-05-31)

70
5 Troubleshooting MS Access Failures
Troubleshooting MS Access Failures
5.1 Introduction to MS Access Process

The MS contacts the access channel using a random access procedure. The access attempt is a
process by which the MS sends a message and receives a response from the BTS. The MS
attempts to access the network by sending access probes. Several access probes compose an
access probe sequence, and many access probe sequences compose an access attempt.
Figure 5-1 shows the signaling flow of air interface access of a calling MS.
Figure 5-1 Signaling flow of air interface access of a calling MS
Issue 01 (2014-05-31)

71
The signaling flow is described as follows:

a.
The MS sends an Origination Meg with the Layer 2 Ack Request on the RACH to
request services.
b.
Upon receiving the Origination Meg, the BS sends a Base Ack Order to the MS.
c.
If a traffic channel is required for the call, the BS sends a Channel Assignment Message
on the paging channel of the air interface to initiate the setup of the radio traffic channel
and sends Null Traffic Data on the traffic channel to the MS to enable the MS to access
the forward channel.
d.
The BS sends an ECAM message to the MS.
e.
The MS sends the Traffic Channel Preamble on the reverse traffic channel to enable the
BS to access the reverse traffic channel.
f.
After accessing the reverse traffic channel, the BS sends the Base Ack Order with the
Layer 2 Ack Request on the forward traffic channel to the MS.
g.
Upon receiving the Base Ack Order, the MS sends the MS Ack Order and Null Traffic
Data on the reverse traffic channel.
h.
The BS sends the Service Connect Meg to the MS to specify the service configuration
for the call. The MS begins processing services according to the specified service
configuration.
i.
Upon receiving the Service Connect Meg, the MS sends a Service Connect Complete
message to the BS. After the radio traffic channel and terrestrial circuits are established,
the BS sends an Assignment Complete message to the MSC and determines the MS is in
the conversation state.
5.2 Troubleshooting the Network Access Failure Upon

Power Up of MSs
Symptom
The MS cannot detect the network.
Cause
Common causes of the fault are as follows:
The carrier is unavailable.
The signaling coverage is problematic.
Analysis
To locate the fault, perform the following operations:
Check the carrier status.
Check the signaling coverage.
Issue 01 (2014-05-31)

72
1. Log in to the Alarm Management System and check whether a BTS Standing Wave Alarm
(ID: 18400) is generated.
If the BTS Standing Wave Alarm is generated, resolve the standing wave problem. Then,
go to 5.
If the BTS Standing Wave Alarm is not generated, go to 2.
2. Run the DSP RES command to query the status of the current carrier.
If the queried Administrative Status of the carrier is Locked, run the UBL RES
command to unblock the carrier. Then, go to 3.
If the queried Operational Status of the carrier is Disabled, resolve the problem by
enabling the carrier. For more information, see section 16.2 "Troubleshooting the
Unavailability of BTS Carriers."
3. Perform drive tests and determine whether there are areas that signals cannot reach.
If there are areas that signals cannot reach, contact network planning engineers to
optimize the network and improve coverage. Then, go to 5.
If there are not areas that signals cannot reach, go to 4.
4. Check whether the output power of the BTS is normal by referring to related BTS manuals.
If the output power of the BTS is normal, go to 5.
If the output power of the BTS is abnormal, restore the output power of the BTS. For
details about how to identify and troubleshoot BTS power failures, see related BTS
manuals.
5. Perform the dialing test on an idle MS, and check whether the signal receive performance of
the MS is normal.
If the signal receive performance of the MS is normal, no further action is required.
If the signal receive performance of the MS is abnormal, contact Huawei technical

support.
----End
5.3 Troubleshooting the Network Access Failure of Some

MSs
Symptom
Some MSs can detect the network, but they cannot access it.
Cause
The protocol version of the RAC is higher than the protocol versions of the MSs.
Analysis
Check the protocol version of the RAC, and protocol versions of the MSs.
Issue 01 (2014-05-31)

73
1. Run the LST PREV command to query the minimum protocol version of the RAC, and the
protocol versions and models of the affected MS. Check whether the protocol versions of the
MSs are higher than the minimum protocol version of the RAC.
If the protocol versions of the MSs are higher than the minimum protocol version of the
RAC:
MSs of a high protocol version only support system messages of a high protocol version.
If the RAC has a low protocol version, MSs of a high protocol version may fail to access
the network because structures of RAC messages may vary with different protocol
versions. For example:
If BandClass is 0: The RAC is at band 800 MHz. The minimum protocol version of
the RAC is 2.
the RAC is 1.
the RAC is 5.
Go to 2.
If the protocol versions of the MSs are lower than the minimum protocol version of the
RAC:
MSs of a low protocol version only support system messages of a low version. If the RAC has
a high protocol version, MSs of a low protocol version may fail to access the network because
structures of RAC messages may vary with different protocol versions.
Go to 2.
2. Run the MOD PREV command to change the minimum protocol versions supported by the
RAC. Perform dialing tests between the affected MS and MSs of various protocol versions
such as versions 1, 4, and 6. Check whether the dialing tests are normal.
If dialing tests are normal, MSs of various protocol versions can access the network. In
this case, you can determine that the setting of the protocol version is corrected and the
fault has been rectified. No further action is required.
If dialing tests are abnormal, contact Huawei technical support.
----End
Issue 01 (2014-05-31)

74
6 Troubleshooting 1X MOC Failures
Troubleshooting 1X MOC Failures
6.1 Introduction to the MOC Process

MS-originated call (MOC) is a process in which the MS functions as the calling party.
Figure 6-1 shows the CDMA2000 1X MOC process.
Figure 6-1 CDMA2000 1X MOC process
The MOC process is described as follows:

a.
The MS sends an Origination Message to the BSS on the access channel over the air
interface, and requires a response from the BSS.
b.
After receiving the Origination Message, the BSS sends a BS Ack Order to the MS.
Issue 01 (2014-05-31)

75
c.
The BSS constructs a CM Service Request message, encapsulates it, and then sends it to
the MSC over the A interface. For CS calls, the BSS can recommend the required
terrestrial link and request the MSC to assign the circuit through this message.
d.
The MSC sends an Assignment Request message to the BSS to request radio resources.
If the MSC can assign the terrestrial link recommended by the BSS in the CM
Service Request message, the MSC assigns the terrestrial link in the Assignment
Request message.
Otherwise, the MSC assigns another terrestrial link.
The BSS then uses the terrestrial link assigned by the MSC.
a.
After assigning TCHs for the MS, the BSS sends a Channel Assignment Message or
Extended Channel Assignment Message on the paging channel to instruct the MS to set
up radio TCHs.
b.
The MS sends a TCH Preamble on the reverse TCH specified by the BSS.
c.
After acquiring the reverse TCH, the BSS sends a BS Ack Order on the forward TCH
and requires a response from the MS.
d.
The MS responds with an MS Ack Order on the reverse TCH.
e.
The BSS sends a Service Connect Message or Service Option Response Order to the MS
to specify the service configuration for the call.
f.
After receiving either the Service Connect Message or the Service Option Response
Order, the MS starts to process services according to the specified service configuration
and responds with a Service Connect Completion Message.
g.
After both the TCH and the terrestrial link are successfully established, the BSS sends an
Assignment Complete Message to the MSC, indicating that the two parties can start
conversation.
h.
If the calling process tone is provided within the TCH frame, the MSC sends the
ringback tone to the MS through the TCH.
6.2 Troubleshooting MOC Failure Due to Unavailable

Radio Resource on the Interface
Symptom
The MS fails to originate a call. The signaling tracing on the A1 interface shows that the cause
value of the Assignment Failure message is "no radio resource available, 0x21."
Cause
CEs are not sufficient.
The Abis interface link is faulty.
Analysis
Issue 01 (2014-05-31)
Check the configuration and usage of CEs of the access BTS or subsystem.

76
Check the Abis interface link.
Check the configuration and usage of CEs.
1. If the system uses a BTS-level license, run the DSP CBTSLICENSE command to query the
number of CEs configured for the access BTS and the number of CEs already in use. In
addition, check whether the number of CEs is sufficient.
If the number of CEs is sufficient, go to 2.
If the number of CEs is not sufficient, add CEs to the BTS.
2. If the system uses a RAC-level license, run the DSP RACLICENSECFG command to query
the number of CEs configured on the RAC and CEs already in use. Then, check whether the
number of CEs is sufficient.
If the number of CEs is sufficient, go to 3.
If the number of CEs is insufficient, apply for a new license that authorizes more CEs.
No further action is required.
3. Check whether an alarm related to the CCPM/HCPM board is generated on the Alarm
Management System.
If such an alarm is generated, rectify the CCPM/HCPM board fault according to the
alarm reference.
If such an alarm is not generated, go to 6.2 4.
Check the Abis interface link.

4. Check whether the RAC and BTS configurations are consistent by running the CHK
CBTSIFCFG command:
If configuration is consistent, go to 5.
If configuration is not consistent, modify the items as indicated by the system.
5. Check whether an alarm related to the Abis interface link of the access BTS is generated on
the Alarm Management System.
If such an alarm is generated, clear the alarm according to the alarm reference.
If such an alarm is not generated, contact Huawei technical support.
----End
Information Collection
If it is necessary to contact Huawei technical support, maintenance engineers should collect
the following information related to the fault:
Records of key events and operations during troubleshooting
Causes of detected faults and troubleshooting methods
Information about current alarms
Information about historical alarms
Operation logs of the RAC
Configuration script of the RAC
Issue 01 (2014-05-31)

77
Configuration script of the access BTS
Running logs of the access SPUO subsystem
Running logs of the access BTS
Subscriber interface tracing (A1, Abis, Um, A9, A11, A3, and A7 interfaces)
For details about how to collect information, see section 2.4 "Collecting the Fault
Localization Information."
6.3 Troubleshooting MOC Failure on A Interface

Symptom
The MS fails to originate a call. The signaling tracing on the A1 interface shows that, after the
RAC sends a CM Service Request to the MSC, the MSC sends a Clear Command or a
N_DISCONNECT_IND message, or does not respond at all, indicating that the call fails to be
set up.
Cause
Configurations of the RAC and MSC are not consistent on the A interface.
The A interface link is faulty.
The MS authentication fails.
Analysis
Check the A interface link.
Check configuration of the A interface.
Check MS authentication.
Check the A interface link.
1. Perform signaling tracing on subscriber interfaces, and check whether the MSC responds with
a message after the RAC sends the CM Service Request to the MSC.
If the MSC responds, go to 2.
If the MSC does not respond, go to 3.
2. Check the message sent by the MSC.
If the message is a N_DISCONNECT_IND message, go to 3.
If the message is a Clear Command, go to 6.
3. Check whether an alarm related to the A interface link is generated on the Alarm
Management System.
Issue 01 (2014-05-31)

78
If such an alarm is not generated, go to 4.
Check configuration of the A interface.

4. Check whether the BSSAP of the RAC and that of the MSC are consistent on the A interface
by running the LST SCCPSSN command on the Service Maintenance System.
If the configuration is consistent, go to 5.
If the configuration is not consistent, modify the configuration of the RAC.
5. Check whether the SCCP subsystem number on the RAC and that on the MSC are consistent
by running the LST SCCPSSN command on the Service Maintenance System.
6. Check whether the A interface version of the RAC and that of the MSC are consistent by
running the LST RACINF command on the Service Maintenance System.
Check MS authentication.
7. Check whether the cause value carried in the Clear Command message is "Authentication
Failure, 0x1A":
If yes, go to 8.
If no, contact Huawei technical support.
8. Check whether broadcast authentication is enabled for the RAC by running the LST
SYSMSGPARA: CCMINF=AUTH command on the Service Maintenance System.
If broadcast authentication is enabled, go to 9.
If broadcast authentication is disabled, run the MOD AUTH command to enable it.
9. Request the maintenance engineers of the MS, R_UIM card, and HLR/AC to check whether
the authentication parameters are consistent. Check the parameters IMSI, ESN, MEID, and
A_Key.
If parameters are consistent, go to 10.
If parameters are not consistent, request the maintenance engineers to modify parameter
settings.
10. Update the MS SSD.

If the MS SSD is not consistent with the HLR/AC SSD, the MS cannot pass the
authentication. To ensure the consistency, manually initiate an SSD update by using one of the
following methods:
Initiate an SSD update on the HLR/AC by using a command.
Initiate an SSD update by canceling the account. Then, open an account on the HLR.
For detailed operations, contact the HLR/AC maintenance engineers.

11. Perform an authentication test on the MS.
Issue 01 (2014-05-31)

79
If an MS with the R_UIM card always fails to pass authentication, interchange the R_UIM
cards of this MS with an MS that has passed the authentication. Determine whether the
problem is caused by the R_UIM cards or the MS.
12. If the fault persists after completing the preceding steps, contact Huawei technical support.
----End
6.4 Troubleshooting MOC Failure Due to Unavailable

Terrestrial Links
Symptom
The MS fails to originate a call. The signaling tracing on the A1 interface shows that the cause
value of the Assignment Failure message is "requested terrestrial resource unavailable, 0x22."
Cause
The A interface link is faulty.
TCs/ECs are unavailable.
SDUs are unavailable.
Analysis
Check the status, type, and configuration of the A interface link.
Check the status of TCs/ECs.
Check the status of SDUs.
Issue 01 (2014-05-31)

80
Check the status, type, and configuration of the A interface link.
1. Check whether an alarm related to the A interface link is generated.
2. Query the A interface type by running the LST RACINF command.
If the type is TDM, go to 4.
If the type is M3UA or SUA, go to 3.
3. Query the destination IP address, port IP address, and gateway IP address of the A interface
board by running the LST ETHLNK and LST IPBRDROUTE commands. Check whether
the IP addresses are consistent with the planning.
If the IP addresses are consistent with the planning, go to 4.
If the IP addresses are not consistent with the planning, run the RMV ETHLNK, ADD
ETHLNK, and MOD IPBRDROUTE commands to change the IP addresses.
4. Query the configuration data of the A2 interface link on the RAC by running the LST TKC
command. Contact the CN engineers to check whether the configuration data on the CN side
is consistent with that on the RAC.
If the configuration is not consistent, run the MOD TKC command to modify the RAC
configuration.
In E1 working mode, the initial CIC number of the RAC must be consistent with that of the
MSC. In T1 working mode, the MSC initial CIC number is equal to the RAC initial number
plus 1. This is because the RAC initial CIC number is configured as not installed by default,
and the MSC initial CIC number is configured as available by default.
Check the status of TCs/ECs.
5. Check the number of TCs on voice service processing boards
(DPUTb/ECUOa/TCUOc/ECUOc) and check whether the number of TCs is greater than 0.
If the number is greater than 0, go to 6.
If the number is less than 0, expand capacity of the voice service processing boards
(DPUTb/ECUOa/TCUOc/ECUOc).
Check the status of SDUs.

6. Check whether the status of the DSP on each APUSc or DPUSb board is normal by running
the DSP DSPSTAT command.
If the status is abnormal, load the DSP again to restore the DSP.
If the status is normal, contact Huawei technical support.
----End
Issue 01 (2014-05-31)

81
Running log of the boards in the access subrack
Issue 01 (2014-05-31)

82
7 Troubleshooting MTC Failures
Troubleshooting MTC Failures
7.1 Introduction to the MTC Process

In the CDMA2000 1X MS-terminated call (MTC) process, the MS functions as the called
party during a call.
Figure 7-1 shows the CDMA2000 1X MTC process.
Figure 7-1 CDMA2000 1X MTC process
Issue 01 (2014-05-31)

83
The MTC process is described as follows:

a.
When a paged MS is within the servicing area of the MSC, the MSC sends a Paging
Request message to the BSS to start the call setup of the paged MS.
b.
The BSS sends a General Page Message that carries the identity code of the MS on the
paging channel.
c.
Upon receiving the General Page Message, the MS sends a Page Response Message to
the BSS on the access channel.
d.
The BSS uses the information to form a Paging Response Message. After encapsulating
this message, the BSS sends it to the MSC. In the message, the BSS can recommend a
terrestrial circuit and request the MSC to assign the circuit.
e.
After receiving the Page Response Message, the BSS sends a BS Ack Order message to
the MS.
f.
The MSC sends an Assignment Request message to the BSS to request radio resources.
If the MSC can assign the terrestrial link recommended by the BSS in the CM
Service Request message, the MSC assigns the terrestrial link in the Assignment
Request message.
Otherwise, the MSC assigns another terrestrial link.
The BSS then uses the terrestrial link assigned by the MSC.
a.
After assigning TCHs for the MS, the BSS sends a Channel Assignment Message or
Extended Channel Assignment Message over the paging channel to start setting up radio
TCHs.
b.
The MS sends a Traffic Channel Preamble on the specified reverse TCH.
c.
After acquiring the reverse TCH, the BSS sends a BS Ack Order on the forward TCH
and requires an ACK from the MS.
d.
In response, the MS sends an MS Ack Order on the reverse TCH to the BSS.
e.
The BSS sends a Service Connect Message or Service Option Response Order to the MS
to specify the service configurations to be used for the call.
f.
Upon receiving the message, the MS starts processing services according to the specified
configurations and responds with the Service Connect Completion Message.
g.
After the radio TCH and the terrestrial circuit are both successfully connected, the BSS
sends an Assignment Complete Message to the MSC, regarding that the MS is handling
the call.
h.
The BSS sends an Alert with Info message to the MS to instruct the MS to ring.
i.
After receiving the message, the MS sends an MS Ack Order to the BSS and begins
ringing.
j.
When the call is answered, the MS sends a Connect Order message to the BSS, which
carries the Layer 2 verification request.
k.
After receiving the message, the BSS sends a BS Ack Order to the MS on the forward
TCH.
l.
The BSS sends a Connect message to inform the MSC that the MS has answered the call.
At this point, it is determined the MS is handling a call.
Issue 01 (2014-05-31)

84
7.2 Troubleshooting the Failure to Receive the Paging

Request
Symptom
When the MTC fails, theV5 interface signal tracing of the called MS indicates the Paging
Request message sent from the MSC is not found.
Cause
Configurations of the signaling points, cells, or LACs on the RAC and core network are not
consistent.
Analysis
Check whether the configurations of the signaling points, cells, or LACs on the RAC and
core network are consistent.
Check the configurations of the V5 interface.
Check the status of V5 interface link.
1. Run DSP SUBCSR command to query the data of a specified subscriber.
2. Run LST V5BAPORT command to list the information of V5 basic velocity ports.
3. Run DSP VDBUSER command is used to display the data of a specified subscriber recorded
in the VDB.
4. Check V5 interface.
----End
Information Collection.
Records of key events and operations during fault troubleshooting
Causes of faults already discovered and troubleshooting methods
Information about active alarms
RAC operation logs
ESN and IMSI of the called MS
All running logs of the SPUO subsystem
Issue 01 (2014-05-31)

85
7.3 Troubleshooting MTC Failures Due to Other Causes

In an MS-terminated call (MTC) process, only the paging process is different from the MOC
process. Therefore, troubleshoot faults in the MTC process by referring to section 6
Troubleshooting 1X MOC Failures.
Issue 01 (2014-05-31)

86
8 Troubleshooting Handoff Failures
Troubleshooting Handoff Failures
8.1 Introduction to Handoffs

Handoff refers to a process during which the link between an MS and the source BTS is
replaced by the new link between the MS and a new BTS when the MS moves to the edge of
a serving cell and is about to enter another serving cell. Handoffs in the CDMA system are
classified into hard handoff and soft handoff.
Soft Handoff
Soft handoff (SHO) refers to the process during which the MS sets up a link to the new cell in
the same frequency before disconnecting the link to the source cell. During a soft handoff, the
MS maintains the communication with the source BTS when it is setting up connection with
the target BTS.
Hard Handoff
Hard handoff (HHO) refers to the process during which the MS disconnects from the carrier
of the source BTS and then starts setting up connection with the carrier of the target BTS.
That is, the MS disconnects from the network and then connects to the network. During a
hard handoff, the communication links are disconnected transiently.
Handoff on the CDMA2000 1X Network

The CDMA2000 1X system supports the following types of handoffs:
Intra-RAC soft handoff
Inter-RAC soft handoff
Softer handoff
Intra-RAC hard handoff
Inter-RAC hard handoff
Access handoff
Handoff on the CDMA2000 1x EV-DO Network

The CDMA2000 1x EV-DO system supports the following types of handoff:
Issue 01 (2014-05-31)
Handoff on the CDMA2000 1x EV-DO network

87
Handoff between the CDMA2000 1X and the CDMA2000 1x EV-DO network
8.2 Troubleshooting Failures When MSs Fail to Trigger

HHOs
Symptom
In the edge area, MSs fail to trigger HHOs, causing a call drop by an increasing the frame
error rate (FER).
Cause
The BTS coverage quality in the edge area is poor.
The switch of the hard handoff algorithm is not enabled.
The HHO threshold is set improperly.
The MS in use may be faulty.
Analysis
When MSs fail to perform HHOs, check the network coverage in the edge area first by
observing whether MSs can detect and report pilot strength of the target BTS and whether the
pilot strength of the target BTS exceeds the HHO threshold. Then, check whether the
parameter configuration of the HHO algorithm is proper.

Figure 8-1 Flowchart for checking the configuration of HHO algorithm
Issue 01 (2014-05-31)

88
1. Check whether the BTS coverage in the edge area is normal, and check whether the
parameters related to signal receiving and BTS engineering (such as downtilt, azimuth, and
height of the antenna) are set properly.
If the BTS coverage is normal and the relevant parameters are set properly, go to 2.
If the BTS coverage is abnormal and the related parameters are set improperly, adjust the
parameter settings to optimize the coverage so that the MSs can report the pilot strength
of the source BTS and target BTS.
2. Check whether the switch of the corresponding HHO algorithm is enabled.
If the switch is enabled, go to 3.
If the switch is disabled, enable the switch of an HHO algorithm that is consistent with
the HHO algorithm set in the RAC.
The switch settings of different HHO algorithms are queried by using different commands.
Table 8-1lists the related commands to querying and modifying switch settings of HHO
algorithms.
Table 8-1 Commands used for querying and modifying HHO algorithm switches
HHO Algorithm
Switch
Definition
Query
Command
Modification
command
Default
Value
Intra-frequency HHO
algorithm switch
1: Turn on the
switch
LST
HOINF
MOD PHOALG
LST
RACHO
MOD PHOALG
LST
RACHO
MOD PHOALG
LST
HOINF
MOD PHOALG
LST
HOINF
MOD PHOALG
0: Turn off the

switch
Pseudo pilot HHO
algorithm switch
1: Turn on the
switch
0: Turn off the
switch
MS-assisted HHO
algorithm switch
1: Turn on the
switch
0: Turn off the
switch
Handdown HHO
algorithm switch
1: Turn on the
switch
0: Turn off the
switch
Direct HHO
algorithm switch
1: Turn on the
switch
0: Turn off the
switch
Issue 01 (2014-05-31)

89
For example, to query the switch setting of the intra-frequency HHO algorithm, run the
following command on the Service Maintenance System: LST HOINF: CN=106, SCTID=0,
CRRID=255, QRYINF=PHOALG;.
3. Check whether the HHO threshold is properly set.
If the threshold is set properly, go to 4.
If the threshold is set improperly, run the corresponding MML command to change the
threshold.
You can run the LST HOINF MML command to query the threshold of the intra-frequency
HHO algorithm.
For example, run LST HOINF: CN=106, SCTID=0, CRRID=255, QRYINF=HHOSF
Table 8-2 lists the MML commands used to modify HHO threshold value. (For details of
these commands, see MML Command Online Help.)
Table 8-2 MML commands related to HHO threshold
HHO Threshold
Modification Command
Definition
MOD DRCT
Modify direct HHO threshold value
MOD HNDDWN
Modify handdown HHO threshold value
MOD HHOBPLT
Modify pseudo pilot HHO threshold value
MOD HHOSF
Modify intra-frequency HHO threshold value
MOD HHOMA
Modify mobile-assisted HHO threshold value
4. Conduct dialing tests in the problem area to check whether MSs perform HHOs normally.
If HHOs are performed normally, no further action is required.
If HHOs are not performed normally, contact Huawei technical support.
----End
RAC version information
Original file of CDR
Issue 01 (2014-05-31)

90
Call tracing results on SysExplorer
BTS version information
Configuration script of the BTS
Results of the tracing on RSSI of the BTS
8.3 Troubleshooting Inter-frequency HHO Failures

Symptom
An MS does not trigger an HHO when it moves to a cell that works on a different frequency
band from the current cell. The air interface tracing results on the Service System
Maintenance shows that the RAC does not send the Handoff Direction Message to the MS.
Cause
The MS does not support the target frequency band.
The switch of inter-frequency HHO is not enabled.
Configurations of inter-frequency HHO algorithm are incorrect.
Configurations of inter-frequency cell neighboring relationship are incorrect.
Analysis
A precondition for performing inter-frequency HHOs is that the MS can search a target carrier
in a frequency band. Another precondition is that the neighboring relationship between the
source carrier and target carrier must be configured on the RAC. The RAC determines
whether the HHO is allowed based on the pilot strength of the target carrier or the values of
other parameters that the MS reports. The threshold of the algorithm affects the
inter-frequency HHO decision by the RAC.
Issue 01 (2014-05-31)

91

Figure 8-2 Flowchart for troubleshooting inter-frequency HHO failures
1. Check whether the MS supports the target frequency band.
Issue 01 (2014-05-31)
If the MS supports the target frequency band, go to 2.

92
If the MS does not support the target frequency band, replace the MS with an MS that
supports the target frequency band.
2. Run the LST RACHO command to check whether the inter-frequency HHO algorithm is
enabled.
If the algorithm is enabled, go to 3.
If the algorithm is disabled, run the MOD RACHO command to enable it.
3. Run the LST NBRCDMACH command to check whether the sector of the source carrier is
configured with correct inter-frequency cell neighboring relationship.
If correct neighboring relationship is configured, go to 4.
If correct neighboring relationship is not configured, run the ADD NBRCDMACH

command to configure correct inter-frequency cell neighboring relationship on the sector
of the source carrier.
4. Run the LST DRCTTRG command to check whether a carrier operates on a different
frequency band is configured as the direct HHO target carrier of the source carrier.
If a carrier in a different frequency band is configured as the direct HHO target carrier of
the source carrier, go to 5.
If no carrier in a different frequency band is configured as the direct HHO target carrier
of the source carrier, run the ADD DRCTTRG command to configure a carrier in
different frequency band as the direct HHO target carrier of the source carrier.
5. Check whether the parameters of inter-frequency HHO algorithm are properly set.
If the parameters are properly set, go to 6.
If the parameters are improperly set, modify the parameters.
6. Conduct dialing tests in the problem area to check whether inter-frequency HHOs can be
performed.
If inter-frequency HHOs can be successfully performed, no further action is required.
If inter-frequency HHOs cannot be performed, contact Huawei technical support.
----End
Configuration scripts of the RAC
Issue 01 (2014-05-31)

93
Configuration scripts of the BTS
8.4 Troubleshooting SHO Failures

Symptom
An MS fails to be handed off at the edge of a cell through a soft handoff to the neighboring
cell, and drops call.
Cause
The neighboring relationship between the source carrier and the target carrier is absent.
The setting of soft handoff threshold is improper.
The target carrier is unavailable.
The gain value of the target carrier is improper.
Issue 01 (2014-05-31)

94

Figure 8-3 Flowchart for troubleshooting soft handoff failures
Start
1
Check the same-frequency

neighboring relation between the
target sector and source sector
Is the samefrequency
neighboring relation
configured?
3
No
Add a same-frequency
neighboring relation
between the target sector
and the source sector
Yes
Check the handoff threshold value
Is the handoff
threshold value
proper?
No
Modify the handoff

threshold value
Yes
Check the target carrier
Is the carrier blocked?

7
Yes
Unblock the target carrier
No
Check the gain values of the source
sector and the target sector
Are the gain values

same?
No
Modify the gain values
Yes
9
Check the PN codes of the target

carrier and other carriers
10
Are the PN codes

same?
11
Yes
Modify the PN code of the

target carrier
No
Make a test call
End
Issue 01 (2014-05-31)

95
1. Check the intra-frequency neighboring relationship between the source sector and target
sector.
On the Service Maintenance System, query all intra-frequency neighboring sectors of the
source sector. For example, run the following command:
LST NBRCDMACH: NBRINF=SFNBR;
If the returned results include the target sector, the target sector and source sector are
intra-frequency neighboring sectors, go to 3
If the returned results do not include the target sector, the target sector and source sector
are intra-frequency neighboring sectors, go to 2.
2. Set the target sector as an intra-frequency neighboring sector of the source sector.
On the Service Maintenance System, configure the target sector as the intra-frequency
neighboring sector of the source sector.
For example, run the following command:
ADD NBRCDMACH: CCDMACH="958-2-0-283"; NBRCDMACHS="119-2310-1-283";
SFFLAG=SINGLE; DFFLAG=SINGLE; NBFLAG=SINGLE;
DFFLAG=SINGLE, NBFLAG=SINGLE;
3. Check the threshold value of the soft handoff.
On the Service Maintenance System, check whether the handoff parameters of the sectors are
set properly.
For example: Run LST DOHO: (for EV-DO network)
Run LST HOINF: (for 1X network)
The threshold value is generally set to the default value, or a value suggested by the network
planning personnel or network optimization personnel. If the threshold value is set to the
value suggested by the network planning personnel or network optimization personnel, check
whether the threshold value is the recommended value. If the two values are consistent, the
setting is proper.
If the threshold value is set to the default value, check whether the handoff parameters of the
target sector are consistent with the parameters of other normal sectors. If the handoff
parameters are consistent, the setting is proper.
If the threshold value is set improperly, go to 5.
If the threshold value is set properly, go to 4.
4. Modify the threshold value

According to the proper value obtained in 3, do as follows to modify the threshold value of
handoff of the target sector:
On the Service Maintenance System, run the MOD HO command (for 1X network) or the
MOD DOHO command (for EV-DO network) to modify the value.
5. Check carriers of the target sector.
On the Service Maintenance System, run the DSP RES command to check whether carriers of
the target sector are locked.
Issue 01 (2014-05-31)

96
For example: Run DSP RES: CN=3; SCTID=5; CRRID=0;

If Administrate State of carriers in the target sector is Locked, these carriers are locked.
If carriers in the target sector are locked, go to 6.
If carriers in the target sector are not locked, go to 7.
6. Unlock carriers of the target sector.

On the Service Maintenance System, run the UBL RES command to unlock carriers in the
target sector.
For example: Run UBL RES: CN=3; SCTID=5; CRRID=0;
7. Check the gain values of the source sector and target sector.
On the Service Maintenance System, run the LST CDMACH command to check whether the
gain values of the source sector and target sector are consistent.
If the gain values are not consistent, go to 8.
If the gain values are consistent, go to 9.
8. Modify the gain value.

Modify the gain values as required if the gain values of the two sectors are different.
On the Service Maintenance System, run the MOD CDMACH command to modify the
value.
9. Perform dialing tests.
In the problem area, make calls and move at the edge of the cell. If call drops do not occur, no
further action is required.
----End
Configuration scripts of the RAC
Configuration scripts of the BTS
Issue 01 (2014-05-31)

97
8.5 Troubleshooting Inter-AN HHO Failures for Dormant

ATs
Symptom
An inter-AN handoff for a dormant AT fails, and an A13 interface fault alarm is reported in
Cause
The A13 interface is faulty.
Issue 01 (2014-05-31)

98

Figure 8-4 Flowchart for troubleshooting inter-AN handoff failures for dormant ATs
Issue 01 (2014-05-31)

99
1. Check whether the source and target ANs have a neighboring relationship.
Run the LST NBRAN command for both the source and target ANs to determine whether a
neighboring relationship is configured between them.
If a neighboring relationship is configured between the source and target ANs, go to 3.
If a neighboring relationship is not configured between the source and target ANs, go to
2.
2. Configure the neighboring relationship between the source and target ANs.
Run the ADD NBRAN command to add the neighboring relationship between the source and
target ANs. For example:
ADD NBRAN: NBRANIP="129.9.123.102"", NBRA16PROTYPE=PREV0,
EVDOTRANSMODE=MODE3, ANHOSWITCH=OFF, SNDA13PAGINGSWITCH=OFF,
DEALA13PAGINGSWITCH=ON;
3. Run the LST NBRANLNK command to check whether a neighboring AN link is configured
between the source and target ANs.
If the neighboring AN link is configured between the source and target ANs, go to 5.
If the neighboring AN link is not configured between the source and target ANs, go to 4.
4. Run the ADD NBRANLNK command to configure the link between the source AN and the
neighboring target AN.
5. Run the LST DOCS command on both the source and target ANs to check whether color
code and subnet are the same.
If color code and subnet are the same, go to 6.
If color code and subnet are different, go to 7.
6. Modify the settings on the source and target ANs.

If the results of 5 show color code and subnet are the same, you need to modify the related
setting according to the parameter values defined by the network planning personnel.
Run the MOD DOCS command to modify color code and subnet on the source AN or
target AN.
Run the MOD DOCS command of the neighboring AN to modify color code and subnet
of the neighboring AN.
7. Check whether the fault is cleared.

Start the Um and the A13 interface tracings on the Service Maintenance System. Move an AT
in the dormant state from the coverage area of the source AN to the coverage area of the target
AN. If no session setup message is detected in the air interface tracing, but an inter-AN
handoff message is detected in the A13 interface tracing, it indicates the fault is resolved. If
the fault persists, contact Huawei technical support.
----End
Issue 01 (2014-05-31)

100
Results of RSSI tracing for the BTS
For details about how to collect the information, see section 2.4 "Collecting the Fault
8.6 Troubleshooting Inter-AN HHO Failures for Active

ATs
Symptom
Call drop and service interruption occur when an inter-AN hard handoff is performed for an
AT that moves in the edge area of two neighboring ANs and has ongoing EV-DO data
services.
Cause
There are license-related alarms.
There are inter-AN link alarms.
There are errors in the inter-AN HHO configuration.
There are network coverage problems.
Issue 01 (2014-05-31)

101

Figure 8-5 Flowchart for troubleshooting inter-AN HHO failures for active ATs
Issue 01 (2014-05-31)

102
Start
Check whether there are

license-related alarms
Yes
Apply for a license
Yes
Clear the alarm by

referring to section 20.11
No
Run the MOD DOHO

command to enable the
switches
No
Modify the color code to

ensure the target and
source AN are consistent
No
Modify one A16 interface

configuration to keep them
consistent
No
Enable the switch for the

HHO algorithms
No
Check whether there are

inter-AN link alarms
Check whether the

switch is enabled for
both the source and
target ANs
Check whether color

codes of the target and
source ANs are
consistent
No
Yes
Yes
Check whether the A16

Interface of the target
AN is consistent with
that of the source AN
Yes
Check whether the

switch for the HHO
algorithms is enabled
Yes

interface protocol of the
target and source ANs
are Huawei proprietary
protocols
8
Check whether an external
carrier is configured for the
target AN
No
No
Run the ADD

DOOUTPLTHHOTRG
command to configure an
external carrier
Yes
Yes
Check whether the

target carrier set or
neighboring carriers for
the HHO are properly
configured on the source
AN
No
Configure the target carrier

set or neighboring carriers
for the HHO
No
Run the MOD

OUTCDMACH command to
enable the external carrier
to support HHOs
No

support
No

support
Yes
10
Check whether the

external carrier supports
HHOs
11

interface session
migration is complete
Yes
Yes
12
Check whether the TCA

and ConnectionClose
messages are delivered
on the source AN
Yes
13
Check whether the TCC

message is received on
the target AN
15
No
Check whether the network

coverage is faulty, or if HHO
parameters are not properly
configured
Yes
14
Check whether the A8/A9

and A10/A11 connections
are successfully activated
No

support
Yes
End
Issue 01 (2014-05-31)

103
1. Browse the alarms to check whether there are license-related alarms.
If a license-related alarm exists, apply for a license.
If there are no license-related alarms, go to 2.
2. Browse the alarms to check whether there are inter-AN link alarms.
If an inter-AN link alarm exists, clear the alarm by referring to section 15.7
"Troubleshooting A13/A16 Link Failure."
If there are no inter-AN link alarms, go to 3.
3. Run the LST DOHO command on the LMT to check whether the Inter-AN HHO Division
Switch is enabled for both the source and target ANs.
If the switches are enabled, go to 4.
If the switches are not enabled, run the MOD DOHO: INTERANHHODIVSW=ON;
command to enable the switches.
4. Run the LST NBRAN command on the LMT to check whether color codes of the target and
source ANs are properly configured.
If color codes are properly configured, go to 5.
If color codes are not properly configured, modify the color code and ensure the target
and source AN are properly configured.
5. Run the LST NBRAN command on the LMT to check whether the A16 Interface Protocol
Revision of Neighbor AN of the target AN is consistent with that of the source AN.
If the A16 Interface Protocol Revision of Neighbor AN is consistent, go to 6.
If the A16 Interface Protocol Revision of Neighbor AN is not consistent, modify one of
the A16 Interface Protocol Revision of Neighbor AN of the source AN and the target
AN to keep them consistent.
6. Check whether the switch for the HHO algorithms is enabled.
If the switch is enabled, go to 7.
If the switch is not enabled, enable the switch for the HHO algorithms by referring to the
CBSS Feature Configuration Guide.
7. Run the LST NBRAN command on the LMT to check whether the A16 Interface Protocol
Revision of Neighbor AN of the target and source ANs are Huawei proprietary protocols.
If the A16 Interface Protocol Revision of Neighbor AN of the source and target ANs
are Huawei proprietary protocols, go to 9.
If the A16 Interface Protocol Revision of Neighbor AN of the source and target ANs
are not Huawei proprietary protocols, go to 8.
8. Check whether an external target carrier is configured for the target AN.
If an external carrier is configured for the target AN, go to 9.
If an external carrier is not configured for the target AN, run the ADD
DOOUTPLTHHOTRG command to configure it.
9. Check whether the target carrier set or neighboring carriers for the HHO are properly
configured on the source AN.
Issue 01 (2014-05-31)

104
If the target carrier set or neighboring carriers for the HHO are properly configured on
the source AN, go to 10.
If the target carrier set or neighboring carriers for the HHO are not properly configured
on the source AN, refer to the CBSS Feature Configuration Guide.
10. Run the LST CDMACH command on the LMT to check whether the external carrier
supports HHO.
If the external carrier supports HHO, go to 11.
If the external carrier does not support HHO, run the MOD OUTCDMACH command
to enable the external carrier to support HHOs.
11. Start tracing the inter-AN handoffs of an AT over the Um, Abis, A9, A11, A13, A16, and
A17 interfaces. Check whether the A16 interface session migration is complete.
If the A16 interface session migration is complete, go to 12.
If the A16 interface session migration is not complete, contact Huawei technical support.
12. Start tracing messages on the target AN to check whether the AT sends the TCA message and
ConnectionClose messages.
If the TCA and ConnectionClose messages are properly delivered on the source AN, go
to 13.
If the TCA and ConnectionClose messages are not properly delivered on the source AN,
contact Huawei technical support.
13. Start tracing messages on the target AN to check whether the AT sends the TCC message.
If the AT sends the TCC message, go to 14.
If the AT does not send the TCC message, go to 15.
14. Start tracing messages on the target AN to check whether the A8/A9 and A10/A11
connections are successfully activated.
If the A8/A9 and A10/A11 connections are successfully activated, no further action is
required.
If the A8/A9 and A10/A11 connections are not successfully activated, contact Huawei
technical support.
15. Perform a drive test in the top areas where HHOs fail. Determine whether the network
coverage is faulty, or if HHO parameters are not properly configured.
If the network coverage is faulty or HHO parameters are not properly configured, no
If the network coverage is not faulty and HHO parameters are properly configured,
contact Huawei technical support.
----End
the following information related to the fault.
Issue 01 (2014-05-31)

105
Running logs of the SPUO subsystem
Running logs of the SMUO subsystem
Running logs of the DPUD subsystem
Running logs of the APUD subsystem
Running logs of PCF interface boards
8.7 Troubleshooting Inter-AN SHO Failures for Active

ATs
Symptom
When an AT in the active state moves from one AN to another AN, the soft HO fails resulting
in call drops.
Cause
The neighboring relationship between the two ANs is not configured.
The link between the two neighboring ANs is not configured.
Color code and subnet configured for one carrier are the same as those for the
neighboring carrier.
Issue 01 (2014-05-31)

106

Figure 8-6 Flowchart for troubleshooting inter-AN soft HO failures for active ATs
Start
Check whether the neighboring

relationship is configured between
the source and target ANs
Is neighboring
relationship configured?
Configure the neighboring

relationship between the
source and target ANs
Check whether a link is

configured between the
Is a link
configured?
Configure the link between the

Check whether color code and

subnet of the carrier on the
source AN are the same as
those of the neighboring
carrier on the target AN
Are the color

code and subnet of the
two ANs the same?
Modify the settings of the

Check whether the fault is

cleared
End
Issue 01 (2014-05-31)

107
1. Check whether the source and target ANs have a neighboring relationship.
Run the LST NBRAN command of both the source and target ANs to check whether a
neighboring relationship is configured between them.
If the command output contains the IP address of the target AN, it indicates that a
neighboring relationship is configured between the source and target ANs. Go to 3.
If the command output does not contain the IP address of the target AN, it indicates that
a neighboring relationship is not configured between the source and target Ans. Go to 2.
2. Configure the neighboring relationship between the source and target ANs.
Run the ADD NBRAN command on the LMT. For example:
ADD NBRAN: NBRANIP="129.9.123.102", NBRA16PROTYPE=PREV0,
EVDOTRANSMODE=MODE3, ANHOSWITCH=OFF, SNDA13PAGINGSWITCH=OFF,
DEALA13PAGINGSWITCH=ON;
3. Check whether a link is configured between the source and target ANs.
Run the LST NBRANLNK command of both the source and target ANs to check whether the
link between the two neighboring ANs is configured.
If the command output contains the IP address of the target AN, it indicates that the link
is configured between neighboring ANs. Go to 5.
If the command output does not contain the IP address of the target AN, go to 4.
4. Configure the link between the source AN and the neighboring target AN.
Run the ADD NBRANLNK command on the Service Maintenance System.
5. Check whether color code and subnet of the carrier on the source AN are the same as those of
the neighboring carrier on the target AN.
Run the LST DOCS command of both the source and target ANs to check whether color code
and subnet of the carrier on the source AN are the same as those of the neighboring carrier on
the target AN.
If color code and subnet of the carrier on the source AN are the same as those of the
neighboring carrier on the target AN, go to 6.
If the color code and subnet of the carrier on the source AN are different from those of
the neighboring carrier on the target AN, go to 7.
6. Modify the settings of the source and target ANs.

If the results of 5 shows color code and subnet of the carrier on the source AN are the same as
those of the neighboring carrier on the target AN, you need to modify the related setting
according to the parameter values defined by the network planning personnel.
Modify color code and subnet of a carrier.
Run the MOD DOCS command on the Service Maintenance System.
Modify color code and subnet of the neighboring AN after color code and subnet of a
carrier is modified.
Run the MOD DOCS command on the Service Maintenance System of the neighboring AN.
7. Check whether the fault is cleared.
Issue 01 (2014-05-31)

108
Start the Um and the A17 interface tracings on the Service Maintenance System. Move an AT
in active state from the coverage area of the source AN to the coverage area of the target AN.
If no session setup message is detected in the air interface tracing, but an inter-AN
handoff message is detected in the A17 interface tracing, it indicates the fault is resolved.
If the fault persists, contact Huawei technical support.
----End
RAC version information.
Issue 01 (2014-05-31)

109
9 Troubleshooting Registration Failures
Troubleshooting Registration Failures
9.1 Introduction to Registration

Location registration occurs when an MS notifies the BTS of its location status, timeslot
period, and other features to enable the BTS to effectively page the MS.
MS registration in the CDMA2000 1X system is used to:
Report the MS location and status so that the MS can be paged when it functions as the
called party.
Enable the MS in timeslot mode and provide timeslot period indexes so that the RAC
can know which timeslot the MS is listening to.
Inform the BSS system of MS type and protocol version so that the BSS can know the
MS's capability to support the channel.
Common types of MS registration include power-up registration, power-down registration,

periodic registration, distance-based registration, zone-based registration, parameter-update
registration, and implicit registration. Figure 9-1 shows the MS registration process.
Figure 9-1 MS registration process
MS
Virtual
MSC
BSS
1. Registration Message
2. Location Updating Request
3. Location Updating Accept
4. Registration Accepted Order
The registration process on the V5 interface is as follows:
1. The MS sends the Registration Message to the BSS to initiate the registration
process. The Registration Message carries the information about cells searched
by the MS.
Issue 01 (2014-05-31)

111
2. After receiving the Registration Message, the BSS generates the Location
Updating Request message based on the information about cells and
authentication and sends the message to the MSC.
3. The MSC authenticates the MS. After the MS survives the authentication, the
MSC records the cell where the MS resides and send the BSS the Location
Updating Accept message.
4. The BSS sends the Registration Accepted Order message to the MS.
5. The registration is complete.
9.2 Troubleshooting Registration Initiation Failure

Symptom
An MS fails to initiate a timer-based registration, or fails to initiate a registration when it is
powered up, powered down, performs an idle handoff to a new location area, or roams to
other areas. No registration message can be tracked on the Service Maintenance System.
Cause
Configuration of system information is incorrect.
Configuration of terminal parameters is incorrect.
Issue 01 (2014-05-31)

112

Figure 9-2 Flowchart for troubleshooting registration initiation failures
Start
1
Check system parameter

messages
Are
parameters of these
messages
correct?
No
Modify system parameter

messages
Yes
Check cell parameters
Are registration
parameters
correct?
5
No
Yes
Check the registration
parameters configured on
an MS
Are
registration
parameters on the
MS correct?
Modify system parameter

messages
Modify cell parameters
No
Modify the registration

parameters configured on
the MS
Yes
Make a test call
End
Analysis
Check the status of carriers.
Check the signal coverage.
1. Run the LST SYSMSGPARA command to check the System Parameter Message (SPM).
Review the following fields:
Issue 01 (2014-05-31)

113
Local Registration Flag: If this field is set to Automatic registration is required for
local MSs (non-roaming MSs), all local MSs automatically initiate registration. That is,
all MSs sharing the same home SID/NID as the local network initiate registration.
SID Roaming Registration Flag: If this field is set to Automatic registration is

required for MSs roaming from other SIDs, all MSs roaming from other SIDs
automatically initiate registration. That is, MSs using SIDs different from the local
network initiate registration.
NID Roaming Registration Flag: If this field is set to Automatic registration is

required for MSs roaming from other NIDs, all MSs roaming from other NIDs
automatically initiate registration. That is, MSs using NIDs different from the local
network initiate registration.
Power-up Registration Flag: This field specifies whether registration is required upon
MS power-up. It must be set to Registered.
Power-down Registration Flag: This field specifies whether registration is required upon
MS power-down. It must be set to Registered.
System Message Parameter Change Registration Flag: This field specifies whether
registration is required after system parameters are changed. It must be set to
Registered.
Time Registration: The value 0 indicates time-based registration is not required.
Registration Zone: The value of this field is usually identical with the LAC.
Reserved Registration Zones: The value 0 indicates zone-based registration is not

required.
Determine whether the SPM message is correct.
If the SPM message is correct, go to 2
If the SPM message is not correct, modify the parameters and perform a dialing test. If
the test result is normal, no further action is required. If the test result is abnormal, go to
2.
2. Run the LST CELL command to check parameters of neighboring cells.

If registration is required when an MS in the idle state is handed off from other cells to the
local cell, compare SIDs, NIDs, and registration zones. The registration zones may either be
the same or different from the local area code. When the SPM message is correct, if one or
several parameters (SIDs, NIDs, and Registration Zones) of neighboring cells are different,
registration is automatically initiated after the MS in the idle state is handed off.
To enable registration when the MS moves from other cells to the local cell:
Modify the value of registration zone. For this operation, go to 3.
Modify the cell parameters so that parameters of other cells are different from those of
the local cell. This will trigger registration of the MS. For this operation, go to 4.
3. Run the MOD SPM command to modify the SPM message.

Run the following command on the Service Maintenance System:
MOD SPM: CN=1, SCTID=0, CRRID=0, PWRUP=YES, PWRDWN=YES, PRMREG=YES,
REGPRD=67;
Check whether the initiation of location registration is normal.
If the initiation is normal, no further action is required.
If the initiation is not normal, go to 5.
Issue 01 (2014-05-31)

114
4. Run the MOD CELL command to modify the SPM message.

Run the following command on the Service Maintenance System:
MOD CELL: CN=1, SCTID=0, PN=100, SID=4, NID=1, PZID=1, LAC="0x123",
ASSALW1X=YES;
Check whether the initiation of location registration is normal.
If the initiation is normal, no further action is required.
If the initiation is not normal, go to 5.
5. Check the setting of MS registration parameters.

This step is only performed when MSs are unable to initiate registration. Contact the supplier
of the MS to check the setting of MS parameters
Some MSs allow setting of parameters to control the initiation of registration. If the fault is
caused by an incorrect setting, modify the registration-related parameters on the MS. Contact
the supplier of the MS for specific modification instructions.
Check whether the setting of the MS registration parameters is correct.
If the setting of MS registration parameters is not correct, modify the settings. If test
result shows the initiation of localization registration is normal, no further action is
required.
If the setting of MS registration parameters is correct, contact Huawei technical support.
----End
Version information of the RAC
Subscriber interface tracing (including messages over all interfaces)
Issue 01 (2014-05-31)

115
9.3 Troubleshooting MS-Initiated Registration Failure

(over V5 Interface)
Symptom
When the V5 interface is used, the MS-initiated registration is rejected by the MSC.

Figure 9-3 Flowchart for MS-initiated registration failure
Start
1
Check the RAC data

configuration
Are the RAC

data correct?
No
Modify the RAC data

configuration
Yes
Check whether the MS is

correctly defined
Is the
MS correctly defined?
No
Modify the MS information

in the HDB
Yes
Make a test call
End
1. Check the RAC data configuration.
Check whether the homing RAC is configured for the current MS. If the homing RAC is not
configured or is incorrectly configured, the MSC rejects the location updating message
reported by the RAC.
Query the mapping between the IMSI and the RAC on the Service Maintenance System by
running the LST IMSIBSC command.
According to the query results, check whether the configured homing RAC is the actual
homing RAC.
Run the STR CRC command to verify that data between the FAM and BAM is consistent.
2. Modify the RAC data configuration.
Issue 01 (2014-05-31)

116
Modify the RAC data configuration to ensure that the mapping between the IMSI and the
RAC is correct.
For example, to modify the configuration of the RAC whose IP address is 192.168.0.1 and
whose mapping IMSI is prefixed with 4600309, run the following command:
MOD IMSIBSC: IMSIMASK="4600309", BSCIP="192.168.0.1";
3. Check whether the MS is correctly defined in the HDB.
If the MS is not correctly defined in the HDB, the MSC rejects the location updating message
reported by the RAC.
For example, to check whether an MS whose IMSI is 460030912120001 is correctly defined,
run the following command on the Service Maintenance System:
DSP SUBSCR: SUBSCRINFO=IMSI, IMSI="460030912127777",
NEEDSECRETDATA=NO;
Check whether the ESN is correct.
4. Modify the subscriber subscription information.
If the ESN or A-KEY is incorrect, run the MOD IMSIAKEYESN command to correct it.
If the MS has been defined, run the RMV SUBSCR command to delete the subscriber. Then,
run the MOD IMSIAKEYESN command to modify the subscriber subscription information.
If the MS-initiated registration failure is caused by other incorrect information, run the MOD
SUBSCR command.
5. Verify that the MS can be registered when being powered on or powered off.
9.4 Troubleshooting Location Update Failure Due to

1X/EV-DO Interoperability
Symptom
When hybrid ATs performing 1X data services detect an EV-DO network, the hybrid ATs
initiate a dormant handoff from 1X data services to EV-DO Rel. 0 packet data services
through location update messages, enabling the hybrid ATs to enter the EV-DO dormant state.
Cause
The EV-DO network lacks coverage.
The setting of hybrid AT parameters is incorrect.
Analysis
Check EV-DO network coverage.
Check whether the setting of hybrid AT parameters is correct.
Issue 01 (2014-05-31)

117
1. Check whether the area where the hybrid AT is located is covered by the EV-DO network by
performing an EV-DO dialing test.
If the hybrid AT is covered by the EV-DO network, go to 2.
If the hybrid AT is not covered by the EV-DO network, 1X/EV-DO interoperation is not
available.
2. Check whether network parameters set on the hybrid AT are correct. For specific
configurations, contact the supplier of the hybrid AT.
If parameters are correct, contact Huawei technical support.
If parameters are incorrect, request the supplier of the hybrid AT to modify the setting.
Then, perform a test. If the test results are normal, no further action is required. If the test
results are abnormal, contact Huawei technical support.
----End
Subscriber interface tracing (including messages over all interfaces)
Issue 01 (2014-05-31)

118
10
10 Troubleshooting Authentication Failures
Troubleshooting Authentication
Failures
10.1 Introduction to Authentication

The purpose of authentication is to verify the authenticity of the MS and the network.
Authentication is classified into two types: 1X service authentication and EV-DO service
authentication.
10.1.1 1X Service Authentication

1X service authentication includes two processes: SSD update and terminal authentication.
Shared secret data (SSD) update is performed to update the SSD parameter stored in the
MS to ensure the consistency of parameters between the MS and the network.
Terminal authentication verifies the authenticity of an MS, denying service to invalid

MSs and thereby deterring fraud.
SSD Update
SSD is a 128-bit data pattern stored on the MS, readily available to the network. The first 64
bits of the SSD are defined as SSD-A that is used to support authentication procedures. The
second 64 bits of the SSD is defined as SSD-B that is used to support voice authentication and
signaling message authentication. The SSD is derived from the A-key and a random challenge
(RANDSSD) through a certain algorithm. The SSD is never broadcast between the MS and
the network across the air interface. The RAC updates the SSD by updating the RANDSSD.
SSD update is initiated in the case of an authentication request failure, or by the AC. Usually,
the entity controlling the authentication in the network initiates the Unique Challenge
procedure after an SSD update procedure is completed.
Figure 10-1 shows a successful case of the SSD update procedure.
Issue 01 (2014-05-31)

119
Figure 10-1 SSD update procedure flowchart
Note: The MSE in the preceding figure indicates a logical module that implements the MSC
functions in RAC6690. It is also called a virtual MSC.
The SSD update procedure is described as follows:
a.
The MSC sends an SSD Update Request message to the BS to indicate that the SSD on
the MS needs updating. The update information is in the form of a random number
(RANDSSD) that can be used by the MS to calculate the new SSD.
b.
Based on the SSD Update Request message from the MSC, the BS sends the SSD
Update message to the MS, indicating the MS should update its SSD.
c.
Upon receiving the SSD Update message from the BS, the MS uses the RANDSSD as
input to the algorithm to generate the new SSD. The MS then selects a 32-bit random
number (RANDBS) and sends it to the BS in a Base Station Challenge Order message.
d.
The BS forwards the Base Station Challenge message to the MSC to verify whether the
new SSD calculated by the MS is the same as that in the network.
e.
Upon receiving the Base Station Challenge message, the MSC uses the new SSD as
input to the algorithm to generate the authentication response signature (AUTHBS). The
MSC then sends the AUTHBS to the BS in the Base Station Challenge Response
message.
f.
Upon receiving the message, the BS transmits the information in a Base Station
Challenge Confirmation Order message to the MS.
g.
If AUTHBS from the MSC is valid, the MS returns an SSD Update Confirmation Order
message to the BS. If AUTHBS from the MSC is invalid, the MS returns an SSD Update
Rejection Order message to the BS.
h.
The BS forwards the information in the SSD Update Response message to the MSC.
Issue 01 (2014-05-31)

120
Terminal Authentication
Terminal authentication verifies the authenticity of an MS, and denies service to unauthorized
MS. The authentication involves a common network algorithm and a parameter unique to
each MS, known only by the MS and the network, called the A-Key. A second level of
security, SSD, is derived from the A-Key and a random challenge (RANDSSD). The A-Key
and the SSD are never broadcast across the air interface. Instead, a publicly available random
number (RAND) is sent to the MS. The RAND and SSD are used as input to the
authentication algorithm for both the MS and the network. The authentication result, referred
to as AUTHR, is calculated by the MS and returned to the network. It is compared to the
AUTHR calculated by the network. If the results match, authentication is successful.
Two forms of authentication are available for CDMA MSs:
Global Challenge Authentication: The RAND value is broadcast on the paging channel
and is available to all MSs accessing the cell. The MS calculates AUTHR using this
RAND, and provides it in its initial access message, which may be a location registration,
origination, or page response.
Unique Challenge: The MSC initiates an independent authentication procedure, with

messaging separate from those used for call setup and registration. The MSC issues a
challenge to the MS containing a unique RANDU value, and the MS responds with its
calculated AUTHU value. The MSC may initiate this procedure at any time when the
MS is on the voice or traffic channels. This process can also be initiated on the control
channel. This procedure is always initiated and controlled by the MSC.
Unique Challenge Procedure

Figure 10-2 Unique challenge flowchart
The unique challenge process is described as follows:

a.
The MSC sends the Authentication Request to the BS.
b.
The BS forwards the information (RANDU) to the MS in an Authentication Challenge

Message.
c.
The MS calculates the result AUTHU based on the specified RANDU and SSD of the
MS. It then returns an Authentication Challenge Response Message to the BS, with the
enclosed AUTHU.
Issue 01 (2014-05-31)

121
d.
The BS forwards the AUTHU information to the MSC using the Authentication
Response message.
10.1.2 EV-DO Service Authentication

EV-DO service authentication is used to verify the authenticity of EV-DO ATs. EV-DO
service authentication consists of the process of session establishment and access
authentication, and the process of re-authentication.
Figure 10-3 shows the process of a successful access authentication.
Figure 10-3 Successful access authentication flowchart
Figure 10-4 shows the process of an unsuccessful access authentication.
Issue 01 (2014-05-31)

122
Figure 10-4 Unsuccessful access authentication flowchart
Re-authentication includes re-authentication of an AT in dormant state and in active state. In

re-authentication of an AT in dormant state, the AT needs to establish a connection. In
re-authentication of an AT in active state, the AT does not need to establish a connection.
Issue 01 (2014-05-31)

123
Figure 10-5 Re-authentication of an AT in dormant state
Figure 10-6 Re-authentication of an AT in active state
Issue 01 (2014-05-31)

124
10.2 Troubleshooting Broadcast Authentication Failure

Symptom
After an MS initiates a registration, the BSS sends a Location Update Request to the MSC.
The MSC then responds with a Location Update Reject message, rejecting the registration.
In an MOC, upon receiving the CM Service message from the BSS, the MSC responds with a
Clear Command message with the cause value of 0X1A, or a N_DISCONNECT_IND
message, and releases the call.
In an MTC, upon receiving the Paging Response message from the BSS, the MSC responds
with a Clear Command message with the cause value of 0X1A, or a N_DISCONNECT_IND
message, and releases the call.
Cause
The authentication switch on the RAC is disabled.
The A-Key value on the MS is incorrect.
The R_UIM of the MS does not support authentication.
If the global challenge authentication of an individual MS fails, common causes of the

fault are as follows:
a.
The A-Key value on the MS is not consistent with that on the HLR of the core network.
b.
The UIM card of the MS is faulty.
If the global challenge authentication of all MSs fails, it indicates the authentication
switch on the RAC is disabled.
Analysis
Query the Authentication Parameters Configured on the RAC
1. Query the authentication switch on the RAC. On the Service Maintenance System, run the
following command:
LST SYSMSGPARA: CN=20, SCTID=0, CRRID=0, CCMINF=AUTH;
The command output is as follows:
%%LST SYSMSGPARA: CN=20, SCTID=0, CRRID=0, CCMINF=AUTH;%%
RETCODE = 0 Execution succeeded
Authentication Information
-------------------------Cell ID
Sector ID
Carrier ID
Authentication Indicator
value
20
0
0
Authenticate
(Number of results = 1)
--END
Random authentication
100
In the output, Authentication Indicator indicates the status of the authentication switch on
the RAC.
Issue 01 (2014-05-31)

125
If Authentication Indicator is Authenticate, go to 3.
If Authentication Indicator is Not Authenticate, go to 2.
2. Enable the authentication switch on the RAC. On the Service Maintenance System, run the
following command:
MOD AUTH: CN=20, SCTID=0, CRRID=0, AUTH=YES, RAND=100;
Set AUTH to YES to enable the authentication switch on the RAC.
If the MS passes the authentication after the data is modified, no further action is
required.
If the authentication fails again after the data is modified, go to 3.
Check Whether the A-Key Value on the MS Is Correct

3. Query the A-Key values on the MS and HLR. To query the A-Key value on the MS, contact
MS maintenance engineers. To query the A-Key value of the MS on the HLR, contact HLR
maintenance engineers.
If the A-Key value on the MS is not consistent with that on the HLR, go to 4.
If the A-Key value on the MS is consistent with that on the HLR, go to 5.
4. Modify the A-Key value on the MS or the HLR. Contact MS or HLR maintenance engineers
to modify the values so that they are consistent.
If the MS passes the authentication after the A-Key values are modified, no further
action is required.
If the authentication fails again after the A-Key values are modified, go to 5.
Check Whether the MS Supports Authentication

5. Insert the R_UIM card of the MS that failed the authentication into an MS that passed the
authentication. If the authentication fails again, you can infer that the R_UIM card is faulty.
Replace the R_UIM card.
If the MS passes the authentication after the R_UIM card is replaced, no further action is
required.
If the authentication fails again, collect relevant information according to the following
"Information Collection" and contact Huawei technical support.
----End
Historical alarm information
Issue 01 (2014-05-31)

126
Subscriber interface tracing
10.3 Troubleshooting Unique Challenge Failure (V5

Interface)
Symptom
During the tracing of single user signaling, the MSC sends the BSS an Authentication Request
message. After receiving an Authentication Response message from the BSS, the MSC sends
a clear command message. During the tracing of the Um interface, the BSS sends the MS an
Authentication Challenge message but does not receive an Authentication Challenge
Response message from the MS.
Issue 01 (2014-05-31)

127

Figure 10-7 Flowchart for troubleshooting specified query failure (V5 interface)
Start
Query the A-keys stored in

the LE and the MS
Is the A-key
stored in the LE
correct?
No
Modify the A-key stored in

the LE
Yes
Is the A-key
stored in the MS
modified?
Yes

the MS
No
4
Check whether the MS

supports the unique
challenge
Does the MS
support this
function?
No
Disable the authentication

to the MS
Yes
6
Make a test call
End
1. Check the A-KEY on the RAC.
To query the A-KEY on the RAC, run the following command on the Service
Maintenance System:
LST IMSIAKEYESN: INFO=IMSI, IMSI="460035545123456";

Execution results:
Issue 01 (2014-05-31)

128
Example 1:List the IMSI-AKEY-ESN relationship of the subscriber with the IMSI of
460030910010001:
LST IMSIAKEYESN: INFO=IMSI, IMSI="460030910010001";
Execution result:
+++
HW-AirBridge
2007-07-19 20:44:36
O&M
#74496
%%LST IMSIAKEYESN: INFO=IMSI, IMSI="460030910010001";%%
IMSI
A_KEY Value
460030910010001
0000000000000000
--
ESN/MEID
-
END
Query the MS A-KEY.
To query the MS A-KEY, enter the super user password on the MS.
2. Modify the A-KEY on the RAC by performing the following operations:
a.
Run the DSP SUBSCR command to query the subscription information of the
subscriber.
b.
Run the RMV SUBSCR command to delete the user data.
c.
Run the LST IMSIAKEYESN command to query the original IMSI-A-KEY-ESN

information of the subscriber.
d.
Run the MOD IMSIAKEYESN command to correct the A-KEY.
e.
Run the ADD SUBSCR command to add the subscriber again.
3. Modify the MS A-KEY.

To modify the MS A-KEY, enter the super user password on the MS.
4. Check whether the MS supports the specified query function.
To modify the MS A-KEY, enter the super user password on the MS.
5. Disable the MS authentication function.
On the Service Maintenance System, run the following command:
MOD SUBSCR: SURACRINFO=IMSI, NUMBER="460030912130020", AUTHCAP=NO,
SMSORGRESDFT=ALWALL, SMSTERRESDFT=ALWALL, SMSTERRESRC=ALWCHG,
AUTOREGESNOPT=DEFAULT, ROAMRESTRICT=NORST;
6. Verify whether the problem is resolved.
If the problem is caused by inconsistent A-KEY configuration, modify the user data on the
RAC to trigger the SSD update. During the single user tracing on the Service Maintenance
System, check whether the MSC sends the clear command message after receiving the
Authentication Response message with the RANDU field. If the MSC does not send the clear
command message, the modification is successful.
If the specified query function is not supported, dialing tests are not required.
----End
Issue 01 (2014-05-31)

129
10.4 SSD Update Failures of an MS (over the V5 Interface)

In the case of the V5 interface, start individual user tracking on the Service Maintenance
System. The tracked message shows that the MSC receives the SSD Update Response
message (this message contains the layer 3 cause value 0x3B which indicates the failure of
the SSD update) and sends a clear command to release the call.
Troubleshooting
Figure 10-8 shows the troubleshooting procedure.
Figure 10-8 Troubleshooting procedure
Start
1
Query the A-keys stored in

the RAC and the MS
Is the A-key
stored in the RAC
correct?
No

the RAC
Yes
Is the A-key
stored in the MS
correct?
No

the MS
Yes
4
Make a test call
End
Procedure
1. Query the A-KEYs stored in the RAC and MS.
For details, see Unique Challenge Failures of an MS (over the V5 Interface).
2. Modify the A-KEY stored in the RAC.
For details, see Unique Challenge Failures of an MS (over the V5 Interface).
3. Modify the A-KEY stored in the MS.
On the MS, enter the super password of the MS to check and modify the A-KEY. The A-KEY
stored in the MS should be consistent with that stored in the RAC.
4. Make a test call.
Issue 01 (2014-05-31)

130
Initiate an SSD update from the RAC. If the SSD update is successful, you can infer that the
fault is rectified.
If an SSD update fail in the case that the A-KEYs stored in the RAC and the MS are
consistent, you can infer that the MS does not supports the SSD update.
10.5 Authentication Initiation Failures (over the V5

Interface)
This describes the authentication initiation failures (over the V5 interface) and the
troubleshooting procedure.
Troubleshooting
In the case of the V5 interface, the MS authentication failure usually results from the incorrect
settings of the authentication flag. Figure 10-9 shows the troubleshooting procedure.
Issue 01 (2014-05-31)

131

Start
1
Check whether the MS

subscribes to the authentication
function
Does the MS
subscribes to the
function?
No
2
Subscribes to the
authentication function
Yes
Check the settings of the
authentication flag on the RAC
Is the
authentication flag
enabled?
No
4
Enable the authentication flag
at the RAC
Yes

authentication flag on the MSC
Is the
authentication flag
enabled?
No
6
at the MSC
Yes

authentication flag on the HDB
Is the
authentication flag
enabled?
No
8
at the HDB
Yes
Make a test call
End
Procedure
1. Check whether the MS subscribes to the authentication function.
On the Service Maintenance System, run DSP SURACR to check whether the MS subscribes
to the authentication function. For example,
Issue 01 (2014-05-31)

132
DSP SURACR: SURACRINFO=PN, PN="0216005000", NEEDSECRETDATA=NO;

If the output displays authentication capability = NO, you can infer that the MS does not
subscribe to the authentication function.
2. Subscribes to the authentication function.
On the Service Maintenance System, run MOD SURACR and set Authentication Capability
to YES. For example,
MOD SURACR: SURACRINFO=PN, NUMBER="0216005000", AUTHCAP=YES,
SMSORGRESDFT=ALWALL, SMSTERRESDFT=ALWALL, SMSTERRESRC=ALWCHG,
AUTOREGESNOPT=DEFAULT, ROAMRESTRICT=NORST;
3. Check the settings of the authentication flag on the RAC.
On the Service Maintenance System, run LST SYSMSGPARA to check the settings of the
authentication flag. For example,
LST SYSMSGPARA: CN=1, SCTID=0, CRRID=11, CCMINF=AUTH;
4. Enable the authentication flag on the RAC.
On the Service Maintenance System, run MOD AUTH to modify the settings of the
authentication flag. For example,
MOD AUTH: CN=10, SCTID=0, CRRID=11, AUTH=YES, RAND=100;
Set AUTH to YES.
5. Check the settings of the authentication flag on the MSC.
On the Service Maintenance System, run LST MSCSYSINFO. For example,
LST MSCSYSINFO:;
6. Enable the authentication flag on the MSC.
On the Service Maintenance System, run MOD MSCSYSINFO to enable the authentication
flag on the MSC. For example,
MOD MSCSYSINFO: AUTHFLG=YES;
7. Check the settings of the authentication flag on the HDB.
On the Service Maintenance System, run LST HDBCFG. For example,
LST HDBCFG:;
8. Enable the authentication flag on the HDB.
On the Service Maintenance System, run MOD HDBCFG to enable the authentication flag
on the HDB. For example,
MOD HDBCFG: AUTHOPT=YES;
Make MOCs and MTCs by using an illegal MS. If all the calls fail, you can infer that the fault
is rectified.
Issue 01 (2014-05-31)

133
To check whether the previous modifications take effect, you can run STR CRC to check the
data on the RAC and the BAM.
10.6 Troubleshooting EV-DO Service Authentication

Failure
Symptom
An AT fails to be authenticated by the AN-AAA. As a result, the AT cannot access the
network.
Cause
The AT is unauthorized.
The authentication mode configured for the AT is incorrect.
The AN-AAA configuration information is incorrect.
The A 12 link is interrupted.
Analysis
Check whether the accessed AT is authorized.
Check whether the setting of the authentication mode of the AT is correct.
Check whether the A12 link is normal.
Check whether the AN-AAA data configuration on the AN is correct.
Check Whether the Configuration Between the AN and the AN-AAA Is Correct
1. Run the LST PCFAAA command to query the binding relationship between the PCF and the
ANAAA.
2. Check whether there is the binding relationship between the PCF and the ANAAA in the
output information.
If the binding relationship is configured, go to 3.
If the binding relationship is not configured, configure it by referring to the section

"Configuring the A12 Interface Data" in the RAC6680 Initial Configuration Guide.
3. Run the LST ANAAA command to check whether the configuration information of the
AN-AAA server is correct. On the Service Maintenance System, run the following command:
LST ANAAA:;
%%LST ANAAA:;%%
Issue 01 (2014-05-31)

134

AN AAA Information
-----------------AN-AAA Server IP Address
an A12 Request
129.11.17.10
--END
Domain Name
AN-AAA Secret Key
huawei.com
Retransmission Times for
123456789
In the output, check whether the configuration information of the AN-AAA server, such as IP
address, domain name, and key, is correct.
If configuration information is correct, go to 4.
If configuration information is not correct, configure the AN-AAA data by referring to

the section "Configuring the A12 Interface Data" in the RAC6690 Initial Configuration
Guide.
Check Whether the A12 Link Is Normal

4. Check whether the ALM-2291 A12 Interface Authentication Path Fault alarm is available on
the RAC.
If the alarm is available, go to 5.
If the alarm is not available, go to 6.
5. Check whether the ALM-2291 A12 Interface Authentication Path Fault alarm is available on
PCFs that are configured with the connecting relationship with the AN-AAA.
If the alarm is available, rectify the fault by referring to the ALM-2291 A12 Interface
Authentication Path Fault alarm.
If the alarm is not available, go to 6.
6. Check whether the authentication mode configured for the AT is correct.

Trace the signaling over the air interface and check whether the authentication mode
configured for the AT is Challenge Handshake Authentication Protocol (CHAP).
If the authentication mode is CHAP, go to 7.
If the authentication mode is not CHAP, change the mode to CHAP and perform the test
again. For details, see manuals related to the AT.
To view the authentication mode, perform the following operations:

Check the ppp-lcp message on the reverse traffic channel (RTC) of the AT.
Double-click ppp-lcp message. Detailed information about the message is displayed.
Issue 01 (2014-05-31)

135
The value of authentication-protocol corresponds to the authentication mode of the AT.

Authentication-Protocol Value
Authentication Mode on the Terminal
0xc223
Challenge Handshake Authentication Protocol
0xc023
Password Authentication Protocol
7. Check whether the AT is authorized.

Check whether the A12 Access Reject message is included in the traced messages.
If A12 Access Reject message is included, have the ANAAA engineers check whether
the subscriber is properly defined.
If A12 Access Reject message is not included, go to 8.
8. Check whether the A12 Access Reject message is included in the traced messages.
If A12 Access Reject message is included, no further action is required.
If A12 Access Reject message is not included, collect relevant information according to
the following "Information Collection" and contact Huawei technical support.
----End
Issue 01 (2014-05-31)

136
Running logs of the access PMUO subsystem
Running logs of the access SMUO subsystem
Running logs of the PCF interface board
Issue 01 (2014-05-31)

137
11
11 Troubleshooting 1X Data Service Failures
Troubleshooting 1X Data Service

Failures
11.1 Introduction to 1X Data Service

During the CDMA2000 1X data service process, a subscriber may be in one of the following
states:
Active: An air traffic channel is available between the MS and the BTS. The MS and the
BTS can transmit data. Connections of the air interface, A8 interface, and A10 interface
are retained.
Dormant: No air traffic channel is available between the MS and the BTS. The PPP link
connection, however, exists between the MS and the PDSN. Connections of the air
interface and the A8 interface are released. The A10 connection is retained.
Null: No traffic channel or PPP link exists between the MS and the BTS. Connections of
the air interface, A8 interface, and A10 interface are released.
Description
During the data service process, the MS can switch from one state to another.
MS-Originated Data Call

Figure 11-1 shows the process of an MS-originated data call.
Issue 01 (2014-05-31)

139
Figure 11-1 Process of an MS-originated data call
The process of an MS-originated data call is described as follows:

a.
The MS sends an Origination Message on the access channel of the air interface to the
BSS.
b.
Upon receiving the message, the BSS sends a BS Ack Order to the MS.
c.
The BSS sends a CM Service Request to the MSC.
d.
The MSC sends an Assignment Request to the BSS, requesting allocation of radio
resources.
e.
The BSS sends an A9-Setup-A8 message to the PCF, requesting the setup of an A8
connection.
f.
The PCF sends an A11-Registration-Request message to the PDSN, requesting the setup
of an A10 connection.
g.
The PDSN accepts the request and sends an A11-Registration-Reply message to the
PCF.
h.
The PCF sends an A9-Connect-A8 message to the BSS. The A8 and A10 connections
are set up.
i.
The BSS sends an Extended Channel Assignment Message (ECAM) on the paging
channel of the air interface.
Issue 01 (2014-05-31)

140
j.
The MS sends the Traffic Channel Preamble (TCH Preamble) on the specified reverse
traffic channel.
k.
After detecting the reverse traffic channel, the BSS sends a BS Ack Order on the forward
traffic channel to the MS.
l.
In response, the MS sends an MS Ack Order on the reverse traffic channel and transmits
null traffic frames on the reverse traffic channel.
m.
The BSS sends a Service Connect Message or a Service Option Response Order to the
MS to specify the service configuration for the call.
n.
After receiving the message, the MS starts to process services according to the specified
service configuration and responds with the Service Connect Completion Message.
o.
After the radio traffic channel and the terrestrial link are set up and interconnected, the
BSS sends an Assignment Complete Message to the MSC.
p.
The MS negotiates with the PDSN to set up a PPP connection. For Mobile IP access
mode, the Mobile IP connection must be set up. The PPP messages and Mobile IP
messages are transmitted on the traffic channel.
q.
After the PPP connection is set up, the data service enters the connection state.
MS-Originated Data Service Release

Figure 11-2 shows the process of an MS-originated data service release.
Figure 11-2 Process of an MS-originated data service release
The process of an MS-originated data service release is described as follows:

a.
The MS sends a Release Order message on the dedicated control channel of the air
interface to the BSS.
b.
The BSS sends a Clear Request to the MSC.
c.
When releasing network resources, the MSC sends a Clear Command message to the
BSS.
d.
The BSS sends a Release Order message to the MS.
Issue 01 (2014-05-31)

141
e.
The BSS sends an A9-Release-A8 message to the PCF, requesting the release of the A8
connection.
f.
The PCF sends an A11-Registration-Request message to the PDSN, requesting the

release of the A10 connection.
g.
The PDSN sends an A11-Registration-Reply message to the PCF. The A10 connection is
released.
h.
The BSS sends an A9-Release-A8 Complete message to the PCF. The A8 connection is
released.
i.
The BSS sends a Clear Complete message to the MSC.
11.2 Troubleshooting 1X Data Call Failure

This section describes the troubleshooting process flow, and troubleshooting procedures for
data service call failures.
11.2.1 Messages are Not Tracked on the A9/A11 Interface

Data calls originated by an MS always fail. The A9/A11 interface is tracked on the Service
Maintenance System. Messages are not tracked.
Troubleshooting
Issue 01 (2014-05-31)

142

Start
Is
the call originated
through an MS?
No
Is
the call originated
through a wireless
modem?
No
Yes
Check the dail-up settings

of the MS
Yes
Yes
Are
the settings correct?
No
Correct the dial-up

settings of the MS
No
Correct the
configuration of the
wireless modem
Yes
Check the configuration of

the wireless modem
Is
the configuration
correct?
Make a test call
End
Procedure
1. Check the dial-up settings of the MS.
Use an MS to dial up and check whether the screen on the MS displays the information on the data
service.
If the MS does not display the information of the data service, check the dial-up settings of the MS.
Ensure that the port rate of the MS is consistent with that of the computer, that the port ID is correct, and
that the settings of dial-up parameters are correct.
2. Check the configuration of the wireless modem.
Use a wireless modem to dial up and observe the indicator on the wireless modem. If the indicator blinks
twice per second, you can infer that the wireless modem functions properly. If the indicator blinks fast,
you can infer that the wireless modem is faulty.
In addition, check whether the port and associated parameters are correct.
Make a data service call to check whether the fault is rectified.
Issue 01 (2014-05-31)

143
----End
11.2.2 Troubleshooting the Data Call Failure Due to Only the

Reverse Messages Received on the A11 Interface
Symptom
Data calls originated by an MS fail. On the Service Maintenance System, signaling tracing is
initiated on A9 and A11 interfaces. Both forward and reverse messages can be tracked on the
A9 interface. Only reverse messages from the PCF to the PDSN can be tracked on the A11
interface.
Cause
The physical connection between the A10/A11 interface board and the PDSN is faulty.
The route from the A10/A11 interface board to the PDSN is not configured properly.
Analysis
Check the physical connection between the A10/A11 interface board and the PDSN.
Check the route from the A10/A11 interface board to the PDSN.
Check the RP interface tracing message on the PDSN.
1. Run the LST ETHLNK command to check whether the physical connection between the
A10/A11 interface board and the PDSN is normal.
If the physical connection is normal, go to 2.
If the physical connection is faulty, correct the connection.
2. Run the LST IPBRDROUTE command to check whether the route from the A10/A11
interface board to the PDSN is configured.
If the route is configured, go to 3.
If the route is not configured, run the ADD IPBRDROUTE command to add a route
from the A10/A11 interface board to the PDSN.
3. Check whether the PDSN RP interface signaling tracing is normal.

Track the RP interface message on the PDSN. Observe whether the PDSN receives the A11
message from the PCF. If the PDSN does not receive the A11 message, check whether the
data configuration of the transport layer between the PDSN and the A10/A11 interface board
is correct.
If the data configuration is correct, contact Huawei technical support.
If the data configuration is not correct, ask PDSN engineers to correct the errors on the
PDSN.
Issue 01 (2014-05-31)

144
----End
11.2.3 Troubleshooting the Release of Data Calls Right After

Dial-Up Connection
Symptom
Data calls originated by an MS are released several seconds after the dial-up connection is set
up. On the Service Maintenance System, signaling tracing is initiated on the A11 interface.
Both forward and reverse messages can be tracked.
Cause
The configuration of the PDSN and the RAC is incorrect.
The configuration of the PPP or AAA server is incorrect.
Analysis
Check the A11 Registration Reply message.
Check the PPP negotiation procedure.
1. Check the cause value and code field of the A11-Registration-Reply message to see whether
the failure is caused by not consistent configuration between the PCF and the PDSN.
The cause value 0x00 indicates the A11 access succeeded. Other cause values indicate that the
A11 access failed.
0x00: Accepted. A11 access succeeded.
0x83: Mobile-node-failed-authentication. A11 access failed.
The failure is caused normally by not consistent configuration between the PCF and the
PDSN.
If the cause value is 0x00, go to 2.
If the cause value is not 0x00, modify the configuration.
Issue 01 (2014-05-31)

145
2. Track PPP messages on the PDSN server, and check whether PPP negotiation is successful.
As this operation involves coordination with the PDSN, contact PDSN engineers for
assistance.
If PPP negotiation is successful, go to 3.
If PPP negotiation fails, resolve the problem.

A PPP negotiation failure is generally caused by an authentication failure. If authentication fails due to
incorrect user name or password, ask AAA server engineers to correct the user name and password.
3. Check whether the configuration of the PPP or AAA server is correct.
If the configuration is correct, contact Huawei technical support.
If the parameter configuration is not correct, check whether user name and password on
the terminal is consistent with that set on the AAA server. If they are not consistent,
obtain the user name and password from AAA server engineers and correct the user
name and password on the terminal. As this step involves operations on the AAA server,
contact AAA server engineers for assistance.
----End
11.3 Troubleshooting 1X Data Service Handoff Failure

Symptom
Handoff of data services fails.
Cause
The radio environment is poor.
Analysis
Check the radio environment.
Check the matching relationship between protocol versions of the PCF and the PDSN.
1. Check whether the radio environment is good.
If data calls are successful, the A11 interface link is functional and handoff failure may be
caused by poor radio environment. You can test the quality of the radio environment by
placing voices calls.
If the radio environment is poor, see the method of solving the voice call handoff problem to
locate and resolve the problem.
----End
Issue 01 (2014-05-31)

146
11.4 Troubleshooting Low Transmission Rate for 1X Data

Service
Symptom
MSs can access the 1X network to perform data services, but the transmission rate is low to
even 0 during the service procedure.
Cause
Failures occur over the air interface.
The transmission over the Abis interface is abnormal.
Resources on the BTS are not sufficient.
The transmission from the PCF to the PDSN is abnormal.
Analysis
Check failures over the air interface.
Check whether resources on the BTS and RAC are sufficient.
Check whether transmission over the Abis interface is normal.
Check whether transmission from the PCF to the PDSN is normal.
On the Service Maintenance System, initiate signaling tracing, traffic tracing of a single user,
and QXDM tracing over the air interface.
1. During QXDM tracing, check whether the frame error rate (FER) over the air interface is high.
The FER of 1X data services should be lower than 5%.
If the FER over the air interface is high, go to 2.
If the FER over the air interface is not high, proceed to 4.
2. Check whether alarms related to error bits are generated during transmission over the Abis
interface.
If the alarms are generated, clear the error bits generated during the transmission over the
Abis interface.
If the alarms are not generated, go to 3.
3. Check whether clock-related alarms are generated on the BTS.
If the alarms are generated, clear the clock-related alarms on the BTS.
If the alarms are not generated, go to 4.
4. During QXDM tracing, check whether the Ec/Io value is within normal range. Generally, the
Ec/Io value should be greater than 6.5 dB.
Issue 01 (2014-05-31)
If the Ec/Io value is within normal range, go to 5.

147
If the Ec/Io value is not within normal range, contact network optimization personnel to
optimization the network.
5. Analyze the signaling on the Service Maintenance System of the RAC. Review the cause
value, carried in the Abis-Burst Response message sent by the BTS during SCH application,
to check whether the resource application from the RAC was approved.
If the radio resources on the BTS are sufficient, the resource application from the RAC is
approved. That is, the cause value is 0x0. If the resources on the BTS are not sufficient, the
cause value is 0x4. For example, CE resources are not sufficient. The cause value can be used
to determine why the BTS rejects the SCH application from the RAC.
If resources on the BTS are sufficient, go to 6.
If resources on the BTS are not sufficient, contact BTS engineers for assistance.
6. After traffic tracing of the single user, check whether the disorder of generic routing
encapsulation (GRE) and packet loss of the GRE are included in the reports pertaining to
FG1X and GOUX on the PCF. If these are included in the reports, it indicates packet loss
occurred during transmission from the PCF to the PDSN.
If the disorder and the packet loss of the GRE are included in the reports, check the
transmission from the PCF to the PDSN. The problem may be caused by an incorrect
port mode of a transmission device such as a switch or router, or incorrect MTU
configuration of the port or equivalent route generated on the transmission network.
If the disorder and the packet loss of the GRE are not included in the reports, contact
Huawei technical support.
----End
Issue 01 (2014-05-31)

148
Logs of the access SPUO subsystem
Running logs of the BTS
Issue 01 (2014-05-31)

149
12
12 Troubleshooting EV-DO Data Service Failures
Troubleshooting EV-DO Data Service

Failures
12.1 Introduction to EV-DO Services

The EV-DO system consists of radio access network and core networks Figure 12-1 shows the
EV-DO system structure.
Figure 12-1 EV-DO system structure
AT
Air
Interface
Radio Access Network

A8
Source AN
A9
PCF
Core Network
A10
A11
PDSN/FA
IPSec
HA
Radius
A12
A18
ANAAA
AAA
IPSec
A13/A16/A17
Target AN
The radio access network consists of the Access Network (AN) and function modules
including the Packet Control Function (PCF) and Access Network-Authentication,
Accounting, Authorization Server (AN-AAA). The AN is responsible for sending and
receiving messages from the BTS, and controlling the BTS. The PCF is responsible for setting
up the connection between the A8 and A10 interfaces, and choosing the Packet Data Service
Node (PDSN). The AN-AAA is responsible for access authentication to complete the
algorithms and related parameters.
The core network consists of the PDSN and function modules such as AAA. The PDSN is
responsible for the setup, management, and release of the packet data session. The AAA is
responsible for the registration, authentication, and charging related to users.
In the case of mobile IP, the core network also includes the Foreign Agent (FA) and the Home
Agent (HA). As the foreign agent of the mobile IP technology, the FA is responsible for
registering, charging, and forwarding subscriber data. The FA and the PDSN share the same
Issue 01 (2014-05-31)

151
physical module. As the starting point of the IPSec tunnel, the HA is used to assign IP
addresses, select routes, and encrypt data when subscribers are roaming.
The interfaces of the EV-DO system are as follows:
A8/A9: internal interfaces between the AN and the PCF. The A8 interface is used to
carry service data, and the A9 interface is used to carry signaling.
A10/A11: interfaces between the PCF and the PDSN, also called R-P interface. The A10
interface is used to carry data, and the A11 interface is used to carry signaling.
A12: an interface between the AN and the AN-AAA. It is used to carry information
regarding access authentication of subscribers.
A13: an interface used to carry call transfer signaling when high-speed data services
between ANs are in the dormant state.
A16: an interface used to carry call transfer signaling when high-speed data services
between ANs are in the active state and hard handoff is performed.
A17: an interface used to carry soft handoff signaling when high-speed data services
between ANs are in the active state.
A18: an interface used to carry transmission of soft handoff data when high-speed data
services between ANs are in the active state.
12.2 Troubleshooting EV-DO UATI Assignment Failure

Symptom
The AT fails to access the EV-DO network, and the HRPD session cannot be set up. The
Unicast Access Terminal Identifier (UATI) assignment fails according to the signaling
analysis.
Cause
The transmission of HardwareID between the AT and the AN fails.
The transmission of UATI between the AT and the AN fails.
Analysis
Trace the message on the subscriber interface of the EV-DO AT whose UATI assignment has
failed, and analyze the tracing code stream to determine the abnormal point of information
exchange between the AT and the AN. Generally, the information exchange failure is caused
by the poor radio environment on the air interface.
If transmission of HardwareID between the AT and the AN has failed, see 1 through 7.
If transmission of UATI between the AT and the AN has failed, see 8 through 13.
On the Service Maintenance System, initiate message tracing on the subscriber interface and
QXDM tracing on the EV-DO AT.
Issue 01 (2014-05-31)

152
1. Check whether the UATI Request message is included in messages traced on the subscriber
interface. For more information regarding tracing, see the section "Tracing Messages over the
BSS Interface" in the CBSS LMT User Guide.
If the UATI Request message is included, go to 2.
If the message is not included, check whether the AT finds the network and whether the
configuration of the AT is correct.
2. Check whether the HardwareID Request message is included in messages traced on the
subscriber interface.
If the HardwareID Request message is included, go to 3.
If the message is not included, contact Huawei technical support.
3. Check whether the HardwareID Response message is included in messages traced on the
If the HardwareID Response message is included, proceed to 8.
If the message is not included, go to 4.
4. Check whether the HardwareID Request message is included in messages traced by the
QXDM.
If the HardwareID Response message is included, proceed to 6.
5. The AN sends the HardwareID Request message, but the AT fails to receive the message. The
message may be lost during transmission over the air interface. You are advised to perform
the test at a new place where the radio environment on the air interface is good, and check
whether the symptoms are the same as those described in 4.
If symptoms remain the same, contact Huawei technical support.
If symptoms are different, refer to related instructions to re-locate the fault.
6. Check whether the HardwareID Response message is included in messages traced by the
QXDM.
If the HardwareID Response message is included, go to 7.
If the message is not included, the AT has failed to respond with the HardwareID
Response message after receiving the HardwareID Request message. This indicates that
the configuration or message processing of the AT is faulty. Contact the AT manufacturer
to examine the problem, or replace the faulty AT with a new one to perform the test
again.
7. The AT sends the HardwareID Response message, but the AN fails to receive the message.
The message may be lost during the transmission over the air interface. You are advised to
perform the test at a new place where the radio environment on the air interface is good, and
check whether the symptoms are the same as those described in 6.
If symptoms are different, refer to the related instructions to re-locate the fault.
8. Check whether the UATI Assignment message is included in messages traced on the
If the UATI Assignment message is included, go to 9.
If the message is not included, contact Huawei technical support.
Issue 01 (2014-05-31)

153
9. Check whether the UATI Complete message is included in messages traced on the subscriber
interface.
If the UATI Complete message is included, the UATI assignment has succeeded. No
10. Check whether the UATI Assignment message is included in messages traced by the QXDM.
If the UATI Assignment message is included, proceed to 12.
11. The AN sends the UATI Assignment message, but the AT fails to receive the message. The
message may be lost during the transmission over the air interface. You are advised to
12. Check whether the UATI Complete message is included in messages traced by the QXDM.
If the UATI Complete message is included, go to 13.
If the message is not included, the AT fails to respond with the UATI Complete message
after receiving the UATI Request message. This indicates that the configuration or
message processing of the AT is faulty. Contact the AT manufacturer to examine the
problem, or replace the faulty AT with a new one.
13. The AT sends the UATI Complete message, but the AN fails to receive the message. The
message may be lost during the transmission over the air interface. You are advised to
----End
Causes of the detected fault and troubleshooting methods
Traffic statistics file of the previous three days
Issue 01 (2014-05-31)

154
12.3 Troubleshooting EV-DO Configuration Negotiation

Failure
Symptom
The AT fails to access the EV-DO network, and the HRPD session cannot be set up. The
configuration negotiation between the AT and the AN fails according to the signaling analysis.
Cause
Trace the message on the subscriber interface of the EV-DO AT that has failed to access the
network, and analyze the tracing code stream. Common causes of the fault are as follows:
The negotiation of protocol types and configuration parameters between the AT and the
AN has failed.
The configuration negotiation messages are lost due to the poor radio environment on the
air interface.
Analysis
The configuration negotiation message includes request and response messages, which are
presented in pairs. After sending the negotiation request message, the AT or AN must receive
the negotiation response message within two seconds. Otherwise, the configuration
negotiation fails. The configuration negotiation ends with the Configuration Complete
message. To locate the fault, perform the following operations:
Check whether the negotiation request message and the negotiation response message
are presented in pairs. For details, see 1 to 2
Determine why the configuration negotiation messages are not presented in pairs. For
details, see 3 to 4.
Check the reason contained in the Session Close message after configuration negotiation
fails. For details, see 5.
On the Service Maintenance System, initiate message tracing on the subscriber interface and
QXDM tracing on the EV-DO AT.
1. Check whether the negotiation request message and the negotiation response message are
presented in pairs in messages traced on the subscriber interface.
If messages are presented in pairs, proceed to 4.
If messages are not presented in pairs, go to 2.
2. Check whether the negotiation request message and the negotiation response message are
included in messages traced by the QXDM, but excluded in messages traced on the subscriber
interface.
Issue 01 (2014-05-31)

155
If the negotiation request message and the negotiation response message are included in
messages traced by the QXDM, but excluded in messages traced on the subscriber
interface, go to 3.
If the negotiation request message and the negotiation response message are excluded in
messages traced by the QXDM, and excluded in messages traced on the subscriber
interface, go to 4.
3. The negotiation request message and the negotiation response message are lost during the
transmission over the air interface. You are advised to perform the test again at a new place
where the radio environment on the air interface is good, and check whether the symptoms are
the same as those described in 2.
4. Check whether the negotiation response message is excluded in messages traced by the
QXDM and messages traced on the subscriber interface.
If the negotiation response message is excluded, perform the following operations. First,
if the AT fails to send the negotiation response message after receiving the negotiation
request message, replace the faulty AT with a new one and perform the test again, or
contact the AT manufacturer to examine the problem. If the AN fails to send the
negotiation response message after receiving the negotiation request message, contact
If the negotiation response message is included, go to 5.
5. View the cause contained in the Session Close message in messages traced on the subscriber
interface, and rectify the fault based on the cause. Then, check whether the fault is rectified.
If the fault is rectified, no further action is required.
If the fault is not rectified, contact Huawei technical support.
----End
Table 12-1 lists the cause values contained in the Session Close message as specified by the
protocol.
Table 12-1 Encoding of CloseReason field
Field Value
Meaning
MoreInfoLen
MoreInfo
0x00
Normal Close
N/A
0x01
Close Reply
N/A
0x02
Protocol Error
N/A
0x03
Protocol Configuration Failure
Followed by "Type" in
Subtype
0x04
Protocol Negotiation Error
variable
0 or multiple "Type" in
Subtype, which is
followed by incorrect
attributes
0x05
Session Configuration Failure
N/A
Issue 01 (2014-05-31)

156
Field Value
Meaning
MoreInfoLen
MoreInfo
0x06
Session Lost
N/A
0x07
Session Unreachable
N/A
0x08
All session resources busy
N/A
All other values are reserved
MoreInfoLen: Length in octets of the MoreInfo field.

MoreInfo: Additional information pertaining to the closure. The format of this field is
determined by the particular close reason.
12.4 Troubleshooting EV-DO Connection Setup Failure

Symptom
The AT fails to access the EV-DO network. The EV-DO Connection Setup Failure according
to the signaling analysis.
Cause
Poor radio environment on the air interface
CEs are not sufficient.
The Abis interface link is faulty.
Faulty link between the PCF and PDSN
Issue 01 (2014-05-31)

157
Analysis
According to signaling tracing process on the Service Maintenance System, identify call
failure points and analyze causes for the failures.
1. Check whether the radio environment is poor. Contact network optimization personnel to
check that the radio environment meets the following requirements. The Ec/Io value must
be over 10 dB. The RSSI value must be in the range of 116.0 dBm to 93.0 dBm.
If normal, go to 2.
If abnormal, contact network optimization personnel to improve the radio environment.
2. Check the configuration and usage of EV-DO CEs.

a.
If the system uses a BTS-level license, run the DSP CBTSLICENSE command to query
the number of EV-DO CEs configured for the access BTS and the number of EV-DO
CEs already in use. In addition, check whether the number of EV-DO CEs is sufficient.
If the number of EV-DO CEs is sufficient, go to 3.
If the number of EV-DO CEs is not sufficient, add EV-DO CEs to the BTS.
b.
If the system uses a BSC-level license, run the DSP BSCLICENSECFG command to
query the number of EV-DO CEs configured on the BSC and EV-DO CEs already in use.
Then, check whether the number of EV-DO CEs is sufficient.
If the number of EV-DO CEs is sufficient, go to 3.
If the number of EV-DO CEs is insufficient, apply for a new license that authorizes
more EV-DO CEs. No further action is required.
3. Check whether the BSC and BTS configurations are consistent by running the CHK
CBTSIFCFG command:
If configuration is consistent, go to 4.
If configuration is not consistent, modify the items as indicated by the system.
4. Check whether an alarm related to the CECM board is generated on the Alarm Management
System.
5. Check whether an alarm related to the Abis interface link of the access BTS is generated on
6. Check whether an alarm related to the A10A11 interface link is generated on the Alarm
Management System.
If such an alarm is not generated, contact Huawei technical support.
----End
Issue 01 (2014-05-31)

158
Configuration script of the BSC
Running logs of the access PCUO subsystem
Localization Information
12.5 Troubleshooting Low Forward Rate for EV-DO

Services
Symptom
After the AT accesses the EV-DO network normally, the forward rate is constant but low
during the service procedure.
Cause
The quality of the air interface is poor.
The bandwidth of the Abis link is not sufficient.
Problems occur between the PCF and the PDSN.
The AT driver or configuration of the computer is abnormal.
Analysis
The constant but low forward rate is generally caused by constrained bandwidth in the traffic
channel. Therefore, review the following items in sequence.
Check the air interface.
Review the bandwidth of the Abis link.
Check the upper-layer modules, such as the SDU, PCF, A10 link, and PDSN.
Check the AT driver and the configuration of the computer.
The BSS performs the following operations to provide overall reference for EV-DO rate
analysis:
Trace flows of single EV-DO subscribers.
Records the information about the EC board, Abis interface board, APUDc board, DPUDb
board, and PCF board.
Issue 01 (2014-05-31)

159
Trace QXDM.
Capture packets on SDU boards and network side.
1. Observe the downlink DRC value on the air interface from the report of the EC board,
generated by the traffic tracing of the single user, to check whether the radio environment on
the air interface is poor. The poor radio environment on the air interface affects the rate.
If the radio environment on the air interface is poor, contact network optimization
personnel to optimize the network.
If the radio environment on the air interface is good, go to 2.
2. To ensure the download rate of EV-DO services, a single EV-DO Rev. A carrier sector should
be configured with two E1 cables, and configured with the bandwidth of 3.6 MHz in FE mode.
You are advised to analyze the bandwidth configuration of the Abis link and related alarms to
check whether the not sufficient bandwidth of the Abis link is caused by configuration or link
fault.
If the not sufficient bandwidth is caused by configuration or link fault, reconfigure the
bandwidth of the Abis link or rectify the fault.
If the not sufficient bandwidth is not caused by the configuration or link fault, go to 3.
3. Generally, the FE networking or the GE networking is used between the PCF and the PDSN
and the link bandwidth is sufficient. In some cases, the E1 transmission network may be used
between the PCF and the PDSN, or the FE networking or the GE networking is used between
the PCF and the PDSN but the bandwidth is constrained. In either case, the transmission
bandwidth between the PCF and the PDSN is not sufficient. In such situations, a computer
can be connected to the mirror port of the switch at the exit of the PCF. The IP address of the
computer should be configured on the same network segment as that of the PCF. Then, the
computer can perform the download test to check whether the download rate cannot reach 10
Mbit/s.
If the download rate cannot reach 10 Mbit/s, expand the bandwidth of transmission links
between the PCF and the PDSN.
If the download rate can reach 10 Mbit/s, go to 4.
4. Check whether TCP MTU (Max Transfer Unit) and TcpWindowSize are set correctly. You
are advised to set TCP MTU (Max Transfer Unit) to 1460 bytes, and TcpWindowSize to
65535 bytes.
If the values are incorrect, modify the parameters.
If the values are set correctly, go to 5.
5. Check whether the AT driver is faulty.
If the AT driver is faulty, replace it or replace the AT to continue the test.
If the AT driver is normal, contact Huawei technical support.
----End
Issue 01 (2014-05-31)

160
Results of the traffic tracing of a single user
Results of the QXDM tracing
12.6 Troubleshooting EV-DO Forward Rate Fluctuation

Symptom
The AT accesses the EV-DO network normally, but the forward rate fluctuates during the
service procedure.
Cause
The driver of the AT or configuration of the computer are abnormal.
Analysis
The forward rate fluctuation is generally caused by the packet loss in the traffic channel. In
the case of TCP services, both the forward packet loss and the reverse packet loss may lead to
the rate fluctuation. Therefore, review the following items in sequence.
Check upper-layer modules, such as the SDU, PCF, A10 link, and PDSN.
Check the driver of the terminal or the configuration of the computer.
analysis:
Records the information about the EC board, Abis interface board, APUDc board,
DPUDb board, and PCF board.
Trace QXDM.
Issue 01 (2014-05-31)

161
generated by the traffic tracing of the single user, to check whether the radio environment on
the air interface is fluctuated. The fluctuation of the radio environment on the air interface
leads to the rate fluctuation.
If the radio environment on the air interface fluctuates, contact network optimization
If the radio environment on the air interface does not fluctuate, go to 2.
2. In the report of the EC board generated by traffic tracing of the single user, observe the
sending of downlink forward data to check whether the branches frequently change. The
frequent change in the main branch affects the forward rate.
If the branches experience frequent change, contact network optimization personnel to

optimize the network.
If the branches do not experience frequent change, go to 3.
3. Check whether the uplink or downlink packet loss is present in the RAC interface board
report generated after the single user tracing.
If packet loss is present, contact Huawei technical support.
If packet loss is not present, go to 4.
4. In the report of the EC board generated by traffic tracing of the single user, check whether
there are a large number of downlink RLP packet loss and downlink Abis packet error. The
RLP packet loss is caused by the Abis packet loss, or Abis packet disorder. In normal cases,
the RLP packet loss rate is lower than 1%, and the number of Abis packet errors is low or
even none. A large proportion of Abis packet error indicates that Abis link is faulty.
If there are a large number of downlink RLP packet loss and downlink Abis packet errors,
check the Abis transmission link.
If there are not a large number of downlink RLP packet loss and downlink Abis packet
errors, go to 5.
5. In the branch report of the APUDc or DPUDb generated by traffic tracing of the single user,
check whether the forward delay or reverse delay is long. The long delay affects the forward
rate.
If forward or reverse delay is long, check the Abis transmission link.
If forward or reverse delay is not long, go to 6
6. In the call report of the APUDc or DPUDb generated by traffic tracing of the single user,
check whether any bytes are lost over the A8 interface.
If any bytes are lost, contact Huawei technical support.
If any bytes not lost, go to 7.
7. Check whether the disorder and the packet loss of the GRE are included in the reports of the
FG1X and the GOUX on the PCF generated by traffic tracing of the single user. If the
disorder and packet loss of the GRE are included in the reports, it indicates packet loss
occurred during the transmission from the PCF to the PDSN.
Issue 01 (2014-05-31)
If the disorder and packet loss of the GRE are included in the reports, check the
transmission from the PCF to the PDSN. Similar problems may be caused by incorrect
port mode of the transmission device (such as switch and router) between the PCF and

162
the PDSN, incorrect MTU parameter configuration of the port, and equivalent route
generated on the transmission network.
If the disorder and packet loss of the GRE are not included in the reports, contact
----End
12.7 Troubleshooting Low Reverse Rate for EV-DO

Services
Symptom
The AT accesses the EV-DO network normally, but the reverse rate is low during the service
procedure.
Cause
The parameter configuration of the RAC is incorrect.
The AT driver or configuration of the computer is abnormal.
Analysis
Check the upper-layer modules, such as the SDU, PCF, A10 link, and PDSN.
Issue 01 (2014-05-31)

163
Check the AT driver or the configuration of the computer.
analysis:
Records the information about the EC board, Abis interface board, APUDc board,
DPUDb board, and PCF board,
Trace QXDM.
1. In the radio resource check report of the BTS, check whether the value of RSSI is abnormal.
Generally, the value of RSSI should be smaller than 100 dB.
If the value of RSSI is abnormal, contact network optimization personnel to resolve the
RSSI problem.
If the value is normal, go to 2.
generated by traffic tracing of the single user, to check whether the radio environment on the
air interface is poor. Although DRC is a forward value, it can be used as reference for the
reverse rate.
If the radio environment on the air interface is poor, contact network optimization
If the radio environment on the air interface is good, go to 3.
3. Perform the forward rate test for EV-DO services to check whether the forward rate can reach
the normal value.
If the forward rate can reach the normal value, go to 4.
If the forward rate cannot reach the normal value, check the problem as specified in 12.6
Troubleshooting EV-DO Forward Rate Fluctuation.
4. Check whether the RAC T2P parameter is set correctly. If the default value of the T2P
parameter on the RAC is used, the reverse rate for EV-DO services can reach 600 Kbit/s. To
reach a higher reverse rate, you are advised to modify the value of the T2P parameter.
If the RAC T2P parameter is set incorrectly, modify the value.
If the value is correct, go to 5.
5. Check whether TCP MTU (Max Transfer Unit) and TcpWindowSize are set correctly on
the computer. You are advised to set TCP MTU (Max Transfer Unit) to 1460 bytes, and
TcpWindowSize to 65535 bytes.
If the values are incorrectly set, modify the parameters.
If the values are correctly set, go to 6.
6. Check whether the AT driver is faulty.
If the AT driver is faulty, replace it or replace the AT to continue the test.
If the AT driver is normal, contact Huawei technical support.
----End
Issue 01 (2014-05-31)

164
Monitoring result of the radio resources on the BTS
Issue 01 (2014-05-31)

165
Issue 01 (2014-05-31)

167
13
13 Troubleshooting License Failures
Troubleshooting License Failures
13.1 Introduction to License

A license helps a network operator to control network capacity, satisfy requirements of
different users, and provide paid enhancement functions and services to subscribers. The
license is encrypted in a file, and corresponds to equipment of subscribers. The network
operator can utilize the desired capacity of equipment after the license file is decrypted. If the
decryption fails, only the default minimum configuration can be used.
The following outlines the steps involved in obtaining a license:
a.
The network operator selects an Equipment Serial Number (ESN).
b.
The license management center generates a license file according to the contract with the
network operator.
c.
The license management center delivers the license file to the network operator.
d.
The network operator powers on the equipment and loads the license file. If the license
file needs to be updated, the network operator can forcibly load the license file to the
related NE by using the FTP protocol.
e.
The PMUO subsystem on the APUOc verifies the validity of the license file.
f.
If the control mode of the license is at the BTS level, the PMUO subsystem sends the
resolved data to each BTS through the SPUO subsystem.
g.
If the control mode of the license is at the RAC level, the PMUO subsystem
automatically allocates CE resources to each SPUO subsystem.
13.2 Troubleshooting Failure to Load License

Symptom
The network operator fails to power on the equipment to load the license file, or the network
operator fails to forcibly load the license file.
Cause
According to license loading and alarm information, common causes of the fault are as
follows:
Issue 01 (2014-05-31)

169
The license file is unavailable in the loading directory.
The communication between the board and the BAM is abnormal.
The license file is abnormal.
Analysis
You can locate the fault by performing the following operations:
Check whether the license file is available.
Check whether the license file is normal.
Check whether the ESN in the license file matches the ESN of the RAC.
Check whether the license file has expired the 60-day trial period.
Check whether the control mode of the license is normal.
1. Check whether the license file is available in the loading directory on the BAM.
Check whether the raclicense.dat file is available in the directory ..\cdma2000\LoadDATA
on the BAM.
If the file is available, go to 2.
If the file is unavailable, go to 8.
2. Check whether the transmission between the BAM and the host is faulty.
If the cause displayed on the loading interface shows the file transmission has failed, the
transmission link between the BAM and the host may be faulty. For details about the
transmission fault between the BAM and the host, see Chapter 8 .
If the transmission link is faulty, resolve the fault. Then, go to 9.
If the transmission link is not faulty, go to 3.
3. Check whether the cause for failing to load the license file is a decoding failure. That is, the
license file is abnormal.
If the cause is a decoding failure, go to 4.
If the cause is not a decoding failure, go to 5.
4. Restore the license file. Then, go to 9.

If the decoding of the license file fails, it indicates the license file has been damaged. Run the
ULD LICENSE command to upload the license file stored in the flash memory of the
APUOc to the BAM, and then rename the file raclicense.dat. By default, the uploaded
license file is stored in the directory ..\cdma2000\license and is named license.ffss. In the
name license.ffss, ff represents the subrack number and ss represents the slot number.
5. Check whether the license file has expired.
If the file has expired, go to 8.
If the file has not expired, go to 6.
6. Check whether the control mode of the license is invalid.

The value of the LQC1LICCCR01 field in the license file represents the control mode. In
normal cases, the value of this field is 1 or 2.
Issue 01 (2014-05-31)

170
If the value is invalid, go to 8.
If the value is valid, go to 7.
7. Check whether the equipment ESN matches the ESN specified in the license file.
The equipment ESN is written to the flash memory of the APUOc. The license file is
requested through the ESNs of the active and standby APUOc boards. Therefore, the
requested license file is only available for the or APUOc. If the APUOc is replaced, the
equipment ESN does not match that specified in the license file. As the system runs in trial
mode for 60 days, the license becomes invalid if the faults are not rectified within the trial
period.
If the equipment ESN matches that specified in the license file, contact Huawei technical
support.
If the equipment ESN does not match that specified in the license file, go to 8.
8. Apply for a new license file to replace the original license file. Then, go to 9.
For details about how to apply for a license file, see the Commercial License Application
Process.
9. Run the LOD LICENSE command to forcibly load the license file. Then, check whether the
loading is successful.
If loading is successful, no further action is required.
If loading is not successful, contact Huawei technical support.
----End
Running logs of the PMUO subsystem
Original license file
Query information about the license file
Software log on the BAM
Issue 01 (2014-05-31)

171
13.3 Troubleshooting Call Access Failure in the RAC Due

to Restriction on License
Symptom
Calls in a RAC fail to access the network, although RAC boards are functional. A "System
License Invalid" alarm is displayed on the Alarm Management System.
Cause
According to the license alarm information, common causes of the fault are as follows:
The license file is invalid.
The configuration exceeds the restriction on license.
Analysis
Load the license file. Check whether the operation fails.
Analyze the license file. Check whether the operation fails.
Check whether the license file is invalid.
Check whether the RAC configuration exceeds the restriction on the license.
1. Query the cause of the System License Invalid alarm.
Start the Alarm Management System from an LMT Query the historical alarms. Select the
System License Invalid alarm, and double-click it to view the cause of the alarm.
2. Check whether the license file fails to be loaded.
If the license fails to be loaded, go to 3.
If it loads successfully, go to 5.
3. Check whether the license file is available in the loading directory on the BAM.
Check whether the raclicense.dat file is available in the directory ..\cdma2000\Loaddata on
the BAM.
If the license is available in the directory, go to 4.
If it is not available in the directory, go to 5.
4. Check whether the transmission between the BAM and the host is faulty.
If the cause displayed on the loading interface shows that the file transmission fails, the
transmission link between the host and the BAM may be faulty. For details about transmission
fault between the BAM and the host, see chapter 16 "Troubleshooting OM Failures."
If the transmission is faulty, resolve the fault. Then, go to 9.
If it is not faulty, go to 5.
5. Check whether the license file failed to be decoded.
Issue 01 (2014-05-31)

172
If the license fail failed to be decoded, go to 6.
If it did not fail to be decoded, go to 7.
6. Restore the license file. Then, go to 13.

If the decoding of the license file fails, it indicates the license file has been damaged. Run the
ULD LICENSE command to upload the license file stored in the flash memory of the
APUOc to the BAM, and then rename the file raclicense.dat. By default, the uploaded
license file is stored in the directory ..\cdma2000\license and is named license.ffss. In the
name license.ffss, ff represents the subrack number and ss represents the slot number.
7. Check whether the license file has expired.
If the license has expired, go to 12.
If it has not expired, go to 8.
8. Check whether the license has entered the trial period.
If the license has entered the trial period, go to 12.
If it has not entered the trial period, go to 9.
9. Check whether the equipment ESN matches the ESN specified in the license file.
The equipment ESN is written to the flash memory of the APUOc. The license file is
requested through the ESNs of the active and standby APUOc boards. Therefore, the
requested license file is only available for the APUOc. If the APUOc is replaced, the
equipment ESN does not match that specified in the license file. As the system runs in trial
mode for 60 days, the license becomes invalid if the faults are not rectified within the trial
period
If the equipment ESN matches the license file, go to 10.
If it does not match, go to 12.
10. Check whether the number of configured carriers exceeds the specifications. That is, check
whether the number of configured carriers exceeds the license restriction.
If the number of configured carriers exceeds the license restriction, go to 11.
If it does not exceed the license restriction, contact Huawei technical support.
11. Check whether services are restored after redundant carriers are deleted.
On the LMT, run the RMV CDMACH command to delete carriers. Ensure that the number of
configured carriers is within the restriction on the license file. In addition, run the RMV
CBTSSECTORCARRIER command to remove carriers in sectors of a BTS, ensuring that
the carrier configuration on the BTS is the same as that on the RAC.
If services are restored, no further action is required.
If services are not restored, contact Huawei technical support.
12. Apply for a new license file to replace the original license file. Then, go to 13.
For details about how to apply for a license file, see the Commercial License Application
Process
13. Run the LOD LICENSE command to forcibly load the license file and check whether the
loading is successful.
If the loading is successful, no further action is required.
If the loading is unsuccessful, contact Huawei technical support.
Issue 01 (2014-05-31)

173
----End
13.1 Troubleshooting Call Access Failure in a Single

Module Due to Restriction on License
Symptom
Calls in a SPUO subsystem fail to access the network, although other SPUO subsystems and
boards of the RAC are functional. The control mode of the license is at the RAC level.
Cause
The SPUO subsystem works abnormally.
Analysis
Switch over or reset the APUOc.
1. Switch over or reset the APUOc
switch over the APUOc, or run the RST BRD command to reset it. You may also right-click
on the equipment panel on the Service Maintenance System, and then select Start Manual
Switch Over or Reset Board.
Check whether services are restored after the APUOc is reset.
Issue 01 (2014-05-31)

174
If services are restored, no further action is required.
If services are not restored, contact Huawei technical support.
---End
Information about history alarms
Running logs of the PMU subsystem
Software logs on the BAM
13.2 Troubleshooting Call Access Failure in a Single BTS

Due to Restriction on License
Symptom
Calls in a BTS fail to access the network, although other BTSs and boards of the RAC are
functional. The control mode of the license is at the BTS level
Cause
The reverse CE resource configuration of the BTS is abnormal.
Analysis
Check whether the reverse CE resource configuration of the BTS is abnormal.
1. Run the following command to query the reverse CE resource configuration of the BTS.
Check whether the value of 1X Reverse CE Number and EV-DO Reverse CE Number is
set to 0, or excessively small.
Issue 01 (2014-05-31)

175
If the value is 0 or excessively small, go to 2.
If the value is not 0 or excessively small, contact Huawei technical support.
2. Modify the reverse CE resource configuration of the BTS, and check whether the fault is
rectified.
On the Service Maintenance System, run the MOD RACBTSINF command to modify the
reverse CE resource configuration of the BTS.
If the fault is not rectified, contact Huawei technical support.
----End
Software logs on the BAM
Running logs of the BTS
Issue 01 (2014-05-31)

176
14
14 Troubleshooting Clock Failures
Troubleshooting Clock Failures
14.1 Introduction to RAC Clock System

14.1.1 Background Information for the RAC Clock System
The RAC system requires two types of synchronization:
Transmission synchronization, which, in a narrow sense, refers to clock synchronization.
Time synchronization, which is also called radio synchronization.
Transmission synchronization uses the reference of the digital synchronization network to

realize the synchronous sampling and synchronous transmission through the clock
synchronization of the entire RAC.
Time synchronization provides the time synchronization function within the RAC by
synchronizing time within the entire RAC.
From the aspect of the transmission synchronization, the RAC is equal to the local exchange
equipment in the radio network, and requires the level-3 clock. Currently, the hardware can
satisfy the requirements of the level-2 clock but the software algorithm can only satisfy the
requirements of the level-3 clock.
From the aspect of time synchronization, the GCUOa receives and is synchronized with the
time of the synchronous satellite, and then exports the time to the SCUOa in each subrack.
The SCUOa then, exports the time to each service board to realize the time synchronization
within the entire RAC. Currently, the deviation of RAC time obtained on each board is within
5 ms.
The RAC clock system is responsible for the transmission synchronization and time
synchronization within the entire RAC. The RAC clock synchronization system consists of
two GCUOa boards working in active/standby mode, and provides clock signals for the RAC
system.
14.1.2 Logical Structure of the Clock Synchronization System

Figure 14-1 shows the logical structure of the RAC clock synchronization system.
Issue 01 (2014-05-31)

177
Figure 14-1 Structure of the logical structure of the clock synchronization system
In the RAC system, the frame numbers on the air interface must be synchronized with the
satellite synchronization time. Therefore, the RAC is required to ensure both transmission
synchronization and time synchronization.
The differences between transmission synchronization and time synchronization are as
follows:
Transmission synchronization is relative synchronization. Generally, it is

synchronization of frequencies. The frequency of a signal keeps pace with the reference
frequency. The start moment of the signal, however, does not need to be consistent with
that of the reference signal.
Time synchronization is absolute synchronization. The start moment is consistent with

Universal Time Coordinated (UTC).
14.1.3 Transmission Synchronization

Clock Sources Available for the RAC
The following clock sources are available for the RAC:
BITS clock signal
Line clock signal extracted through the A interface (2.048 MHz line clock signal
extracted from the EIUAa, OIUAa, PEUAa, POUAa, or PO1Aa)
Satellite synchronization clock signal
Policy for Choosing the Clock Source of the RAC
Issue 01 (2014-05-31)

178
The policies for choosing the clock source of the RAC are as follows:
Line clock signals extracted from the A interface are used on a priority basis. If such
signals are not available, the satellite synchronization clock signals are used. BITS clock
signals are not commonly used.
If the line clock signal extracted from the A interface is used and multiple subracks are
configured for the RAC, the clock signal is extracted from the EIUAa, OIUAa, PEUAa,
POUAa, or PO1Aa of the CMPS on a priority basis.
When the FG1Aa or FG2Aa is used as an A interface board, it cannot provide line clock
signals. In this case, the RAC cannot extract line clock signals from the A interface.
Clock Signal Transmission in Transmission Synchronization
After the clock source is selected, the transmission synchronization clock signal is transmitted
as follows:
a.
The RAC sends the clock signal to the GCUOa for phase locking through the reference
clock signal input cable.
b.
The GCUOa generates an 8 kHz system clock signal for the RAC and sends the signal to
the SCUOa in the primary processing subrack by using the backplane, and to the SCUOa
in the secondary processing subrack by using the Y-shaped clock signal cable.
c.
The SCUOa in each subrack performs phase locking for the 8 kHz system clock signal to
convert the signal to a 32 MHz signal. The SCUOa then sends the 32 MHz signal to the
other boards in the subrack as the working clock signal of the subrack.
14.1.4 Time Synchronization

Time synchronization for the RAC is realized through the GPS or GLONASS.
The radio traffic frames sent by the RAC to the BTS carry RFN frame numbers, which must
be synchronized with the system absolute time. The GPS start moment (1980-01-06 00:00) is
RFN frame No0. The next 15 frames are numbered from 1 to 15. The 16th frame is numbered
0 again, and a cycle is formed. The interval between two frames is 20 ms.
Process of Transmitting Time Synchronization Clock Signal
The time synchronization clock signal is transmitted as follows:
a.
The GCUOa receives the signal from the GPS or GLONASS antenna.
b.
The GCUOa extracts 1PPS and absolute time information and sends the information to
the SCUOa in the primary processing subrack through the backplane, or to the SCUOa in
the secondary processing subrack through the Y-shaped clock signal cable.
c.
Based on the signal, the SCUOa generates an RFN cell and distributes the RFN cell
through the bus on the backplane to all the boards. In practice, only the APUSc, APUDc,
DPUSb and DPUDb use the RFN cell.
RAC Clock Fault Alarms

0 lists the alarms indicating RAC clock faults.
Issue 01 (2014-05-31)

179
Table 14-1 Alarms generated because of RAC clock faults

ID
Alarm
ALM-6250
Insufficient Number of Satellites Traced by Satellite Card over 24

Hours
ALM-6253
Satellite Card Antenna Fault Alarm
ALM-6254
Satellite Card Fault Alarm
ALM-6256
Satellite Card 1PPS Signal Abnormal over 24 Hours
ALM-6258
Inconsistent Time of Satellite Cards on Active and Standby Boards
ALM-6259
Time Resource Unusable Alarm
ALM-6261
Satellite Card Time Abnormal Alarm
ALM-6280
Unavailable System Clock Reference
ALM-6288
System Clock Source Locking Failure
ALM-6343
Synchronization Time Resource Unusable Alarm
ALM-6344
DSP Synchronization Time Information Receiving Abnormal
ALM-6025
Clock Phase-Locked Loop Fault
ALM-6044
SCU Clock Reference Source Abnormal
ALM-9058
Board Clock Signal Input Fault
14.2 Introduction to BTS Clock System

The BTS uses a satellite synchronization antenna system to receive clock signals from the
GPS/GLONASS.
Functional Structure of the Satellite Antenna System of the BTS

The satellite antenna system of the BTS consists of the antenna, feeder, and surge protector, as
shown in Figure 14-2.
Issue 01 (2014-05-31)

180
Figure 14-2 Satellite synchronization antenna system
a.
indicates GPS antenna.
b.
indicates feeder, with the other end connected to the surge protector on the RF unit.
If the distance between the satellite antenna and the RF unit is shorter than 50 m (164.04 ft), use an
RG8 feeder.
If the distance ranges between 50 m (164.04 ft) and 100 m (328.08 ft), use a 1/2" feeder.
Clock Source of a BTS

In a CDMA system, the system time of all BTSs must be synchronous.
The BTS can use the following types of synchronization clock sources.
Board synchronization clock: a synchronization clock output by the satellite card in the
CMPT/USCU
Internal clock: used when no external clock source is available. When the internal clock
is used, the crystal oscillator of the CMPT is in the free-run or holdover state.
IP-based clock: 1588v2 transmission synchronization clock, a land time synchronization

mode based on circuit switching and transmission. The clock is obtained using the public
land cable transmission, reducing reliance on the GPS. In this clock system, at least one
server is required to provide time information. All devices in the network synchronize
their time with that of the server by following a certain algorithm. Only BTSs using
BBUs support this clock synchronization mode.
TOD-based clock. 1PPS+TOD synchronization indicates that a BTS implements time

synchronization by obtaining pulse per second (1PPS) and time of day (TOD) signals. The
1588v2 synchronization clock signals can be sent to the CBTS through the Ethernet or
synchronous digital hierarchy (SDH) network. When the SDH network is used, the device at
the transmission end implements time synchronization by sending 1PPS+TOD clock signals
to the CBTS. TOD signals are used to transmit information, such as time information, clock
type, and running status of the clock. Only BTSs configured with the universal satellite card
and clock unit (USCU) support this clock synchronization mode. Synchronization clock
sources of a BTS should be configured in descending order of priority. The board
synchronization source is generally configured with the highest priority.
Issue 01 (2014-05-31)

181
If multiple synchronization sources are configured for a BTS, the BTS searches for an available
synchronization source in descending order of priority.
The internal synchronization clock source is not configured with a synchronization clock. Therefore,
it is not regarded as an available synchronization source.
Local Time of a BTS

The BTS obtains the universal time coordinated (UTC) from the satellite synchronization
system. To enable the BTS to determine the local time based on the UTC, you must set the
local time zone and the adjustment minute (time offset).
If the daylight saving time (DST) is used on the site, you must run the SET CBTSDAYLT
command to configure the start time and end time of DST.
Synchronization Between the BTS and RAC

Method 1: The BTS and the BSC synchronize their time with a specified satellite system by
using respective satellite cards. This enables synchronization between the BTS and the BSC.
Method 2: The BSC synchronizes its time with the satellite through the satellite receiving
system. The BTS synchronizes its time with the satellite by obtaining clock signals over the
FE interface from the 1588v2 clock server.
On the Service Maintenance System, the following are subject to the time on the BAM:
Command execution time
Alarm reporting time
Event logging time
Alarms Related to BTS Clock Failures

Table 14-2 lists the alarms related to BTS clock failures.
Table 14-2 Alarms related to BTS clock failures
ID
Alarm
ALM-19365
Locked Satellites Insufficient
ALM-19366
BTS Clock Holding for 8 Hours
ALM-19367
BTS Clock Holding for 23 Hours
ALM-19368
BTS Clock Failure
ALM-19369
Reference Source Configuration Incorrect
ALM-19370
Satellite Antenna Fault
ALM-19371
Satellite Card Fault
ALM-19373
Reference Source IPCLK Unavailable
ALM-19374
TOD Reference Source Abnormal
Issue 01 (2014-05-31)

182
ID
Alarm
ALM-19375
TOD Reference Source Unavailable
ALM-19406
IP Clock Link Failure
14.3 Troubleshooting High FER in Markov Calls

Symptom
The voice quality is poor with intermittent voices. On the Service Maintenance System, after
the Markov call monitoring is enabled, it is detected the FER exceeds 10%.
Cause
The satellite clock of the BTS is abnormal.
The BTS system clock is abnormal.
Analysis
Check and clear clock-related alarms.
Check and resolve BTS clock locking problem.
1. Run the DSP CLKSRC command to query whether the current RAC clock source is correct.
For details about the RAC clock data configuration, see the RAC6690 Initial Configuration
Guide.
If the current system clock source is correct, go to 2.
If the current system clock source is incorrect, run the RMV CLKSRC or ADD
CLKSRC command to modify the RAC clock source.
2. In the alarm management system, check whether there are any alarms listed in Table 14-1.
If there are any of these alarms in the alarm management system, clear them.
If there are not these alarms in the alarm management system, go to 3.
3. In the alarm management system, check whether there are any alarms listed in Table 14-2.
If there are not these alarms in the alarm management system, contact Huawei for
technical support.
----End
Issue 01 (2014-05-31)

183
14.4 Troubleshooting Incorrect Time Displayed on

ATs/MSs
Symptom
The time displayed on an MS differs from the local time.
Cause
The time displayed on an MS depends on the GPS time in the system messages sent by the
RASYS and the time zone of the area where the MS resides.
The GPS clock on the RAC is abnormal.
The local time offset is incorrect.
Check whether the GPS clock on the RAC is normal.
Check whether the local time offset is correct.
Analysis
1. In the alarm management system, check whether there are any of alarms listed on Table 19-1.
If there are not these alarms in the alarm management system, go to 2.
2. Check whether the local time offset of 1X messages are correctly configured. Run the LST
SYSMSGPARA command to query the configuration of the synchronization channel
messages of the cell where the MS resides. Then, Check whether Local Time Offset in the
messages is the local time zone.
If the Local Time Offset in the messages is the local time zone, go to 3.
If the Local Time Offset in the messages is not the local time zone, set Local Time Offset
to the local time zone.
3. Check whether the local time offset of EV-DO messages are correct. Run the LST DOSPM
command to query the configuration of the synchronization channel messages of the cell
Issue 01 (2014-05-31)

184
where the AT resides. Check whether Local Time Offset in the messages is the local time
zone.
If the Local Time Offset in the messages is the local time zone, go to 4.
If the Local Time Offset in the messages is not the local time zone, set Local Time Offset
to the local time zone.
4. Enable the MS to access the network again, and check whether the displayed time is correct.
If the displayed time is correct, no operation is required.
If the displayed time is incorrect, contact Huawei for technical support.

NOTE
The local time offset is included in the 1X synchronization channel message, which is received by an
MS only when the MS searches for a 1X network. Therefore, modification of the local time offset takes
effects on the MS only when the MS accesses the network again.
----End
Collect the following information before contacting Huawei for technical support:
Records of key issues and operations during troubleshooting
Causes of detected faults and rectification methods
Current alarm
Historical alarm
RAC operation logs
RAC configuration scripts
Issue 01 (2014-05-31)

185
15
15 Troubleshooting Transmission Failures
Troubleshooting Transmission
Failures
15.1 Introduction to Transmission

This section describes the overview information regarding the links and the troubleshooting
principles of transmission failures. This provides guidelines for locating and troubleshooting
transmission failures.
15.1.1 Introduction to Links

Links between the CDMA2000 network interfaces are categorized into physical links and
logical links.
Physical links are actual links used to carry all the logical links. Table 15-1 lists common
physical links.
Table 15-1 List of common physical links
Physical Link (IP Transmission)
Physical Link (ATM Transmission)
ETH link
UNI link
TRUNK link
IMA link
MLPPP link
Fractional ATM link
PPP link
Fractional IMA link
Logical links are virtual links used to transmit the signaling, service data, and OM messages
between the network interfaces. One logical link can be carried on different physical links.
Table 15-2 lists common logical links.
Issue 01 (2014-05-31)

187
Table 15-2 List of common logical links

Logical Link
over the Abis
Interface
Logical Link Between

ANs
Logical Link
Between RACs
Logical Link over

Other Interfaces
OM link
A13/A16 link
A3 link
A8/A9 link
Signaling link
A17 link
A7 link
A10/A11 link
Traffic link
A18 link
A12 link
15.1.2 Troubleshooting Principles of Transmission Failures

The troubleshooting principles of transmission failures are as follows:
a.
Locating the transmission failure based on the protocol layer;
b.
Performing the loopback by segment and checking the DIP switches;
c.
Performing the ping detection;
d.
Checking the configuration to ensure that the connection is normal.
Locating the Transmission Fault Based on the Protocol Layer

According to the network protocol structure, each interface can be classified into multiple
layers according to the protocol type. The transmission fault can be located by protocol layer.
Table 15-3 describes the typical network protocol structure in IP transmission mode.
Table 15-3 Structure of the typical network protocol (IP transmission)
Application Layer
Logical Link
Transport layer
TCP/UDP link
Network layer
IP link
Link layer
MAC/MLPPP/PPP/HDLC link
Physical layer
PHY/E1/T1 link
As shown in the preceding table, PHY links, E1/T1 links, MAC links, PPP/MLPPP links, IP
links, and logical links are at different layers. If the transmission interface is faulty, you can
locate the fault by protocol layer in bottom-up mode.
Before locating the fault in the transmission link, you need to check whether the Alarm
Management System reports physical layer alarms, link layer alarms, or logical link alarms.
If the Alarm Management System only reports the logical link alarms, such as the Abis
signaling link fault alarm, troubleshoot the failure by checking the data configuration
directly.
If the Alarm Management System reports the physical layer alarms and link layer alarms,
such as the E1/T1 link alarm and Ethernet link alarm, clear the physical layer alarms by
performing the loopback by segment and checking the DIP switches, and then handle the
data link layer alarms.
Issue 01 (2014-05-31)

188
Performing the Loopback by Segment

Perform the loopback by segment to check whether the alarm is cleared.
If the alarm is cleared, the problem does not lie in the link segment.
If the alarm persists, the problem lies in the link segment.
By performing the loopback by segment, you can accurately locate the physical faults. When
the E1/T1 link alarm or FE link alarm is generated, the loopback by segment is an effective
means of locating the problem.
Checking the DIP Switches

The precautions for checking the DIP switches are as follows:
When you check the grounding status, you need to check the grounding status of all the
transmission devices.
Check whether the resistance switch is set to 120 or 75 .
If the alarm of E1/T1 BER Threshold Exceeded is reported and other E1/T1 transmission link
alarms are not reported within one hour, the DIP switches may be set incorrectly.
Performing the Ping Detection

The ping detection is an effective means of detecting problems on the network layer, such as
the IP layer, and is widely used for locating transmission problems. When a CDMA network
interface is faulty, the Alarm Management System reports alarms related to the logical
interface fault without reporting the physical layer alarm and link layer alarm. In this case,
you need to perform the ping detection to check the transmission at the IP layer.
The ping detection can be performed by using either of the following methods:
Use the port IP address to ping the node IP address of the transmission link to check the
transmission at the IP layer. Note that the route must be configured correctly.
Use the logical IP address to ping the logical IP address of the interconnected device to
check whether the logical link is normal. For example, if the A10/A11 interface is faulty,
you can use the logical IP address of the interface board to ping the logical IP address of
the interconnected PDSN device to check whether the logical link fault is caused by the
fault at the IP layer. Note that the route must be configured correctly.
Checking the Configuration

Check the configuration if the following conditions are met:
The physical layer alarms and link layer alarms are not generated.
The IP layer is normal based on the ping detection.
The logical link alarms, such as the Abis signaling link alarm, are generated.
Run the CHK CBTSIFCFG command to check whether the script configuration of the RAC
is the same as that of the BTS.
Issue 01 (2014-05-31)

189
15.2 Troubleshooting Abis Interface Link Failures

15.2.1 Troubleshooting Abis Transmission Link Failure
Symptom
Table 15-4 describes the symptoms of the Abis transmission link faults.
Table 15-4 List of transmission link fault symptoms
Item
Symptom
Service
1. The OM link between the RAC and the BTS cannot be set up.
2. All the services between the RAC and the BTS are interrupted.
Alarm
E1/T1 Loss of Signal (LOS)

E1/T1 Loss of Frame Alignment (LOF)
E1/T1 Remote Alarm Indication (RAI)
E1/T1 Alarm Indication Signal (AIS)
E1/T1 Loss of Multiframe Alignment (LOM)
E1/T1 Link Loopback
E1/T1 1-Hour Slip Frame Threshold Exceeded
E1/T1 BER Threshold Exceeded
Loss of Signals on the Optical Port (RLOS)
Loss of Signal Frames on the Optical Port (RLOF)
Optical Port Loss of Frame Alignment(ROOF)
Optical Port Signal Failure (RSF)
Optical Port Signal Deterioration (RSD) alarm
Optical Port Loopback Alarm
Optical Module Fault
Optical Module Mismatch
Ethernet Link Fault Alarm
Ethernet Link Loopback Alarm
IMA/Fractional IMA Link in Loss of Frame Alignment
IMA/Fractional IMA Link Out of Synchronization
IMA/Fractional IMA Link Remote Reception Defect
IMA/Fractional IMA Link in Receive Failure
Issue 01 (2014-05-31)

190
Item
Symptom
IMA/Fractional IMA Link TX Fault at Far End
IMA/Fractional IMA Link Remote Reception Failure
PPP Link Fault
MLPPP Group Fault Alarm
Ethernet TRUNK Link Down
Ethernet TRUNK Group Down
Ethernet Link Transmission and Reception Defect
Cause
The physical link is faulty.
The data configuration is incorrect.
Analysis
Check whether the physical link is faulty.
Check whether the link configuration is correct.
1. Check whether the settings of the DIP switches of the Abis interface are correct.
If the settings are correct, go to 2.
If the settings are incorrect, set the DIP switches of the Abis interface correctly.
For details about how to set the DIP switches of the Abis interface on the RAC, see the
RAC6690 Hardware Description. For details about how to set the DIP switches of the Abis
interface board on the BTS, see the BBU3900 User Guide.
2. Check whether the Alarm Management System reports alarms related to the E1/T1, optical
interface, or Ethernet.
If the Alarm Management System reports such alarms, clear the alarms according to the
handling suggestions in the alarm reference.
If the Alarm Management System does not report such alarms, go to 3 when the E1/T1
or STM-1 transmission mode is used. Go to 4 if the FE transmission mode is used.
3. Run the SET TRTEST command to start an E1/T1 crossed pair connection test. Then, run
the DSP TRTEST command to view the test result.
If the E1/T1 crossed pair connection is abnormal, reconnect the E1/T1 crossed pair.
If the E1/T1 crossed pair connection is normal, go to 4.
Issue 01 (2014-05-31)

191
4. Check whether the Alarm Management System reports alarms related to the fractional
IMA/IMA link, PPP/MLPPP link, or Ethernet link.
If the Alarm Management System reports such alarms, clear the alarms according to the
handling suggestions in the alarm reference. If these alarms persist, go to 5.
If the Alarm Management System does not report such alarms, no further action is
required.
5. If the fractional IMA link group is configured, check whether the timeslots configured for the
RAC are consistent with the timeslots configured for the BTS. If they are not consistent,
change the configuration of timeslots as required.
If the PPP or MLPPP link group is configured and is carried on the STM-1, run the LST
SDHCFG command to check whether the configuration of the RAC is consistent with the
configuration of the intermediate transmission device. If they are not consistent, change the
configuration as required.
If the ETHLINK or ETHTRK link is configured, check the information about the route from
the RAC to the intermediate transmission device and the information about the route from the
RAC to the BTS. If the route information is not configured, configure it as required.
----End
15.2.2 Troubleshooting Abis Maintenance Link Failure

Symptom
The Alarm Management System reports the alarm of BTS OM Link Interrupted. As a result,
you cannot maintain the BTS through the BAM.
Cause
The Abis transmission link is faulty.
Analysis
Check whether the Abis transmission link is faulty.
Check whether the data configuration is correct.
1. If the Alarm Management System reports alarms related to the E1/T1, optical interface,
PPP/MLPPP link, or Ethernet, troubleshoot the fault by referring to the troubleshooting
procedure for the Abis transmission link failure.
Issue 01 (2014-05-31)

192
If the fault persists, go to 2.
2. Run the LST BTSLNK command to check whether the following configurations of the BTS
OM links are correct: board type, MLPPP group number, Ethernet port number, IP address,
and gateway IP address of the interface board.
If the configurations are correct, go to 4.
If the configurations are incorrect, go to 3.
3. Run the RMV BTSOMLNK and ADD BTSOMLNK commands to change the
configurations of OM links.
If the fault is not rectified and the link type is ETHLNK or ETHTRK, go to 4.
If the fault is not rectified and the link type is PPP or MLPPP, contact Huawei technical
support.
4. Run the LST BTSBOOTP command to check whether the following BTS BOOTP
configurations are correct: the logical IP address, port IP address, and gateway IP address of
the BTS interface board, and BTS electronic serial number (ESN).
If the BTS BOOTP configurations are correct and the Abis interface uses the Layer 2
networking mode, go to 5.
If the BTS BOOTP configurations are correct and the Abis interface uses the Layer 3
networking mode, go to 6.
If the BTS BOOTP configurations are incorrect, run the MOD BTSBOOTP command
or RMV BTSBOOTP and ADD BTSBOOTP commands to change the configurations
as required.
5. Run the LST SRVVLANID or the DSP CBTSVLAN command to check whether the BTS
VLAN configuration, including VLANID, is correct. You must ensure that the VLAN
configuration of the intermediate transmission device is consistent with the BTS VLAN
configuration.
If the configuration is incorrect, run the MOD SRVVLANID command to change the
configuration as required.
6. Check whether the configuration of DHCP Relay of the intermediate transmission device is
correct.
If the configuration is incorrect, reconfigure DHCP Relay.
----End
15.2.3 Troubleshooting Abis Signaling Link Failure

Symptom
The Alarm Management System reports the alarm of Abis Signaling Link Interrupted, and
subscribers cannot access the network. The command result of DSP SIGLNKSTAT shows
that the Abis link is disconnected.
Issue 01 (2014-05-31)

193
Cause
Analysis
signaling links are correct: interface board, MP group number, Ethernet port number, interface
board IP address, gateway IP address, and SCTP link number.
If the configurations are incorrect, run the RMV BTSSIGLNK and ADD BTSSIGLNK
commands to change the configurations.
2. Run the LST CDMACH command to check whether the RAC is configured with the correct
type of carriers.
If the RAC is configured with the correct type of carriers, go to 3.
If carriers are not configured, configure them. If the RAC is configured with incorrect
type of carriers, go to 3.
3. Run the DSP CBTSSECTORCARRIERINFO command to check whether the BTS is

configured with the correct type of carriers.
If the BTS is configured with the correct type of carriers, go to 4.
If carriers are not configured, configure them. If the BTS is configured with incorrect
type of carriers, go to 4.
4. Troubleshoot the fault according to the handling suggestions of the alarm of Abis Signaling
Link Interrupted on the Alarm Management System.
----End
15.2.4 Troubleshooting Abis Traffic Link Failure

Symptom
Subscribers cannot access the network.
Issue 01 (2014-05-31)

194
Cause
Analysis
1. Troubleshoot the fault by referring to the troubleshooting procedure of the Abis transmission
link fault if the Alarm Management System reports alarms related to E1/T1, optical port,
PPP/MLPPP link, or Ethernet.
If the fault persists, go to 2.
signaling links are correct: interface board, MP group number, Ethernet port number, interface
board IP address, and gateway IP address.
If the configurations are incorrect, run the RMV BTSTRFLNK and ADD
BTSTRFLNK commands to change the configurations.
3. Run the CHK CBTSIFCFG command to check whether the configurations of traffic links on
the RAC are consistent with those on the BTS.
If the configurations are consistent, contact Huawei technical support.
If the configurations are not consistent, change the configurations of traffic links on the
BTS.
---End
15.3 Troubleshooting A3 Interface Failure

Symptom
Subscribers cannot perform A3 handoffs.
Cause
The A3 link configurations are incorrect.
The PMU on the peer end is faulty or is reset.
The transmission link is faulty.
Issue 01 (2014-05-31)

195
Analysis
Check whether the A3 links between RACs are configured correctly. For details, see 1.
Check whether any alarm is generated for the logical links that carry A3 links.
Check whether the interface board is faulty.
Check whether the PMU on the peer end is faulty.
1. Run the LST NBRBSCLNK command to check whether the following configurations related
to the A3 interface are incorrect: interface board slot number, link mode of the bearer (such as
IMA, MLPPP, PPP, or FE link), and link number of logical links.
If the configurations are incorrect, change the configurations. If the A3 handoffs recover,
no further action is required.
2. Check whether any alarm is generated for the logical links that carry the A3 links. To check
the link status, run the DSP IMAGRPSTAT, DSP MPLNKSTAT, DSP PPPLNKSTAT, or
DSP ETHLNKSTAT command.
If any alarm is generated, clear the alarm according to the handling suggestions in the
alarm reference. If the A3 handoffs recover, no further action is required.
If the alarm is not generated, go to 3.
3. Check whether the interface board is reset.
If the interface board is reset, wait until the board starts again. If the A3 handoffs recover,
If the interface board is not reset, go to 4.
4. Request the device maintenance engineers on the peer end to check whether the PMU
subsystem is reset.
If the PMU subsystem is reset, wait until the PMU restarts. If the A3 handoffs recover,
If the PMU subsystem is not reset, go to 5.
5. Switch over or reset the interface board at low traffic hours.
If the A3 handoffs recover, no further action is required.
If the alarm persists, contact Huawei technical support.
----End

Troubleshoot the fault according to the handling suggestions of the alarm of A7 Signaling
Link Interrupted over IP connection (Alarm ID: 2351) in the alarm reference.
Issue 01 (2014-05-31)

196
15.5 Troubleshooting A10/A11 Link Failure

Troubleshoot the fault according to the handling suggestions of the alarm of The Link of
A10/A11 Interface Fault (Alarm ID: 1181) in the alarm reference.
15.6 Troubleshooting A12 Link Failure

Symptom
When subscribers access the network for the first time, access authentication and dialing fail,
and the dial-up connection cannot be set up.
Cause
Service failure occurs between the PCF and the AAA.
Configurations of network connections between the PCF and the AAA are incorrect.
Physical connection failures occur between the PCF and the AAA.
Analysis
Review the alarm information.
Troubleshoot the service failure between the PCF and the AAA according to the handling
suggestions of the alarm of AN-AAA Authentication Unreachable (Alarm ID: 2293).
Troubleshoot the configuration problems of the network connections between the PCF
and the AAA according to the handling suggestions of the alarm of A12 Interface
Authentication Path Fault (Alarm ID: 2291).
Troubleshoot the physical connection failures between the PCF and the AAA according
to the handling suggestions of the alarm of Ethernet Link Fault Alarm (Alarm ID: 851).
Troubleshoot the fault according to the handling suggestions in the alarm reference.
15.7 Troubleshooting A13/A16 Link Failure

Troubleshoot the fault according to the handling suggestions of the alarm of A13/A16
Interface Channel Fault (Alarm ID: 2350) in the alarm reference.

Troubleshoot the fault according to the handling suggestions of the alarm of A17 Signaling
Link Interrupted (Alarm ID: 2352) in the alarm reference.
Issue 01 (2014-05-31)

197

Symptom
Subscribers cannot perform A18 handoffs.
Cause
Configurations of the network connections between the AN and its adjacent ANs are
incorrect.
Network connections between the AN and its adjacent ANs are interrupted.
Analysis
Check whether the A18 links between ANs are configured correctly.
Check whether any alarm is generated for the logical links that carry the A18 links.
Check the network connections between adjacent ANs.
1. Run the LST BSCINF and LST NBRAN commands to query information about the serving
AN and the adjacent ANs. Check whether identical IP addresses are allocated to the serving
AN and adjacent ANs and that the IP address allocated to adjacent ANs is not a broadcast IP
address.
If identical IP addresses are allocated, change the related configurations. If the A18
handoffs recover, no further action is required.
If no identical IP address is allocated, go to 2.
2. Run the LST NBRANLNK command to check whether the configurations of the A18 links
on the adjacent ANs are incorrect.
If the configurations are incorrect, change the related configurations. If the A18 handoffs
recover, no further action is required.
3. Check the network structure to determine whether the serving AN and the adjacent ANs are
on the same network segment.
If the serving AN and the adjacent ANs are on the same network segment, go to 4.
If the serving AN and the adjacent ANs are not on the same network segment, run the
ADD IPBRDROUTE command to add the route configuration.
4. Check whether any alarm is generated for the logical links that carry the A18 links. To check
the link status, run the DSP IMAGRPSTAT, DSP MPLNKSTAT, DSP PPPLNKSTAT, or
DSP ETHLNKSTAT command.
If any alarm is generated, clear the alarm according to the handling suggestions in the
alarm reference. If the A18 handoffs recover, no further action is required.
If no alarm is generated, go to 5.
Issue 01 (2014-05-31)

198
5. Wait for five minutes and then check whether the alarm is cleared.
If the alarm is cleared, no further action is required.
If the alarm persists, contact Huawei technical support.
----End
15.10 Troubleshooting E1 Connection Failure

Symptom
The V5 interface cannot be started and the E1 link is unavailable.
Issue 01 (2014-05-31)

199

Figure 15-1 Flowchart for troubleshooting E1 connection failures
Start
1
Check the status of the E1

link that corresponds to the
V5 interface
2
Is the E1 link
normal?
Check the physical

connection of the E1
cable
No
Yes
Is the
cable correctly
connected?
No
Correct the physical

connection
Yes
Check clocks
Are clocks
normal?
Yes
No
Adjust clocks
Yes
Check whether the CRC
configured on the RAC
matches that on the LE
Are they
consistent?
No
Modify the CRC on the RAC
End
1.
Check the status of the E1 link used during V5 interface configuration.
To query the status of the E1 link used during V5 interface configuration, run the following
command on the Service Maintenance System:
DSP E1T1STAT: FN=2, SN=14, BTP=EIUAa;
2.
Check the physical connection of the E1 cable.
Check whether the physical connection of the E1 cable is correct. If the E1 cable is not
correctly connected, connect the cable correctly.
Issue 01 (2014-05-31)

200
3.
Check the clock.
On the Alarm Management System, choose Browse > Fault Alarm. The Fault Alarm
Browse window is displayed.
4.
Check whether clock-related alarms are generated.
Run the LST BRDPARA command to check whether configurations of clock parameters are
correct.
5.
Check whether the CRC4 verification flag is consistent with that on the switch.
The CRC4 verification flag should be consistent with that on the switch. You can run the LST
V5LNK command to check the configuration for CRC4 verification flag on the RAC.
If the CRC4 verification flag is inconsistent with that on the switch, run the MOD V5LNK
command to modify the configuration.
NOTE
If the E1 cable is correctly connected, and if the CRC4 verification flag is consistent with the switch flag,
you are advised to perform the segmental loopback to locate the problem, such as the E1 cable remote
loopback and transmission loopback.
----End
15.11 Troubleshooting V5 Link Failure

Symptom
The V5 link is faulty or blocked.
Issue 01 (2014-05-31)

201

Figure 15-2 Flowchart for troubleshooting a V5 link failure
Start
1
Check the status of the E1

link
Is the E1 link
normal?
No
Rectify the E1 link failure
Yes
Check the status of the V5

link
Is the V5 link
normal?
No
Rectify the V5 link failure
Yes
End
1.
Check the E1 link status.
On the Service Maintenance System, run DSP E1T1STAT command to check the status of
the E1 link used during the V5 interface configuration.
For example, DSP E1T1STAT: FN=2, SN=14, BTP=EIUAa;
2.
Query the status of the V5 link.
On the Service Maintenance System, run the DSP V5LNK command to query the status of
the V5 link. For example,
DSP V5LNK: FN=3, V5ID=2, LINKS=0, BN=16;
3.
Resolve the problem of the V5 link.
If the V5 link is in the BLOCK state, run the UBL V5LNK command on the RAC to
unblock the V5 link. If the V5 link is still in the BLOCK state, have LE engineers to run
the corresponding command on the LE to unblock the V5 link.
If the V5 link is in the FAULT state, wait for two minutes and check the status of the V5
link. If the V5 link is still in the BLOCK state, have Huawei engineers locate and rectify
the fault.
----End
Issue 01 (2014-05-31)

202
15.12 Troubleshooting V5 Interface Failure

The V5 interface is the logical interface between the RAC and the LE.
Symptom
The status of the V5 interface is not Normal but the E1 link and V5 link are running properly.

Figure 15-3 Flowchart for troubleshooting the V5 interface fault
Start

channel C of the V5
interface
Is the
configuration
correct?
No
Modify the configuration of

channel C of the V5
interface
Yes
3

the V5 interface on the RAC
and the LE
Are the V5
interface data
consistent?
No
Modify the configuration of

the V5 interface on the RAC
and the LE
No
Ask LE engineers to correct

the connection
Yes
5
Track the LAP signaling

over the V5 interface
Are the TX
and RX ends correctly
connected?
Yes
End
Issue 01 (2014-05-31)

203
1.
Check the configuration of the V5 C channel.
On the Service Maintenance System, run the LST V5CCH command to query the
configuration of the V5 C channel.
2.
Modify the configuration of the V5 C channel.
On the Service Maintenance System, run the MOD V5CCH command.

3.
Check the V5 interface configuration on the LE and RAC.
The following table lists the V5 configuration that should be consistent between the LE and
the RAC.
Table 15-5 Data to be negotiated between the LE and the RAC
Negotiation
Item
Command
Value
Remarks
V5ID,
ANV5ID
LST V5ITF
0
to
16777215
V5ID and ANV5ID are numbered on

the LE.
V5VER
LST V5ITF
V51, V52
V5VER configured on the RAC

should be consistent with that on the
LE. Currently, the RAC supports only
version V5.2.
VARIANT
LST V5ITF
0 to 127
VARIANT configured on the RAC

LE. Generally, VARIANT is set to 0.
LINKID
LST V5LNK
0 to 254
LINKID configured on the RAC must

be consistent with that on the LE.
TSNo
LST V5CCH
15, 16, 31
TSNo configured on the RAC should

PROTTYPE
LST V5CCH
Protect Group
1 Main
PROTTYPE configured on the RAC

LE.
Protect Group
1 Standby
Protect Group
2 Main
Protect Group
2 Standby
CHNID
LST V5CCH
0 to 65534
CHNID configured on the RAC

LE.
PSTNLCCID
LST V5ITF
0 to 65534
PSTNLCCID configured on the RAC

LE.
Issue 01 (2014-05-31)

204
Negotiation
Item
Command
Value
Remarks
L3ADDR
LST
V5BAPORT
0 to 32767
L3ADDR configured on the RAC

must be consistent with that on the
LE.
TELNO
LST
V5BAPORT
Within
bits
32
TELNO configured on the RAC must

V5PARAVAL
3
LST
V5SOFTPARA
Supported or
Not
Supported
V5PARAVAL3 configured on the

RAC must be consistent with that on
the LE.
4.
Modify the V5 interface configuration on the LE and RAC.
If configuration inconsistency occurs, modify the configuration as follows:
If the configuration for the V5 interface is incorrect, run the MOD V5ITF command to
modify the configuration.
If the configuration for the V5 link is incorrect, run the MOD V5LNK command to
If the configuration for the C channel is incorrect, run the MOD V5CCH command to
If the acceleration synchronization parameter needs to be modified, run the MOD

V5SOFTPARA command and set the parameter to PARA3.
5.
Trace the V5 LAP signaling.
Enable the LAP signaling tracing. If no frame signaling is received from the LE, faults
occur on the LE. Have the LE engineers rectify the faults.
If there is some signaling on C path of the C channel, check whether the E1 cable is
incorrectly connected.
----End
15.13 Troubleshooting A+ Interface Failures

The A+ interface is also called mobile V5 interface. It is extended from the standard V5
interface and used to connect a radio access controller (RAC) to a local exchange (LE).
This section describes how to troubleshoot the faults in A+ interface between the RAC and
the LE.
Symptom
The status of the V5 interface is not Normal but the E1 link and V5 link are normal.
Impacts of the faults are as follows:
Issue 01 (2014-05-31)
If no A+ interface is configured between the RAC and the LE, subscribers under the
coverage of the RAC cannot initiate calls.

205
Voice and data services that are processed by all subscribers registered on the LE are
handed off to other LEs. This increases the load of other LEs.

Figure 15-4 shows the flowchart for troubleshooting the A+ interface faults.
Figure 15-4 Flowchart for troubleshooting the A+ interface faults
Start
Check the status of the interface

board.
Is the interface board working

properly?
No
Replace the interface board.
Yes
Check the status of physical

links.
Are the physical links

operational?
No
Troubleshoot the physical links.
Yes
Check the configurations for the

A+ interfaces on both the RAC
and LE sides.
Is the A+ interface
configuration on the LE consistent
with that on the RAC?.
No
Uniform the A+ interface

configuration between the LE
and the RAC.
Yes
End
1.
Check the status of the interface board.
On the service maintenance system, run the DSP BRDINFO command to query the status of
the interface board. For example,
Issue 01 (2014-05-31)

206
DSP BRDINFO: FN=3, SN=15;

2.
Replace the faulty board.
For details about how to replace a board, see the operations in the Site Maintenance Guide.
3.
Check the status of the physical links.
On the service maintenance system, run the DSP E1T1STAT command to query the
status of E1 links connected to the RAC. For example,
DSP E1T1STAT: FN=3, SN=15, BTP=EIUAa;
Query the status of A+ links.
On the service maintenance system, run the DSP V5LNK command to query the link status.
For example,
DSP V5LNK: V5ID=2, LINKS=0, BN=16;
4.
Troubleshoot the physical links.
If the E1 links are not operational, see15.10 15.10 Troubleshooting E1 Connection

Failure.
If the A+ links are not operational, troubleshoot the fault as follows:
5.
If the A+ links are blocked, run the UBL V5LNK command to unblock the link on
the RAC side. If the links are still blocked after the unblock operation on the RAC,
have the LE technical support engineers unblock the link.
If the links are faulty, wait for 2 minutes. Then, query the status of the link. If the
status is still Fault, contact Huawei technical support engineers.
Check the A+ interface configuration on the LE and RAC.
Check whether the configuration on the LE is consistent with that on the RAC, such as the
interface IDs, interface protocol versions, protection groups. For details about the
configuration, see Table 15-6.
Table 15-6 A+ interface parameters to be negotiated between the LE and the RAC
Negotiation Items
Value
Description
V5 Interface ID
0 to 16777215
The V5 interface ID is numbered

on the LE side.
V5 Protocol Version
V51 or V52
The V5 protocol version must be

consistent with that on the LE.
RACs now only support V5.2.
Variant
0 to 127
Variables of each interface must

be consistent with those on the
LE. It generally is set to 0.
Link ID
0 to 254
The link ID must be consistent

with that on the LE.
OFFICENO V5
0 to 65534
This parameter is invalid when

the V5 interface is used.
Issue 01 (2014-05-31)

207
Timeslot
15, 16, or 31
The number of the timeslot

occupied by each physical
C-channel must be consistent with
that on the LE.
Protect Group Type
1: Group 1 (active)
The protect group type of each

physical C-channel must be
2: Group 1
(standby)
3: Group 2 (active)
4: Group 2
(standby)
Logic C Channel ID
0 to 65534
The logic C-channel ID of each

physical C-channel must be
PSTN Logic Communication

Channel ID
0 to 65534
PSTN logic communication

channel ID of each V5 interface
must be consistent with that on
the LE.
L3 Address
0 to 32767
The L3 address must be consistent

with that on the LE.
Phone No.
A 4- to 32-digit
decimal string.
The phone number must be

Whether to Support
Accelerate Synchronization
Procedure
Supported or Not
Supported
The Whether to Support

Accelerate Synchronization
Procedure must be consistent with
that on the LE.
6.
Modify the configuration of the A+ interface on the LE or RAC.
If the A+ interface configuration on the LE is inconsistent with that on the RAC, perform the
following operations:
If the A+ interface configuration is incorrect, run the MOD V5ITF command to correct
the configuration.
If the link configuration is incorrect, run the MOD V5LNK command to correct the
configuration.
If the C-channel configuration is incorrect, run the MOD V5CCH command to correct
the configuration.
If the setting for Whether to Support Accelerate Synchronization Procedure needs to

be changed, run the MOD V5SOFTPARA command to set Whether to Support
Accelerate Synchronization Procedure to PARA3.
----End
Issue 01 (2014-05-31)

208
16
16 Troubleshooting OM Failures
Troubleshooting OM Failures
16.1 Introduction to the BAM OM

Operation and maintenance (OM) failures do not interrupt ongoing services but may result in
BTS maintenance failures and even BTS upgrade failures. For example, if BTS OMLs are
interrupted, users may fail to log in to the BTS through telnet from the BAM. OM failures
severely affect the system and require quick troubleshooting.
Generally, the following OM failures require quick troubleshooting:
Failures to ping BTS OMLs from the BAM
Failures to log in to the BTS through telnet
Unavailability of BTS carriers
Remote OM failures
Local OM failures
16.2 Troubleshooting the Unavailability of BTS Carriers

Symptom
1X MSs or EV-DO ATs cannot access the network.
Cause
For ATs with access authentication failures, trace messages over subscriber interfaces and
analyze the traced code stream and alarms to locate the fault. Common causes of the fault are
as follows:
The signaling link is faulty.
The BTS and RAC configurations are not consistent.
The configurations of ARFCNs are improper.
Analysis
Issue 01 (2014-05-31)
Check whether the signaling link is normal.

209
Check whether BTS and RAC configurations are consistent.
Check whether ARFCNs of carriers are properly configured.
1. Run the MML command DSP SIGLNKSTAT to check whether the signaling link is normal.
If the signaling link is normal, go to 2.
If the signaling link is faulty, rectify the fault.
2. Run the MML command CHK CBTSIFCFG to check whether carrier configurations and IP
addresses on the RAC and BTS are consistent respectively.
If the carrier configurations and IP addresses on the RAC and BTS are consistent
respectively, contact Huawei technical support.
If the carrier configurations or IP addresses on the RAC and BTS are inconsistent
respectively, modify the configuration on the RAC and BTS to ensure consistency.
----End
16.3 Troubleshooting BTS Ping Failures

Symptom
The OM IP address of the BTS cannot be pinged from the BAM, though the interface boards
of the BTS and BSC are functional.
Cause
According to the analysis of the license-related alarm information, common causes of the
fault are as follows:
The link configuration is not consistent with physical connections.
Analysis
Check the E1 links configured for the BTS.
Check the status of the E1 links.
Check whether the link configuration is consistent with physical connections.
1. Check the E1 links configured for the BTS.
On the Service Maintenance System, run the LST BTSLNK command.
+++
HW-Airbridge
O&M
#85
%%LST BTSLNK:;%%
Issue 01 (2014-05-31)
2009-12-23 11:33:30

210

RETCODE = 0
Execution succeeded
BTS Link Information

-------------------Index
BTS ID
BTS Name
BTS2266
BTS2267
Link Type
Subrack No.
SPUO Slot No.=>
O&M Link
O&M Link
2
2
10
10
1
2
2266
2267
Index
SPUO Subsystem No.
Interface Board
Slot No.
Link Mode
Logic Link No.=>
1
2
1
1
17
14
ETH
PPP
0
1(1)
Index
Bandwidth (Kbps)
Link Flag
O&M IP Address
BTS Interface=>
Board IP Address
1
2
129.10.40.218
129.9.200.219
10.10.10.10
12.23.25.26
Index
Gateway IP Address
1
2
150.150.150.11
-
-------------------Index
BTS ID
BTS Name
SPUO Subrack No.=>
Signaling Link
Signaling Link
2
2
1
2
2266
2267
Index
SPUO Slot No.
SPUO Subsystem No.
Interface Board=>
Subrack No.
1
2
10
10
1
1
2
2
Index
Interface Board
Slot No.
Link Mode
Logic Link No.
Bandwidth (Kbps)=>
1
2
18
14
ETH
PPP
0
1(1)
Index
Link Flag
BTS Signaling IP
Address
BTS Interface=>
Board IP Address
1
2
80.126.8.218
80.126.8.219
10.10.10.10
12.23.25.26
Index
Gateway IP Address
Issue 01 (2014-05-31)
BTS2266
BTS2267
Link Type
System Type
Protocol Type=>

211
1
2
150.150.150.11
-
Index
SCTP Link No.
1
2
2
-
CDMA2000 1X
CDMA2000 1X and
EV-DO
SCTP
TCP
-------------------Index
BTS ID
BTS Name
BTS2266
BTS2267
Link Type
Subrack No.=>
Traffic Link
Traffic Link
2
2
1
2
2266
2267
Index
SPUO Slot No.
SPUO Subsystem No.
Interface Board
Slot No.
Link Mode=>
1
2
10
10
1
1
18
14
ETH
PPP
Index
Logic Link No.
System Type
Bandwidth (Kbps)=>
1
2
0
1(1)
1984
Index
BTS Link Bandwidth

(Kbps)
Link Flag
BTS Signaling IP=>

Address
1
2
66
-
2
1
80.126.8.218
80.126.8.219
Index
BTS Interface
Board IP Address
Gateway IP Address
FP MUX Switch=>
1
2
10.10.10.10
12.23.25.26
150.150.150.11
-
Off
-
Index
FP MUX Time Out

(0.1ms)
Max Mux Subframe

length(Byte)
Max Mux Frame

length(Byte)
1
2
---
END
2. Check the status of the E1 links.

On the Service Maintenance System, run the DSP E1T1STAT command.
Issue 01 (2014-05-31)

212
+++
HW-Airbridge
2007-05-29 15:11:29
O&M
#89331
%%DSP E1T1STAT: FN=2, SN=14, BTP=PEUBa, E1T1NO=1;%%
Query Result
-----------Index
Slot
14
E1/T1No.
E1/
T1OperationalStatus
Aavailable
(Number of Results = 1)
---
END
3. Check whether the link configuration is consistent with physical connections.

According to the command output in 1, the E1 (E1 No.: 1) needs to be connected to the
BTS (BTSID: 2267). If the E1 1 is connected to another BTS, the BTS cannot be pinged
from the RAC. Check whether the E1 is connected to another BTS.
If the E1 is connected to (BTSID: 2267), contact Huawei technical support.
If the E1 is connected to another BTS, go to 4.
4. Modify the physical connections according to the data configuration, and then check whether
the BTS can be successfully pinged from the BAM.
If the BTS can be successfully pinged from the BAM, no further action is required.
If the BTS cannot be pinged from the BAM, contact Huawei technical support.
----End
Information about history alarms
Logs of interface boards
Issue 01 (2014-05-31)

213
16.4 Troubleshooting BTS Remote OM Failures

Symptom
The remote Service Maintenance System fails to ping the BTS. As a result, the BTS data
cannot be uploaded or downloaded, or board software cannot be loaded.
Cause
The symptoms of BTS remote OM failures are as follows:
The Abis interface link works normally, but the remote Service Maintenance System
fails to ping the BTS.
Uploading or downloading the BTS data fails.
The remote Service Maintenance System fails to display the working status of the BTS.
Loading board software fails.
Analysis
Table 16-1 describes possible causes of remote OM failures.
Table 16-1 Possible causes of remote OM failures
Possible Cause
Analysis
The BOOTP information is

incorrectly set.
If the Huawei RAC6690 is used, you do not need to

configure the BOOTP information.
If the Huawei RAC6600 and E1/T1 transmission links

are used, you need to configure the BOOTP information.
Run the LST BTSBTPINFO command to check whether

the BOOTP information is correctly set. Ensure
parameters such as the OM IP address and the VPI/VCI
are correctly set. After configuring the basic and BOOTP
information about the BTS, choose Start > Run on the
BAM, and then run ping XXX.XXX.XXX.XXX to check
whether the BTS OM link is correctly set. The
XXX.XXX.XXX.XXX represents the OM IP address of the
BTS.
Advanced FTP properties are
incorrectly set.
If advanced FTP properties are incorrectly set, uploading

or downloading data may fail.
The version of the software

on the BAM is not consistent
with the version of the BTS
software.
If the version of the software on the BAM is not consistent

with the version of the BTS software, the BAM may fail to
identify the BTS software. Consequently, loading software
fails.
The Abis transmission link is

faulty.
If OM failures result from a fault in the Abis transmission

link, the services of the BTS are affected. Therefore, if
OM failures occur but the services of the BTS run
normally, the Abis transmission link is normal.
The CMPT is faulty.
If the OMU in the CMPT is faulty, the OM fails. Check

whether the OMU in the CMPT is faulty by switching over
Issue 01 (2014-05-31)

214
Possible Cause
Analysis
active and standby CMPTs, or replacing the CMPT.
The OM link data is

incorrectly configured.
The BTS or RAC data may be incorrectly configured in

the following scenarios:
OM links are added.
The route is added.

Figure 16-1 shows the process for troubleshooting remote OM failures.
Figure 16-1 Flowchart for troubleshooting remote OM failures
1. Check whether the BAM is working properly.
Issue 01 (2014-05-31)

215
Check whether the BAM starts up normally, and the loading process is normal.
2. Check whether the transmission system is faulty.
Run the LST ALMFE command to query active alarms. The transmission system is faulty if
alarms related to E1/T1 links, FE links, or IMA/UNI/FRAC/PPP links are generated on the
Alarm Management System.
3. Check whether the BTS or the RAC is correctly configured.
Check whether the queried BTS type is consistent with the configuration.
Check whether the value of BTSTP set through the ADD BTS command is consistent
with the value of BTSCLASS set through the SET CBTSINFO command. If the
settings are not consistent, modify the settings to be consistent.
Check whether the route information on the BAM is correctly configured.
The BTS is managed through the Service Maintenance System on the BAM and data is
loaded from the BAM to the BTS. The BAM, however, fails to telnet to the BTS. In this case,
the route to the BAM may be incorrectly configured because signal streams are sent to the
BTS in form of IP packets during the telnet.
Check whether the data for Abis transmission is correctly configured.
Ping the BTS on the RAC. If the BTS cannot be pinged, the BOOTP information is
Run the LST BTSBTPINFO command to check whether the following BOOTP information
is correct:
BTS ID
OM IP address of the BTS
Slot No., subslot No., and optical port No. of the CLPC for the active/standby CMUX
that provides the OM link or the subrack No. of the CIPS that connects the RAC and the
BTS
Gateway IP address of the BTS
VCI/VPI
If the BOOTP information is incorrect, run the MOD BTSBTPINFO command to modify the
configuration.
4. Check whether advanced FTP properties are correctly configured.
If the BTS fails to upload or download data, the user name, password, or advanced FTP
properties may be incorrect.
On the BAM, check whether the user name omu is valid and whether the password is
correct. Ensure the user name and password are both omu. In the properties of the user,
ensure "Users cannot change the password" and "The password is permanently valid" are
selected.
Check whether the FTP service is enabled on the Internet service manager on the BAM.
Then, check whether the user right is correctly configured. Ensure the virtual path is
correctly configured and enabled. The virtual path must be consistent with the root path
of the loading path. For example, if the loading path is D:\btsload, the virtual path should
be D:.
5. Check whether the version of the software on the BAM is consistent with the version of the
BTS software.
Issue 01 (2014-05-31)

216
If the version of the software on the BAM is not consistent with the version of the BTS
software, the following failures occur and the BTS fails to identify the board No.:
Downloading or activating the FPGA software or the CPU software fails during the
board upgrade.
Each BTS board is marked with a gray cross on the remote Service Maintenance System
after an upgrade.
Ensure the version of the software on the BAM is consistent with the version of the BTS
software before an upgraded.
6. Check whether the voltage is normal.
Check whether the power system of the equipment room functions correctly. If the power
system is faulty, contact power system maintenance engineers from the customer.
Check whether AC/DC power equipment in the different types of BTSs is faulty. For details,
see Table 16-2.
Table 16-2 AC/DC supply devices for different types of BTSs
BTS Type
Checklist
DBS3900
The APM30 supplies power and the DCDU distributes power for the
BBU3900/RRU3606/ODU3601CE.
BTS3900
The external power system is correctly connected to the DCDU.
BTS3900A
The external power system is correctly connected to the cabinet.
BTS3900C
The external power system is correctly connected to the DCDU when DC

power is supplied or is correctly connected to the cabinet when AC
power is supplied.
BTS3606CE
BTS3606AC
7. Check whether the CMPT is faulty.

The OMU, the core of the OM channel, is built in the CMPT. If the CMPT is faulty, the OM
channel is disconnected.
If the BOOTP information is correctly set and the Abis transmission link is normal, the CMPT
may be faulty. Switch over active and standby CMPTs or replace the CMPT.
---End
Issue 01 (2014-05-31)

217
17
17 Troubleshooting Power Supply Failures
Troubleshooting Power Supply

Failures
17.1 Introduction to the BTS Power Supply

The DBS3900 supports 48 V DC or 220/110 V AC power supply.
17.1.1 Power Modules of the BBU3900, RRU3606, and

ODU3601CE
Power modules or power input ports are provided on the BBU3900, RRU3606, and
ODU3601CE.
Power supply of the BBU3900

The UPEU functions as the power module of the BBU3900. It converts 48 V DC to +12
V DC and supplies +12 V DC power to boards.
Power supply of the RRU3606

The RRU3606 provides RTN(+) and NEG(-) terminals on the cable distribution panel.
Both ports support 48 V DC power supply.
Power supply of the ODU3601CE

The power module of the ODU3601CE is classified into the MAPM and MDPM.
The MAPM supports 220 V AC and 110 V AC power supply.
The MDPM supports 48 V DC power supply.
17.1.2 AC/DC Power Equipment of the DBS3900

The AC/DC power equipment of the DBS3900 includes the DCDU, APM30 (AC type), and,
optionally, battery cabinet.
Table 17-1 and Table 17-2 list the AC/DC power equipment to be used when the DBS3900 is
installed indoors and outdoors.
Table 17-1 Indoor scenario
Power Input
Power Equipment
48 V DC
DCDU
Issue 01 (2014-05-31)

218
Table 17-2 Outdoor scenario

Power Input
Power Equipment
48 V DC
DCDU
220 V AC/110 V AC
APM30 (AC type) and battery cabinet (optional)
17.2 BBU Power Module Failures

The BTS power system consists of the BBU3900 power module, ODU3601CE power module,
and AC/DC power equipment. When the BTS cannot be powered on, or the BTS restarts
repeatedly and the cause of each restart varies, you must troubleshoot BTS power system
failures.
17.2.1 Troubleshooting BBU Power Module Failures

If the BBU3900 power module is faulty, ongoing services may be interrupted and chips may
be damaged. This section describes the symptom, analysis, and troubleshooting procedure of
BBU power module failures.
Symptom
The UPEU functions as the power module of the BBU3900, and works in active/standby
mode.
Table 17-3 describes symptoms of UPEU failures.
Table 17-3 Symptoms
Item
Symptom
Service
Services are interrupted.
Board status
The power indicator on the UPEU is off.
Alarm
The BTS may report the following alarms:
Power Board Failure
Board Input Voltage Too Low
Analysis
Table 17-4 describes possible causes of UPEU failures.
Issue 01 (2014-05-31)

219
Table 17-4 Possible causes

Possible Cause
Analysis
Power Board
Failure
The UPEU is not correctly installed in the slot.

The configured number and position of the UPEU are not consistent
with the actual conditions.
The UPEU is faulty and needs to be replaced.
Board Input
Voltage Too Low
The input voltage of the UPEU is beyond the range of 38.4 V DC to

57 V DC.

Figure 17-1 shows the process for troubleshooting BBU3900 power module failures.
Figure 17-1 Flowchart for troubleshooting BBU3900 power module failures
Issue 01 (2014-05-31)

220
1. Check whether the UPEU is correctly installed.
If the UPEU is not correctly installed, the Power Board Failure alarm is generated after you
run the LST ALMFE command.
Check whether the connector is securely inserted in the PWR port on the UPEU. If the
connector is loose, secure it.
Check whether the connector at the other end is correctly connected to the DCDU of the
cabinet.
2. Check whether parameters for the UPEU are correctly configured.
Run the DSP CBTSBBUPWRINFO command to check whether the configured number
and position of the UPEU are correct. The UPEU supports the active/standby working
mode.
If the configured number or position of the UPEU is incorrect, run the RMV
CBTSUPEU command to remove the UPEU. Then, run the ADD CBTSUPEU
command to configure the UPEU again.
3. Check whether the UPEU is faulty.

Replace the UPEU. If the fault is rectified, the original UPEU is faulty.
4. Check whether DC supply is faulty.
Check whether the input voltage of the UPEU is within the range from 38.4 V DC to
57 V DC.
If the input voltage is within the range from 38.4 V DC to 57 V DC, the external
DC supply is normal.
If the input voltage is beyond the range from 38.4 V DC to 57 V DC, the external
DC supply is faulty.
Check whether the DCDU is faulty.

For details, see instructions related to the DCDU.
----End
17.2.2 Troubleshooting ODU3601CE Power Module Failures

When the ODU3601CE power module fails, ongoing services may be interrupted and chips
may be damaged. This section describes the symptom, analysis, and troubleshooting
procedure of ODU power module failures.
Symptom
The MAPM/MDPM functions as the power module of the ODU3601CE.
Table 17-5 describes the symptoms of MAPM/MDPM failures.
Issue 01 (2014-05-31)

221
Table 17-5 Symptoms

Item
Symptom
Service
Board status
The INPUT indicator on the MAPM/MDPM is off.

The FAIL indicator on the MAPM/MDPM is on.
The OUTPUT indicator on the MAPM/MDPM is off.
Alarm
Power Board Failure
Analysis
Table 17-6 describes the possible causes of MAPM/MDPM failures.
Possible Cause
Analysis
Power Board Failure
The MAPM/MDPM is not correctly installed in the slot.

The MAPM/MDPM is faulty and needs to be replaced.
Board Input Voltage

Too Low
The input voltage of the MAPM/MDPM is beyond the following

range:
36 V DC to 57 V DC (48 V DC supply)
90 V AC to 135 V AC (110 V AC supply)

Figure 17-2 shows the process for troubleshooting ODU3601CE power module failures.
Issue 01 (2014-05-31)

222
Figure 17-2 Flowchart for troubleshooting ODU3601CE power module failures
1. Check whether the MAPM/MDPM is correctly installed.
Check whether the connector is securely inserted in the AC INPUT/DC INPUT port on
the MAPM/MDPM. If the connector is loose, secure it.
Check whether the connector at the other end is securely connected to the APM30. If the
connector is loose, secure it.
2. Check whether the MAPM/MDPM is faulty.

Replace the MAPM/MDPM. If the alarm is cleared, the original MAPM/MDPM is faulty.
3. Check whether AC/DC supply is faulty.
Issue 01 (2014-05-31)
Check whether the input voltage of the MAPM is within the range from 90 V AC to 135
V when 110 V AC power is supplied or is within the range from 176 V AC to 290 V AC
when 220 V AC power is supplied.

223
If the input voltage is within the range, the external AC power supply is normal.
If the input voltage is beyond the range, the AC power supply fails.
Check whether the input voltage of the MDPM is within the range from 36 V DC to
57 V DC.
If the input voltage is within the range, the external DC supply is normal.
If the input voltage of the MDPM is beyond the range, the DC supply is faulty.
Check whether the AC/DC power system is faulty.

For details, see the APM30 User Guide or the instructions related to the DCDU.
----End
17.3 Troubleshooting ODU3601CE Power Module Failures

ODU3601CE power module failures may interrupt ongoing services and damage chips. This
section describes the symptom, analysis, and troubleshooting procedure of ODU power
module failures.
Symptom
The ODU3601CE uses the power module MAPM/MDPM.
Table 17-7 describes symptoms of ODU3601CE power module failures.
Table 17-7 Symptoms
Item
Symptom
Service
Board status
The INPUT indicator on the MAPM/MDPM is off.

The FAIL indicator on the MAPM/MDPM is on.
The OUTPUT indicator on the MAPM/MDPM is off.
Alarm
Power Board Failure
Analysis
Table 17-8 describes possible causes of ODU3601CE power module failures.
Possible Cause
Analysis
Power Board Failure
The MAPM/MDPM is incorrectly installed in the slot.

The MAPM/MDPM is faulty and needs to be replaced.
Issue 01 (2014-05-31)

224
Possible Cause
Analysis
Board Input Voltage

Too Low
The input voltage of the MAPM/MDPM is beyond the

following ranges:
36 V DC to 57 V DC (48 V DC supply)

Figure 17-3 shows the process for troubleshooting ODU3601CE power module failures.
Figure 17-3 Flowchart for troubleshooting ODU3601CE power module failures
1. Check whether the MAPM/MDPM is correctly installed.
Issue 01 (2014-05-31)

225
Check whether the connector is securely inserted in the AC INPUT/DC INPUT port. If
the connector is loose, secure it.
Check whether the connector at the other end of the cable is securely connected to the
APM30. If the connector is loose, secure it.
2. Check whether the MAPM/MDPM is faulty.

Replace the MAPM/MDPM. If the fault is rectified, the original MAPM/MDPM is faulty.
3. Check whether the AC/DC supply is within the normal range.
Check whether the input voltage of the MAPM ranges from 90 V AC to 135 V AC when
110 V AC power is supplied or ranges from 176 V AC to 290 V AC when 220 V AC
power is supplied.
If the input voltage of the MAPM is within the range, the external AC supply is
normal.
If the input voltage of the MAPM is beyond the range, the external AC supply is
faulty.
Check whether the input voltage of the MDPM ranges from 36 V DC to 57 V DC.
If the input voltage of the MDPM is within the range, the external DC supply is
normal.
If the input voltage of the MDPM is beyond the range, the DC supply is faulty.
Check whether the AC/DC power system is faulty.

For details, see the APM30 User Guide or instructions related to the DCDU.
----End
Issue 01 (2014-05-31)

226
18
18 Troubleshooting BTS Environment Monitoring Failures
Troubleshooting BTS Environment

Monitoring Failures
18.1 Introduction to BTS Environment Monitoring

The BTS environment monitoring system consists of alarm ports, EMUA, and PMU. This
section describes BTS environment monitoring in terms of terminology, equipment, functions,
and specifications.
18.1.1 Terminology
The terminologies of BTS environment monitoring equipment are as follows:
Boolean value
A variable that determines the ON or OFF state
Analog value
A continuous variable such as the temperature and humidity
Dry contact
A port used for reporting equipment status
Active contact
A contact through which output signals carry output voltages
Basic port
Default ports used for monitoring water immersion, infrared rays, door status,
temperatures and humidity, and smoke
High level or low level

When you set parameters for Boolean extended ports on the BTS, you can set Alarm
Boolean to a high level or a low level. A high-level alarm is generated when the voltage
detector detects that the voltage level rises to a preset threshold after the switch of the
sensor or dry contact is on, as shown in Figure 18-1.
Issue 01 (2014-05-31)

227
Figure 18-1 Principle of the extended port alarm
A low-level alarm is generated under conditions opposite to that of a high-level alarm.
18.1.2 Environment Monitoring Equipment

Environment monitoring equipment for the DBS3900 includes the PMU and, optionally, the
EMUA. As the core of power management and environment monitoring, the PMU collects,
processes, and reports environment variables. In addition, the PMU has the following
functions:
Communicates with an upper-level device through the RS232/RS422 serial port.
Manages the power system and controls the charge and discharge of batteries.
Detects and reports information about water immersion, smoke, door status, and standby
Boolean values. Reports the ambient temperature, battery temperature, and standby
analog values.
Detects power distribution conditions and reports related alarms (including dry contact
alarms)
For details about the PMU, see the APM30 User Guide.
The EMUA is an environment monitoring unit. The EMUA monitors the following items:
Environment
Intrusion
Power distribution
For details about the EMUA, see the EMUA User Guide.
18.1.3 Environment Monitoring Equipment Functions

The PMU and EMUA monitor Boolean value signals, control value signals, current analog
signals, voltage analog signals, and environment value analog signals in real time.
Table 18-1 lists functions of the PMU and EMUA.
Issue 01 (2014-05-31)

228
Table 18-1 Functions of the PMU and EMUA

Equipment
Function Set
Function
PMU
Control value signal
Controls equalized/float charge and current limit

for batteries.
Provides overload protection for batteries.
Boolean value signal
Reports the AC Power Supply Lightning

Protector Failure alarm.
Reports the Auxiliary Battery Cabinet Lightning
Arrester alarm.
Reports the Cabinet Smoke Alarm or Cabinet
Access Control Alarm.
Current and voltage

analog signal
Reports current of the battery group.

Reports total load current.
Reports input voltage.
Power system
management
Reports PSU failures, and protects the PSU.

Reports communication failures between the
PSU and the PMU.
Reports alarms related to fuse status.
Reports alarms related to availability of mains.
Reports alarms related to mains overvoltage and
undervoltage.
EMUA
Boolean value signal
Reports the Cabinet Smoke Alarm, Cabinet

Access Control Alarm, and Cabinet Water
Immersion Alarm.
Environment value
analog signal
Reports the temperature in the cabinet (with

sensors).
Reports humidity in the cabinet (with sensors).
18.1.4 Specifications
Environmental specifications for the BTS include equipment storage, transportation, and
operating specifications. This section describes the requirements for the ambient temperature
and humidity of equipment operating.
Requirements for the operating temperature are as follows:
BBU: 10C to +55C
RRU: 40C to +52C
ODU: 40C to +70C
Requirements for the operating humidity are as follows:
Issue 01 (2014-05-31)
BBU:
Indoors: 5% to 95%
Outdoors: 5% to 100%
229
RRU: 5% to 100%
ODU: 5% to 100%
18.2 BTS Environment Monitoring Failures

The BTS environment monitoring system monitors equipment operations in real time. This
enables you to obtain real-time environmental information. This section describes the
symptom, analysis, and troubleshooting procedure of BTS environment monitoring failures.
Symptom
Table 18-2 describes symptoms of BTS environment monitoring failures.
Table 18-2 Symptoms
Item
Symptom
Board status
RUN and ALM indicators on the EMUA blink at 0.5 Hz.
Alarm
When the environmental specifications for the BTS are beyond the preset
range, alarms are generated and reported by the environment monitoring
equipment to the RAC. These alarms include:
Temperature of Equipment Room Too High/Low or Board

Temperature Too High/Low
Humidity of Equipment Room too High/Low
Smoke Alarm of Equipment Room/ Cabinet Smoke Alarm
Water-Logging Alarm of Equipment Room/Cabinet Water Immersion

Alarm
DC Over-Voltage Alarm/DC Under-Voltage Alarm
Failure of Reading Temperature Sensor
Access Control Alarm of Equipment Room/Cabinet Access Control

Alarm
Analysis
Table 18-3 describes possible causes of BTS environment monitoring failures.
Possible Cause
Analysis
Environmental
specifications are
beyond the preset
ranges.
Board temperature and

humidity alarm
Issue 01 (2014-05-31)
The ambient temperature/humidity is

excessively high or low when. For
example, a fire occurs in the equipment
room or the BTS fan is stalled.

230
Possible Cause
Analysis
Cabinet Smoke Alarm
Smoke exists in the cabinet. For

example, components in the cabinet are
burnt or a fire occurs in the cabinet.
Cabinet Water Immersion

Alarm
Water accumulates in the equipment

room.
DC Over-Voltage Alarm/DC
Under-Voltage Alarm
The DC voltage is unsteady, or the DC

alarm threshold is incorrectly set.
Failure of Reading
Temperature Sensor
The temperature sensor is faulty, or the

I2C bus connector is faulty.
Cabinet Access Control

Alarm
The cabinet door is open and needs to

be closed.
If automatic clearance of the cabinet door
control alarm is not configured, this alarm
persists after the cabinet door is closed. The
alarm needs to be manually cleared on the
Alarm Management System.
The environment
monitoring
device is
incorrectly
installed.
If the environment monitoring device is incorrectly installed or the

communication cable is faulty, communication fails between the
environment monitoring device and the BTS. As a result, alarms are
not generated when faults exist in the operating environment of the
BTS.
If faults exist in the operating environment of the BTS but alarms are
not generated, check the status of the CMPT, PMU, EMUA, and
backplane. If necessary, check whether the boards are faulty by
replacing or switching over the boards.

Figure 18-2 shows the process for troubleshooting BTS environment monitoring failures.
Issue 01 (2014-05-31)

231
Figure 18-2 Flowchart for troubleshooting BTS environment monitoring failures
1. Check whether environmental specifications of the BTS are beyond the preset ranges.
Clear related alarms. For details, see the alarm reference.
2. Check whether the environment monitoring device and related cables are correctly installed.
For details about how to install the EMUA, see the EMUA User Guide.
Issue 01 (2014-05-31)
Check whether the EMUA is powered on.

232
If the RUN indicator on the EMUA blinks at 0.5 Hz and the ALM indicator is off, the
EMUA is powered on. If the RUN indicator is off, the power cable may be reversely
connected. For a description of indicators, see the EMUA User Guide.
Check whether the EMUA is correctly installed, and whether the communication cable is
securely connected to the EMUA and CMPT.
Run the DSP CBTSEMUAINFO command to query EMUA information. If
"PMU-main processing module Communication Link Interrupted" is displayed in the
execution result, the EMUA or communication cable is incorrectly installed.
Check whether the cables are securely connected to the EMUA and the sensors.
For details about the ports on the EMUA and sensors, see the EMUA User Guide.
Check whether the DIP switches on the EMUA are correctly set.
The DIP switch enables or disables sensors. For example, if you want to enable the
water sensor, set the DIP switch for the water sensor to ON. For details about the DIP
switches on the EMUA, see the EMUA User Guide.
You need to set the DIP switch according to the communication protocol supported
by the BTS before the EMUA communicates with the BTS through the serial port.
For example, set the four bits of the SW_ADDR DIP switch to ON (0000) if the
protocol type used by the BTS is CDMA. For the indication of the SW_ADDR DIP
switch, see the EMUA User Guide.
3. Check whether the data of the environment monitoring device is correctly configured.
Run the DSP CBTSEMUA command to check whether the BTS environment
monitoring board is configured.
If the environment monitoring board is not configured, run the ADD CBTSEMUA
command to add an environment monitoring board.
Run the DSP CBTSENVALGEXTPORT, DSP CBTSENVSWTEXTPORT, DSP

CBTSENVTEMPPARA, and DSP CBTSENVHUMPARA commands to check
whether analog extended ports, Boolean value extended ports, and temperature and
humidity measurement ranges are added, respectively.
Check whether the environment monitoring device supports analog extended ports or
Boolean extended ports according to the instructions related to the environment
monitoring device.
Follow the instructions related to the environment monitoring device and check
whether the parameters are correctly set.
The temperature and humidity are analog values. Analog values must be set
according to the actual conditions and software configuration rules. For example, the
difference between the upper alarm threshold and the lower alarm threshold must be
greater than 2% of the measurement range of analog values.
4. Check whether the CMPT, EMUA, or PMU is faulty.

Replace the CMPT, EMUA, PMU, or backplane, and then check whether it is faulty. If the
BTS is configured with a standby CMPT, you can switch over active and standby CMPTs to
check whether the originally active CMPT is faulty.
a.
For details about how to replace the components in the BBU3900, see the BBU3900
User Guide.
b.
For details on how to replace the RRU3606, see the RRU3606 User Guide.
c.
For details about how to replace the components in the ODU3601CE, see the Airbridge
ODU3601CE User Guide.
----End
Issue 01 (2014-05-31)

233
19
19 Troubleshooting BTS Startup Failures
Troubleshooting BTS Startup Failures
19.1 Introduction to the BTS Startup Process

After the BTS is powered on, boards are initialized. Then, OM links are set up and satellites
are traced before software is loaded onto the boards. After that, the BTS sets up signaling
links and traffic links, and sets cell information. This process enables a normal operation of
the BTS.
Figure 19-1 shows the BTS startup process after the BTS is powered on.
Figure 19-1 Flowchart of the BTS startup process
Issue 01 (2014-05-31)

234
Board Initialization
After the BTS is powered on, the boot software on each board loads the BTS software from
the flash memory to the RAM, starts self-check and initialization, and sets up communication
links between boards. If initialization fails, the corresponding boards are reset.
Table 19-1 describes board status during board initialization.
Table 19-1 Board status
Item
Status
BTS board
When the CMPT is powered on and initialized, the RUN indicator

blinks at 4 Hz.
The ALM indicator blinks at different frequencies according to
severities of alarms related to boards.
Service
Maintenance
System
When the CMPT is initialized, the BTS is in a link-disconnected

state.
OM Link Setup
Before you remotely configure the BTS on the BAM, an OM link must be set up between the
BTS and the BAM. The physical transmission bearer between the BTS and the RAC can be
E1/T1 or FE cables. The transmission mode over the physical bearer can be ATM or IP. E1/T1
links support ATM or IP transmission, while FE links only support IP transmission. The BBU
currently supports IP over E1/T1 and IP over FE transmission.
If the Huawei RAC6690 is used, the information about the OM link needs to be configured on
the RAC, not on the BTS.
If the Huawei RAC6610 is used, the BTS sends two BOOTP requests to the RAC to obtain
the IP address of the CMPT, route information, and OM IP address of the BTS.
During the startup of the BTS, the CMPT sends the BOOTP request to the CBPE in the
RAC.
From the BOOTP request, the CBPE obtains information such as the IP address of the
CMPT and route information according to the information about the BOOTP
transmission channel.
The CBPE sends the CMPT the BOOTP response frame that contains the IP address of
the CMPT and other information.
The BTS obtains the OM IP address of the BTS, and sends the TCP link setup request to
the BAM.
The BAM receives this request, and the BTS sets up an OM link to the BAM.
If IP over FE transmission is used, BOOTP requests are not sent.
Satellite Tracing
After initialization, the CMPT/USCU traces satellites to obtain reliable clock signals.
Issue 01 (2014-05-31)
If satellite tracing fails, the CMPT/USCU restarts repeatedly.

235
If a standby CMPT is configured and the links of the standby CMPT are normal, the BTS
switches over the active and standby CMPTs.
BTS Software Loading

BTS software can be loaded from the BAM or the flash memory.
The BTS preferentially downloads configuration files from the BAM and then activates the
configuration files.
Table 19-2 shows board and link status when the BTS downloads configuration files from the
BAM.
Table 19-2 Board and link status
Item
Status
BTS board
Boards are reset, and ACT indicators on boards are on.
Service Maintenance
System
After configuration files are downloaded and activated, the status

of all boards is displayed on the equipment panel.
Correlated alarm
The link interruption alarm is generated.
If the BTS software version is not consistent with that on the BAM, the BTS automatically
downloads the BTS software from the BAM when the automatic download switch is on. If the
OM link to the BAM cannot be set up and the configuration files are available in the flash
memory of the CMPT, the BTS downloads the configuration files from the flash memory.
Signaling Link Setup

After the CMPT is configured, the CMPT sets up Abis signaling links by using configuration
parameters. This enables signaling exchange between the BTS and the RAC.
If all the Abis signaling links of the BTS are interrupted for 10 minutes, the BTS is
automatically reset.
Traffic Link Setup

After the BTS obtains a reliable clock source, the HCPM/HECM sets up an Abis traffic link
through the CMPT. This enables traffic data interchange between the BTS and the RAC.
Cell Setup
After Abis signaling links are set up, the BBU reports information about BTS resource
configuration to the RAC and requests logical configuration from the RAC. The RAC sends
cell configuration data to the BBU. The BTS configures carrier attributes, sets up common
channels, and updates overhead messages. This enables MSs to access the network and
initiate calls.
Issue 01 (2014-05-31)

236
19.2 BTS Startup Failures

If a fault occurs during the BTS startup process, it may result in BTS startup failures.
Therefore, BTS startup failures may involve one or more types of failures such as power
supply failures or clock system failures. This section describes the symptom, analysis, and
troubleshooting procedure of BTS startup failures.
Symptom
Table 19-3 lists symptoms of BTS startup failures.
Table 19-3 Symptoms
Item
Symptom
Service
The BTS is repeatedly reset.

A carrier repeatedly restarts.
Board
status
The RUN or ALM indicator on BTS boards blinks fast or the boards are in
offline state.
The CMPT is repeatedly reset.
Alarm
Physical link alarms
Physical link alarms are generated when signals on E1 links are lost, receive
signals on FE links are lost, frames on E1/T1 links are out of
synchronization, or FE link transmission develops an error.
OM link alarms
OM link alarms are generated when the communication link between the
RAC and the BTS is disconnected, or when the OM links between the CMPT
and other boards are disconnected.
Signaling/traffic link alarms
Signaling/traffic link alarms are generated when activated links are not
sufficient in the link group or when the Abis signaling link is disconnected.
GPS clock alarms
GPS clock alarms are generated when the satellites locked by the satellite
card are not sufficient, or when a short- or open-circuit occurs between the
satellite card and the satellite antenna.
Carrier resource alarms
Carrier resource alarms are generated when the sector carrier is incorrectly
configured, or when the ARFCN of the sector carrier is incorrect.
Configuration file loading alarms
Configuration file loading alarms are generated when configuration files

contain errors.
Issue 01 (2014-05-31)

237
Analysis
Table 19-4 describes possible causes of BTS startup failures.
Possible Cause
Analysis
The board hardware

is faulty.
The CMPT, or the slot for the

CMPT is faulty. The settings
of DIP switches are incorrect.
Alarms related to E1/T1, or FE transmission, are

generated.
The GPS clock signal cable is

not securely connected to the
CMPT.
Alarms indicating that satellites are unlocked, that

OM links are faulty, or that a short-circuit or an open
circuit occurs between the satellite card and the
satellite antenna are generated.
The slot of the HCPM/HECM

is faulty.
On the Service Maintenance System, the indicator on

the RF unit is gray and the indicator on the
HCPM/HECM is red. When the CSM chip is faulty,
the ACT indicator blinks at 0.25 Hz and the ALM
indicator is on.
Abis transmission is
faulty.
The bit error rate (BER) is excessively high in the loopback test conducted between
the transmission equipment room to the RAC or the BTS.
The transmission link is unavailable according to the query result, and alarms related
to E1/T1 links are generated.
The cabinet is
incorrectly grounded.
The transmission link is intermittently disconnected, or the BER of E1/T1 Link Too
High alarm is generated. The alarm is cleared after the BTS is powered off and reset.
The alarm, however, is generated again after the BTS runs for a certain period.
The power equipment

is faulty.
The AC/DC power equipment

(APM30 or DCDU) has no
power input, or the input
power is abnormal.
The equipment room is powered off.
The AC/DC power equipment

(APM30 or DCDU) has no
power output, or the output
power is abnormal.
The AC/DC power equipment has no power input, or

the input power is abnormal.
The power supply to the equipment room is not

switched on.
The AC power supply to the equipment room is
unstable.
The switch of the AC/DC power equipment is turned

off.
The AC/DC power equipment is faulty.
Issue 01 (2014-05-31)
The connection between the

AC/DC power equipment and
the DBS3900 (BBU/RRU) is
faulty.
The connection between the AC/DC power

equipment and the BBU/RRU is faulty if the output
power of the AC/DC power equipment is normal, but
the indicators on the panel of the BBU/RRU are off.

the BTS3900 is faulty.

equipment and the BTS3900 is faulty if the output
the indicators on the panels of BTS3900 components
are off.

238
Possible Cause
The GPS clock

system is faulty.
Analysis
the BTS3900A is faulty.

equipment and the BTS3900A is faulty if the output
the indicators on the panels of BTS3900A
components are off.

the BTS3900C is faulty.

equipment and the BTS3900C is faulty if the output
the indicators on the panels of BTS3900C
components are off.

the BTS3606CE is faulty.

equipment and the BTS3606CE is faulty if the output
the indicators on the panels of BTS3606CE
components are off.

the BTS3606AC is faulty.

equipment and the BTS3606AC is faulty if the
output power of the AC/DC power equipment is
normal, but the indicators on the panels of
BTS3606AC components are off.
The power module is faulty.
If the power module is faulty, services may be

interrupted.
The satellite card or the CMPT

is faulty.
Run the DSP CBTSBRDSPECSTAT command to

query the type of satellite card.
The satellite card is faulty if the number of traced
satellites is 0 when the GPS antenna is installed in a
proper position.
You can determine whether the number of traced
satellites is 0 in the following cases:
The query result shows the type of the satellite

card is unknown.
The type of the satellite card is queried, but the

Satellite Antenna Short-Circuited alarm is
generated.
The type of the satellite card is queried, but the

Number of Locked Satellites Insufficient alarm is
generated.
The CMPT is faulty if the type of the satellite card is

queried, but the Satellite Antenna Open Circuit alarm
is generated and the voltage at the GPS port on the
panel of the CMPT is 0 V DC or less than 4.5 V DC.
The GPS antenna system is
faulty.
Issue 01 (2014-05-31)
The BTS does not work. Run the SET CBTSCLK

command to set Reference Clock Source of High
Priority to INCLK. If the BTS is operational, the
GPS antenna system is faulty.

239
Possible Cause
Analysis
The installation position of the
GPS antenna is improper.
There are high buildings around the installation

position.
The antenna is located under a microwave antenna, a
high-voltage cable, or a TV tower.
The installation position is susceptible to lightning
strikes, or the antenna is beyond the coverage range
of a lightning rod.
The data
configuration is
incorrect, or is not
consistent with that of
the RAC.
Sector carrier resources or

local cell IDs are not
configured, or incorrectly
configured.
The indicators on the front panel of each board are

functional, but carrier resources are unavailable.
The mask or the IP address of

the OM link or the signaling
link is not configured, or
If the OM link is faulty, the BTS cannot upload

software.
The transmission resources are

not configured, or incorrectly
configured.
The transmission link number or the link group

number is incorrect, or beyond the value range.
The bands are not configured,

or incorrectly configured.
After the BTS starts, the OM link is set up but the

BTS fails to work.
If the signaling link is faulty, the BTS restarts

automatically every 10 minutes.
The BAM server is

faulty.
The BAM server is not started, or the load process on the BAM server is improper.
Therefore, the OM link cannot be set up and the BTS startup fails.
The temperature of
the BTS is beyond the
normal range.
The requirements for the ambient temperature of the BTS are as follows:
Ambient temperature for the DBS3900:
BBU3900: 10C to +55C
RRU3606: 40C to +52C
Ambient temperature for the BTS3900: 10C to +55C

Ambient temperature for the BTS3900A: 40C to +52C
Ambient temperature for the BTS3900C: 40C to +52C
Ambient temperature for the BTS3606CE: 5C to +55C
Ambient temperature for the BTS3606AC: 40C to +52C
Issue 01 (2014-05-31)

240

Figure 19-2 shows the procedure for troubleshooting BTS startup failures.
Figure 19-2 Flowchart for troubleshooting BTS startup failures
Issue 01 (2014-05-31)

241
1. Check the BAM server.
Check whether the fault is caused by BAM server problems. Check whether the BAM
server starts, and whether the load process is proper.
2. Check the transmission system.
Check whether the fault is caused by transmission system problems.
Run the LST ALMFE command to query the current alarms. The transmission system is
faulty if alarms related to the E1/T1 link, FE link, and IMA/UNI/FRAC/PPP link are
generated on the Alarm Management System.
For details about how to troubleshoot the transmission system, see chapter 15
"Troubleshooting Transmission Failures."
3. Check the data configuration.
Issue 01 (2014-05-31)

242
Check whether the fault is caused by incorrect data configurations.
Check the configurations of the sector carrier or local cell ID on the RAC and BTS.
On the BAM, run the LST CELL command to check whether the cell information is
configured, and whether the cell information configured on the RAC is consistent
with that configured on the BTS. Run the RMV CBTSCELL, ADD CBTSCELL,
MOD CELL, ADD CELL, or RMV CELL command to modify the cell resource
configuration.
CELLID configured on the MSC must be consistent with that configured on the RAC. LOCALCELLID
configured on the RAC must be consistent with that configured on the BTS.
Check the mask, OM IP address, or signaling link IP address on the RAC and the
BTS.
Run the LST RACBTSINF and LST BTS commands to check whether the OM IP
address configured on the RAC is consistent with that configured on the BTS.
On the BAM, run the DSP SIGLNKSTAT command to check the signaling link
status. If the signaling link is not set up, run the LST BTSLNK and DSP
CBTSTERSIGLNK commands to check whether data configurations such as the
mask or the signaling link IP address, on the BTS and RAC are consistent.
Check the transmission resources on the RAC and BTS.

Run the DSP CBTSLNK command to query information about the transmission link.
Configure an E1 link only for active/standby CMPTs.
Check the band information on the RAC.
Run the LST CDMACH command to check whether the band configuration is
correct. If the band configuration is incorrect, run the RMV CDMACH, ADD
CDMACH, or MOD CDMACH command to modify it.
4. Check the ambient temperature for the BTS.

Check whether the ambient temperature for the BTS is within the proper range.
Run the DSP CBTSENVPARA command to check whether the ambient temperature for
the BTS is within the proper range.
Before you run the DSP CBTSENVPARA command, ensure the BTS is equipped with
the Environment Monitoring Unit A (EMUA) and the Power Monitoring Unit (PMU). If
the ambient temperature for the BTS is beyond the normal range, adjust the ambient
temperature.
5. Check the GPS clock system.
Check whether the fault is caused by GPS clock system problems.
Check the satellite card and the CMPT.

Check whether the satellite card or the CMPT is faulty. If the satellite card or the
CMPT is faulty, replace the satellite card or the CMPT.
Bypass the surge protector.

Remove the surge protector, and then connect the two cables that were previously
connected to the surge protector. If the GPS antenna system is operational, the surge
protector is faulty, cables are not securely connected, or cables are inversely
connected. In such a case, replace the surge protector or reconnect the cables.
Issue 01 (2014-05-31)
Check the resistance between the shield layer and the core wire of the GPS antenna
feeder.

243
Disconnect the clock signal cable from the CMPT and disconnect the GPS antenna.
Use a multimeter to measure the resistance between the shield layer and the core wire
of the GPS antenna feeder. Ensure the resistance is more than one megaohm.
Shortcircuit the shield layer and the core wire at one end of the feeder. Check the
resistance between the shield layer and the core wire at the other end of the feeder.
Ensure the resistance is less than 10 ohms.
Check the outdoor connectors of the GPS antenna system.

Ensure all outdoor connectors are securely wrapped with waterproof tape.
Check the resistance of the GPS antenna.

Use a multimeter to measure the resistance of the GPS antenna.
If the resistance is less than 10 ohms, the GPS antenna is faulty. Replace the GPS
antenna.
If the resistance ranges from 150 ohms to 200 ohms, test the working current of the GPS
antenna.
6. Check the current of the GPS antenna.
Reconnect the antenna system. Disconnect the cable from the GPS port on the panel of
the CMPT. Connect the outer shell of the cable to the outer layer of the GPS port. Use a
multimeter to measure the current between the cable and the core wire of the GPS port.
If the current ranges from 20 mA to 30 mA, the GPS antenna is operational. If the GPS
antenna is faulty, replace it.
Check whether there are interference sources and obstacles around the GPS antenna.
High buildings or tall trees, and highpower microwave devices or radio broadcast
stations, affect the normal operation of the GPS antenna.
7. Check the power supply voltage.

Check whether the fault is caused by power supply problems.
Check whether the power system of the equipment room functions properly.
If the power system is faulty, ask the customer to resolve the power problems.
Based on Table 19-5, check the AC/DC power equipment of BTSs of different types.
Table 19-5 AC/DC power equipment of BTSs

BTS Type
Check Whether...
DBS3900
The APM30 and DCDU (the APM30 and DCDU have normal power
output) are securely connected to the BBU3900/RRU3606.
BTS3900
Whether the external power system is securely connected to the DCDU.
BTS3900A
The external power system is securely connected to the cabinet.
BTS3900C
Whether the external power system is securely connected to the DCDU

when DC power is supplied or to the cabinet when AC power is supplied.
BTS3606CE
BTS3606AC
8. Check the boards.
Issue 01 (2014-05-31)

244
Check whether the fault is caused by board faults.
Check the status of CMPT ports.

Table 19-6 describes the commands used for the different transmission types and
query results.
---End
Table 19-6 Commands used for different transmission types and query results
Type
Commands and Query Results
E1/T1
Run the DSP CBTSMLTDRPBRDSTAT command to query the resistance at

the CMPT port. The resistance at the CMPT port is 75 ohm if E1 transmission is
used. The resistance at the CMPT port is 100 ohms if T1 transmission is used.
FE
Run the DSP CBTSFEPORTINFO command. The query result includes the
link status and the loopback status.
Check the DIP switches on the CMPT and UELP.

For details about the DIP switches, see the DBS3900 Product Description.
Check the indicators on the panel of the CMPT.

If the RUN indicator blinks at 4 Hz, the CMPT is faulty. Replace the CMPT.
Check whether the GPS clock signal cable is securely connected to the GPS port on
the panel of the CMPT.
Insecure connection between the GPS clock signal cable and the GPS port may cause
unlocking of satellites. Before you determine whether the out-of-lock failure is
caused by a fault in the CMPT or the slot for the CMPT, run the SET CBTSCLK
command to set Reference Clock Source of High Priority to INCLK. If the fault is
rectified, the CMPT or the slot for the CMPT is normal. In this case, locate the
out-of-lock failure in the GPS antenna system.
Disconnect the GPS clock signal cable from the GPS port on the panel of the CMPT.
Connect the positive pole of a multimeter to the internal hole of the GPS port and the
negative pole to the outer shell. Then, test whether the output voltage of the GPS port
is less than 4.5 V DC or is 0 V DC. If the output voltage of the GPS port is abnormal,
the CMPT or the slot for the CMPT is faulty. Replace the CMPT or install the CMPT
in another slot.
Check the indicators on the panel of the HCPM/HCEM.

If the RUN indicator blinks at 4 Hz, the HCPM/HCEM is faulty. Replace the HCPM
or the HCEM.
If the ACT indicator blinks at 0.25 Hz and the ALM indicator is on, the CSM chip is
faulty. Replace the CSM chip.
Check the cabinet equipment.

The HCPM/HCEM sends synchronization clock signals to the RF module. Therefore,
if the HCPM/HCEM is faulty, the RF module functions improperly.
Check the grounding conditions of equipment.

Use a multimeter to test the resistance between the ground port of each device and the
ground bar of the equipment room. If the measured resistance is less than 10 ohms,
the devices are properly grounded.
----End
Issue 01 (2014-05-31)

245
Running logs of the BTS.
Issue 01 (2014-05-31)

246
CDMA WLL10.0
20 Troubleshooting BTS RF Failures
20
Troubleshooting BTS RF Failures
20.1 Introduction to the BTS RF

This chapter describes the system configuration, and modules of RF subsystems of different
BTSs.
DBS3900 RF Subsystem
The RRU3606 is the DBS3900 RF module. It receives and transmits radio signals, and
implements communication between MSs and the radio network system.
BTS3900 RF Subsystem
The CRFU is the BTS3900 RF module. It receives and transmits radio signals, and
BTS3900A RF Subsystem
The CRFU is the BTS3900A RF module. It receives and transmits radio signals, and
BTS3900C RF Subsystem
The RRU3606 is the BTS3900C RF module. It receives and transmits radio signals, and
BTS3606CE RF Subsystem
The STDM and SPAM are the BTS3606CE RF modules. They receive and transmit radio
signals, and implement communication between MSs and the radio network system.
The STDM contains two sub-modules: STRM and SDFU. The STRM supports
modulation and demodulation of baseband signals, up-conversion, and down-conversion.
The SDFU filters signals and performs duplex isolation.
The SPAM consists of three SPABs and one SPMB. The three SPABs amplify downlink
signals of three sectors. The SPMB processes signals reported by the SPABs, and ensures
the normal operation of the SPABs.
Issue 01 (2014-05-31)

247
CDMA WLL10.0
BTS3606AC RF Subsystem
The STDM and SPAM are the BTS3606CE RF modules. They receive and transmit radio
signals, and implement communication between MSs and the radio network system.
The STDM contains two sub-modules: STRM and SDFU. The STRM supports
modulation and demodulation of baseband signals, up-conversion, and down-conversion.
The SDFU filters signals and performs duplex isolation.
The SPAM consists of three SPABs and one SPMB. The three SPABs amplify downlink
signals of three sectors. The SPMB processes signals reported by the SPABs, and ensures
the normal operation of the SPABs.
20.2 Test and Analysis of the BTS Reverse RSSI

Before locating an RSSI fault, you must test the RSSI. This section describes how to test and
analyze reverse RSSI of fourth-generation BTSs.
20.2.1 Testing the Reverse RSSI

The reverse RSSI is tested in either local mode or remote mode. This section describes the
procedure for testing the reverse RSSI in local mode.
Local Mode and Remote Mode
To trace the reverse RSSI in remote mode, select RSSI Monitoring under Resource
Monitoring on the Service Maintenance System, or use Telnet to log in to the BTS.
To trace the reverse RSSI in local mode, connect a crossover cable to the CMPT, and use
Telnet to trace the reverse RSSI.
The commands for RSSI tracing are only applicable to RRUs or RFUs of
fourth-generation BTSs.
RSSI tracing does not stop when you end the Telnet connection. Therefore, you must
stop the tracing and disable serial port redirection when RSSI tracing in Telnet mode is
complete.
If the Telnet connection is ended improperly, enable serial port redirection again and stop
all tracing tasks.
The character string for the item parameter of the str infotrace command is case
sensitive.
The RSSI values obtained in local RSSI tracing are instantaneous values measured every
100 milliseconds. A value is reported every three seconds.
Precautions
Test Procedure
1. Connect cables as shown in Figure 20-1. Set the IP address of the PC to 172.16.16.1.
Issue 01 (2014-05-31)

248
CDMA WLL10.0
Figure 20-1 Cable connection
2. Choose Start > Run. In the Run dialog box, enter Telnet 172.16.16.16 to start the Telnet
program. Enter the user name and the password, and enable the automatic association.
AirBridge BTS3606 CDMA BTS Local Maintenance Console.
Copyright (C) 2000-2006 Huawei Technologies Co., Ltd. All Rights Reserved.
> User name: system
> Password :
HW CBTS>opnday
associational inputting on
3. Start the reverse RSSI tracing.
To enable serial port redirection, run the following command:
HW CBTS>str info
trace: brdtp=trm, brdid=0;
To start the tracing, run the following command:
HW CBTS>str infotrace: brdtp=trm, brdid=0, item="TrcRssi";

HW CBTS>
[2008-11-13 19:18:11]
RU0
: Chan 0 Rssi:(Main) -113.6 dbm,(Divs) -113.4 dbm,
Chan 1 Rssi:(Main) N/A dbm,(Divs) N/A dbm,
To stop the tracing, run the following command:
HW CBTS>str infotrace: brdtp=trm, brdid=0, item="StpRssi";
To disable serial port redirection, run the following command:
HW CBTS>stp infotrace: brdtp=trm, brdid=0;
---End
20.2.2 Analyzing Reverse RSSI Test Results

Analysis Procedure
1. Analyze the test results.
The following RSSI values are for reference only as the air interface quality varies at different sites.
Issue 01 (2014-05-31)

249
CDMA WLL10.0
If the average value of main RSSIs ranges from 116 dBm to 93 dBm, the receive main is
functional.
If the average value of diversity RSSIs ranges from 116 dBm to 93 dBm, the receive diversity is
functional.
If the main and diversity of the RRU3606/CRFU are both connected to the antenna system, the
difference between the average value of main RSSIs and the average value of diversity RSSIs must
be within 6 dBm.
2. Handle exceptions as required.

If an RSSI is not within the normal range, see section 20.3 "BTS Reverse RSSI
Exception" for troubleshooting.
---End
20.3 BTS Reverse RSSI Exception

If BTS reverse RSSI failures occur, the reverse sensitivity and reverse capacity of the BTS
decrease. This affects MS access to the network.
Symptom
The current and long-term RSSI information facilitates fault analysis and location. Current
information can be obtained through RSSI tracing on the Service Maintenance System or in
Telnet mode. Long-term RSSI information can be obtained from U2000 traffic statistics.
RSSI problems generally fall into the following three scenarios:
Scenario 1: The difference between the main RSSI and the diversity RSSI is higher than
6 dBm.
Scenario 2: The main RSSI is within the normal range from 116 dBm to 93 dBm, and
the diversity RSSI is lower than 116 dBm.
Scenario 3: Both main and diversity RSSIs are higher than 93 dBm.
Cause
Common causes of the RSSI exception are as follows:
The problem in scenario 1 is common and easy to resolve. It is generally caused by

engineering problems in the antenna system.
The problem in scenario 2 is generally caused by insecure connection of main and

diversity cables.
The problem in scenario 3 is more complicated and is related to factors such as

parameter setting, user operations, repeaters, a single subscriber, and narrowband
interference.
Analysis
Before going to a site, you must analyze relevant data on the U2000, or on the Service
Maintenance System. RSSI exception involves many factors and requires the customer and
network planners to work together to locate the problems. Data analysis involves the
following:
Issue 01 (2014-05-31)

250
CDMA WLL10.0
Analyze U2000 traffic statistics to obtain information on how the main and diversity
RSSIs change over time.
Test power change.
Scan the reverse spectrum.
Analyze the distribution of sites whose RSSIs are abnormal on the network plan map.
Analyze CDR data. Generally, CDR data is analyzed when MSs are considered to be
faulty.
Scenario 1: The difference between the main RSSI and the diversity RSSI is significant.
a.
When the RX_INB and RX_OUTA ports on one RFU/RRU are not connected to those
on another RFU/RRU, the diversity RSSI is within the normal range from 116 dBm to
93 dBm, and the difference between the main RSSI and the diversity RSSI is higher
than 6 dBm.
Symptom: When the RX_INB and RX_OUTA ports on one RFU/RRU are not connected
to those on another RFU/RRU, the diversity RSSI is within the normal range from 116
dBm to 93 dBm, and the difference between the main RSSI and the diversity RSSI is
higher than 6 dBm. If the diversity RSSI is below 116 dBm over a long period, the
possible cause is that the diversity feeder is not securely connected or the contact inside
the connector is poor.
The main feeder is improperly prepared, bringing cross-modulation interference to BTS

transmit power. This causes the RSSI exception.
Trace the main and diversity RSSIs on the Service Maintenance System in real time.
Run the MOD CDMACH command to set the baseband gains of all carriers carried on the
RFU/RRU. Do not change the RF gain. Check whether the difference between the main
RSSI and the diversity RSSI increases when the value of the baseband gain is set to 4000.
If the difference increases, set the value of the baseband gain to 1000 to check whether the
difference decreases and is within the normal range.
If either of the previous scenarios occurs, the main antenna system for this sector is faulty.
If the feeder is faulty, cross-modulation interference increases when the transmit power
increases. Cross-modulation interference decreases when the transmit power decreases.
Set the baseband gain of the carriers to the original values.
Issue 01 (2014-05-31)

251
CDMA WLL10.0
Add a load to locate which part of the feeder is faulty. A load is added to absorb the
transmit power of the BTS to exclude external factors for the RSSI exception.
Unblock the carriers and connect the load to the ANT_TX/RXA port on the RFU/RRU
whose antenna system is faulty. Then, check whether the difference between the main RSSI
and the diversity RSSI is lower than 6 dBm by tracing main and diversity RSSIs. If the
difference is lower than 6 dBm, the RFU/RRU is normal. If the difference is not lower than
6 dBm, the RFU/RRU is faulty.
Connect the load to the joint where the feeder and the jumper are connected on the
RFU/RRU side. Then, check whether the RFU/RRU and the jumper are normal. If they are
faulty, check the joints or replace the jumper.
Connect the load to the joint where the antenna and the jumper are connected. Then, check
whether the RFU/RRU, jumpers, and feeder are normal. If they are faulty, check the joints,
or replace the jumpers or the feeder. If they are normal, the antenna is faulty or the RSSI
exception is caused by external factors.
Connect the load to the joint where the jumper and the feeder are connected on the antenna
side. Then, check whether the RFU/RRU, jumper, and feeder are normal. If they are faulty,
check the joints, or replace the jumper or the feeder.
b.
When the RX_INB and RX_OUTA ports on one RFU/RRU are connected to those on
another RFU/RRU, the difference between the main RSSI and the diversity RSSI of one
sector is higher than 6 dBm.
Symptom: When the RX_INB and RX_OUTA ports on one RFU/RRU are connected to
those on another RFU/RRU, the difference between the main RSSI and the diversity RSSI
of one sector is higher than 6 dBm. The main RSSIs of all carriers carried on one
RFU/RRU are higher than 93 dBm, and the diversity RSSIs are within the normal range
from 116 dBm to 93 dBm. The main RSSIs of all carriers carried on the other RFU/RRU
are within the normal range from 116 dBm to 93 dBm, and diversity RSSIs are higher
than 93 dBm. For example: RFU0/RRU0 is configured with carriers 10 and 11, and
RFU1/RRU1 is configured with carriers 6 and 7. The main RSSIs of carriers 10 and 11 are
higher than 93 dBm, and the diversity RSSIs of carriers 10 and 11 are within the normal
range from 116 dBm to 93 dBm. The main RSSIs of carriers 6 and 7 are within the
normal range from 116 dBm to 93 dBm, and the diversity RSSIs of carriers 6 and 7 are
higher than 93 dBm.
Issue 01 (2014-05-31)

252
CDMA WLL10.0
When the RFUs/RRUs configured for a BTS work in active/standby mode, two feeders for
one sector are connected to the ANT_TX/RXA ports on the RFU/RRUs. In this case, when
the main RSSIs of the carriers are higher than 93 dBm, the antenna system connected to
the RFU/RRU carrying these carriers is faulty.
For example, if the main RSSIs of carriers 10 and 11 are higher than 93 dBm, the antenna
system connected to RFU0/RRU0 is faulty. If the main RSSIs of carriers 6 and 7 are higher
than 93 dBm, the antenna system connected to RFU1/RRU1 is faulty.
To check whether the antenna system is faulty, run the MOD CDMACH command to set
the baseband gain of all carriers carried on the RFU/RRU whose antenna system is faulty.
Do not change the RF gain. Then, check whether the difference between the main RSSI and
the diversity RSSI increases when the value of the baseband gain is set to 4000. If the
difference increases, set the value of the baseband gain to 1000 to check whether the
difference decreases and whether it is lower than 6 dBm.
If either of the previous scenarios occurs, the main feeder for this sector is faulty.
If the feeder is faulty, RSSI increases when the transmit power increases because
cross-modulation interference has increased. RSSI decreases when the transmit power
decreases because cross-modulation interference has decreased.
Set the baseband gain of all carriers to the original values.
Add a load to locate which end of the feeder is faulty. A load is added to absorb the
transmit power of the BTS to exclude external factors for the RSSI exception.
difference is lower than 6 dBm, the RFU/RRU is normal. Then, perform the next operation.
If the difference is not lower than 6 dBm, the RFU/RRU is faulty. Then, replace the
RFU/RRU.
RFU/RRU side. Then, check whether the RFU/RRU and the jumper work properly. If they
do not work properly, check the joints or replace the jumper.
Issue 01 (2014-05-31)

253
CDMA WLL10.0
whether the RFU/RRU, jumpers, and feeder work properly. If they do not work properly,
check the joints, or replace the jumpers or the feeder. If they work properly, the antenna is
faulty or the RSSI exception is caused by external factors.
side. Then, check whether the RFU/RRU, jumper, and feeder work properly. If they do not
work properly, check the joints, or replace the jumper or the feeder.
Scenario 2: The main RSSI is within the normal range from 116 dBm to 93 dBm, and the
diversity RSSI is lower than 116 dBm.
a.
When the RX_INB and RX_OUTA ports on one RFU/RRU are not connected to those
on another RFU/RRU, the main RSSI is within the normal range from 116 dBm to 93
dBm, but the diversity RSSI is lower than 116 dBm over a long period.
Symptom: When the RX_INB and RX_OUTA ports on one RFU/RRU are not connected
to those on another RFU/RRU, the main RSSI is within the normal range from 116 dBm
to 93 dBm, but the diversity RSSI is lower than 116 dBm over a long period.
This is caused by poor diversity reception performance.
If the BTS is a distributed base station, check whether a jumper is connected to the
ANT_RXB port on the RRU. If there is no jumper connected to this port, ignore the RSSI
exception.
If the BTS is an outdoor macro base station, check whether the diversity feeder works
properly using the following method: Switch the main and diversity feeders with each
other. Then, check the transmit power and voltage standing wave ratio (VSWR) of the
carrier. If the VSWR is higher than 2, one end of the feeder is disconnected or not securely
connected.
Add a load to locate the problem. A load is added to absorb the transmit power of the BTS
to exclude external factors for the RSSI exception.
RFU/RRU.
Issue 01 (2014-05-31)

254
CDMA WLL10.0
b.
When the RX_INB and RX_OUTA ports on one RFU/RRU are connected to those on
another RFU/RRU, the main RSSI is within the normal range from 116 dBm to 93
dBm, but the diversity RSSI is lower than 116 dBm over a long period.
Symptom: When the RX_INB and RX_OUTA ports on one RFU/RRU are connected to
those on another RFU/RRU, the main RSSI is within the normal range from 116 dBm to
93 dBm, but the diversity RSSI is lower than 116 dBm over a long period.
Check whether the cables between the RFUs/RRUs are securely connected and the
diversity bypass switch is enabled.
This is caused by poor diversity reception performance.
If the BTS is an outdoor macro base station, check whether the diversity feeder works
properly using the following method: Switch the main and diversity feeders with each
other. Then, check the transmit power and VSWR of the carrier. If the VSWR is higher
than 2, one end of the feeder is disconnected or not securely connected.
Add a load to locate the problem. A load is added to absorb the transmit power of the BTS
to exclude external factors for the RSSI exception.
RFU/RRU.
Issue 01 (2014-05-31)

255
CDMA WLL10.0
RFU/RRU side. Then, check whether the RFU/RRU and the jumper work properly. If they
do not work properly, check the joints or replace the jumper.
Connect the load to the joint where the feeder and the jumper are connected on the antenna
Scenario 3: Both main and diversity RSSIs are higher than 93 dBm.
a.
Both main and diversity RSSIs of all carriers of a sector are higher than 93 dBm, and
this is not affected by traffic changes.
Symptom: Both main and diversity RSSIs of all carriers of a sector are higher than 93
dBm, and this is not affected by traffic changes.
If the BTS is a distributed base station, the RSSI exception is caused by the distributed
system. Add a load to confirm that the RSSI exception is not caused by the RFU/RRU.
If the BTS is an outdoor base station, check whether the RSSI exception is caused by a
radio repeater, because the radio repeater affects the signals when receiving and amplifying
the signals on a whole band.
On the Service Maintenance System, run the STR CBTSRVSWITFERMNIT:; command

to start the reverse spectrum scanning function. Then, test the spectrum of external signals
using this function. Name the results after the BTS ID and save files to
D:\Airbridge\services\BTSITFLOG.
Replay the spectrum using the Nastar and analyze the traffic statistics on the U2000 to
check whether the spectrum exceptions are consistent with the abnormal traffic statistics.
If the spectrum shape is

and the band is between 825 MHz and 835 MHz,
the RSSI exception is caused by the interference of the radio repeater.
Issue 01 (2014-05-31)

256
CDMA WLL10.0
Based on the previous operations, the interference source is in the range the sector covers
but the exact place cannot be located. In this case, test the RSSIs of other BTSs around the
current BTS to locate the interference source using the following method: On the Mapinfo,
locate the BTSs whose RSSIs are abnormal around the current BTS. Then, trace and
analyze the spectrum and traffic statistics of those BTSs using the method mentioned
previously. Finally, locate the interference source according to the node of different
directions where RSSI exceptions occur.
Locating method: Start locating the interference source at the BTS where the RSSI is
greatly affected. Then, locate the interference source using the YBT250 along the antenna
direction of the sector where the RSSI exception occurs.
Yagi-Uda antennas are widely used for most radio repeaters and are installed on the
building top or an open area. Therefore, locate the interference source using the YBT250 at
a place with a higher altitude.
The power of a radio repeater is low. Therefore, there is a clear wave on the spectrum
analyzer only when the distance between the spectrum analyzer and the antenna is shorter
than 200 m. After the interference source is located, power off the radio repeater to check
whether the RSSI is normal.
b.
Both main and diversity RSSIs of all carriers of a sector are higher than 93 dBm, and
this is greatly affected by traffic changes. The RSSI is higher than 93 dBm in daytime,
and is within the normal range from 116 dBm to 93 dBm at night.
Symptom: Both main and diversity RSSIs of all carriers of a sector are higher than 93
dBm, and this is greatly affected by traffic changes. The RSSI is higher than 93 dBm in
daytime, and is within the normal range from 116 dBm to 93 dBm at night.
To locate the problem, check the items in the following sequence: network optimization
parameters, neighboring cell, heavy traffic, and interference source.
For network optimization parameters, check the RegZone and Location Area Code
parameters, and access parameters to confirm the values of these parameters for the BTS
with abnormal RSSIs are the same as those for other BTSs.
Issue 01 (2014-05-31)

257
CDMA WLL10.0
Both main and diversity RSSIs of all carriers of a sector are higher than 93 dBm because
two sectors are not configured as neighboring sectors. As a result, an MS cannot be handed
off to the target sector with strong pilot signals and the MS transmit power automatically
increases. Then, the base noise of the target sector increases. This affects other MSs in the
target sector. Finally, main and diversity RSSIs increase.
Some MSs try to access the network many times when there is a heavy traffic. As a result,
main and diversity RSSIs increase. This can be determined after the traffic statistics for
carrier traffic and congestion are analyzed.
A radio repeater affects the BTS with abnormal RSSIs 24 hours every day. When MSs are
within the coverage range of the radio repeater, and the traffic of the MSs differs greatly in
daytime and at night, main and diversity RSSIs may increase. Use the following method to
check whether main and diversity RSSIs increase due to an interference source: Trace the
reverse spectrum and analyze it using the Nastar. If the spectrum shape is
and the band is between 825 MHz and 835 MHz, the RSSI exception is caused by the
interference of a radio repeater.
Based on the previous operations, the interference source is in the range the sector covers
but the exact place cannot be located. In this case, test the RSSIs of other BTSs around the
current BTS to locate the interference source using the following method: On the Mapinfo,
locate the BTSs whose RSSIs are abnormal around the current BTS. Then, trace and
analyze the spectrum and traffic statistics of those BTSs using the method mentioned
previously. Finally, locate the interference source according to the node of different
directions where RSSI exceptions occur.
Locating method: Start locating the interference source at the BTS where the RSSI is
greatly affected. Then, locate the interference source using the YBT250 along the antenna
direction of the sector where the RSSI exception occurs.
Yagi-Uda antennas are widely used for most radio repeaters and are installed on the
building top or an open area. Therefore, locate the interference source using the YBT250 at
a place with a higher altitude.
The power of a radio repeater is low. Therefore, there is a clear wave on the spectrum
analyzer only when the distance between the spectrum analyzer and the antenna is shorter
than 200 m. After the interference source is located, power off the radio repeater to check
whether the RSSI is normal.
Issue 01 (2014-05-31)

258
CDMA WLL10.0
c.
Both main and diversity RSSIs of some carriers of a sector are higher than 93 dBm.
Symptom: Both main and diversity RSSIs of some carriers of a sector
are higher than 93 dBm.
Check whether the carriers are affected by traffic changes.
If the carriers are affected by traffic changes,

check the configuration of network
optimization parameters and neighboring
relationship between cells.
For network optimization
parameters, check the
RegZone and Location Area
Code parameters, and
access parameters to
confirm that the values of
these parameters for the
BTS with abnormal RSSIs
are the same as those for
other BTSs.
Both main and diversity

RSSIs of all carriers of a
sector are higher than 93
dBm because two sectors
are not configured as
neighboring sectors. As a
result, an MS cannot be
handed off to the target
sector with strong pilot
signals, and the MS transmit
power automatically
increases. Then, the base
noise of the target sector
increases. This affects other
MSs in the target sector.
Finally, main and diversity
RSSIs increase.
Locate the interference

source using the YBT250.
On the Mapinfo, locate the

BTSs with abnormal RSSIs
around the current BTS.
Then, trace and analyze the
spectrums and traffic
statistics of those BTSs
using the method
mentioned previously.
Locate the interference
source according to the
node of different directions
where RSSI exceptions
occur.
If it is not affected by traffic changes, the RSSI

exception occurs due to the narrowband
interference or excessively high-power
interference of a single MS.
Trace the reverse spectrum on the BAM and compare

the traffic statistics with the collected information. If
narrowband (100 MHz to 200 MHz) interference
signals exist when traffic statistics deteriorate, and this
band is consistent with that of the interfered carriers,
the RSSI exception occurs due to the narrowband
interference.
If the spectrum analyzer scans the signals

with a bandwidth of 1.25 MHz, and scanning time
is the same as that when traffic statistics
deteriorate, the RSSI exception occurs due to the
strong interference of CDMA MSs.
Locate the MSs by identifying the MSs with the

maximum transmit power over a long period of time
according to the CDR.
After obtaining the international mobile subscriber

identity (IMSI), conduct a test using the MSs with the
help of local telecom engineers.
Check whether a neighboring

relationship is configured for
cells and whether the priority
is reasonable.
20.4 Troubleshooting BTS VSWR Failures

When the impedance of an antenna does not match that of a feeder, the antenna cannot receive
all high frequency energy transmitted through the feeder, and some of the energy forms
reflected waves. If the reflected wave or VSWR is too high, the transmit power decreases or
increases, and the coverage range diminishes. This section describes the symptoms, analysis,
and troubleshooting procedure for BTS VSWR failures.
Symptom
Table 20-1 describes the symptoms of the BTS standing wave.
Issue 01 (2014-05-31)

259
CDMA WLL10.0
Table 20-1 Symptoms of the BTS standing wave

Item
Symptom
Service
The MS cannot receive signals or can only receive weak signals. This
may lead to call drops. The coverage range of the BTS or the sector
carrier diminishes.
Status of the RF
module
The RF module is abnormal.
Alarm
A large number of standing wave alarms are generated.
Alarms related to the RF system are generated.
Analysis
Table 20-2 describes the possible causes of BTS standing wave failures.
Table 20-2 Possible causes of BTS standing wave failures
Possible Cause
Analysis
The antenna
system is faulty.
Engineering quality
The joint between the antenna and the feeder

is not well wrapped, the joint between the
jumper and the feeder is not well wrapped, or
the jumper connector is improperly prepared.
Antenna quality
The antenna is damaged or is not protected

from water leakage.
Delivery mistake
The jumper connector does not match the

jumper.
The RF module
is faulty.
When the frequency configured during the execution of the ADD

CDMACH command is consistent with that supported by the RF
module, check whether the frequency supported by the RF module is
within the frequency range supported by the duplexer. If the frequency
is beyond the range, standing wave alarms are generated.
The standing wave alarms are seldom generated by faults in the RF
module. Therefore, replacing the RF module is an option only when
you fail to locate the fault using other methods.
Issue 01 (2014-05-31)

260
CDMA WLL10.0

Figure 20-2 shows the process for troubleshooting the BTS standing wave failures.
Figure 20-2 Flowchart for troubleshooting BTS standing wave failures
1. Check the antenna system.
Check whether the faults are caused by the antenna system. When checking the antenna
system, adhere to the following rules.
Issue 01 (2014-05-31)
If the antenna is damaged, the antenna system is open-circuited. If water enters the
antenna, the antenna system is short-circuited. In either of the preceding situations, the
VSWR is higher than 4.0. In normal situations, the VSWR must be lower than 1.5. The
thresholds for the standing wave alarms are as follows:
If the VSWR is higher than 4.0, the standing wave alarm is generated.
If the VSWR ranges from 2.5 to 4.0 and the RRU/CRFU is used as the RF module,
the standing wave alarm is generated.
If the RF module is STDM and the VSWR ranges from 2.0 to 4.0, the standing wave
alarm is generated.
In other cases, the standing wave alarm is not generated.
When the BTS is put into service, test the BTS coverage and record details of the test
location.

261
CDMA WLL10.0
After any standing wave alarm is generated, perform the coverage level test for the BTS
and compare results with the information recorded when the BTS is put into service. If
coverage is not affected, the alarms are false. If the coverage is affected and the TX level
of the power amplifier is normal, the fault may be in the antenna system.
To measure the VSWR of the antenna system, connect the RF jumper connector at the
cabinet top to the input port of the SiteMaster.
If the BTS is functional, the VSWR must be smaller than 1.5. If the VSWR is equal to or
greater than 1.5, check the antenna system. Use a SiteMaster to locate the position with
the greatest echo loss. Then examine the construction.

When installing the antenna system, ensure that the feeders are securely connected to the
RF output port and the feeders are not crossed. Errors are mostly found in a BTS that
serves multiple sectors.

Check whether the feeder connectors are properly prepared, whether the connectors are
waterproofed, and whether the cables are intact.
Ensure that the connectors are well prepared, effective waterproofing measures are taken,
no water leaks are found in the connectors and cables, and cables are intact. The sites
that have significant temperature difference are prone to water penetration. If the feeder
is faulty, replace it with a new one of the same type.
Check the antenna.

Check whether the antenna is damaged and whether there is any trace of water leakage
on the connectors of the antenna and jumpers. Ensure the antenna is intact. There must
be no water damage on the connectors of the antenna and jumpers. If the antenna is
faulty, contact Huawei technical support.
2. Check the RF module.

Check whether the faults are caused by the RF module.
Run the LST CELL command to check whether the frequency band of the cell is
consistent with that supported by the RF module.
If the frequency band of the cell is incorrect, modify the data configuration.
If the RF module does not support the required band, replace the RF module.
Before you remove the RF cable or replace the RF components, power off the RF module.
If the fault persists when the antenna system is normal, replace the RF module and check
whether the fault is rectified.
----End
Follow-up Procedure
If faults persist, contact Huawei technical support.
Issue 01 (2014-05-31)

262
CDMA WLL10.0
21 Subscriber Data Resource Failures
21
Subscriber Data Resource Failures
21.1 Introduction to the Subscriber Data Resources

This describes how to define or delete a subscriber, how to modify an IMSI, and how to
modify a PN.
This section applies to the scenario where the V5 interface is used. When the A+ interface is
used, the user data is managed by the LE (Huawei NGN).
Defining a Subscriber
Before providing the RAC services to a subscriber, you must define the subscriber first.
The prerequisites for defining a subscriber are as follows:
The IMSI of the subscriber is included in the IMSIs allocated to the RAC.
The mapping between the IMSI and the A-KEY or the ESN is configured.
The PN of the subscriber belongs to a configured PN resource.
The IMSI and the PN specified for this subscriber are not used by other subscribers.
Deleting a Subscriber
To stop providing the RAC services to a subscriber, you must delete the subscriber. After the
subscriber is deleted, the PN and the IMSI of the subscriber can be used by other subscribers.
You can delete a subscriber by using a forcible or non-forcible method.
When you select a method of deleting a subscriber, note that:
If you use the forcible method, you can delete a subscriber even if the subscriber is in a
call or is engaged in other services. In addition, the call or the ongoing services are
forcibly interrupted.
If you use the non-forcible method, you cannot delete a subscriber who is in a call or is
engaged in other service.
If you delete subscribers in batches, the specified subscribers are forcibly deleted
irrespective of whether the Forcibly deleting a subscriber field is set to YES or NO.
Issue 01 (2014-05-31)

263
CDMA WLL10.0
Modifying an IMSI
Modifying an IMSI refers to modifying the IMSI of a subscriber and the A-KEY and the ESN
that correspond to the IMSI without changing the PN of the subscriber.
When you modify the IMSI of a subscriber, note that:
The new IMSI used in the modification belongs to an IMSI resource that is administered
by the HDB. In addition, the A-KEY and the ESN that correspond to the new IMSI are
correctly configured.
If you use the forcible method, you can modify the IMSI of a subscriber who is in a call
or is engaged in other services.
If you do not use the forcible method, you cannot modify the IMSI of a subscriber who is
in a call or is engaged in other services.
When you modify the IMSI of a subscriber, only the ESN and A-KEY of the subscriber
are modified if the new IMSI is the same as the original IMSI. In this case, the forcible
method of modifying the IMSI is unavailable.
If the new IMSI is different from the original IMSI, you can use the forcible or
non-forcible method to modify the IMSI of the subscriber based on the requirements of
the subscriber.
Modifying a PN
When you modify the PN of a subscriber, ensure that the new PN belongs to a configured PN
resource and that the related V5 resource is correctly configured.
Modifying the PN of a subscriber does not affect the in-process call or other ongoing services
of the subscriber.
21.2 Defining a Subscriber Fails

This describes the subscriber definition failures and the troubleshooting procedure.
Troubleshooting
Issue 01 (2014-05-31)

264
CDMA WLL10.0

Start
1
Check the HDataMan

process
Is the process
normal?
2
No
Restart the HDataMan

process
Yes
Check whether the IMSI or
the PN is used
Is the
IMSI or the PN
used?
Yes
Use a new IMSI or PN
No
Check the IMSI-RAC

correspondence
Is the
correspondence
configured?
5
No
Add the IMSI-RAC

correspondence
Yes
Check the PN-subrack
correspondence
Is the
correspondence
configured?
7
No
Add the PN-subrack

correspondence
Yes
Check the IMSI-AKEY-ESN
correspondence
Is the
correspondence
configured?
9
No
Add the IMSI-AKEY-ESN

correspondence
Yes
Check the V5 basic velocity
port table
Is the table
configured?
11
No
10
Add the V5 basic velocity

port table
Yes
Redefine the MS
End
Issue 01 (2014-05-31)

265
CDMA WLL10.0
Procedure
1. Check the HDataMan process.
Start the BAM Manager and check whether the status of the HDataMan process is Started.
If the status is not Started, restart the HDataMan process and provide the log under the
directory D:\AirBridge\Services\Log to the Huawei local office.
2. Check whether the IMSI or the PN is used.
1.
On the Service Maintenance System, check whether the IMSI is used. For example,
For example,
DSP SUBSCR: SUBSCRINFO=IMSI, IMSI="460030912120001", NEEDSECRETDATA=NO;
If data on the IMSI are displayed, you can infer that the IMSI is used and you cannot use
this IMSI to define a subscriber.
If no data on the IMSI are displayed, you can use this IMSI after you delete the
corresponding subscriber or modify the PN of the corresponding MS.
2.
On the Service Maintenance System, check whether the PN is used.

For example,
DSP SUBSCR: SUBSCRINFO=PN, PN="6005001", NEEDSECRETDATA=NO;
If data on the PN are displayed, you can infer that the PN is used and you cannot use this
PN to define a subscriber.
If no data on the PN are displayed, you can use this PN after you delete the
corresponding subscriber or modify the PN of the corresponding MS.
3. Check the IMSI-RAC mapping.

LST IMSIBSC: BSCIP="129.11.17.1";
Check whether the IMSI is in the IMSI segments administered by the RAC. If the IMSI is not
in the IMSI segments administered by the RAC, add the mapping between the IMSI and the
RAC or modify the IMSI of the MS.
4. Add the IMSI-RAC mapping.
ADD IMSIBSC: IMSIMASK="4600309", BSCIP="129.11.17.1";
5. Check the PN-subrack mapping.

LST PNSUBRCK:;
Check whether the PN is in the PN segments. If the PN is not in the PN segments, add a new
PN segment.
6. Add the PN-subrack mapping.
ADD PNSUBRCK: BPN="6000000", EPN="9000000", FN=3;
Issue 01 (2014-05-31)

266
CDMA WLL10.0
7. Check the IMSI-A-KEY-ESN mapping.

LST IMSIA-KEYESN: INFO=IMSI, IMSI="460030912120001";
If no data are displayed, add the IMSI-A-KEY-ESN mapping.

8. Add the IMSI-A-KEY-ESN mapping.
ADD IMSIA-KEYESN: IMSI="460030912120001", A-KEY="1234567890123456", AUTOREGESNOPT=NO,
ESN="12345678";
9. Check the V5 basic velocity port table.

LST V5BAPORT: V5INFO=TELNO, TELNO="6005000";
If no data are displayed, add the V5 basic velocity port table.

10. Add the V5 basic velocity port table.
ADD V5BAPORT: FN=3, DID=DID_ASL_V52, V5ID=0, L3ADDR=0, TELNO="6005000";
The configuration of the V5 resources must be consistent with that on the LE.
11. Redefine the subscriber.

Redefine the subscriber and check whether the fault is rectified.
----End
21.3 Deleting a Subscriber Fails

This describes the subscriber deletion failures and the troubleshooting procedure.
Troubleshooting
Issue 01 (2014-05-31)

267
CDMA WLL10.0
Start
1
Check the HDataMan

process
Is the process
normal?
No

process
Yes
Check whether the
subscriber is defined
Is the subscriber
defined?
3
No
Deleting the subscriber fails
Yes
Check whether the
subscriber is in a call
Is the subscriber in
a call?
4
No
Rectify other faults
Yes
Forcibly delete the
subscriber
End
Procedure
1. Check the HDataMan process.
Start the BAM Manager and check whether the status of the HDataMan process is Started.
If the status is not Started, restart the HDataMan process and provide the log under the
2. Check whether the subscriber is defined.
Issue 01 (2014-05-31)

268
CDMA WLL10.0

If no data are displayed, you can infer that the subscriber is defined and you cannot delete the
subscriber.
3. Check whether the subscriber is in a call.
DSP VDBUSER: NTYPE=PN, PN="6005000";
If the status of the subscriber is ACTIVE, you can infer that the subscriber is in a call and
you cannot delete this subscriber.
If you need to delete a subscriber who is in a call, go to Step 4.
4. Forcibly delete a subscriber.

RMV SUBSCR: SUBSCRINFO=PN, PN="6005006", IFFORCE=YES;
----End
21.4 Modifying an IMSI Fails

This describes the IMSI modification failures and the troubleshooting procedure.
Troubleshooting
Issue 01 (2014-05-31)

269
CDMA WLL10.0
Start
1
Check the HDataMan

process
Is the process
normal?
No

process
Yes
Check whether the
Is
the subscriber
defined?
No
Modifying the IMSI fails
Yes
Check whether the new

IMSI is used
Is the IMSI used?
Yes
Use another IMSI
No
Modify the IMSI
End
Procedure
1. Check whether the HDataMan process is normal.
Start the BAM Manager and check whether the status of the HDataMan process is Started. If
the status is not Started, restart the HDataMan process and provide the log under the
Issue 01 (2014-05-31)

270
CDMA WLL10.0
If no data are displayed, you can infer that the subscriber is not defined and you cannot
modify the IMSI for the subscriber.
3. Check whether the new IMSI is used.
DSP SUBSCR: SUBSCRINFO=IMSI, IMSI="460030912120001", NEEDSECRETDATA=NO;
If data on the new IMSI are displayed, you can infer that the new IMSI is used and you cannot
use this IMSI.
Ensure that that the new IMSI exists in the IMSI-RAC mapping, and that the IMSI-A-KEY-ESN
mapping is configured.
4. Modify the IMSI.

Run MOD SUBSCRIMSI to modify the IMSI. For example,
MOD SUBSCRIMSI: PN="50081000", IMSI="460030900010001", IFFORCE=NO;
If the new IMSI is identical with the original one, the subscriber data in the FAM are forcibly updated.
----End
21.5 Modifying a PN Fails

This describes the PN modification failures and the troubleshooting procedure.
Troubleshooting
Issue 01 (2014-05-31)

271
CDMA WLL10.0
Start
1
Check the HDataMan

process
Is the process
normal?
No

process
Yes
Check whether the
Is
the subscriber
defined?
No
Modifying the PN fails
Yes
Check whether the new PN

is used
Is the PN used?
Yes
Use another PN
No
Modify the PN
End
Procedure
1. Check whether the HDataMan process is normal.
Start the BAM Manager and check whether the status of the HDataMan process is Started. If
the status is not Started, restart the HDataMan process and provide the log under the
Issue 01 (2014-05-31)

272
CDMA WLL10.0
If no data are displayed, you can infer that the subscriber is not defined and you cannot
modify the PN for the subscriber.
3. Check whether the new PN is used.
Ensure that the new PN exists in the PN-subrack mapping, and that the V5 basic velocity port table is
configured.

If data on the new PN are displayed, you can infer that the new PN is used and you cannot use
this PN. Use another new PN that is not used.
4. Modify the PN.
Run MOD SUBSCRPN to modify the PN. For example,
MOD SUBSCRPN: SUBSCRINFO=PN, OLDPN="50081000", NEWPN="50081001";
----End
Issue 01 (2014-05-31)

273
CDMA WLL10.0
22 Roaming Billing Failures
22
Roaming Billing Failures
22.1 Introduction to the Roaming

This describes the procedure of the roaming MOC voice service.
This section applies to the scenario where the V5 interface is used. When the A+ interface is
used, the user data is managed by the LE (Huawei NGN).
Roaming is a process in which MS moves from the coverage area of one RAC system to the
coverage area of another RAC system. The services originated by an MS that roams to a new
coverage area are called roaming services.
Figure 22-1 shows the procedure of the roaming MOC voice service.
Figure 22-1 Procedure of the roaming MOC voice service
MS
VCN-V
BSS-V
LE
VCN-H
1.Origination Message
2.Base Station
Ack Order
3.Complete L3 Info:
CM Service Request
4.Roam CM Service
Request
5.ESTABLISH
6.ESTABLISH ACK
7.ALLOCATION
11.Channel Assignment
Message
10.Assignment
Request
9.Roam
Assignment Request
8.ALLOCAITON
COMPLETE
12.Tch Preamble
13.BS Ack Order
14.MS Ack Order
15.Service Connect
Message
16.Service Connect
Completion
17.Assignment
Complete
18.Roam Assignment
Complete
19.Send Called
Number(DTMF)
RingBack Tone
Issue 01 (2014-05-31)

275
CDMA WLL10.0
Procedure
2 MOC Failures shows the procedure of the roaming MOC voice service.
1.
Upon receipt of the CM_Service_Request message, the MSC-V resolves the cell
information carried in the CM_Service_Request message, computes the roaming billing
area code by using a specific roaming billing algorithm. Then the MSC-V constructs the
roaming billing area code in the Roam CM_Service_Request message and sends the
Roam CM_Service_Request message to the MSC-H.
2.
The MSC-H verifies the Roam CM_Service_Request message and decodes the
information in this message. Then the MSC-H constructs the roaming ID, the home
location information, and the access location information in the original ESTABLISH
message and sends this message to the LE.
22.2 LE Does Not Receive Any Roaming Billing

Information
The procedure applies for troubleshooting the problem that the LE does not receive any
roaming billing information.
Troubleshooting
Issue 01 (2014-05-31)

276
CDMA WLL10.0

Start
1
Check the roaming-related

system-level software
parameter and V5 software
parameter
2
Are
these parameters
enabled?
3
No
Yes
Check the correspondence
between the roaming
charging area number and
the roaming charging area
ID
4
Is the
correspondence
configured?
5
No
Add the correspondence

between the roaming
charging area number and
the roaming charging area
ID
Yes
between the cell and the
roaming charging area ID
Is the
correspondence
configured?
7
Enable the roaming-related

system-level software
parameter and V5 software
parameter
No

between the cell and the
roaming charging area ID
Yes
Check the roaming charging
area ID in the subscription
profile
8
Is the ID configured?
No

between the number
segment and the roaming
charging area ID
Yes
Is the
correspondence
configured?
Yes
No
between the number
segment and the roaming
charging area ID
End
Issue 01 (2014-05-31)

277
CDMA WLL10.0
Procedure
1. Check the roaming-related system-level software parameter and V5 software parameter.
1.
Check whether the roaming-related system-level software parameter is enabled.

Run the following command: LST V5SOFTPARA: V5PARAIDX=PARA36;
The output is as follows:
%%LST V5SOFTPARA: V5ID=2, V5PARAIDX=PARA36;%%
Execution result:
+++
HW-AirBridge
2007-07-19 16:45:27
O&M
#22900
%%LST V5SOFTPARA: FN=3;%%
Query V5 Software Parameter
--------------------------Subrack No. = 3
V5 Interface ID = 10
Parameter Index = PARA0(Reserved)
Parameter Value = 0
Subrack No.
V5 Interface ID
Parameter Index
Parameter Value
=
=
=
=
3
10
PARA1(AN Invoke TEI Cancellation Procedure)
Host does not initiate TEI cancellation procedure
Subrack No.
V5 Interface ID
Parameter Index
Parameter Value
=
=
=
=
3
10
PARA2(Reserved)
0
Subrack No.
V5 Interface ID
Parameter Index
Parameter Value
=
=
=
=
3
10
PARA3(Exchange Parameter)
Accelerated Synchronization Supported
Subrack No.
V5 Interface ID
Parameter Index
Parameter Value
=
=
=
=
3
10
PARA4(Link Fault Monitoring Timer)
5
TO BE CONTINUED
--END
2. Enable the roaming-related system-level software parameter and V5 software parameter.

Run MOD V5SOFTPARA to enable the roaming-related system-level software
parameter.
For example, MOD V5SOFTPARA: FN=3, V5ID=5, V5PARAIDX=PARA36,
V5PARAVAL36=YES;
3. Check the mapping between the roaming billing area number and the roaming billing area ID.
Issue 01 (2014-05-31)

278
CDMA WLL10.0
Run LST RCAREA to check whether the mapping between the roaming billing area number
and the roaming billing area ID is configured.
4. Add the mapping between the roaming billing area number and the roaming billing area ID.
Run ADD RCAREA to add the mapping between the roaming billing area number and the
roaming billing area ID.
5. Check the mapping between the cell and the roaming billing area ID.
Run LST CELL to check whether the mapping between the cell and the roaming billing area
ID is configured.
6. Add the mapping between the cell and the roaming billing area ID.
Run MOD CELL to add the mapping between the cell and the roaming billing area ID.
7. Check the roaming billing area ID in the subscription profile.
Run DSP SUBSCR to check whether the roaming billing area ID is configured in the
subscription profile.
If the output displays roaming billing Area ID List = -, -, -, you can infer that this ID is not
configured.
8. Check the mapping between the number segment and the roaming billing area ID.
Run LST RCPN to check whether the mapping between the number segment and the
roaming billing area ID is configured.
9. Add the mapping between the number segment and the roaming billing area ID.
Run ADD RCPN to add the mapping between the number segment and the roaming billing
area ID.
----End
Issue 01 (2014-05-31)

279

Troubleshooting PDF

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Troubleshooting PDF

Diunggah oleh

Hak Cipta:

Format Tersedia

CDMA WLL10.

HUAWEI TECHNOLOGIES CO., LTD.

Copyright Huawei Technologies Co., Ltd. 2014 All rights reserved.

Trademarks and Permissions

Huawei Technologies Co., Ltd.

Huawei Industrial Base

Huawei Proprietary and Confidential

CDMA WLL10.0 Troubleshooting Guide

This is the first official release. Compared with CDMA

Draft A release for CDMA WLL10.0.

Huawei Proprietary and Confidential

CDMA WLL10.0 Troubleshooting Guide

Huawei Proprietary and Confidential

CDMA WLL10.0 Troubleshooting Guide

1.8 Others ............................................................................................................................................................. 13

2 RAC Troubleshooting Process and Methods ........................................................................ 14

3 Single Point of Failure ............................................................................................................... 29

4 Troubleshooting Emergencies .................................................................................................. 33

5 Troubleshooting MS Access Failures ...................................................................................... 71

Huawei Proprietary and Confidential

CDMA WLL10.0 Troubleshooting Guide

6 Troubleshooting 1X MOC Failures ......................................................................................... 75

7 Troubleshooting MTC Failures ................................................................................................ 83

8 Troubleshooting Handoff Failures .......................................................................................... 87

9 Troubleshooting Registration Failures ................................................................................. 111

10 Troubleshooting Authentication Failures .......................................................................... 119

11 Troubleshooting 1X Data Service Failures ......................................................................... 139

Huawei Proprietary and Confidential

CDMA WLL10.0 Troubleshooting Guide

12 Troubleshooting EV-DO Data Service Failures ................................................................ 151

13 Troubleshooting License Failures........................................................................................ 169

14 Troubleshooting Clock Failures ........................................................................................... 177

15 Troubleshooting Transmission Failures ............................................................................ 187

Huawei Proprietary and Confidential

CDMA WLL10.0 Troubleshooting Guide

15.11 Troubleshooting V5 Link Failure ............................................................................................................. 201

16 Troubleshooting OM Failures .............................................................................................. 209

17 Troubleshooting Power Supply Failures ........................................................................... 218

18 Troubleshooting BTS Environment Monitoring Failures .............................................. 227

19 Troubleshooting BTS Startup Failures ............................................................................... 234

20 Troubleshooting BTS RF Failures ....................................................................................... 247

21 Subscriber Data Resource Failures ...................................................................................... 263

Huawei Proprietary and Confidential

CDMA WLL10.0 Troubleshooting Guide

22 Roaming Billing Failures ....................................................................................................... 275

Huawei Proprietary and Confidential

CDMA WLL10.0 Troubleshooting Guide

1.1 General Safety Precautions

1.1.1 All Safety Precautions

Huawei Proprietary and Confidential

CDMA WLL10.0 Troubleshooting Guide

1.1.3 Local Safety Regulations

1.1.4 General Installation Requirements

Only trained personnel are allowed to operate the equipment.

Only personnel authorized by Huawei are allowed to replace equipment or components,

1.1.5 Grounding Requirements

When installing equipment, ground it first. When removing equipment, disconnect

Do not damage grounding conductors.

Do not operate the equipment without a grounding conductor.

Equipment must be permanently connected to safety protection. Before operation, check

1.1.6 Human Safety

Do not operate equipment and cables during lightning strikes.

1.1.7 Equipment Safety