GBSS14.0 Troubleshooting Guide (02) (PDF) - en

GBSS14.
0
Troubleshooting Guide
Issue 02
Date 2012-11-07
HUAWEI TECHNOLOGIES CO., LTD.

Copyright Huawei Technologies Co., Ltd. 2012. 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 02 (2012-11-07) Huawei Proprietary and Confidential
Copyright Huawei Technologies Co., Ltd.
i
About This Document
Overview
This document provides methods for troubleshooting the GBSS in the following scenarios:
l Customers lodge complaints.
l Faults are discovered during routine maintenance.
l Equipment faults occur abruptly.
Product Version
The following table lists the product versions related to this document.
Product Name Product Version
BSC6900 V900R014C00
BSC6000 V900R014C00
BTS3900/BTS3900A/BTS3900L/
BTS3900AL/DBS3900
V900R014C00

Intended Audience
This document is intended for:
l Maintenance engineers
l Field engineers
Organization
1 Change in the GBSS Troubleshooting Guide
This chapter describes the changes in the GBSS Troubleshooting Guide.
2 Troubleshooting Procedure
This chapter describes the basic troubleshooting procedure and each step.
GBSS14.0
Troubleshooting Guide About This Document
ii
3 Common Maintenance Functions
This chapter describes common maintenance functions used during fault location.
4 Handover Problems
This chapter describes how to locate and troubleshoot handover problems.
5 Call Drops
This chapter describes how to locate and troubleshoot call drops.
6 Access Faults
This chapter describes how to locate and troubleshoot access faults.
7 Voice Problems
This chapter describes how to locate and troubleshoot voice problems.
8 PS Counter Problems
This chapter describes how to locate and troubleshoot PS counter problems.
9 PS Channel Faults
This chapter describes how to locate and troubleshoot PS channel faults.
10 Cell PS Service Faults
This chapter describes how to locate and troubleshoot cell PS service faults.
11 IP Transmission Faults
This chapter describes how to locate and troubleshoot IP transmission faults.
12 Interference Problems
This chapter describes how to locate and troubleshoot interference problems.
13 Faults on Main and Diversity RX Channels
This chapter describes how to locate and troubleshoot faults on main and diversity receive (RX)
channels.
14 No Traffic
This chapter describes how to locate and troubleshoot no traffic on 3900 series base stations.
15 Appendix: How to Collect Fault Information
When faults cannot be rectified by referring to this document, collect fault information for
Huawei technical support to quickly troubleshoot the faults. This section describes how to collect
fault information.
Conventions
Symbol Conventions
The symbols that may be found in this document are defined as follows.
GBSS14.0
iii
Symbol Description
Indicates a hazard with a high level of risk, which if not
avoided, will result in death or serious injury.
Indicates a hazard with a medium or low level of risk, which
if not avoided, could result in minor or moderate injury.
Indicates a potentially hazardous situation, which if not
avoided, could result in equipment damage, data loss,
performance degradation, or unexpected results.
Indicates a tip that may help you solve a problem or save
time.
Provides additional information to emphasize or supplement
important points of the main text.

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

Command Conventions
The command conventions that may be found in this document are defined as follows.
Boldface The keywords of a command line are in boldface.
Italic Command arguments are in italics.
[ ] Items (keywords or arguments) in brackets [ ] are optional.
{ x | y | ... } Optional items are grouped in braces and separated by
vertical bars. One item is selected.
[ x | y | ... ] Optional items are grouped in brackets and separated by
vertical bars. One item is selected or no item is selected.
GBSS14.0
iv
{ x | y | ... }
*
Optional items are grouped in braces and separated by
vertical bars. A minimum of one item or a maximum of all
items can be selected.
[ x | y | ... ]
*
Optional items are grouped in brackets and separated by
vertical bars. Several items or no item can be selected.

GUI Conventions
The GUI conventions that may be found in this document are defined as follows.
Boldface Buttons, menus, parameters, tabs, window, and dialog titles
are in boldface. For example, click OK.
> Multi-level menus are in boldface and separated by the ">"
signs. For example, choose File > Create > Folder.

Keyboard Operations
The keyboard operations that may be found in this document are defined as follows.
Format Description
Key Press the key. For example, press Enter and press Tab.
Key 1+Key 2 Press the keys concurrently. For example, pressing Ctrl+Alt
+A means the three keys should be pressed concurrently.
Key 1, Key 2 Press the keys in turn. For example, pressing Alt, A means
the two keys should be pressed in turn.

Mouse Operations
The mouse operations that may be found in this document are defined as follows.
Action Description
Click Select and release the primary mouse button without moving
the pointer.
Double-click Press the primary mouse button twice continuously and
quickly without moving the pointer.
Drag Press and hold the primary mouse button and move the
pointer to a certain position.
GBSS14.0
v
Contents
About This Document.....................................................................................................................ii
1 Change in the GBSS Troubleshooting Guide.........................................................................1
2 Troubleshooting Procedure.........................................................................................................3
2.1 Troubleshooting Flowchart.................................................................................................................................4
2.2 Collecting Fault Information..............................................................................................................................4
2.3 Determining a Fault Type...................................................................................................................................7
2.3.1 Fault Types................................................................................................................................................7
2.3.2 Methods for Determining a Fault Type.....................................................................................................8
2.4 Identifying Fault Causes.....................................................................................................................................9
2.5 Troubleshooting Faults.....................................................................................................................................10
2.5.1 Overview.................................................................................................................................................10
2.5.2 Methods for Troubleshooting Faults.......................................................................................................10
2.5.3 Follow-up Procedure...............................................................................................................................11
3 Common Maintenance Functions............................................................................................12
3.1 Maintenance Functions for Identifying Voice Problems..................................................................................13
3.1.1 Querying Call Resource Usage of an MS................................................................................................13
3.1.2 External Voice Loopback........................................................................................................................13
3.1.3 One-Way Audio Detection......................................................................................................................18
3.1.4 Crosstalk Detection..................................................................................................................................20
3.1.5 Optimizing Um Interface Crosstalk.........................................................................................................21
3.1.6 Binding MSs to BSC Resources..............................................................................................................21
3.1.7 Performing Dialing Tests on the Um Interface........................................................................................22
3.1.8 Performing Dialing Tests on the A Interface...........................................................................................22
3.1.9 Detecting Noise on the A Interface.........................................................................................................24
3.2 Maintenance Functions for Identifying Transmission Problems......................................................................25
3.2.1 Crossed Pair Detection............................................................................................................................25
3.2.2 Monitoring Port BER Seconds................................................................................................................28
3.2.3 Querying Ethernet Port Attributes...........................................................................................................28
3.2.4 Performing IP Loopback.........................................................................................................................29
3.2.5 BTS Tracing............................................................................................................................................30
3.3 Maintenance Functions for Identifying Um and RF Problems.........................................................................31
3.3.1 Monitoring Channel Interference Bands.................................................................................................31
GBSS14.0
Troubleshooting Guide Contents
vi
3.3.2 Testing Passive Intermodulation Interference Online.............................................................................32
3.3.3 Scanning Frequency Spectrum Online....................................................................................................33
3.4 Maintenance Functions Related to Interface Tracing.......................................................................................35
3.4.1 Tracing CS Domain Messages of a Single Subscriber............................................................................35
3.4.2 Tracing PS Domain Messages for a Single Subscriber...........................................................................37
3.5 Maintenance Functions for Identifying PS Problems.......................................................................................39
3.5.1 Monitoring Channel Status......................................................................................................................39
3.5.2 Performing a PDCH Loopback Test........................................................................................................41
3.6 Maintenance Functions for Identifying Clock Problems..................................................................................45
3.6.1 Querying BSC Clock Source Status........................................................................................................45
3.6.2 Querying BSC Board Clock Status.........................................................................................................46
3.6.3 Maintaining BTS Clock...........................................................................................................................47
3.7 Maintenance Functions Related to No Traffic..................................................................................................48
3.7.1 Reporting the No Traffic Alarm Independently......................................................................................48
3.7.2 No-Traffic Self-Healing..........................................................................................................................49
4 Handover Problems.....................................................................................................................51
4.1 Handover Principles.........................................................................................................................................52
4.1.1 Handover Procedure................................................................................................................................52
4.1.2 Handover Success Rate...........................................................................................................................54
4.2 Locating Handover Problems...........................................................................................................................57
4.2.1 Principles.................................................................................................................................................57
4.2.2 Procedure for Locating Handover Problems...........................................................................................57
4.3 Troubleshooting Handover Problems Due to Hardware Faults........................................................................62
4.4 Handover Problems Due to Incorrect Data Configurations..............................................................................65
4.5 Troubleshooting Handover Problems Due to Traffic Congestion in the Target Cell.......................................69
4.6 Troubleshooting Handover Problems Due to Poor Um Interface Quality.......................................................71
4.7 Troubleshooting Handover Problems Due to NE Faults..................................................................................75
4.8 Troubleshooting Handover Problems Due to Inappropriate Inter-BSC/Inter-MSC/Inter-RAT Interaction
................................................................................................................................................................................78
5 Call Drops.....................................................................................................................................83
5.1 Call Drop Rate..................................................................................................................................................84
5.2 Locating Call Drops..........................................................................................................................................85
5.2.1 Procedure for Locating Call Drops..........................................................................................................85
5.2.2 Counters Related to Call Drops...............................................................................................................89
5.2.3 Types of Call Drops.................................................................................................................................91
5.3 Troubleshooting Call Drops Due to Poor Um Interface Quality......................................................................94
5.4 Troubleshooting Call Drops Due to Equipment Faults....................................................................................99
5.5 Troubleshooting Call Drops Due to Transmission Faults..............................................................................103
5.6 Troubleshooting Call Drops Due to Incorrect Parameter Settings.................................................................104
6 Access Faults...............................................................................................................................111
6.1 Access Principles............................................................................................................................................113
6.2 Locating Access Faults...................................................................................................................................114
GBSS14.0
vii
6.2.1 Procedure for Locating Access Faults...................................................................................................115
6.2.2 Common Causes for Access Faults.......................................................................................................122
6.3 Troubleshooting Access Faults Due to Poor Um Interface Quality...............................................................126
6.4 Troubleshooting Low Immediate Assignment Success Rates Due to SDCCH Congestion..........................132
6.5 Troubleshooting Low Immediate Assignment Success Rates Due to Hardware or Transmission Faults
..............................................................................................................................................................................136
6.6 Troubleshooting Low Immediate Assignment Success Rates Due to Location Updates of Problem MSs
..............................................................................................................................................................................140
6.7 Troubleshooting Low Assignment Success Rates Due to TCH Congestion..................................................143
6.8 Troubleshooting Low Assignment Success Rates Due to Hardware or Transmission Faults........................147
6.9 Troubleshooting Low Assignment Success Rates Due to Inappropriate BSC Configuration.......................151
7 Voice Problems..........................................................................................................................156
7.1 GSM CS Signal Flow.....................................................................................................................................157
7.2 Common Voice Problems and Problem Location Methods...........................................................................162
7.3 Troubleshooting One-Way Audio or No Audio.............................................................................................163
7.4 Troubleshooting Noise...................................................................................................................................169
7.5 Troubleshooting Crosstalk..............................................................................................................................176
7.6 Troubleshooting Echoes.................................................................................................................................182
7.7 Troubleshooting Discontinuous Voice or Low MOS.....................................................................................187
8 PS Counter Problems................................................................................................................193
8.1 PS Counters....................................................................................................................................................194
8.2 Locating PS Counter Problems.......................................................................................................................195
8.2.1 Principles for Locating PS Counter Problems.......................................................................................195
8.2.2 Procedure for Locating PS Counter Problems.......................................................................................195
8.3 Troubleshooting Low TBF Establishment Success Rates..............................................................................196
8.4 Troubleshooting High TBF Call Drop Rates..................................................................................................205
8.5 Troubleshooting Low Average Throughput at the RLC Layer......................................................................212
8.6 Troubleshooting Low Percentage of High-Rate Coding Schemes to All Coding Schemes...........................219
8.7 Troubleshooting High RLC Data Block Retransmission Rates.....................................................................227
9 PS Channel Faults......................................................................................................................234
9.1 Identifying PS Channel Faults........................................................................................................................235
9.2 Locating PS Channel Faults...........................................................................................................................235
9.3 Troubleshooting PDCH Faults Due to Channel Inactivity.............................................................................237
9.4 Troubleshooting PDCH Faults Due to Channel Asynchronization................................................................245
10 Cell PS Service Faults.............................................................................................................253
10.1 Remarks on Cell PS Service Faults..............................................................................................................254
10.2 Locating Cell PS Service Faults...................................................................................................................254
10.3 Troubleshooting Cell PS Service Faults Due to Gb Interface Issues...........................................................260
10.4 Troubleshooting Cell PS Service Faults Due to Incorrect Data Configurations..........................................262
10.5 Troubleshooting Cell PS Service Faults Due to Hardware Issues................................................................264
10.6 Troubleshooting Cell PS Service Faults Due to Incorrect Cable Connections Inside the BSC...................266
GBSS14.0
viii
11 IP Transmission Faults...........................................................................................................268
11.1 Troubleshooting FE/GE Transmission Faults..............................................................................................269
11.2 Troubleshooting IP Layer Faults..................................................................................................................276
11.3 Troubleshooting PPP or MLPPP Link Faults...............................................................................................281
11.4 Troubleshooting LAPD Link Faults.............................................................................................................287
11.5 Troubleshooting SCTP Link Faults..............................................................................................................296
11.6 Troubleshooting IP Path Problems...............................................................................................................304
11.7 Troubleshooting DHCP Problems................................................................................................................310
11.8 Troubleshooting IP PM Activation Failures.................................................................................................316
11.9 Troubleshooting IP Clock Faults..................................................................................................................319
12 Interference Problems.............................................................................................................329
12.1 Interference...................................................................................................................................................330
12.2 Locating Interference Problems....................................................................................................................331
12.3 Troubleshooting Co-channel or Adjacent-Channel Interference..................................................................334
12.4 Troubleshooting Intermodulation Interference.............................................................................................336
12.5 Troubleshooting Interference from the CDMA Network.............................................................................341
12.6 Troubleshooting External Interference.........................................................................................................344
13 Faults on Main and Diversity RX Channels.......................................................................348
13.1 Principles of Main and Diversity Reception.................................................................................................349
13.2 Locating Faults on Main and Diversity RX Channels..................................................................................349
13.3 Troubleshooting Faults on Main and Diversity RX Channels Due to Incorrect Data Configurations.........351
13.4 Troubleshooting Faults on Main and Diversity RX Channels Due to Incorrect Antenna Connections.......354
13.5 Troubleshooting Faults on Main and Diversity RX Channels Due to Hardware Faults..............................358
14 No Traffic..................................................................................................................................361
14.1 Introduction to No Traffic............................................................................................................................362
14.2 Locating No Traffic......................................................................................................................................362
14.3 Troubleshooting No Traffic Due to No Calls...............................................................................................367
14.4 Troubleshooting No Traffic Due to Transmission or Equipment Faults......................................................368
14.5 Troubleshooting No Traffic Due to Incorrect Data Configurations.............................................................370
14.6 Troubleshooting No Traffic Due to Poor Um Interface Quality..................................................................372
14.7 Troubleshooting No Traffic Due to Antenna System Faults........................................................................374
14.8 Resetting.......................................................................................................................................................378
15 Appendix: How to Collect Fault Information....................................................................379
GBSS14.0
ix
1 Change in the GBSS Troubleshooting Guide
This chapter describes the changes in the GBSS Troubleshooting Guide.
02 (2012-11-07)
This is the second commercial release of GBSS14.0.
Compared with issue 01 (2012-06-30) of GBSS14.0, this issue does not include any new topics.
Compared with issue 01 (2012-06-30) of GBSS14.0, this issue incorporates the following
changes:
content Description
11.2 Troubleshooting IP Layer Faults The troubleshooting procedure is optimized.
11.4 Troubleshooting LAPD Link Faults The troubleshooting procedure is optimized.
11.5 Troubleshooting SCTP Link Faults The troubleshooting procedure is optimized.
11.6 Troubleshooting IP Path Problems The troubleshooting procedure is optimized.

Compared with issue 01 (2012-06-30) of GBSS14.0, this issue does not excludes any topics.
01 (2012-06-30)
This is the first commercial release of GBSS14.0.
Compared with issue Draft A (2012-04-26) of GBSS14.0, this issue does not include any new
topics.
Compared with issue Draft A (2012-04-26) of GBSS14.0, this issue incorporates the following
changes:
content Description
7.7 Troubleshooting Discontinuous Voice
or Low MOS
l The typical case is modified.

GBSS14.0
Troubleshooting Guide 1 Change in the GBSS Troubleshooting Guide
1
Compared with issue Draft A (2012-04-26) of GBSS14.0, this issue does not excludes any topics.
Draft A (2012-04-26)
This is the Draft A release of GBSS14.0.
Compared with issue 01 (2012-01-05) of GBSS13.0, this issue includes the following new topics:
l 3.1.9 Detecting Noise on the A Interface
l 3.2.5 BTS Tracing
l 3.5.2 Performing a PDCH Loopback Test
l 3.7 Maintenance Functions Related to No Traffic
l 3.7.1 Reporting the No Traffic Alarm Independently
l 3.7.2 No-Traffic Self-Healing
Compared with issue 01 (2012-01-05) of GBSS13.0, this issue incorporates the following
changes:
content Description
7.4 Troubleshooting Noise l The operations related to noise detection
are added to the troubleshooting
description.
l Voice log collection is added to the
problem location information table.
9.3 Troubleshooting PDCH Faults Due to
Channel Inactivity
The operations related to PDCH loopback
tests are added to the troubleshooting
description.
9.4 Troubleshooting PDCH Faults Due to
Channel Asynchronization
The operations related to PDCH loopback
tests are added to the troubleshooting
description.
11.4 Troubleshooting LAPD Link Faults The BTS tracing result is added to the
11.6 Troubleshooting IP Path Problems The BTS tracing result is added to the

Compared with issue 01 (2012-01-05) of GBSS13.0, this issue does not exclude any topics.
GBSS14.0
Troubleshooting Guide 1 Change in the GBSS Troubleshooting Guide
2
2 Troubleshooting Procedure
About This Chapter
This chapter describes the basic troubleshooting procedure and each step.
2.1 Troubleshooting Flowchart
This section shows the troubleshooting flowchart.
2.2 Collecting Fault Information
This section provides methods for collecting information about faults and describes the fault
information types.
2.3 Determining a Fault Type
After collecting fault information, analyze the symptoms to determine a fault type.
2.4 Identifying Fault Causes
To identify the specific cause of a fault, exclude possible causes by analyzing the symptoms.
2.5 Troubleshooting Faults
This section provides the methods for troubleshooting faults as well as follow-up procedures.
GBSS14.0
Troubleshooting Guide 2 Troubleshooting Procedure
3
2.1 Troubleshooting Flowchart
This section shows the troubleshooting flowchart.
Figure 2-1 shows the troubleshooting flowchart.
Figure 2-1 Troubleshooting flowchart

2.2 Collecting Fault Information
This section provides methods for collecting information about faults and describes the fault
information types.
Methods for Collecting Fault Information
Before troubleshooting a fault, collect the following information:
GBSS14.0
4
l Fault symptoms
l Time, place, and frequency of the fault
l Fault range and impact
l Equipment operating status before the fault occurs
l Operations performed on the equipment before the fault occurs and the operation results
l Alarms generated when the fault occurs and the associated alarms
l Board indicator status when the fault occurs
l Measures taken after the fault occurs and the effects of measures
The methods for collecting fault information are as follows:
l Obtain the symptoms, time, place, and frequency of the fault from the subscribers and
technical support engineers.
l Obtain the equipment operating status, symptoms, operations performed before the fault
occurs, as well as measures taken after the fault occurs and the effect of those measures
from the equipment operation and maintenance (O&M) engineers.
l Monitor the board indicator status and alarms reported on the LMT to understand the
software and hardware operating status.
l Simulate services, measure performance, and trace interface signaling messages to
understand the fault range and impact.
NOTE
If you encounter severe faults, do not troubleshoot the faults before determining the specific causes. In this
case, you are advised to collect sufficient information, or contact Huawei for technical support.
Fault Information Types
l Alarm information
Alarm information is exported by the BSS alarm system and reported with any combination
of the following: sounds, lights, indicators, or onscreen indications. Viewing the alarm
information is a common method for analyzing faults.
Alarm information includes a description of the fault symptoms and causes, as well as fault
rectification suggestions. Alarm information includes detailed information about hardware,
links, trunks, and CPU load.
In most cases, alarm information is sufficient to locate the specific cause of a fault.
Otherwise, you can use the alarm information with other information to locate a fault.
NOTE
For a description of the alarm system, see the BSC6900 GSM LMT User Guide. For details about
how to handle an alarm, see the BSC6900 GSM Alarm Reference.
l Indicator status
Indicators provide the operating status of boards, circuits, links, optical paths, or nodes.
Viewing the indicator status helps quickly locate the general cause of a fault. Because
indicator status is generally not informative enough to locate a fault, this information is
often used with the alarm information to locate a fault. Table 2-1 uses the SCUa as an
example to describe the board indicators.
GBSS14.0
5
Table 2-1 LEDs on the SCUa board
LED Color Status Description
RUN Green ON for 1s and OFF for 1s The board is functional.
ON for 0.125s and OFF
for 0.125s
The board is in loading
state.
ON There is power supply,
but the board is faulty.
OFF There is no power
supply, or the board is
faulty.
ALM Red OFF There is no alarm.
ON or blinking There is a fault alarm.
ACT Green ON The board is in active
mode.
OFF The board is in standby
mode.
LINK (at the
Ethernet port)
Green ON The link is well
connected.
OFF The link is disconnected.
ACT (at the
Ethernet port)
Green OFF There is no data
transmission over the
Ethernet port.
Blinking There is data
transmission over the
Ethernet port.

NOTE
For a description of indicators on various boards, see the BSC6900 GSM Hardware Description.
Operation and maintenance (O&M) engineers should be familiar with indicators to facilitate fault
location.
l Dialing test results
Dialing tests are performed to determine whether BSS services are normal. In addition,
dialing tests are performed to collect information such as MS signaling, network signaling,
and detailed fault symptom descriptions.
l Instrument measurement results
Instrument and meter measurement results are true indication of fault causes. Instrument
measurement results are widely used for power supply tests, signaling analysis, wave
analysis, and bit error detection. For example, the procedure for troubleshooting high call
drop rates at a site using a signaling analyzer is as follows:
Select some signaling messages related to call drops by using a signaling analyzer.
GBSS14.0
6
Analyze the signaling messages. The timing advance (TA) value approaches 63.
Change the data configuration to reduce the cell radius.
NOTE
For details about methods for using an instrument, see the related user guide.
l Traffic statistics
Traffic statistics are generally used to analyze service faults such as call drops and handover
problems.
Traffic statistics can be used with traced signaling messages to troubleshoot high call drop
rates, low handover success rates, or call exceptions.
NOTE
For details about how to use traffic statistics to analyze problems, see the BSC6900 GSM LMT User
Guide. For counter meanings, see the BSC6900 GSM Performance Counter Reference.
l Signaling messages traced over interfaces
Signaling messages are generally used to identify causes of call connection failures or inter-
site signaling interaction failures.
NOTE
For details about how to how to trace the signaling messages, see the BSC6900 GSM LMT User
Guide.
2.3 Determining a Fault Type
After collecting fault information, analyze the symptoms to determine a fault type.
You can also Contact Huawei Customer Service Center to determine a fault type.
NOTE
If a severe fault occurs, Contact Huawei Customer Service Center.
2.3.1 Fault Types
This section lists the fault types covered in this document.
l CS voice problems
l CS service faults
Handover problems
Call drops
Access problems
l PS service faults
PS counter problems
PS channel faults
No PS service available in a cell
l Equipment faults
IP transmission faults
Interference
Main diversity receive channel faults
No traffic
GBSS14.0
7
NOTE
Determine the fault type based on symptoms. Different fault types may have the same symptoms. For
example, call drops problems may have the same symptoms as handover problems. In this case, methods
for troubleshooting call drops problems will be linked to the methods for troubleshooting handover
problems.
2.3.2 Methods for Determining a Fault Type
This section describes methods for determining a fault type.
l Monitoring
Monitoring is a common method for determining fault ranges. You can observe alarms,
indicator status, and LMT panel status.
l Analysis of Top N deteriorating performance counters
This method can determine a fault type when performance counters deteriorate. With this
method, you can sort out the Top N deteriorating performance counters for cells and TRXs.
Then, you can determine whether performance counters for certain cells or an entire BSC
deteriorate. For specific cases, see 4 Handover Problems.
l Loopback tests
Loopback tests can locate transmission, link, and voice problems. Loopback tests are
classified into hardware loopback tests and software loopback tests. For specific cases, see
3.1.2 External Voice Loopback.
You can determine whether equipment operates normally and software parameters are set
correctly by checking the status of the transmission equipment, transmission channels,
services, and signaling interaction status after loop back tests are performed. Loopback
tests can also be performed to determine whether transmission faults occur or trunk
parameters are set incorrectly. During site deployment or trunk capacity expansion, BSS
trunk loopback tests can help determine whether trunk parameters and signaling link data
are configured correctly.
NOTE
Loopback tests are also performed to locate transmission faults.
l Process of elimination
This method can exclude both software problems and hardware problems. To exclude
software problems, disable a certain function or feature to check whether a fault can be
rectified. If the fault is rectified, the function or feature is abnormal. Otherwise, the function
or feature is normal.
To exclude hardware problems, replace faulty boards.
For example, when troubleshooting co-channel or adjacent-channel interference, replace
the cell ARFCN with an ARFCN without interference (such as an E-GSM900 ARFCN).
Then, check whether the interference problem is resolved.
l Regularity identification
Identifying problem regularity helps to narrow the fault range. When narrowing the fault
range, consider the following factors:
1. Whether a certain board is faulty
2. Whether a certain DSP is faulty
3. Whether a certain transmission path is faulty
4. Whether a certain TRX is faulty
5. Whether a certain type of MS is faulty
GBSS14.0
8
6. Whether a certain type of channel is faulty
7. Whether an enabled feature is abnormal, such as Flex TSC, downlink power control,
or BCCH power consumption reduction
8. Whether an alarm is reported multiple times
For example, if a Cell Out of Service alarm is reported, check whether one or multiple cells
are out of service.
If only one cell is out of service, the TRX serving this cell may be faulty, or the cell
data configurations may be incorrect.
If multiple cells are out of service, determine whether these cells are served by one or
multiple BTSs.
If these cells are served by one BTS, check whether any transmission alarms (such
as LAPD or E1 alarms) are reported. If any transmission alarms are reported, a power
failure or transmission faults may have occurred at the BTS.
If these cells are served by multiple BTSs, check whether these BTSs are located in
the same area. If these BTSs are located in the same area, the power may have failed
or the optical fibers in the area may be damaged.
l Comparison/Interchange
Problems can be identified by comparing faulty components with normal components or
by interchanging the possibly faulty components with normal components.
Use the comparison method when there is only a single fault type.
Use the interchange method when there are multiple fault types. Interchange can be
used for the following items:
1. TRXs and boards
2. Transmission cables
3. Antennas
4. ARFCNs
For example, when severe interference in a certain cell cannot be eliminated after
troubleshooting cable connection faults, interchange the antenna system for the abnormal
cell with that for a normal cell. If the interference is eliminated, the original antenna system
is faulty. For details, see the typical case in 12.4 Troubleshooting Intermodulation
Interference.
2.4 Identifying Fault Causes
To identify the specific cause of a fault, exclude possible causes by analyzing the symptoms.
Generally, you need to analyze the causes of the following faults:
l Service faults
When a CS or PS service fault occurs, check the interfaces within the BSS to determine
whether it is faulty. If the BSS is faulty, continue identifying the fault cause.
When a handover or access problem occurs, start measuring traffic statistics and tracing
signaling messages. Then, determine the fault location according to protocols.
l Subsystem faults
Subsystem faults include clock, interface link, and equipment faults. These faults have
narrow ranges and are generally associated with alarms. In addition, information including
GBSS14.0
9
board indicators and error messages is available. Therefore, it is easy to identify the causes
of subsystem faults.
2.5 Troubleshooting Faults
This section provides the methods for troubleshooting faults as well as follow-up procedures.
2.5.1 Overview
Troubleshooting faults is a process of taking proper measures to rectify faults and restore a
system to good working order. Methods for troubleshooting faults include cable connection
check, board replacement, data configuration modification, board switchover, and board
resetting.
Consider the following items when troubleshooting a fault:
l Use different troubleshooting procedures according to fault types.
l Verify that the fault is rectified after the troubleshooting procedure.
l After a fault is rectified, review the troubleshooting process, record the key points, and
provide preventive and improvement measures.
NOTE
When severe faults occur, Contact Huawei Customer Service Center.
2.5.2 Methods for Troubleshooting Faults
This section provides methods for troubleshooting faults.
l Fault isolation
Isolation is the act of isolating the fault location from the surrounding service unit to prevent
the fault from adversely impacting ongoing services.
For example, when a DSP on a DPU is faulty and the DPU cannot be replaced immediately,
run the MML command INH DSP to isolate the DSP. For details, see the typical case in
7.4 Troubleshooting Noise.
l Switchover/resetting
During a switchover, services are switched from an active device to a standby device. You
can compare the system operating status before and after the switchover. By resetting part
of a device or the whole device, you can determine the software operating status.
Exercise caution when using switchover/resetting methods for the following reasons:
Both methods are auxiliary methods used only in an emergency.
Both methods can prevent a fault from recurring in a short time due to software bugs.
However, they cannot identify the root cause of a problem. This may lead to equipment
faults or operation instability.
Resetting may lead to service interruptions or even system crash, affecting normal BSS
operations. For example, some or all services over the A interface are interrupted. In this
case, perform the following operations:
1. Check whether any A interface transmission alarms have been reported on the BSC.
2. Reset the MSC interface board communicating with the A interface board.
3. Switch over the active and standby A interface boards.
GBSS14.0
10
4. When the BSC works in BM/TC separated mode, switch over the active and standby
Ater interface boards in the BM subrack.
5. Switch over the XPU boards where SS7 signaling links are configured.
6. Perform local loopback tests on the port of the Ater interface board in the BM subrack.
Then, check whether the Ater interface board can receive messages it has sent.
l Replacement
If other methods are ineffective, replace faulty equipment such as boards, cables, or
antennas.
NOTE
1. If a fault persists after a board is replaced, reinsert the board instead of shipping the board back
to Huawei headquarters.
2. If no equipment is available for replacing the faulty equipment, remove and then reinstall the
equipment.
2.5.3 Follow-up Procedure
This section describes the handling operations performed after a fault is rectified.
l After a fault is rectified, query the equipment status, board indicators, and alarms to verify
that the faulty NE is operating normally. In addition, perform dialing tests and check traffic
statistics to verify that services are operating properly.
l If the fault persists, collect fault location information and Contact Huawei Customer Service
Center.
GBSS14.0
11
3 Common Maintenance Functions
About This Chapter
This chapter describes common maintenance functions used during fault location.
3.1 Maintenance Functions for Identifying Voice Problems
This section describes maintenance functions for identifying voice problems.
3.2 Maintenance Functions for Identifying Transmission Problems
This section describes maintenance functions for identifying transmission problems.
3.3 Maintenance Functions for Identifying Um and RF Problems
This section describes maintenance functions for identifying Um and RF problems.
3.4 Maintenance Functions Related to Interface Tracing
This section describes maintenance functions related to interface tracing.
3.5 Maintenance Functions for Identifying PS Problems
This section describes maintenance functions for identifying PS problems.
3.6 Maintenance Functions for Identifying Clock Problems
This section describes maintenance functions for identifying clock problems.
3.7 Maintenance Functions Related to No Traffic
This section describes the maintenance functions related to no traffic.
GBSS14.0
Troubleshooting Guide 3 Common Maintenance Functions
12
3.1 Maintenance Functions for Identifying Voice Problems
This section describes maintenance functions for identifying voice problems.
3.1.1 Querying Call Resource Usage of an MS
This section describes how to query the call resource usage of an MS.
Function Description
This function queries the call resource usage of an MS that has set up a call and is used to identify
BSS voice problems. The query can be performed by entering the MS's Mobile Station
International ISDN Number (MSISDN), International Mobile Subscriber Identity (IMSI),
Temporary Mobile Subscriber Identity (TMSI), or International Mobile Equipment Identity
(IMEI).
Procedure
1. On the LMT, run the MML command DSP CALLRES, then press Enter or click Assist.
2. Set User Query Type to BYTMSI(By TMSI), BYIMSI(By IMSI), BYMSISDN(By
MSISDN), or BYIMEI(By IMEI). The corresponding MS identifier (ID) is displayed.
NOTE
l If you set User Identity Type to BYMSISDN(By MSISDN), set the MSISDN to the number of
the peer end. When querying the call resource usage of the calling MS, set the MSISDN to the
called number. When querying the call resource usage of the called MS, set the MSISDN to the
calling number (the Calling Line Identification Presentation function must be enabled).
l If you set User Identity Type to BYTMSI(By TMSI) or BYIMSI(By IMSI), confirm the
reallocation policy configured on the MSC side. If the MS's TMSI is used to set up a call, set
User Query Type to BYTMSI(By TMSI) to query the call resource usage. If the MS's IMSI is
used to set up a call, set User Query Type to BYIMSI(By IMSI) to query the call resource
usage.
l If you set User Identity Type to BYIMEI(By IMEI), determine whether the MSC can obtain
the IMEI.
3. Set the ID based on the specified User Query Type. Then, click Exec.
Operation Results
The query result shows the call resource usage of the MS, including information about the BM
subrack, TC link, A interface, and Ater interface. The query result also includes information
such as digital signal processor (DSP) number, channel number, service type, circuit
identification codes (CICs) on the A interface, as well as timeslots occupied by the GEIUA,
GEIUB, and GEIUT.
3.1.2 External Voice Loopback
This section describes how to start or stop external voice loopback and query the status of the
current voice loopback.
Voice loopback refers to routing voice data back to its source over the same path it was sent on.
By comparing the sent voice with the looped-back voice, voice problems can be identified
GBSS14.0
13
segment by segment. This function is used to identify voice problems such as one-way audio,
no audio, crosstalk, or noise on a BSC or BTS.
Currently, voice loopback can be performed in all 14 positions of the BSC and BTS. Figure
3-1, Figure 3-2, and Figure 3-3 show 12 loopback positions in a BSC in three networking modes.
The loopback positions are the same for multi-core boards.
Figure 3-1 Abis over TDM + A over TDM

Figure 3-2 Abis over IP + A over TDM

Figure 3-3 Abis over TDM + A over IP
GBSS14.0
14

NOTE
1. TDM BTSs support only MSC-oriented loopback testing on the TMU. BTSs do not support loopback
testing on the TRU. Only IP BTSs and high-speed data link control (HDLC) BTSs support both MSC-
oriented and MS-oriented loopback testing on the DPTU.
2. In TDM networks, the loopback testing is performed over the Ater and Abis interfaces at 64 Kbit/s
whereas services are processed over the two interfaces at 16 Kbit/s or 8 Kbit/s. As a result, a loopback
test of the channel used by one subscriber will lead to loopback tests of the channels used by other
subscribers on the same 64 Kbit/s timeslot.
Procedure
l Choosing menu items
1. Click Device Maintenance on the LMT main page. The Device Maintenance tab
page is displayed.
2. On the BSC Maintenance tab page, choose BSC Maintenance > Maintain User
Resources > Remote Speech Channel Loopback. The Remote Speech Channel
Loopback dialog box is displayed.
3. In the Remote Speech Channel Loopback dialog box, set the parameters as required,
and click Start. A message is displayed, informing you that the loopback is
successfully started.
NOTE
l If you select MSISDN in the Trace Object Symbol Type area, set the MSISDN to the
number of the peer end.
l (Recommended) If the calling party is traced, set the MSISDN to the called number.
l If the called party is traced, set the MSISDN to the calling number (the Calling Line
Identification Presentation function must be enabled).
l If you select TMSI or IMSI in the Trace Object Symbol Type area, confirm the
reallocation policy configured on the MSC side.
l If the MS's TMSI is used to set up a call, you can select TMSI in the Trace Object
Symbol Type area to query the call resource usage.
l If the MS's IMSI is used to set up a call, set Trace Object Symbol Type to IMSI to
query the call resource usage.
l If you select IMEI in the Trace Object Symbol Type area, determine whether the MSC
can obtain the IMEI.
4. After the loopback is started, click Query to query the remote speech channel
loopback.
5. Click Cancel stop the remote speech loopback.
NOTE
To end a remote speech loopback, select IMSI, IMEI, TMSI, or MSIDSN in the Trace Object
Symbol Type area to ensure that the parameter setting in the Trace Object Symbol Type area
is the same as that is previously set for the loopback.
l Running MML commands
1. After a call is set up successfully, run the MML command STR CALLRESLOP on
the LMT, and press Enter or click Assist.
2. Set the relevant parameters, and click Exec to start the loopback
3. After the loopback is complete, run the MML command STP CALLRESLOP to stop
the loopback.
GBSS14.0
15
Operation Results
1. The expected loopback effect is TDM three-way audio. That is, subscriber A can
communicate with subscriber B. In addition, during an MS-oriented loopback test of the
channel used by subscriber A, subscriber A can hear his or her own voice and subscriber
B can hear subscriber A's voice. Three-way audio is not implemented in IP mode. Therefore,
in IP mode, subscriber B cannot hear subscriber A's voice during an MS-oriented loopback
on subscriber A.
2. Three-way audio is implemented for loopback testing in the BSC TC subrack in either TDM
or IP mode.
3. When FG2a is configured over the A, Abis, or Ater interface, a subscriber can hear his or
her own voice and the peer end's voice during a loopback over these interfaces, but the peer
end cannot hear any voice regardless of whether the loopback is MSC- or MS-oriented.
4. During a loopback on an IP BTS, a subscriber can hear his or her own voice and the peer
end's voice, but the peer end cannot hear any voice regardless of whether the loopback is
MSC-oriented or MS-oriented.
5. Table 3-1 lists the loopback results for various positions when the ID of subscriber A is
used to perform loopback. The results are similar if the ID of subscriber B is used.
Table 3-1 Loopback results
Loopback Position and
Direction
Interface
Board Type
Subscriber A Subscriber B
NSS Interface Unit (MSC
Direction)
TDM
interface
board
Can hear B but not
self
Can hear self but
not A
IP/HDLC
interface
board
Cannot hear self or
B
Can hear self but
not A
NSS Interface Unit (MS
Direction)
TDM
interface
board
Can hear self but
not B
Can hear A but
not self
IP/HDLC
interface
board
Can hear self but
not B
Cannot hear A or
self
NSS TC (Near Abis
Interface) (MSC Direction)
Can hear B but not
self
Can hear self but
not A
NSS TC (Near Abis
Interface) (MS Direction)
Can hear self but
not B
Can hear A but
not self
NSS TC (Near A Interface)
(MSC Direction)
Can hear B but not
self
Can hear self but
not A
NSS TC (Near A Interface)
(MS Direction)
Can hear self but
not B
Can hear A but
not self
NSS TNU (Near Abis
Can hear B but not
self
Can hear self but
not A
GBSS14.0
16
Direction
Interface
Board Type
NSS TNU (Near Abis
Can hear self but
not B
Can hear A but
not self
NSS TNU (Near A
Can hear B but not
self
Can hear self but
not A
NSS TNU (Near A
Can hear self but
not B
Can hear A but
not self
NSS Ater Interface Unit
(MSC Direction)
TDM
interface
board
Can hear B but not
self
Can hear self but
not A
IP/HDLC
interface
board
Cannot hear self or
B
Can hear self but
not A
NSS Ater Interface Unit
(MS Direction)
TDM
interface
board
Can hear self but
not B
Can hear A but
not self
IP/HDLC
interface
board
Can hear self but
not B
Cannot hear A or
self
BSS Ater Interface Unit
(MSC Direction)
TDM
interface
board
Can hear B but not
self
Can hear self but
not A
IP/HDLC
interface
board
Cannot hear self or
B
Can hear self but
not A
BSS Ater Interface Unit
(MS Direction)
TDM
interface
board
Can hear self but
not B
Can hear A but
not self
IP/HDLC
interface
board
Can hear self but
not B
Cannot hear A or
self
BSS TC (Near Abis
Can hear B but not
self
Can hear self but
not A
BSS TC (Near Abis
Can hear self but
not B
Can hear A but
not self
BSS TC (Near A Interface)
(MSC Direction)
Can hear B but not
self
Can hear self but
not A
BSS TC (Near A Interface)
(MS Direction)
Can hear self but
not B
Can hear A but
not self
GBSS14.0
17
Direction
Interface
Board Type
BSS TNU (Near Abis
Can hear B but not
self
Can hear self but
not A
BSS TNU(Near Abis
Can hear self but
not B
Can hear A but
not self
BSS TNU (Near A
Can hear B but not
self
Can hear self but
not A
BSS TNU (Near A
Can hear self but
not B
Can hear A but
not self
BSS Interface Unit (MSC
Direction)
TDM
interface
board
Can hear B but not
self
Can hear self but
not A
IP/HDLC
interface
board
Cannot hear self or
B
Can hear self but
not A
BSS Interface Unit (MS
Direction)
TDM
interface
board
Can hear self but
not B
Can hear A but
not self
IP/HDLC
interface
board
Can hear self but
not B
Cannot hear A or
self
TMU/PTU (MSC
Direction)
Non-IP BTS Can hear B but not
self
Can hear self but
not A
IP BTS Cannot hear self or
B
Can hear self but
not A
TMU/PTU (MS Direction) Non-IP BTS Can hear self but
not B
Can hear A but
not self
IP BTS Can hear self but
not B
Cannot hear A or
self

3.1.3 One-Way Audio Detection
This section describes how to detect one-way audio or no audio on the BSS.
This function is used to detect one-way audio or no audio by checking uplink and downlink
voice and data transmission of a BSC or BTS. When one-way audio or no audio is detected,
record the call resource information and determine the faulty device to efficiently identify the
problems.
GBSS14.0
18
NOTE
l One-way audio logs are saved in \bam\common\fam\famlogfmt\.
l BSC6900 V900R013 supports one-way audio detection in IP and TDM transmission modes.
l The BTS TRXs must support one-way audio detection. In addition, BTSs of GBSS 13.0 support one-
way audio detection in IP transmission mode.
l One-way audio detection cannot be used with the local switching function. Therefore, before enabling
one-way audio detection, ensure that the local switching function is disabled.
Procedure
Before one-way audio detection is enabled, check the transmission mode of the Abis interface
and run the MML commands SET BSCBASIC and SET GCELLSOFT. The specific
operations in different scenarios are described as follows:
l Scenario 1: TDM transmission is used for the A, Ater, and Abis interfaces.
1. SET BSCBASIC: SpeechAlmPeriod=12, SPEECHCHANALARMTHRES=10,
SPEECHCHANRESUMEALARMTHRES=6,
MuteTestLogStyle=LEV1_MUTETEST_LOG_REC-0&LEV2_MUTETEST_
LOG_REC-1&IP_MUTETEST_LOG_REC-0&CIC_MUTETEST_LOG_RE
C-0, SpeechErrorForceHOSwitch=OFF;
2. SET GCELLSOFT: IDTYPE=BYID, CELLID=0,
TCMUTEDETECTFLAG=ENABLE, MUTECHECKCLASS1PERIOD=5,
EXCEPFRAMETHRES=25, MUTECHECKCLASS2SWITCH=ENABLE,
DETECTFRAMEPERIOD=2, MUTECHECKPEIROD=4;
l Scenario 2: IP transmission is used for the A, Ater, and Abis interfaces.
MuteTestLogStyle=LEV1_MUTETEST_LOG_REC-0&LEV2_MUTETEST_
LOG_REC-0&IP_MUTETEST_LOG_REC-1&CIC_MUTETEST_LOG_RE
C-0, SpeechErrorForceHOSwitch=OFF;
EXCEPFRAMETHRES=25;
l Scenario 3: The transmission modes of the A, Ater, and Abis interfaces are different, and
IP transmission is used for the A, Ater, or Abis interface.
MuteTestLogStyle=LEV1_MUTETEST_LOG_REC-0&LEV2_MUTETEST_LOG
_REC-1&IP_MUTETEST_LOG_REC-1&CIC_MUTETEST_LOG_REC-0,
SpeechErrorForceHOSwitch=OFF;
EXCEPFRAMETHRES=25, MUTECHECKCLASS2SWITCH=ENABLE,
DETECTFRAMEPERIOD=2, MUTECHECKPEIROD=4;
Operation Results
l Each time the BSC detects one-way audio, a log prefixed by [CDIG] is recorded. To obtain
the log, run the MML command COL LOG.
GBSS14.0
19
l No tool is required to open the log. You can use EXCEL to open the log file. SubType in
the logs can be used to select the appropriate transmission mode used by the BSC. If the
BSC uses TDM transmission mode, select SubType:TDM_L2. If the BSC uses IP
transmission mode, select SubType:IP_MUTE.
l All resource information related to a call is recorded after one-way audio occurs during the
call. Therefore, when any node is faulty, the faulty node information is recorded in all logs.
Table 3-2 shows the mapping between the faulty nodes and the fields in the logs.
Table 3-2 Mapping between the faulty nodes and the fields in the logs
Analysis Item Field Field Description
BTS TrxId TRX ID
Abis interface AbisSubrackNo Subrack number of the Abis
interface board
AbisSlotNo Slot number of the Abis
interface board
AbisPort Port number of the Abis
interface board
TNU TNURack Subrack number of TNU
TNUSlot TNU slot number
TNUPort TNU port number
TC resources TcSubRackNo TC subrack number
TcSlotNo TC slot number
TcDspNo TC DSP number
A interface Acic CIC number
Ater interface AterLinkNo Ater link number

3.1.4 Crosstalk Detection
This section describes how to detect crosstalk on the BSS.
This function detects crosstalk due to abnormal data exchange between a BTS and the BSC.
Crosstalk on the Um and A interfaces cannot be detected.
Procedure
CAUTION
This function must be configured on both the BSC and the BTS.
GBSS14.0
20
1. To enable this function on the BSC, run the MML command SET BSCBASIC with Cross
Call Detect Time Threshold set to the recommended value 10.
Operation Result
Each time the BSC detects crosstalk, a crosstalk log is recorded. The crosstalk logs are recorded
together with one-way audio logs. You can run the MML command COL LOG to obtain one-
way audio log files prefixed by [CDIG].
No tool is required to open the log files. You can open the log file in .xls format.
When the number of crosstalks on the BSC exceeds Speech Channel Alarm Threshold,
ALM-21814 BSS Internal Voice Channel Abnormal is reported.
3.1.5 Optimizing Um Interface Crosstalk
This section describes how to enable crosstalk optimization for the Um interface.
This function is used when severe crosstalk occurs over the Um interface in a cell. The symptoms
of crosstalk over the Um interface are as follows: 1. The crosstalk occurs during a call rather
than at the beginning of a call. 2. The Um interface quality for a party in the call is poor. 3. The
voices of two parties at the peer end can be heard.
NOTE
When this function is enabled, the BSC sends a Channel Rel message to the MS after a call is dropped. In
addition, the BSC delays the value of the timer T3109 to enable the MS to release Um interface resources.
However, traffic may be congested in the cell because channel reassignment is delayed. Therefore,
determine whether to enable this function according to site requirements. This function is disabled by
default.
Procedure
Run the MML command SET GCELLSOFT with Um Interface Crosstalk Optimization
Allowed set to YES(Allowed).
3.1.6 Binding MSs to BSC Resources
This section describes how to bind MSs to BSC resources.
This function applies only to the binding of the specified Ater or digital signal processor (DSP)
resources during site deployment, swapping, fault location, or maintenance.
Procedure
1. Run the MML command SET RSVRES to reserve TC and BM resources of a BSC.
2. Run the MML command SET USRRESBIND to set the parameters to bind MSs to the
reserved resources.
GBSS14.0
21
NOTE
l A maximum of two MSs can be bound to the reserved resources.
l In downlink setup messages, a country code prefix may be added to the calling number. Therefore, if
First User Type or Second User Type is set to MSISND, First User Identity or Second User
Identity must be set to a value prefixed with the country code to ensure data consistency.
Operation Results
Perform a dialing test using the specified Ater or DSP resources to check whether voice problems
are caused by faults in the DSP or Ater interface. If so, troubleshoot the voice problems. Then,
run the MML command SET USRRESBIND to release the bound resources.
3.1.7 Performing Dialing Tests on the Um Interface
This section describes how to perform dialing tests on the Um interface.
This function locates problems on the Um interface by specifying TRXs or channels in the test
cell for the test MS.
Procedure
CAUTION
The channels on which the timeslots are specified must be traffic channels (TCHs). If the
channels are not TCHs, the timeslots on these channels are automatically filtered out. Therefore,
dialing tests cannot be performed on these timeslots.
1. Run the MML command SET UMTESTPARA to configure the mobile station
international ISDN number (MSISDN), site, cell, TRX, and timeslot for the test MS. If no
TRX or timeslot is configured, dialing tests are performed in the specified cell by default.
Operation Results
l If only one timeslot is specified for dialing tests and calls are connected, the test MS makes
calls on the specified timeslot.
l If only one timeslot is specified for dialing tests and calls are not connected, the timeslot
may be specified on a non-TCH channel or faulty TCH.
l If two or more timeslots are specified for dialing tests, one call can occupy only one timeslot.
Therefore, calls must be initiated in succession to perform dialing tests on all specified
timeslots. The timeslots on two half-rate channels can be occupied twice.
3.1.8 Performing Dialing Tests on the A Interface
This section describes how to perform dialing tests on the A interface.
Perform a dialing test on the A interface to troubleshoot voice problems caused by poor
transmission quality on the A interface. During the dialing test, the BSC identifies the test MS,
GBSS14.0
22
receives the DTMF message from the MS, and records the dialing test result according to the
received DTMF message. If A Interface Block CIC is set to YES(Yes), the BSC blocks the
circuit occupied by a call when the call is released. Therefore, the circuit for the dialing test
cannot be occupied by other calls. If A Interface Block CIC is set to NO(No), a large number
of dialing tests are performed on the A interface circuits that the MSC allocates to the BSC.
Procedure
CAUTION
l Do not set A Interface Block CIC to YES(Yes) when services are in progress. If A Interface
Block CIC is set to YES(Yes), circuits on the A interface are blocked automatically. In this
situation, resources on the A interface may be insufficient.
l This function does not apply to the A over IP mode.
l To enable automatic dialing tests on the A interface, perform the following operations:
1. Run the MML command SET ATESTPARA to enable automatic dialing tests on the
A interface.
Set Automatic Dialing Test on A Interface to YES(Yes).
Set MSISDN in A Interface Test to the called number.
Specify A Interface Uplink One-Way DTMF Message, A Interface Downlink
One-Way DTMF Message, A Interface No Audio DTMF Message, A Interface
Noise DTMF Message, or A Interface Normal DTMF Message as the DTMF
messages that the test MS sends during dialing tests.
Set A Interface Block CIC to YES(Yes). This indicates that the circuit used by
the call during a dialing test is automatically blocked when the call is released. In
this situation, resources on the A interface may be insufficient. Therefore, do not
set A Interface Block CIC to YES(Yes) when services are in progress.
Set A Interface Sampling Test to YES(Yes) and set A Interface E1/T1 Sampling
Number to the number of timeslots to be tested.
l To disable automatic dialing tests on the A interface, perform the following operations:
1. Run the MML command SET ATESTPARA with Automatic Dialing Test on A
Interface set to NO(No) to disable automatic dialing tests on the A interface.
Operation Results
1. If you enter the DTMF message that is specified by running the MML command SET
ATESTPARA on the calling MS, the call duration, circuit identification code (CIC),
channel information, and Abis interface information are recorded in the dialing test log file.
The recorded information can be used to locate the following voice problems: uplink or
downlink one-way audio, no audio, and noise.
2. During a dialing test on the A interface, one dialing test log is recorded when a DTMF
message is received. The path to save the dialing test log file is \mbsc\bam\common\fam
\famlogfmt. The prefix of the dialing test log file name is [AIDG]. You can use EXCEL
to open log files.
3. You can obtain the information about CICs, DPC, and Ater interface based on the DTMF
messages corresponding to voice problems, and comprehensively analyze whether voice
GBSS14.0
23
problems are caused by faults in the A interface. Table 3-3 lists the format of log files that
record the information about dialing tests on the A interface.
Table 3-3 Format of log files that record the information about dialing tests on the A
interface
No. Information
1 Call start time (in format of YYYY.MM.DD
HH:MM:SS)
2 DTMF message type
3 DPC
4 CIC
5 Mobile phone number
6 Carrier number and channel number
7 Information about the Abis interface:
l If the TDM transmission is used on the Abis
interface, the following information is logged:
subrack number, slot number, port number,
timeslot number, and sub-timeslot number for an
interface board.
l If the Abis interface over IP is used, IP address
and ports used on the Abis interface board is
logged.
l If the HDLC transmission is used on the Abis
interface, the HDLC port and sub-port numbers
are logged.
8 Ater interface data such as Asub interface link No.,
Asub timeslot number in the link, and Asub interface
data rate.
NOTE
The information is unavailable in TC/BM combined mode.

3.1.9 Detecting Noise on the A Interface
This section describes how to detect noise on the A interface.
The noise detection function provides an important method for the BSS to locate noise problems.
In A over TDM mode, the TC module of the BSC performs noise detection on the PCM code
streams over the A interface, records the calls experiencing the noise problem, and generates
logs.
GBSS14.0
24
NOTE
l This function is used only in A over TDM mode and does not take into account the transmission mode
on the Abis interface.
l This function is mutually exclusive with the following features: GBFD-117701 BSC Local Switch,
GBFD-117702 BTS Local Switch, and GBFD-115701 TFO(Tandem Free Operation).
l The CPU usage of the digital signal processor (DSP) enabled with this function increases by up to 3%.
Procedure
l Enabling the noise detection function
1. Run the MML command SET GCELLSOFT to enable the noise detection function.
In this step, set the following parameters as follows:
Set Noise Detect Switch to ON(On).
Set Noise Detect Period to 5.
Set Noise Detect Threshold to 15.
Set Noise Detect Level to HIGH(High).
Set Fuzzy Noise Switch to OFF(Off).
l Disabling the noise detection function
1. Run the MML command SET GCELLSOFT to disable the noise detection function. In
this step, set Noise Detect Switch to OFF(Off).
Operation Results
l You are advised to analyze voice logs after this function is enabled for at least one hour
during peak hours.
l The BSC automatically saves voice logs in the following directory: \bam\common\fam
\famlogfmt\.
l The procedure for analyzing voice logs is as follows:
1. On the BSC LMT, click Device Maintenance. The Device Maintenance tab page is
displayed.
2. Choose BSC Maintenance > Maintain User Resources > Voice Log Analysis from
the BSC Maintenance tab page. The Voice Log Analysis dialog box is displayed.
3. In the Voice Log Analysis dialog box, set Log Type to A interface noise, and set
other parameters to appropriate values. Then, click Analyze. The analysis result is
displayed in a table, showing the information about possible fault points.
3.2 Maintenance Functions for Identifying Transmission
Problems
This section describes maintenance functions for identifying transmission problems.
3.2.1 Crossed Pair Detection
This section describes how to enable crossed pair detection.
GBSS14.0
25
A crossed pair is classified into big crossed pair and small crossed pair. A big crossed pair refers
to crossed TX/RX between two pairs of E1 cables, as shown in Figure 3-4. A small crossed pair
refers to crossed TX/RX between an E1 cable in a pair and an E1 cable in another pair, as shown
in Figure 3-5. When a crossed pair occurs on an E1 port of a device, the physical layer signals
are available and no alarm is triggered. However, upper-layer links are disconnected and services
are interrupted because data from other ports is received.
Figure 3-4 Big crossed pair

Figure 3-5 Small crossed pair

There are a large number of E1 cables at a site and checking E1 connections is time-consuming.
BSC6900V900R011 supports crossed pair detection, which helps determine whether a crossed
pair is occurring on E1 ports and provides the relevant problem location information. Crossed
pair detection applies only to small E1 crossed pairs over the A, Abis, and Ater interfaces.
There are two methods to detect small crossed pairs: loopback detection and alarm-based
detection. If alarm-based detection is used, ensure that the connection to the peer port is normal
and that no loopback occurs. If loopback detection is used, perform remote loopback by
connecting TX and RX ports (physical loopback) or by sending commands. Only physical
loopback can be performed on the ports of Ater operation and maintenance links (OMLs).
GBSS14.0
26
NOTE
1. To perform loopback detection, do as follows: Set the port on the remote device to remote loopback
or physical loopback without modifying configuration data. Import the test data (containing the port
number) into the local E1 port. After performing the loopback, check whether the received port
information is the same as the imported data. If the received port information is the same as the imported
data, the E1 cables are connected correctly. If the received port information is not the same as the
imported data, the cables are crossed.
2. To perform alarm-based detection, do as follows: Disable the TX function of the local E1 port, which
causes the remote E1 port to generate a loss of signal (LOS) alarm. The remote alarm indication (RAI)
is inserted into the TX signals of the remote port. If the E1 cables are connected correctly, the local
port receives the RAI. If the E1 cables are crossed, no alarm is generated on the local port.
3. The restrictions of the crossed pair function are as follows:
l Crossed pair detection can be performed only on the E1 electrical interfaces of the EIUa or PEUa
boards.
l If the RX and TX connectors of the E1 cable for one port are incorrectly connected as a self-
loopback on the DDF, this fault cannot be detected using loopback detection.
l When the E1 interface boards work in active/standby mode, this function can be performed only
on the active board.
l When the E1 interface boards work in active/standby mode, alarm-based detection can be
performed only when the Y-shaped cable networking mode is used.
l Before performing alarm-based detection, there must be no loopback on the remote port.
l Do not perform crossed pair detection unless necessary because doing so may interrupt services.
Notify telecom operators of possible impacts on a live network before performing alarm-based
detection for online maintenance.
l Crossed pair detection commands must be executed in sequence. The next command for crossed
pair detection cannot be executed until after the current detection command is executed completely.
l No alarm is reported on the E1 port on which crossed pair detection is to be performed.
l Although loopback detection can be performed on a single port or a whole board, alarm-based
detection can be performed only on a single port.
Procedure
Run the MML command CHK E1T1CRS to enable crossed pair detection.
Operation Results
After the MML command is executed successfully, a window is displayed, indicating whether
cable connections are faulty, as shown in the following figure.
+++ HUAWEI 2009-06-15 16:43:29
O&M #27137
%%CHK E1T1CRS: SRN=0, SN=15, BT=EIUa, MTHD=ALARM_METHOD, PN=0;%%
RETCODE = 0 Execution succeeded.
Check E1/T1 Cross Connection
----------------------------
Subrack No. Slot No. Link No. Check Result Cross Link No.
0 15 0 Not Cross <NULL>
(Number of results = 1)
--- END
GBSS14.0
27
3.2.2 Monitoring Port BER Seconds
This section describes how to detect the bit error rate (BER) seconds on an E1/T1 port. This
function helps you learn about the transmission quality of the link corresponding to the port in
real time.
If any bit error occurs on the E1/T1 port, you can start this task to obtain data such as BERS,
critical BERS, unavailable seconds, frame errors, CRC errors. Based on the data, you can
evaluate the operating status of the transmission network and identify the causes for the bit errors
in combination with the performance of the peer end. The AEUa/PEUa/EIUa/OIUa/POUc board
supports this function.
Procedure
1. On the LMT, click Monitor. The Monitor tab page is displayed.
2. In the Monitor Navigation Tree, choose Monitor > Common Monitoring. Then, double-
click BERS Monitoring.
3. In the BERS Monitoring dialog box that is displayed, set the relevant parameters. Then,
click Submit.
Operation Results
After the monitoring task is started, a monitoring window is displayed, showing the real-time
monitoring result by list and chart. The task name and related parameters are displayed in the
title bar of the window, as shown in Figure 3-6.
Figure 3-6 Monitoring results

3.2.3 Querying Ethernet Port Attributes
This section describes how to query the attribute of Ethernet ports on the local maintenance
terminal (LMT) when the BTS discards a large number of packets.
GBSS14.0
28
This function applies to poor voice quality on the BTS side in the following scenarios:
l The alarms ALM-25881 MAC Excessive Frame Error Rate and ALM-25897 IP Excessive
Frame Error Rate are generated.
l The network quality is poor.
Procedure
1. Run the MML command DSP BTSETHPORT to query the status of an Ethernet port.
l Set Cabinet No., Subrack No., Slot No. according to the location of the GTMU.
l Set Port No. based on the requirements of the live network. This parameter is optional.
If this parameter is empty, the status of the two types of Ethernet ports will be queried.
If this parameter is set to 0, the status of the electrical ports will be queried. If this
parameter is set to 1, the status of the optical ports will be queried.
Operation Results
l The BTS works in full-duplex mode, and the transmission rate of the BTS is consistent
with that of the peer device.
l If multiple query results show that the Receive CRC Error Packages is large and increases
significantly, the BTS has discarded a large number of packets.
3.2.4 Performing IP Loopback
This section describes how to perform an IP loopback test. IP loopback is used to locate
transmission faults and to check whether the settings of any trunk parameters are correctly in
Abis over IP mode. For example, loop back voice signals on an IP channel section by section to
locate voice problems.
This function applies only to the Abis over IP mode. To check whether an exception occurs on
the BSC side, perform an IP loopback test on the BSC side. To check whether an exception
occurs on the Abis or Um interface, perform an IP loopback test between the BSC and the BTS.
If the test result shows that no exception occurs on the Abis interface and the transmission delay
is shorter than 15 ms, exceptions may occur on the transmission link between the Abis interface
and the BSC or on the Um interface.
Procedure
NOTE
l Only one IP loopback test can be started for one digital signal processor (DSP).
l A maximum of two IP loopback tests can be started for one board.
l A maximum of two IP loopback tests can be started for one BTS.
l A maximum of four IP loopback tests can be started for one BSC.
l IP loopback tests are incompatible with ping tests.
l IP loopback tests can be started only when a GBSS13.0 BTS is used.
1. Run the MML command SET BTSIPLOPTST to set IP loopback parameters for the BTS
to be tested.
GBSS14.0
29
2. Run the MML command STR IPLOPTST to start an IP loopback test. If Loop type is set
to LOCAL_LOOP(LOCAL_LOOP), the test will be performed on the BSC side. If Loop
type is set to REMOTE_LOOP(REMOTE_LOOP), the test will be performed between
the BSC and the BTS.
3. Run the MML command DSP IPLOPTST to query the test result. Compare the value of
Number of sent packets with that of Number of received packets shown in the test result.
If the two values are the same, no packet is discarded during this loopback. If the two values
are different, packets are discarded during this loopback.
4. Run the MML command STP IPLOPTST to stop the IP loopback test.
Operation Results
If the output of the MML command DSP IPLOPTST shows that the value of Number of sent
packets is the same as that of Number of received packets, no packet is discarded during this
loopback. If the two values are different, packets are discarded during this loopback.
3.2.5 BTS Tracing
This section describes how to perform the BTS tracing function. With this function, a BTS in
IP over FE networking mode can trace the status of sending and receiving media access control
(MAC) data packets. This helps locate transmission-related problems.
The BTS tracing function is used when traffic on the Abis interface is congested. It enables a
BTS to trace the status of sending and receiving MAC data packets. The BTS then saves and
uploads tracing result files to the BSC.
NOTE
l This function is supported only by the GTMUb and UTRPc boards on 3900 series base stations.
l This function does not support real-time reporting of tracing result files.
l This function does not support simultaneous tracing and obtaining tracing files. The BTS stops a tracing
task when obtaining tracing result files.
l This function applies only to low-data flow tracing tasks because the tracing memory is limited. The
BTS stops a tracing task if more than 8 MB data packets are being traced.
l This function requires support from BTSs of V100R014C00.
Procedure
1. Run the MML command STR BTSTRC to start the BTS tracing function. Set the
parameters as follows:
l Set Cabinet No. to the number of the cabinet accommodating the GTMUb or UTRPc
board. Set Subrack No. to the number of the subrack accommodating the GTMUb or
UTRPc board. Set Slot No. to the number of the slot accommodating the GTMUb or
UTRPc board. In normal cases, set Cabinet No. to 0, Subrack No. to 0, and Slot No.
to 6 for the GTMUb board.
l Set other parameters to appropriate values based on individual needs.
GBSS14.0
30
NOTE
l The GTMUb backplane does not support the tracing type specified by MACTRACE(MAC
Trace).
l The BTS cannot perform tracing tasks of tracing types specified by MACTRACE(MAC Trace),
IKETRACE(IKETRACE), and IPSECTRACE(IPSECTRACE) simultaneously. If the BTS has
started a tracing task of a specific tracing type, the BTS cannot start any tracing task of another
tracing type.
2. Run the MML command STP BTSTRC to stop the BTS tracing function. Set the location
of the GTMUb or UTRPc board and Trace Type to be the same as those specified in 1.
3. Run the MML command STR BTSLOG to obtain the BTS log file. Set BTS Index or
BTS Name to be the same as that specified in 1. In addition, set Command Parameter to
TRCLOG.
After this command is executed successfully, the progress and name of the obtained BTS
log file are displayed on the LMT.
NOTE
When UTRPc is used for transmission, Board Type must be set to TMU(TMU/DTMU). Otherwise,
the BTS log file cannot be obtained.
4. Enable the FTP server and run the MML command ULD BTSLOG to upload the BTS log
file from the OMU to the FTP server. Set the parameters as follows:
l Set Log Type to CMPLOG(Compress Log).
l Set File Name to the name of the BTS log file obtained in 3.
l Set FTPServer IP to the IP address of the FTP server. The FTP user name and password
are specified by users.
l File Directory is optional. If this parameter is not specified, the BTS log file is saved
in the FTP root directory after being uploaded.
3.3 Maintenance Functions for Identifying Um and RF
Problems
This section describes maintenance functions for identifying Um and RF problems.
3.3.1 Monitoring Channel Interference Bands
This section describes how to view the interference band of idle channels to monitor interference
on these channels.
This section describes how to detect the interference band of an idle channel to monitor the
interference conditions on the channel.
Procedure
1. On the LMT, click Device Maintenance. The Device Maintenance tab page is
displayed.
GBSS14.0
31
2. On the BTS Maintenance tab page, choose BTS Maintenance > Monitor Channel
Interference Band. The Monitor Channel Interference Band tab page is displayed.
3. On the displayed Monitor Channel Interference Band tab page, set the relevant
parameters. Then, click Start.
NOTE
In the Device Navigation Tree, right-click the target BTS, and choose Monitor Channel
Interference Band from the shortcut menu.
Run the MML command DSP CHNJAM to monitor the interference band on a channel.
Operation Results
Figure 3-7 is an example of the menu operation results. The interference bands on all the
channels are displayed and refreshed every 10s.
Figure 3-7 Monitor Channel Interference Band dialog box

3.3.2 Testing Passive Intermodulation Interference Online
This section describes how to test passive intermodulation interference in online mode.
This function is used to check whether the live network is experiencing passive intermodulation
interference. Online passive intermodulation interference tests have no impact on ongoing
services. To check whether the live network is experiencing passive intermodulation
interference, calculate the difference between the uplink receive level measured when the cell
transmits power with services performed and that measured when the transmit power of all
carriers and channels in the cell reaches the maximum values. Then, compare this level difference
with the level difference decision threshold. Downlink power is available for all normal services,
and therefore the accuracy of the level difference decision result is associated with the proportion
of the duration when services are performed to the entire test duration. This proportion can be
used as the level difference decision threshold. Run the MML command STR BTSRFTST to
set the level difference decision threshold.
GBSS14.0
32
Procedure
NOTE
l Only one of common passive intermodulation interference tests, online passive intermodulation
interference tests, offline passive intermodulation interference tests, CDMA network interference tests,
online frequency spectrum scanning, and offline frequency spectrum scanning can be performed in a
cell once.
l Only one online passive intermodulation interference test can be performed in a BSC.
1. Run the MML command STR BTSRFTST to start an online passive intermodulation
interference test. You are advised to set parameters as follows:
l Set Test Type to PIMONLINE(Online Antenna Passive Intermodulation Test).
l Set Difference Threshold to 10.
l Set Service Rate Threshold to 20.
2. Run the MML command STP BTSRFTST to stop the online passive intermodulation
interference test.
NOTE
Operation Results
Each carrier in the cell reports a result of the online passive intermodulation interference test,
but the power transmitted by other carriers affects this result. Therefore, if all carriers in the cell
report valid test results, the test is valid. If one or multiple carriers in the cell report invalid test
results, the test is invalid. To obtain valid test results, perform this test again during off-peak
hours, or change the proportion of ongoing services to all normal services to 40% and perform
this test again.
After the test is stopped, the test results are displayed by running the MML command STR
BTSRFTST.
3.3.3 Scanning Frequency Spectrum Online
This section describes how to scan frequency spectrum in online mode. The main and diversity
receive levels of the specified frequency help you troubleshoot interference on the Um interface
on the local maintenance terminal (LMT).
This function applies to the scenario when a timeslot on a non-broadcast control channel (non-
BCCH) carrier is used. During the online frequency spectrum scanning, the BSC automatically
blocks this timeslot to prevent services from accessing the network. In this way, received signal
strength indicator (RSSI) tests are performed only for this timeslot, and other timeslots on the
non-BCCH carrier or the timeslots on other carriers are not affected.
Online frequency spectrum scanning does not cause cell blocking, and the services processed
in the cell are not affected.
GBSS14.0
33
Procedure
NOTE
Online frequency spectrum scanning can be performed only when the following conditions are met:
l Only one online frequency spectrum scanning test is performed on one carrier.
l No critical alarm is reported by the module corresponding to the carrier to be tested.
l No LAPD alarm is reported by the carrier to be tested.
l The channel corresponding to the timeslot to be tested must be a full-rate traffic channel (TCHF), half-
rate traffic channel (TCHH), or packet data channel (PDCH).
1. Log in to the local maintenance terminal (LMT) and click Monitor. The Monitor tab page
is displayed.
2. Choose Monitor > GSM Monitoring > Spectrum Scan Monitoring in Monitor
Navigation Tree. The Spectrum Scan Monitoring dialog box is displayed.
3. Set parameters in the Spectrum Scan Monitoring dialog box.
l Set Monitor Item to Frequency Time Domain Scan.
l Set Channel Type to TCHFR, TCHHR, or PDTCH.
4. Click Submit to start online frequency spectrum scanning. The test automatically stops
when the duration specified by Duration(Minute) ends.
Operation Results
Figure 3-8 shows an example of online frequency spectrum scanning results. Real-time
monitoring results are displayed in table and chart. The title of the window indicates the task
name and related parameters.
If the LMT is installed in the root directory of drive C, the scanning results will be saved in C:
\Web LMT\output\MBSC\monitor by default.
Figure 3-8 Example of online frequency spectrum scanning results

GBSS14.0
34
3.4 Maintenance Functions Related to Interface Tracing
This section describes maintenance functions related to interface tracing.
3.4.1 Tracing CS Domain Messages of a Single Subscriber
This section describes how to trace signaling messages of a single subscriber on the A, Abis, or
Um interface.
This section describes how to trace signaling messages on the A, Abis, or Um interface for a
specified subscriber. The user can be specified by IMSI, IMEI, TMSI, MSISDN, CELLID, or
channel.
Procedure
1. On the LMT, Click Trace. The Trace tab page is displayed.
2. In the Trace Navigation Tree, choose Trace > GSM Services. Double-click Single User
CS Trace. The Single User CS Trace dialog box is displayed, as shown in Figure 3-9.
Figure 3-9 CS domain message tracing for a single subscriber

GBSS14.0
35
3. In the Single User CS Trace dialog box, set the relevant parameters.
l CDT Mode: If you select the CDT mode, you can trace interfaces between internal
modules.
l Debug Mode: If you select the debug mode, you can trace stream data in Abis over IP,
Ater over IP, and A over IP scenarios. Interface boards must be selected on the Other
tab page.
l Location Flag: Indicates information such as cell ID and TA.
l Algorithmic Trace: traces algorithmic traces for a single subscriber in the CS domain.
This function is used for internal fault diagnosis and the identification type for the traced
subscriber must be TMSI, IMEI, IMSI, or MSISDN.
l User Plane Trace: When you select User Plane Trace, a dialog box is displayed, as
shown in Figure 3-11.
Frame Control Info: traces control information in speech frames.
TFO Control Info: traces in-band signaling messages related to tandem free
operation (TFO) and local switching.
Speech Evaluate Switch: performs MOS scoring for voices in A over TDM mode.
Figure 3-10 Single User CS Trace dialog box

GBSS14.0
36
NOTE
l If you trace the user messages by MSISDN, you are advised to set the MSISDN to that of the
peer end:
l (Recommended) To trace the calling MS, set the MSISDN to that of the called MS.
l To trace the called MS, set the MSISDN to that of the calling MS, which is displayed on the
called MS.
l If you trace the user messages by TMSI or IMSI, check the reassignment policies on the MSC
side:
l If TMSI is carried, you can trace the MS through the TMSI.
l If IMSI is carried, you can trace the MS through the IMSI.
l If you trace the user messages by IMEI, check whether the IMEI is available to the MSC.
l If you trace the user messages by CELLID, all calls in the cell are traced.
l If you trace the user messages by CHANINFO, the call carried by the specific channel is traced.
4. Click Submit.
Operation Results
l Successful operation
No traced message is displayed on the LMT if the Save to OMU trace mode is selected.
You can view the tracing result saved on the OMU by referring to Browsing Traced
Messages Offline.
A window shown in Figure 3-11 is displayed if the Report trace mode is selected. The
message browsing window displays information about each traced message, including
the task number, task time, RFN, subrack number, slot number, subsystem number,
message direction, message type, message source, user ID, and message content.
Figure 3-11 Results of CS domain message tracing for a single subscriber

l If the tracing fails, a dialog box is displayed with a failure cause.
3.4.2 Tracing PS Domain Messages for a Single Subscriber
This section describes how to trace messages of a single subscriber on the Gb, Abis, or Um
interface as well as trace internal messages or Um data blocks for a single subscriber.
This section describes how to trace signaling messages and internal messages on the Gb/Abis/
Um interface or the data block on the Um interface for a specified subscriber. You can trace the
GBSS14.0
37
subscriber by the IMSI or temporary link level identity (TLLI). You can perform this task to
locate a fault in the PS domain in the following procedures: PS service channel assignment
failure, abnormal TBF release, and PS packet loss or disconnection.
Procedure
1. On the Web LMT, click Trace. The Trace tab page is displayed.
2. In the Trace Navigation Tree, choose Trace > GSM Services. Double-click Single User
PS Trace. The Single User PS Trace dialog box is displayed, as shown in Figure 3-12.
Figure 3-12 PS domain message tracing of a single subscriber

3. In the Single User PS Trace dialog box, set the relevant parameters.
l The Trace Um Datablock Message can be selected only when Um Interface is selected
under Trace Interface Type.
If you start tracing by TLLI, query the TLLI of the MS by running the DSP
MSCONTEXT command. During the PS service, the TLLI may be reassigned to
the MS. In this case, run this command to query the new TLLI for the tracing
operation.
l Report Mode: When Trace Um Datablock Message is selected, Um datablock
messages are reported. When Abis Interface is selected, MAC Report must be selected
and TRAU Report must be deselected. In this case, messages are reported in the
message format of the Um interface.
l For the description of Trace Mode, see Trace Mode.
4. Click Submit.
GBSS14.0
38
Operation Results
l Successful operation
No traced message is displayed on the LMT if the Save to OMU trace mode is selected.
You can view the tracing result saved on the OMU by referring to Browsing Traced
Messages Offline.
A window shown in Figure 3-13 is displayed if the Report trace mode is selected. The
message browsing window displays information about each traced message, including
the task number, task time, RFN, subrack number, slot number, subsystem number,
message direction, message type, message source, user ID, and message content.
Figure 3-13 Results of PS domain message tracing for a single subscriber

l If the tracing fails, a dialog box is displayed with a failure cause.
3.5 Maintenance Functions for Identifying PS Problems
This section describes maintenance functions for identifying PS problems.
3.5.1 Monitoring Channel Status
This section describes how to monitor channel usage and subchannel usage on a TRX.
If a built-in PCU is configured, you can query the LMT for information about the physical data
channel (PDCH) by using the channel status monitoring function. The information includes
Applied Bandwidth, Available Bandwidth, Uplink GPRS TBF, Downlink GPRS TBF, Uplink
EGPRS TBF, and Downlink EGPRS TBF.
Procedure
NOTE
In the Device Navigation Tree, right-click the target BTS, cell, or TRX, and choose Monitor Channel
Status from the shortcut menu.
GBSS14.0
39
l Through menu operations
1. Click Device Maintenance. The Device Maintenance tab page is displayed.
Status. The Monitor Channel Status tab page is displayed.
3. On the Monitor Channel Status tab page, set the relevant parameters. Then, click
Start.
NOTE
l Each dot in a column represents a sub-channel of the corresponding channel. The SDCCH channel
has eight sub-channels, the full-rate TCH has only one sub-channel, and the half-rate TCH has
two sub-channels.
l The sub-channel status is indicated with different colors.
l Green indicates that the channel is in normal state. If you move the cursor to the corresponding
indicator, you can view the current channel type, applied bandwidth, and available bandwidth
from the pop-up information. The applied bandwidth and the available bandwidth are equal
and both bandwidths are greater than or equal to 16 Kbit/s. The number of uplink or downlink
TBF blocks is proportional to the MSs that can be multiplexed on the current channel.
l Red indicates that the channel is abnormal. If you move the cursor to the corresponding
indicator, you can view the current channel type, applied bandwidth, and available bandwidth
from the pop-up information. The applied bandwidth is not equal to the available bandwidth,
or the available bandwidth is 0 Kbit/s.
l Blue indicates that the channel is blocked. If you move the cursor to the corresponding
indicator, you can view the current channel type and the channel status, which is Locked.
l If a TRX number is marked with *, the TRX is in TRX cooperation state.
l Through MML commands
1. Run the DSP CHNSTAT command to monitor the channel status.
Operation Results
Figure 3-14 shows an example of the results of monitoring channel status.
Figure 3-14 Monitoring channel status

The various channel statuses on the Monitor Channel Status tab page are described as follows:
l Idle indicates that the channel is normal but not occupied.
l Working indicates that the channel is normal and occupied.
GBSS14.0
40
l Locked/Shut down indicates that the channel is blocked.
l Subordinate Channel indicates that a channel sharing the same TRX as the current channel
is transmitting power. This is a normal state.
l Faulty indicates that the channel is faulty.
l Uninstalled indicates that the channel is not activated.
Right-click the channel to be queried. The detailed information about the channel is displayed,
as shown in Figure 3-15.
Figure 3-15 Channel status monitoring result

3.5.2 Performing a PDCH Loopback Test
This section describes how to perform a PDCH loopback test.
In Abis over TDM mode, Abis links carrying PDCHs pass through multiple switch units within
the BSC and the BTS. If a switch unit or transmission link is faulty in Abis over TDM terrestrial,
microwave, or satellite mode, the PDCHs carried on the switch unit or transmission link become
out of synchronization or faulty.
If a fault always occurs, a loopback test is used to quickly identify the fault and fault type. If a
fault occasionally occurs, long-time loopback and tracing tests are performed on faulty PDCHs.
Figure 3-16 shows the five loopback points on a faulty PDCH.
GBSS14.0
41
Figure 3-16 PDCH loopback points

When the loopback point is DPU, TNU, or TMU, a physical loopback for signals is implemented
by using the network chip. When the loopback point is TRU, the DSP on the TRU copies the
downlink data to the uplink data flow.
The DSP then compares the data frame received on the uplink with the data frame transmitted
on the downlink. If they are the same, the received data frame is considered as a correct frame.
If they are different, the received data frame is considered as an error frame. By comparing the
number of transmitted frames with that of received correct frames, the DSP can determine
whether the link is faulty and the fault severity. The number of transmitted frames and number
of received correct frames can be queried by running the MML command DSP
PDCHLOOPTST or using menu items on the LMT. For details, see Procedure.
NOTE
l A PDCH loopback test can be performed when the BSC is configured with a built-in packet control
unit (PCU) and the Abis interface uses the fixed TDM networking mode.
l A PDCH loopback test cannot be performed on odd-numbered PDCHs in a dual-timeslot extended cell.
l A PDCH loopback test is supported only by 3900 series base stations of V100R014C00 or later.
CAUTION
1. A PDCH being looped back cannot provide services. Therefore, stop the loopback test
immediately after you obtain the loopback result.
2. If a board except DPU is used as a loopback point and active and standby TNU boards are
switched over, the loopback result is inaccurate. You can check whether a switchover occurs
by referring to EVT-22832 Board Switchover.
3. If the Abis link becomes faulty during a loopback test, the test is automatically stopped.
4. If a PS cell resets during a loopback test, the test is automatically stopped.
5. If cells are distributed on the DPUg board, the DPU board cannot be used as the loopback
point.
Preparations
Obtain the index of the TRX with the test PDCH by performing the following operations on the
LMT:
1. On the LMT, click Device Maintenance. The Device Maintenance tab page is displayed.
GBSS14.0
42
Status. The Monitor Channel Status tab page is displayed.
3. On the Monitor Channel Status tab page, move the mouse pointer to the TRX with the
test PDCH. The TRX information is displayed, including the TRX index. As shown in
Figure 3-17, the index of TRX 0 is 0.
Figure 3-17 Index of the TRX with the test PDCH

Procedure
l Using menu items
1. On the Monitor Channel Status tab page, right-click the test PDCH and choose Start
Loop from the shortcut menu. The Start Loop dialog box is displayed.
2. In the Start Loop dialog box, set Loopback Duration, Report Period, and
Loopback Location to appropriate values based on individual needs. In addition,
select whether to save the query results during the loopback test. The default save path
of query results is LMT installation path\MBSC\output\btsmaintenance. Then,
click Ok to start a loopback test. The LMT automatically queries and displays the
loopback result periodically, as specified by Report Period.
3. On the Monitor Channel Status tab page, right-click the test PDCH and choose Stop
Loop from the shortcut menu.
4. On the Monitor Channel Status tab page, query the loopback status of the test PDCH.
If the test PDCH is highlighted in yellow, it is in the loopback state.
l Using MML commands
Run the MML command STR PDCHLOOPTST to start a PDCH loopback test.
Run the MML command DSP PDCHLOOPTST to query the PDCH loopback test
result.
Run the MML command STP PDCHLOOPTST to stop the PDCH loopback test.
Run the MML command DSP CHNSTAT to query the PDCH loopback status.
Operation Results
l Saving loopback results
Using menu items: When setting loopback test parameters for the first time, you can
determine whether to select the Save File option in the Start Loop dialog box. If you
select this option, it becomes unavailable when you set these parameters subsequently
because the option continues to take effect. If you do not want to save loopback results,
reopen the Monitor Channel Status tab page to deselect the Save File option.
GBSS14.0
43
Figure 3-18 Saving loopback results by using menu items

Using MML commands: Select Save Result on the upper right of the command input
box before running the MML command DSP PDCHLOOPTST, as shown in Figure
3-19.
Figure 3-19 Saving results by using MML commands

l Obtaining loopback results
The save path of loopback results is specified by users. If you perform a loopback test by
using menu items, the default save path is LMT installation path\MBSC\output
\btsmaintenance.
l Analyzing loopback results and troubleshooting
The troubleshooting methods for different loopback results are as follows:
If an exception occurs when Loopback Location is set to TRX(TRX) but no exception
occurs when Loopback Location is set to TMU(TMU), the link between the TMU and
the TRX may be faulty. Run the MML command RST TRX to reset the TRX.
If the fault is rectified, no further action is required.
If the fault persists, Contact Huawei Customer Service Center.
GBSS14.0
44
If an exception occurs when Loopback Location is set to TMU(TMU) but no exception
occurs when Loopback Location is set to TNUTOEIU(TNU installed in the same
subracket as EIU), the EIU or Abis transmission may be faulty. Locate the fault in the
EIU or Abis transmission.
If an exception occurs when Loopback Location is set to TNUTOEIU(TNU installed
in the same subracket as EIU) but no exception occurs when Loopback Location is
set to TNUTODPU(TNU installed in the same subracket as DPU), the link between
the two TNU boards may be faulty. Contact Huawei Customer Service Center.
If an exception occurs when Loopback Location is set to TNUTODPU(TNU installed
in the same subracket as DPU) but no exception occurs when Loopback Location is
set to DPU(DPU), the links between the two TNU and the DPU boards may be faulty.
Contact Huawei Customer Service Center.
If an exception occurs when Loopback Location is set to DPU(DPU), the board with
DSPs or the link between the DPU board and the board with DSPs may be faulty. Run
the MML command RST DSP to reset the DSPs.
3.6 Maintenance Functions for Identifying Clock Problems
This section describes maintenance functions for identifying clock problems.
3.6.1 Querying BSC Clock Source Status
This section describes how to query BSC clock source status.
This function is used to check the clock status of the GCGa or GCUa on the M2000 or LMT,
including the status of clock source used in the current system, as well as mode of switching
clock sources. If the clock source level is Unavailable, or Phase-locked loop state of current
clock is Unknown, the clock source is lost. In this case, contact the maintenance engineers to
resolve the problem until the clock source level is Available, or Phase-locked loop state of
current clock is Trace.
Procedure
displayed.
2. On the BSC Device Panel tab page, right-click the GCUa and choose Query BSC
Board Clock Status from the shortcut menu.
3. In the Query BSC Board Clock Status dialog box that is displayed, check the board
clock status, as shown in Figure 3-20.
GBSS14.0
45
Figure 3-20 Querying BSC clock source status

Run the MML command DSP CLK and set Subrack No. as well as Slot No. to query the
status of the GCUa or GCGa in the MPS. The GCUa and GCGa are permanently located
in slots 12 and 13 respectively.
3.6.2 Querying BSC Board Clock Status
This section describes how to query BSC board clock status.
This function is used to query the status of each BSC board clock. For the GCUa board, you can
query information such as the status of clock source used in the current system, and mode of
switching clock sources.
CAUTION
This function cannot be used to query the clock status of the FG2a, GOUa, FG2c, or GOUc.
Procedure
displayed.
GBSS14.0
46
2. On the BSC Maintenance tab page, choose BSC Maintenance > Device
Maintenance > Query BSC Board Clock Status. The Query BSC Board Clock
Status dialog box is displayed.
3. In the Query BSC Board Clock Status dialog box that is displayed, set the relevant
parameters. Then, click Query to query the board clock status, as shown in Figure
3-21.
Figure 3-21 Querying results of BSC Board Clock Status

Run the MML command DSP CLK to query the BSC board clock status.
3.6.3 Maintaining BTS Clock
This section describes how to query BTS board clock information.
This function is used to query the board clock information and clock type of a BTS.
Procedure
Starting BTS device panel.
On the BTS device panel, right-click the main control board and choose Maintain Clock
from the shortcut menu.
In the Maintain Clock dialog box that is displayed, set the relevant parameters. Then,
click Query to query the board clock information, as shown in Figure 3-22.
GBSS14.0
47
Figure 3-22 Maintain Clock dialog box

Run the MML command DSP BTSBRD to query the board clock information of a BTS.
Run the MML command LST BTSCLK to query the clock source type of a BTS.
3.7 Maintenance Functions Related to No Traffic
This section describes the maintenance functions related to no traffic.
3.7.1 Reporting the No Traffic Alarm Independently
This section describes how to set the mode for reporting the no traffic alarm.
The ALM-28008 Radio Link Failure alarm has seven tributaries, of which tributary 2 indicates
that no traffic is available on TRX. Based on the ALM-28008 Radio Link Failure alarm, the
function for reporting the no traffic alarm independently incorporates the Reporting No Traffic
Alarm Independently parameter, you can determine whether to report the ALM-28009 Carrier
No Traffic or ALM-28008 Radio Link Failure alarm based on individual needs.
NOTE
3900 series base stations of V100R014C00 and later support this function.
GBSS14.0
48
Procedure
1. Run the MML command SET GTRXRLALM to enable the function for reporting the no
traffic alarm independently. In this step, set the following parameters as follows:
l Set Wireless Link Alarm Flag to YES(Yes).
l Set Reporting No Traffic Alarm Independently to ON(On).
2. Run the MML command LST GTRXRLALM to query the parameter settings of the
function for reporting the no traffic alarm independently.
Operation Results
l If Reporting No Traffic Alarm Independently is set to ON(On) and if there is no traffic
on any TRX, the BTS reports the ALM-28009 Carrier No Traffic alarm.
l If Reporting No Traffic Alarm Independently is set to OFF(Off) and if there is no traffic
on any TRX, the BTS reports the ALM-28008 Radio Link Failure alarm with the specific
cause of No Traffic on TRX.
3.7.2 No-Traffic Self-Healing
This section describes how to perform the no-traffic self-healing function in the specified mode
within the specified period.
By default, if there is no traffic for more than 4 consecutive hours, a no-traffic alarm is reported.
However, also by default, the BTS does not detect no-traffic alarms between 22:00 and 08:00.
To solve this problem, the BTS performs the no-traffic self-healing function in the specified
mode within the specified period.
NOTE
This function is supported only by 3900 series base stations of V100R014C00 or later.
Procedure
1. Run the MML command SET GTRXRLALM to enable the function of independently
reporting no-traffic alarms. Set the parameters as follows:
l Set Wireless Link Alarm Flag to YES(Yes).
l Set Statistical Period of No-traffic to 48. The unit of this parameter is 5 minutes.
l Set No Traffic Self-Healing Period to 12. The unit of this parameter is 5 minutes.
l Set No Traffic Self-Healing Mode to an appropriate value based on specific needs.
If this parameter is set to NONE(No Operation), the BTS does not perform self-
healing.
If this parameter is set to RECONFIG(TRX Reconfiguration), TRXs with no
traffic are removed and then reconfigured.
If this parameter is set to LVL2_RESET(Level-2 RF Board Reset), all TRXs on
a board with no traffic are removed and then reconfigured. This takes a short time
because only service data needs to be reinitialized and alarms are suppressed.
If this parameter is set to CARRIER_SRESET(RF Board Soft Reset), the BTS
performs a soft reset on RF boards. A soft reset affects services more severely and
takes a longer time than a level-2 reset on RF boards.
GBSS14.0
49
If this parameter is set to CARRIER_HRESET(RF Board Power-off Reset), the
BTS is powered off and on again.
The parameter value SITE_RESET(BTS Reset) is currently invalid for No Traffic
Self-Healing Mode.
2. Run the MML command LST GTRXRLALM to query the settings of the parameters used
for performing no-traffic self-healing.
NOTE
l The BTS performs self-healing only once a day. If the BTS detects no-traffic for the second time, it is
not allowed to perform self-healing again. If the no traffic period exceeds the duration specified by
Statistical Period of No-traffic, a no-traffic alarm is reported.
l Upon detecting no-traffic, the BTS determines whether no traffic occurs on a TRX or on all TRXs of
a board based on the detection result. If no traffic occurs on a TRX and No Traffic Self-Healing
Mode is set to a value except NONE(No Operation), the BTS performs self-healing in the mode
specified by RECONFIG(TRX Reconfiguration). If no traffic occurs on all TRXs of a board, the
BTS performs self-healing in the configured mode.
l If RF boards are configured with non-GSM TRXs, the BTS does not perform self-healing in the mode
specified by CARRIER_SRESET(RF Board Soft Reset) or CARRIER_HRESET(RF Board
Power-off Reset). If BTSs are cascaded on a common public radio interface (CPRI) port, the BTS
does not perform self-healing in the mode specified by CARRIER_HRESET(RF Board Power-off
Reset).
Operation Results
Use the parameter settings described in Procedure as an example. If there is no traffic for 60
(12 x 5) minutes, the BTS performs no-traffic detection and self-healing in the mode specified
by No Traffic Self-Healing Mode. If the total no traffic period exceeds 240 (48 x 5) minutes,
a no-traffic alarm is reported.
GBSS14.0
50
4 Handover Problems
About This Chapter
This chapter describes how to locate and troubleshoot handover problems.
4.1 Handover Principles
Handovers are performed to ensure service continuity during MS movement and to optimize
network performance.
4.2 Locating Handover Problems
This section describes how to locate handover problems.
4.3 Troubleshooting Handover Problems Due to Hardware Faults
This section describes how to troubleshoot handover problems due to hardware faults.
4.4 Handover Problems Due to Incorrect Data Configurations
This section describes how to troubleshoot handover problems due to incorrect data
configurations.
4.5 Troubleshooting Handover Problems Due to Traffic Congestion in the Target Cell
This section describes how to troubleshoot handover problems due to traffic congestion in the
target cell.
4.6 Troubleshooting Handover Problems Due to Poor Um Interface Quality
This section describes how to troubleshoot handover problems due to poor Um interface quality.
4.7 Troubleshooting Handover Problems Due to NE Faults
This section describes how to troubleshoot handover problems due to NE faults.
4.8 Troubleshooting Handover Problems Due to Inappropriate Inter-BSC/Inter-MSC/Inter-RAT
Interaction
This section describes how to troubleshoot handover problems due to inappropriate inter-BSC,
inter-MSC, or inter-RAT interaction.
GBSS14.0
Troubleshooting Guide 4 Handover Problems
51
4.1 Handover Principles
Handovers are performed to ensure service continuity during MS movement and to optimize
network performance.
Before a handover, the in-service MS and the serving BTS evaluate the quality of downlink and
uplink radio links respectively and submit the measurement reports to the BSC.The BSC then
determines whether to trigger a handover based on the measurement reports and actual network
conditions.
4.1.1 Handover Procedure
This section describes the handover procedure. The intra-BSC handover is used as an example.
Figure 4-1 shows an intra-BSC handover procedure.
GBSS14.0
52
Figure 4-1 Intra-BSC handover procedure

The intra-BSC handover procedure is as follows:
1. An MS sends a measurement report to BTS 1 (the source BTS) on the SACCH over the
Um interface.
2. BTS 1 sends the measurement result to the BSC.
3. The BSC determines the target cell based on the measurement result and sends a Channel
Activation message to BTS 2 (the target BTS).
4. BTS 2 enables the power amplifier to receive uplink messages on the channel specified in
the Channel Activation message. Then, BTS 2 sends a Channel Activation Acknowledge
message to the BSC.
GBSS14.0
53
5. The BSC sends a Handover Command message to BTS 1, which forwards this message to
the MS on the FACCH. At the same time, the BSC starts timer T3101.
6. The MS sends a Handover Access message to BTS 2 on the FACCH. At the same time,
the MS starts timer T3124 if this is an asynchronous handover.
7. BTS 2 sends a Handover Detect message to the BSC.
8. If this is an asynchronous handover, BTS 2 sends a PHY INFO message to the MS, which
contains the new timing advance (TA) value calculated by BTS 2. Upon receiving this
message, the MS stops timer T3124.
9. The MS sends SABM frames to BTS 2 on the FACCH.
10. Upon receiving the first SABM frame, BTS 2 sends an Establish Indication message to the
BSC, which informs the BSC that the radio link has been established.
11. At the same time, BTS 2 sends a UA frame to the MS on the FACCH, which informs the
MS that the radio link has been established.
12. The MS sends a Handover Complete message to BTS 2 on the FACCH. BSC 2 then
forwards this message to the BSC, which informs the BSC that the handover is complete.
13. The BSC stops timer T3103 and sends the MSC a Handover Performed message, which
contains the target cell information.
14. The BSC sends BTS 1 a Deactivate SACCH message.
15. The BSC sends BTS 1 a Release Request message with the cause value of Local End
Release, indicating that the release process is not related to the MS.
16. Upon receiving the Release Request message, BTS 1 responds with a Release Confirm
message.
17. The BSC sends BTS1 an RF Channel Release message, instructing BTS 1 to release the
original TCH.
18. Upon receiving the RF Channel Release message, BTS 1 responds with an RF Channel
Release Acknowledge message, indicating that the original TCH is released and can be
reassigned.
4.1.2 Handover Success Rate
Handover success rates are classified into the following success rates: intra-cell handover, intra-
BSC handover, and inter-BSC handover.
Formula
Handover success rate = Number of successful handovers/Number of handover requests
Radio handover success rate = Number of successful handovers/Number of handover commands
Measurement Points in Signaling Procedures
Figure 4-2 and Figure 4-3 show the measurement points in the signaling procedures for intra-
BSC handovers and inter-BSC handovers respectively.
GBSS14.0
54
Figure 4-2 Measurement points in the signaling procedure for intra-BSC handovers
A1: CH320:Number of Incoming Internal Inter-Cell Handover Requests and CH300:Internal Intra-Cell
Handover Requests
B1: CH321: Number of Incoming Internal Inter-Cell Handover Responses and CH301:Internal Intra-Cell
Handover Commands
C1: CH323:Number of Successful Incoming Internal Inter-Cell Handovers and CH303:Successful Internal
Intra-Cell Handovers

GBSS14.0
55
Figure 4-3 Measurement points in the signaling procedure for inter-BSC handovers
A2: CH340:Incoming External Inter-Cell Handover Requests
B2: CH341:Incoming External Inter-Cell Handover Responses
C2: CH343:Successful Incoming External Inter-Cell Handovers
A3: CH330:Outgoing External Inter-Cell Handover Requests
B3: CH331:Outgoing External Inter-Cell Handover Commands
C3: CH333:Successful Outgoing External Inter-Cell Handovers

The formulas for calculating the various handover success rates are as follows:
l Handover success rate = (C1: CH323:Number of Successful Incoming Internal Inter-Cell
Handovers + C3)/(A1: CH320:Number of Incoming Internal Inter-Cell Handover Requests
+ A3)
l Radio handover success rate = (C1: CH323:Number of Successful Incoming Internal Inter-
Cell Handovers + C3)/(B1: CH321: Number of Incoming Internal Inter-Cell Handover
Responses + B3)
l RH303B:Intra-BSC Handover Success Rate = C1/A1
l RH303C:Intra-BSC Radio Handover Success Rate = C1/B1
l TH343:Success Rate of Incoming External Inter-Cell Handovers = C2/A2
l RH303D:Success Rate of Incoming External Inter-Cell Radio Handovers = C2/B2
l TH333:Success Rate of Outgoing External Inter-Cell Handovers = C3/A3
l RH303E:Success Rate of External Outgoing Cell Radio Handovers = C3/B3
GBSS14.0
56
NOTE
You can compare the handover success rate with the radio handover success rate to determine whether a
handover is caused by Um interface problems.
l If the handover success rate is lower than the radio handover success rate, check for problems related
to terrestrial links and network capacity.
l If both the handover success rate and the radio handover success rate are low and nearly equal, check
for interference and coverage problems.
4.2 Locating Handover Problems
This section describes how to locate handover problems.
4.2.1 Principles
Handover problems may be caused by inappropriate data configurations, hardware faults,
interference, or poor Um interface quality. Determine the specific cause of a handover problem
before resolving the problem.
Determine whether a handover problem occurs on an entire network or in a cell based on the
fault range and background information.
l If a handover problem occurs on an entire network, focus on MSC/BSC parameter settings
and signaling interactions.
l If a handover problem occurs in a cell, focus on data configuration, frequency, and the
hardware of the problem cell.
Handover problems can be located using the following methods:
1. Analyzing handover traffic statistics
2. Checking for top N cells with severe handover problems
3. Checking for equipment and transmission alarms
4. Checking for interference and coverage problems
5. Checking neighboring cell planning data
6. Checking parameter settings
4.2.2 Procedure for Locating Handover Problems
This section describes the procedure for locating handover problems.
Common Procedure
Figure 4-4 shows the common procedure for locating handover problems.
GBSS14.0
57
Figure 4-4 Common procedure for locating handover problems

NOTE
Collect the problem location information by referring to Table 4-1 before contacting Huawei for technical
support.
GBSS14.0
58
Table 4-1 Handover problem location information
No. Item Description Remarks
1 Symptom Provide the start time and end time of the problem,
specific symptom, and impact range (whether the
problem occurs in a cell, a BTS, a BSC, or all BSCs
under an MSC).

2 Operations
before and
after the
problem
occurs
Provide the operations before and after the problem
occurs, such as board replacement, software upgrade,
clock source change, dynamic data configuration, BTS
reset, BSC reset, MSC swapping, and MSC data
modification.

3 Faulty NE
version
Obtain the BSC and BTS software versions that are used
when the problem occurs.
For details
about how
to obtain
the BSC
and BTS
software
versions
that are
used when
the
problem
occurs, see
15
Appendix
: How to
Collect
Fault
Informati
on.
4 Configurati
on data
script
If any NEs are upgraded, obtain the configuration data
used before and after the upgrade.
If any messages are traced, obtain the configuration data
used during message tracing.
In other situations, obtain the configuration data used
For details
about how
to obtain
the
preceding
informatio
n, see 15
Appendix
: How to
Collect
Fault
Informati
on.
GBSS14.0
59
5 Historical
alarms
Obtain historical alarms generated when the problem
occurs.
For details
about how
to obtain
the
historical
alarms,
see 15
Appendix
: How to
Collect
Fault
Informati
on.
6 Original
traffic
statistics
If any NEs are upgraded, obtain the original traffic
statistics measured before and after the upgrade.
In emergencies, obtain the original traffic statistics
measured before and after the problem occurs.
In other situations, obtain the original traffic statistics
measured within the latest two or three days.
NOTE
If top N cells can be identified, you can customize the GCELL-
GCELL and GCELL-NCELL measurements for the top N
cells on the M2000, and collect the measurements when the
problem occurs.
The GCELL-GCELL and GCELL-NCELL measurements
may affect the CPU usage. Observe the CPU usage after the
measurements start, and stop the measurements after they are
complete.
For details
about how
to obtain
the
original
traffic
statistics,
see 15
Appendix
: How to
Collect
Fault
Informati
on.
7 Operation
logs
Obtain the operation logs generated from two days
before the problem occurs till now.
For details
about how
to obtain
the
operation
logs, see
15
Appendix
: How to
Collect
Fault
Informati
on.
GBSS14.0
60
8 Faulty
signaling
If the problem occurs in the laboratory or during a drive
test (DT), obtain the single-user call detail trace (CDT)
signaling.
If the inter-RAT handover occurs, obtain the signaling
on the A interface.
If top N cells can be identified, obtain the signaling on
the Abis and A interfaces for a cell among top N cells
In other situations, signaling collection is not required.
For details
about how
to obtain
the faulty
signaling,
see 15
Appendix
: How to
Collect
Fault
Informati
on.
9 GCHR and
GCSR logs
Obtain the GCHR and GCSR logs generated when the
problem occurs, including the logs generated for all
subracks.
For details
about how
to obtain
the GCHR
and GCSR
logs, see
15
Appendix
: How to
Collect
Fault
Informati
on.

Location Procedure
1. Analyze the information contained in 4.1.2 Handover Success Rate, and determine
whether there are top N cells with low handover success rates.
l If yes, go to Step 2.
l If no, go to 4.7 Troubleshooting Handover Problems Due to NE Faults. Then, check
whether the handover problem is resolved.
If yes, no further action is required.
If no, go to Step 2.
2. Check whether the source and target cells belong to the same BSC.
l If no, go to 4.8 Troubleshooting Handover Problems Due to Inappropriate Inter-
BSC/Inter-MSC/Inter-RAT Interaction. Then, check whether the handover problem
is resolved.
3. Check whether any hardware alarms have been reported for the problem cell.
l If no, go to Step 4.
GBSS14.0
61
l If yes, go to 4.3 Troubleshooting Handover Problems Due to Hardware Faults.
Then, check whether the handover problem is resolved.
4. Check whether handover data configurations are correct.
l If no, go to 4.4 Handover Problems Due to Incorrect Data Configurations. Then,
check whether the handover problem is resolved.
5. Check whether the channels of the target cell are congested.
l If yes, go to 4.5 Troubleshooting Handover Problems Due to Traffic Congestion in
the Target Cell. Then, check whether the handover problem is resolved.
6. Check whether the Um interface quality is poor.
l If yes, go to 4.6 Troubleshooting Handover Problems Due to Poor Um Interface
Quality. Then, check whether the handover problem is resolved.
7. If the handover problem persists, Contact Huawei Customer Service Center.
4.3 Troubleshooting Handover Problems Due to Hardware
Faults
This section describes how to troubleshoot handover problems due to hardware faults.
Symptom
When a hardware fault occurs in a cell, the alarm system reports correlated alarms such as
transmission alarms and TRX alarms.
If a handover problem occurred but data configurations are not modified for the problem cell
and its neighboring cells, check for BTS hardware faults.
Background Information
The alarms related to hardware faults are as follows:
l ALM-21807 OML Fault
Link access procedure on the D channel (LAPD) links are required for communication over
the data link layer between the BSC and a BTS. Links used for receiving and transmitting
operation and maintenance (O&M) messages are called operation and maintenance links
(OMLs), or LAPD_OMLs. ALM-21807 OML Fault is reported when the BSC detects that
GBSS14.0
62
the LAPD_OML to a BTS is interrupted, or that the handshake between the BSC and a
BTS expired.
l BTS LAPD alarms
ALM-4102 TRX LAPD Link Interrupt Alarm
ALM-3052 LAPD alarm
ALM-3572 LAPD alarm
These alarms are reported when a LAPD link is interrupted and the related TRX cannot
communicate with the BSC. As a result, the TRX cannot provide services and shuts down
the power amplifier. If this TRX is a BCCH TRX, the cells served by the TRX cannot
provide services.
l ALM-2204 TRX Communication Alarm
This alarm is reported when the communication between a TRX and the TMU failed. When
this alarm is reported, the TRX cannot operate properly.
l TRX standing wave alarms
ALM-2156 TRX VSWR Alarm
ALM-4144 TRX VSWR alarm
ALM-26529 RF Unit VSWR Threshold Crossed
These alarms are reported when the voltage standing wave ratio (VSWR) detected over a
TRX power output port exceeds 3 or when the cable is not properly connected to a DTRU
power output port (TX1, TX2, or TCOM). When this alarm is reported, the services
processed by the TRX are interrupted.
l ALM-28008 Radio Link Failure
This alarm is reported when a BTS detects a radio link exception.
l Clock source exception alarms
ALM-2208 Clock Reference Abnormal Alarm
ALM-3146 Clock Reference Abnormal alarm
ALM-3666 Clock Reference Abnormal alarm
ALM-4708 Clock Reference Abnormal Alarm
ALM-26262 External Clock Reference Problem
If a BTS clock is unstable, it may deviate from the other BTS clocks. As a result, handover
failures and call drops may occur.
Location Procedure
Figure 4-5 shows the procedure for locating handover problems due to hardware faults.
GBSS14.0
63
Figure 4-5 Procedure for locating handover problems due to hardware faults

Troubleshooting Procedure
1. Check whether any of the hardware alarms listed in Background Information have been
reported.
2. Clear hardware alarms.
l If the alarms persist, go to Step 3.
l If the alarms are cleared, check whether the handover problem is resolved.
3. Go to 4.2.2 Procedure for Locating Handover Problems.
Typical Case
Symptom
The success rate for handovers between all the cells under a BTS and their neighboring cells
under another BTS is 10.7%, whereas normally the success rate should be at least 98%. The
success rate for handovers between the cells under the same BTS is 99.2% during peak hours.
Cause Analysis
Possible causes for this problem are: hardware faults, cell channel congestion, incorrect
neighboring cell configurations, and clock source exceptions.
1. Check whether neighboring cells are configured properly using a network optimization
tool. Then, check whether any neighboring relationships are missing or redundant on the
LMT. Ensure that no neighboring cells are missing or redundant.
GBSS14.0
64
2. Check all the TRX boards. All the TRX boards operate normally, and none of the TRX
alarms listed in Background Information are reported.
3. Check the TMU. A clock source exception alarm listed in Background Information is
reported.
4. Replace the TMU. The alarm is cleared, and the success rate for handovers is at least 99.5%
between all the cells under a BTS and their neighboring cells.
4.4 Handover Problems Due to Incorrect Data
Configurations
This section describes how to troubleshoot handover problems due to incorrect data
configurations.
Symptom
l The signal quality in the serving cell is poor. Handovers often cannot be initiated, and the
call drop rate is high.
l The signal level and quality in the neighboring cell is slightly better than the serving cell.
Handovers are performed frequently, which deteriorates voice quality and increases the
number of call drops.
l If the P/N criterion is set inappropriately, PBGT handovers often fail, and the handover
success rate is less than 98%.
l Impact of handover threshold settings
Edge handovers are performed when the receive level is continuously less than the value
of Edge HO UL RX_LEV Threshold or Edge HO DL RX_LEV Threshold during a
specified period. Generally, Edge HO UL RX_LEV Threshold is set to 10, and Edge HO
DL RX_LEV Threshold is set to 20 in handover algorithm I or 15 in handover algorithm
II. If Edge HO UL RX_LEV Threshold or Edge HO DL RX_LEV Threshold is set too
low, a handover cannot be initiated when it should be. If Edge HO UL RX_LEV
Threshold or Edge HO DL RX_LEV Threshold is set too high, handovers are performed
frequently, which reduces the cell coverage area and leads to call drops. Therefore, set
Edge HO UL RX_LEV Threshold and Edge HO DL RX_LEV Threshold to appropriate
values based on the cell coverage. Changing the value of Edge HO UL RX_LEV
Threshold or Edge HO DL RX_LEV Threshold can change the coverage area of a cell.
If the serving cell coverage is weak, increase the value of Edge HO UL RX_LEV
Threshold or Edge HO DL RX_LEV Threshold by 2 dB to 5 dB to expedite handovers
to a suitable neighboring cell.
l Impact of neighboring cell configurations
If neighboring relationships are not configured or configured incorrectly even though the
signal level of a neighboring cell is high, the MS may report incorrect neighboring cell
information or may not report any neighboring cell information. As a result, the MS cannot
perform a handover or may have difficulty performing a handover.
l Incorrect setting of NCC Permitted
NCC Permitted is contained in system information 2 and 6. An MS measures only the signal
level of cells with NCC Permitted set to 1. If NCC Permitted for a serving cell is set
incorrectly, an MS cannot hand over to a neighboring cell. NCC Permitted consists of 8
GBSS14.0
65
bits, with bit 7 being the most significant bit and bit 0 being the least significant bit. Each
bit corresponds to an NCC (0 to 7).
l Inappropriate data configurations for cells with repeaters or RXU co-cells
Inappropriate data configurations for cells with repeaters or RXU co-cells may lead to
asynchronous handover failures.
l Impact of hysteresis configurations
The difference between the signal level of a candidate cell and that of the serving cell must
be greater than the handover hysteresis. Therefore, a large handover hysteresis may lead
to handover failures. If the serving cell coverage is weak, decrease the handover hysteresis
by 1 to 2 dB to expedite handovers to a suitable neighboring cell. If coverage overlap exists,
increase the handover hysteresis by 1 to 2 dB.
l Inappropriate configuration of optimal cell measurement time
During common handovers, an MS selects the target cell according to the N/P criteria. That
is, the MS selects the optimal cell for P seconds in N seconds as the target cell. If two cells
are the optimal cell alternatively, a handover may fail because the handover algorithm
cannot determine the target cell. In this case, reduce the optimal cell measurement time by
adjusting the values of N and P and ensure that the handover decision is more sensitive to
level changes. Handover failures may also occur when the receive level of a moving MS
fluctuates significantly in a serving cell with complex topography, which makes it difficult
for the target cell to meet the N/P criteria. The following are some N/P parameters:
Handover algorithm II Edge HO Watch Time
Handover algorithm II Edge HO Valid Time
Handover algorithm I Edge HO Watch Time
Handover algorithm I Edge HO Valid Time
Intracell F-H HO Stat Time
Intracell F-H HO Last Time
Location Procedure
Figure 4-6 shows the procedure for locating handover problems due to incorrect data
configurations.
GBSS14.0
66
Figure 4-6 Procedure for locating handover problems due to incorrect data configurations

1. Run the MML command LST GCELLHO2GBA2 to check whether neighboring cells are
configured correctly, especially whether any neighboring cells are missing based on
measurement reports, onsite network planning data, and engineering parameter settings.
Then, run the MML command LST GCELLIDLEBASIC to check whether NCC
permitted for the serving cell is set correctly.
l If yes (see Background Information), go to Step 2.
GBSS14.0
67
l If no, adjust neighboring cell configurations, or run the MML command SET
GCELLIDLEBASIC to set NCC permitted to its correct value by referring to
Background Information. Then, check whether the handover problem is resolved.
2. Check whether the problem cell is configured with a repeater or an RXU co-cell based on
the network plan, data configurations, and engineering parameter settings.
l If yes, run the MML command LST GCELLSOFT and check whether Directly
Magnifier BTS Flag or Co-Cell Switch is set to Yes.
If yes, go to 3.
If no, run the MML command SET GCELLSOFT to set Directly Magnifier BTS
Flag or Co-Cell Switch to Yes. Then, check whether the handover problem is
resolved.
3. Run the MML command LST GCELLHOBASIC to check whether Edge HO UL
RX_LEV Threshold and Edge HO DL RX_LEV Threshold are set correctly by referring
to Background Information.
l If no, run the MML command SET GCELLHOBASIC to change the value. Then,
4. Run the MML command LST GCELLHOBASIC to check whether Inter-layer HO
Hysteresis is set correctly by referring to Background Information.
5. Run the MML command LST GCELLHOBASIC to check whether parameters relevant
to optimal cell measurement time such as Handover algorithm II Edge HO Watch
Time and Handover algorithm II Edge HO Valid Time are set correctly by referring to
Background Information.
Typical Case
Symptom
GBSS14.0
68
The handover success rates for some cells are low. The outgoing handovers in these cells are
normal, but the number of incoming cell handovers is 0.
Cause Analysis
Possible causes for this problem are: incorrect data configurations, interference.
1. Check whether the neighboring cells of the problem cell work on the same frequency and
have the same BSIC.
No such neighboring cells exist.
2. Check whether the BCCH frequency used by the problem cell has been changed.
The BCCH frequency has not been changed.
3. Check whether there is strong interference for the problem cell.
The traffic statistics show that the interference bands are normal and that there are a small
number of call drops and handovers due to poor voice quality in the problem cell. Even if
there is strong interference for the problem cell, at least one handover can be performed
successfully. Therefore, the handover problem is not caused by interference.
4. Check whether the TRXs are operating properly.
The TRXs are operating properly.
5. Check the data configurations for the problem cell.
The BSIC of the problem cell has been changed, but the corresponding data of the
neighboring cells has not been changed. As a result, the BSC cannot locate the target cell
after initiating a handover request.
6. Change the corresponding data of all neighboring cells. The handover problem is resolved.
4.5 Troubleshooting Handover Problems Due to Traffic
Congestion in the Target Cell
This section describes how to troubleshoot handover problems due to traffic congestion in the
target cell.
Symptom
A handover to the target cell fails because the TCH congestion rates are high over several periods.
The possible causes of traffic congestion in the target cell are as follows:
l The number of MSs in the cell increases sharply because of assemblies or other activities.
l The network optimization parameters are set inappropriately, which causes a large number
of MSs to camp on the cell.
l The handover parameters are set inappropriately, which causes a large number of MSs to
hand over to the cell.
l The local switching function is enabled, which causes the number of handover attempts to
increase.
The traffic statistics associated with TCH congestion in the target cell are as follows:
GBSS14.0
69
l Number of failed internal intra-cell handovers due to congestion
H3029A:Failed Internal Intra-Cell Handovers (No Channel Available) (TCH)
H3229A:Number of Unsuccessful Incoming Internal Inter-Cell Handovers (No Channel
Available) (TCH)
l Traffic volume on TCHs
K3014:Traffic Volume on TCH
l TCH congestion rate (all TCHs are occupied)
K3011A:Failed TCH Seizures due to Busy TCH (Traffic Channel)
K3011B:Failed TCH Seizures in TCH Handovers due to Busy TCH (Traffic Channel)
Location Procedure
Figure 4-7 shows the procedure for locating handover problems due to traffic congestion in the
target cell.
Figure 4-7 Procedure for locating handover problems due to traffic congestion in the target cell

1. View the traffic statistics associated with TCH congestion rates listed in Background
Information over several periods to determine whether serious TCH congestion occurred
in the cell.
2. Run the MML command LST GTRXDEV to check whether TCH Rate Adjust Allow is
set to Yes.
l If yes, split the cell, expand the cell capacity, or adjust network optimization parameters
to reduce the number of MSs in the cell. Then, check whether the handover problem is
resolved.
GBSS14.0
70
l If no, run the MML command SET GTRXDEV to set TCH Rate Adjust Allow to
Yes. Then, check whether the handover problem is resolved.
If no, split the cell, expand the cell capacity, or adjust network optimization
parameters to reduce the number of MSs in the cell. Then, check whether the
handover problem is resolved. If yes, no further action is required. If no, go to Step
3.
Typical Case
Symptom
Call drops sometimes occur when an MS hands over from the source cell to the target cell.
Cause Analysis
Possible causes of this problem are as follows:
1. There are coverage holes in the target cell after cell coverage is reduced.
2. TRXs in the cell are faulty.
3. TCHs in the cell are faulty.
4. There are no sufficient handover resources in the cell.
1. Check whether the cell coverage and MS signals in the cell are normal.
a. The cell coverage is normal.
b. MS signals in the cell are normal.
2. Check whether TRXs in the cell are faulty.
TRXs in the cell are normal.
3. Check whether TCHs in the cell are faulty.
TCHs in the cell are normal.
4. Perform single-user signaling tracing.
The following results are found:
l When handover failure messages are sent, all TCHs in the target cell are occupied.
l When there are available TCHs in the cell, handovers can be performed successfully.
These results show that handover failures occur because TCHs in the cell are congested
and handover resources are insufficient.
5. Expand the BTS capacity. The handover problem is resolved.
4.6 Troubleshooting Handover Problems Due to Poor Um
Interface Quality
This section describes how to troubleshoot handover problems due to poor Um interface quality.
GBSS14.0
71
Symptom
Handover failures may occur when an MS fails to receive a handover command message from
the network, or when an MS fails to occupy the assigned TCH in the target cell.
l Interference may deteriorate the signal quality of the target cell. As a result, MSs fail to
occupy TCHs in the target cell even if the signal level of the target cell meets requirements.
Common interference consists of uplink or downlink interference, antenna intermodulation
interference, CDMA network interference, and uplink or downlink intra-system
interference.
The common methods for locating interference are as follows:
Interference bands are the bands of uplink interference levels on each TCH that the
BTS reports to the BSC when TCHs are in the idle state. There are five interference
bands. The higher the interference band, the higher the interference level. The level
ranges for the five interference bands are as follows:
Interference band 1: -105 to -98 dBm
Analyze Interference Band Measurement per TRX (MR.Iterf.TRX). If the number
of interference levels in the high interference bands is great, for example, if the
percentage of interference levels in interference bands 4 or 5 exceeds 30%, there is
interference.
The following counters are associated with interference band measurement.
AS4207A:Mean Number of TCHFs in Interference Band 1
AS4207B:Mean Number of TCHFs in Interference Band 2
AS4207C:Mean Number of TCHFs in Interference Band 3
AS4207D:Mean Number of TCHFs in Interference Band 4
AS4207E:Mean Number of TCHFs in Interference Band 5
AS4208A:Mean Number of TCHHs in Interference Band 1
AS4208B:Mean Number of TCHHs in Interference Band 2
AS4208C:Mean Number of TCHHs in Interference Band 3
AS4208D:Mean Number of TCHHs in Interference Band 4
AS4208E:Mean Number of TCHHs in Interference Band 5
The method for locating the interference problem is described as follows:
Perform drive tests (DTs) to identify the cell or frequency with strong interference on
the live network. Then eliminate the interference by changing the frequency, or by
adjusting the antenna tilt, transmit power, or cell coverage.
l If the Um interface quality is poor, MSs cannot receive any handover commands or physical
information. As a result, MSs send handover failure messages with one of the following
cause values: unspecified, timer expiry, protocol error, and other causes.
The method for checking the Um interface quality is described as follows:
GBSS14.0
72
Analyze Receive Quality Measurement Distribution per TRX
(MR.RecvQualOrig.TRX) to check the Um interface quality. Receive Quality
Measurement Distribution per TRX(MR.RecvQualOrig.TRX) measures the
distribution of receive quality in the measurement reports received on TCHs. The
receive quality is divided into eight bands ranging from band 0 to 7. Each receive quality
band corresponds to a bit error rate (BER) range. A higher receive quality band indicates
a higher BER and poorer receive quality. If the percentage of uplink or downlink receive
quality bands 6 and 7 exceeds 10%, the uplink or downlink transmission quality on the
Um interface is poor.
The following counters are associated with the Um interface quality:
Number of MRs on Downlink TCHF (Receive Quality Rank N)
Number of MRs on Uplink TCHF (Receive Quality Rank N)
Number of MRs on Downlink TCHH (Receive Quality Rank N)
Number of MRs on Uplink TCHH (Receive Quality Rank N)
The method for improving the Um interface quality is described as follows:
Network optimization engineers perform frequency optimization. If the Um interface
quality is not improved, perform DTs to locate and resolve the problem associated with
the receive quality and receive level. This is especially important if the problem is a
high receive level and poor receive quality.
Location Procedure
Figure 4-8 shows the procedure for locating handover problems due to poor Um interface
quality.
Figure 4-8 Procedure for locating handover problems due to poor Um interface quality

GBSS14.0
73
1. View the traffic statistics associated with interference bands listed in Background
Information to determine whether there is interference in the cell. Generally, there is
interference in the cell if the percentage of interference levels in interference bands 4 and
5 exceeds 30%.
l If yes, remove the interference source or change the frequency by referring to
2. View the traffic statistics associated with uplink and downlink quality listed in Background
Information to check whether the Um interface quality in the cell is satisfactory. Generally,
the uplink or downlink transmission quality of the Um interface is poor if the percentage
of uplink or downlink quality bands 6 and 7 exceeds 10%.
l If no, perform network optimization to improve the Um interface quality by referring
to Background Information. Then, check whether the handover problem is resolved.
Typical Case
Symptom
The intra-BSC incoming radio handover success rate for a cell under a BTS is between 10% and
30%, and the handover failure rate is high.
Cause Analysis
There are coverage holes in the areas with heavy traffic, and the signal strength on the uplink is
weak.
1. Check the hardware.
BTS maintenance boards and channels are normal.
2. Check the handover configuration data.
The handover configuration data is correct.
3. Perform DTs on the road 2 km away from the BTS where handovers are frequently
performed. If the MS fails to hand over to the target cell, the MS attempts to hand over
back to the source cell. Handovers to the source cell are sometimes successful, but the call
is dropped immediately after the MS hands over back to the source cell.
4. Perform several dialing tests on a locked frequency. When the MS serves as the calling
MS, the dialing tests fail. When the MS serves as the called MS, calls are connected but
dropped immediately. The problem location result indicates that the faulty components in
the combining and distribution unit (CDU) result in the high uplink channel loss, which
leads to a weak uplink signal strength.
GBSS14.0
74
5. Replace the CDU. If the incoming handover success rate exceeds 95%, the handover
problem is resolved.
4.7 Troubleshooting Handover Problems Due to NE Faults
This section describes how to troubleshoot handover problems due to NE faults.
Symptom
Handover failures occur in most cells under a BSC, but there are no top N cells with sluggish
performance.
l Handover failures occur when the BSC clock source operates abnormally.
You can run the MML command DSP CLK to check whether the BSC clock source
operates normally.
If Phase-locked loop state of current clock is set to Trace, the BSC clock source
operates normally.
If Phase-locked loop state of current clock is not set to Trace, the BSC clock source
operates abnormally.
l The methods for resolving the BSC clock source problem are as follows:
If a line clock serves as the BSC clock source, check whether the EIUa or OIUa board
that retrieves line clock signals reports any of the following alarms. If any of the
following alarms are reported, clear these alarms by referring to the Alarm Reference.
Then, check whether Phase-locked loop state of current clock is set to Trace. If
Phase-locked loop state of current clock is set to Trace or any of the following alarms
are not reported, switch over the active and standby GCUa boards or replace the active
GCUa with a new one to resolve the BSC clock source problem. If the BSC clock source
problem persists, Contact Huawei Customer Service Center.
ALM-21201 E1/T1 Loss of Signal
ALM-21202 E1/T1 Loss of Frame Alignment
ALM-21203 E1/T1 Remote Alarm Indication Signal
ALM-21204 E1/T1 Alarm Indication Signal
ALM-21205 E1/T1 Loss of Multiframe Alignment
ALM-21206 E1/T1 Loopback
ALM-21207 E1/T1 Excessive Bit Error Rate
ALM-21208 E1/T1 Excessive Slip Frames
ALM-21209 E1/T1 Online Loopback Detection
ALM-21252 SDH/SONET Loss of Signal
ALM-21253 SDH/SONET MS Remote Defect Indication
ALM-21254 SDH/SONET Loss of Frame
ALM-21255 SDH/SONET Loss of Frame Alignment
ALM-21256 SDH/SONET Loss of Cell Delineation
ALM-21257 SDH/SONET Signal Degraded
GBSS14.0
75
If the BITS clock serves as the BSC clock source, check whether the cable to the SMB
port (CLKIN0/1) on the GCUa is connected properly or the BITS clock source operates
normally.
Location Procedure
Figure 4-9 shows the procedure for locating handover problems due to NE faults.
Figure 4-9 Procedure for locating handover problems due to NE faults

1. Run the MML command DSP CLK to check whether Phase-locked loop state of current
clock is set to Trace.
l If no, set Phase-locked loop state of current clock to Trace by referring to
Typical Case
Symptom
There are 140 BTSs served by a BSC. The TMU clocks for 27 of the 140 BTSs are in the pull-
in state, and the TMU clocks for 38 BTSs are in the free-run state. The handover success rate of
the BSC is low and clock source exception alarms are reported on a large number of BTSs.
Cause Analysis
The clock source for the transmission equipment operates abnormally.
GBSS14.0
76
1. Check the BSC board clocks in each subrack.
The BSC board clocks in each subrack are normal.
2. Check the distribution of problem BTSs on the BSC.
The problem BTSs are distributed on boards in different subracks. This indicates that the
handover problem does not lie in a specific board or subrack.
3. Check the software for the 13 MHz clock frequency of the BTS.
4. Change the clock mode and trace mode of the problem BTSs. Only some BTSs properly
trace the BSC clock, which is the upper-level clock. The other BTSs are in the pull-in or
free-run state. Regarding the BTSs that properly trace the BSC clock, the current values of
these clocks are not between 1500 and 1900 and largely different from the default values
and standard values. The difference values are larger than 1000. This indicates that the BSC
clock may be unreliable. However, the BSC clock check result shows that the BSC clock
is operating properly.
5. Figure 4-10 shows the network topology. The problem may lie in the clock source of the
SDH equipment. The SDH equipment is Metro2050 and the clock board is STG. The upper-
level line clock or local internal clock can be configured as the clock source of the SDH
equipment. When the problem occurs, the local internal clock serves as the clock source
of SDH 2. In this situation, the local internal clock also serves as the clock source of other
SDH equipment.
Figure 4-10 Network topology

6. Configure the upper-level line clock as the clock source of SDH 2, which indicates that
SDH 2 traces the clock of SDH 1. Four hours later, clocks for 8 BTSs are in the locked
state, but clocks for 42 BTSs are still in the pull-in state and clocks for 15 BTSs are still in
the free-run state. Six hours later, all clocks for the problem BTSs under the BSC are in the
locked state. According to the traffic statistics, the handover success rate has increased from
84% to 97%.
GBSS14.0
77
4.8 Troubleshooting Handover Problems Due to
Inappropriate Inter-BSC/Inter-MSC/Inter-RAT Interaction
This section describes how to troubleshoot handover problems due to inappropriate inter-BSC,
inter-MSC, or inter-RAT interaction.
Symptom
l The inter-BSC handover failure rate is high.
l The inter-RAT handover failure rate is high.
The possible causes of inter-BSC or inter-RAT handover failures are as follows:
l Cell data associated with MSC handovers is configured incorrectly. The cell data includes
cell global identity (CGI), location area code (LAC), and handover number.
l Cell data associated with handovers to the target BSC is configured incorrectly.
l Inter-RAT neighboring cells are configured incorrectly.
l Encryption is performed improperly.
l The handover procedure is performed improperly.
Location Procedure
Figure 4-11 shows the procedure for locating handover problems due to inappropriate inter-
BSC, inter-MSC, or inter-RAT interaction.
GBSS14.0
78
Figure 4-11 Procedure for locating handover problems due to inappropriate inter-BSC, inter-
MSC, or inter-RAT interaction

1. Run the MML command DSP CLK to check whether the BSC properly traces the upper-
level clock (MSC clock).
l If Phase-locked loop state of current clock is set to Trace, go to Step 2.
l If Phase-locked loop state of current clock is not set to Trace, use the BSC to trace
the MSC clock. Then, check whether the handover problem is resolved.
GBSS14.0
79
2. Check whether neighboring cell configurations for the source and target BSCs are correct
based on the network planning data and engineering parameters of the live network. Also
check the system information and measurement reports collected during DTs.
l If no, correct the neighboring cell configurations. Then, check whether the handover
problem is resolved.
3. Check whether data configurations for the problem cell served by the MSC are correct. The
data includes CGI, LAC, and handover number as well as the office to which the problem
cell belongs.
l If no, correct the data configurations. Then, check whether the handover problem is
resolved.
4. Check whether the encryption procedure causes handover failures according to the
signaling procedure.
l If yes, adjust the encryption parameters or encryption procedure of the MSC or BSC.
Then, check whether the handover problem is resolved.
5. Trace the signaling on the A or E interface to check whether the signaling interactions
between the source BSC and the MSC, between MSCs, and between networks are normal.
l If no, identify the cause of abnormal signaling interactions by checking the A interface
version, signaling interaction on the E interface, and signaling interaction between
networks. Then, check whether the handover problem is resolved.
Typical Case 1
Symptom
According to traffic statistics, the handover success rate for BSC A is lower than the handover
success rates for other BSCs. However, the historical traffic statistics show that the handover
success rate for BSC A is about 88%.
Cause Analysis
The MSC is not configured with any external LAC data.
GBSS14.0
80
1. View the success rates for various handovers. The inter-BSC outgoing handover success
rate for BSC A is between 50% and 70%.
2. View the cell-level inter-BSC handover success rates. The inter-BSC handover success
rates for some cells are small. The geographic display of these problem cells shows that
these cells are located near the border of the areas served by vendor B's equipment.
Therefore, it is suspected that the neighboring cell data of Huawei equipment is not
synchronized because modifications to data configurations for vendor B's equipment were
performed without notification. However, the check result of neighboring cell data shows
that the data is configured correctly.
3. Perform signaling tracing on the problem cells under BSC A. After a handover request is
delivered, the target cell cannot be identified. The LAC of BSC A is inconsistent with the
LAC of vendor B's equipment. Therefore, it is suspected that the MSC serving BSC A may
not be configured with the external LAC data for the cells near the border of the areas served
by vendor B's equipment.
4. Contact MSC maintenance engineers to analyze the problem. The MSC is not configured
with the LAC data for the cells near the border of the areas served by vendor B's equipment.
After the required LAC data is configured, the handover success rate exceeds 96%.
Typical Case 2
Symptom
After a BTS is swapped from BSC TP 01 to BSC TP 03, the outgoing radio handover success
rate for vendor M's network is low, but other performance counters are normal. BSC TP 01 and
BSC TP 03 are of the same version and served by different MSCs.
Cause Analysis
According to the signaling analysis, the encryption algorithm delivered by vendor M's MSC is
incorrect. As a result, the encryption algorithm used by the MS is not the same as that used by
vendor M's BTS during handovers.
1. The Huawei MSC is configured with the A5/2 encryption algorithm. The Huawei BSS and
vendor M's BSS, however, are configured with A5/0 and A5/1 encryption algorithms. As
a result, after the MS accesses the Huawei network, the MS is not encrypted and notifies
the Huawei MSC of relevant information.
2. During an outgoing handover to vendor M's network, vendor M's MSC requests that the
MS be encrypted and sends the BSC an HO REQ message containing the supported
encryption algorithms A5/0, A5/1, and A5/2. The HO REQ message, however, does not
carry the information element Chosen Encryption Algorithm to show the
encryption algorithm used by the MS.
3. Unaware of the encryption algorithm change during the handover, vendor M's MSC selects
the A5/1 encryption algorithm and does not notify the MS of the encryption algorithm
change using the HO REQ ACK message containing the Layer 3 information element.
4. The BSC does not obtain the encryption algorithm change information from the HO REQ
ACK message and instructs the MS to use the original encryption algorithm A5/0.
5. The encryption algorithm used by the MS is not the same as that used by vendor M's BTS.
When accessing vendor M's network, the MS fails to receive the Physical Info
message from vendor M's BTS because the Physical Info message is encrypted by
GBSS14.0
81
the A5/1 algorithm. As a result, the MS fails to access vendor M's network and is handed
over back to the original channel.
6. Change the encryption algorithm on vendor M's MSC. The handover problem is resolved.
GBSS14.0
82
5 Call Drops
About This Chapter
This chapter describes how to locate and troubleshoot call drops.
5.1 Call Drop Rate
The call drop rate indicates the probability with which an MS will release ongoing calls
unexpectedly after accessing a TCH. A high call drop rate may significantly deteriorate user
experience.
5.2 Locating Call Drops
This section describes how to locate call drops.
5.3 Troubleshooting Call Drops Due to Poor Um Interface Quality
This section describes how to troubleshoot call drops due to poor Um interface quality.
5.4 Troubleshooting Call Drops Due to Equipment Faults
This section describes how to troubleshoot call drops due to equipment faults.
5.5 Troubleshooting Call Drops Due to Transmission Faults
This section describes how to troubleshoot call drops due to transmission faults.
5.6 Troubleshooting Call Drops Due to Incorrect Parameter Settings
This section describes how to troubleshoot call drops due to incorrect parameter settings.
GBSS14.0
Troubleshooting Guide 5 Call Drops
83
5.1 Call Drop Rate
The call drop rate indicates the probability with which an MS will release ongoing calls
unexpectedly after accessing a TCH. A high call drop rate may significantly deteriorate user
experience.
Formula
See the online help for the formulas for calculating the following counters associated with call
drops:
l ZTR304A:Call Drop Rate on TCH per cell(Excluding Handover)
l ZTR304:Call Drop Rate on TCH per cell(including Handover)
Call Drop Rate on TCH per cell(Excluding Handover) indicates the call drop rate in the stable
state. With regard to the formulas for calculating the two counters, the numerators in both
formulas are the same, except that Successful TCH Seizures in TCH handovers (Traffic Channel)
is included in the denominator of ZTR304:Call Drop Rate on TCH per cell(including Handover)
but not in the denominator of ZTR304A:Call Drop Rate on TCH per cell(Excluding Handover).
Therefore, the value of the former is smaller than that of the latter.
Measurement Points and Signaling Procedure
See the online help for CM33:Call Drops on Traffic Channel.
According to the measurement points for the call drop rate, call drops are classified into two
types:
l Call drops in the stable state, as shown in Figure 5-1
l Call drops in the handover state, as shown in Figure 5-2
GBSS14.0
84
Figure 5-1 Procedure for Call drops in the stable state

Figure 5-2 Procedure for call drops in the handover state

5.2 Locating Call Drops
This section describes how to locate call drops.
5.2.1 Procedure for Locating Call Drops
Before locating call drops, determine the fault range.
GBSS14.0
85
Principles
l Before locating call drops, determine whether the fault exists on the entire network or only
in certain cells by analyzing 5.2.2 Counters Related to Call Drops.
l Analyze the proportion of the various types of call drops to determine whether call drops
are caused by poor Um interface quality.
If the values of CM333:Call Drops due to Abis Terrestrial Link Failure (Traffic
Channel) and CM334:Call Drops due to Equipment Failure (Traffic Channel) increase,
call drops are not caused by poor Um interface quality. In this case, check for equipment
and transmission faults.
If the counters indicating call drops due to poor Um interface quality increase, check
for inappropriate network parameter settings, interference, and coverage problems.
Location Procedure
Figure 5-3 shows the procedure for locating call drops.
Figure 5-3 Procedure for locating call drops
GBSS14.0
86

NOTE
support.
Table 5-1 Call drop location information
problem occurs in a cell, a BTS, a BSC, or all BSCs under
an MSC).

2 Operatio
ns before
and after
the
problem
occurs
modification.

3 Faulty
NE
version
For details
about how to
obtain the
BSC and BTS
software
versions that
are used when
the problem
occurs, see 15
Appendix:
How to
Collect Fault
Information.
4 Configur
ation data
script
Obtain the configuration data script used when the
problem occurs.
For details
about how to
obtain the
configuration
data script, see
15 Appendix:
How to
Collect Fault
Information.
5 Historica
l alarms
Obtain the historical alarms generated within three days
before and after the problem occurs.
For details
about how to
obtain the
historical
alarms, see 15
Appendix:
How to
Collect Fault
Information.
GBSS14.0
87
6 Original
traffic
statistics
Obtain the original traffic statistics measured within two
days before and after the problem occurs.
For details
about how to
obtain the
original traffic
statistics, see
15 Appendix:
How to
Collect Fault
Information.
7 GCHR
and
GCSR
logs
Obtain the GCHR and GCSR logs generated within two
hours before and after the problem occurs, including the
logs generated for all subracks.
For details
about how to
obtain the
GCHR and
GCSR logs,
see 15
Appendix:
How to
Collect Fault
Information.
8 Common
debuggin
g logs
Obtain the common debugging logs generated within
two days before and after the problem occurs.
For details
about how to
obtain the
common
debugging
logs, see 15
Appendix:
How to
Collect Fault
Information.
9 Operatio
n logs
Obtain the operation logs generated within 10 days
For details
about how to
obtain the
operation logs,
see 15
Appendix:
How to
Collect Fault
Information.
10 Faulty
signaling
Obtain the signaling on the Abis and A interfaces and
single-user signaling of one or two faulty cells when the
problem occurs.
For details
about how to
obtain the
faulty
signaling, see
15 Appendix:
How to
Collect Fault
Information.
GBSS14.0
88
11 BTS logs Obtain all logs generated for one or two faulty BTSs. For details
about how to
obtain BTS
logs, see 15
Appendix:
How to
Collect Fault
Information.

5.2.2 Counters Related to Call Drops
The counters related to call drops are classified according to call drop type for easy
troubleshooting.
Table 5-2 lists the counters related to call drops.
Table 5-2 Counters related to call drops
Counters related to call drops
CM33:Call Drops on Traffic
Channel
CM33C:Call Drops on Radio
Interface (Traffic Channel)
CM330:Call Drops on Radio
Interface in Stable State
(Traffic Channel)
Interface in Handover State
(Traffic Channel)
CM332:Call Drops Due to
No MR from MS for a Long
Time (Traffic Channel)
/
CM333:Call Drops due to
Abis Terrestrial Link Failure
(Traffic Channel)
/
Equipment Failure (Traffic
Channel)
/
Forced Handover (Traffic
Channel)
/
local switching Start Failure
/
Failures to Return to Normal
Call from local switching
/

GBSS14.0
89
CM33C:Call Drops on Radio Interface (Traffic Channel) indicates call drops due to poor Um
interface quality, which is the most common cause of call drops on a network. CM333:Call
Drops due to Abis Terrestrial Link Failure (Traffic Channel) and CM334:Call Drops due to
Equipment Failure (Traffic Channel) indicate call drops due to transmission and equipment
faults, respectively. Pay attention to these two counters if their values are large.
Table 5-3 lists the counters related to call drops due to poor Um interface quality.
Table 5-3 Counters related to call drops due to poor Um interface quality
Counters related to call drops due to poor Um interface quality
CM33C:Call Drops on Radio
Interface (Traffic Channel)
Interface in Stable State
(Traffic Channel)
CM3300:Call Drops on
Traffic Channel in Stable
State (Error Indication)
State (Connection Failure)
State (Release Indication)
Interface in Handover State
(Traffic Channel)
H3027Ca:Failed Internal
Intra-Cell Handovers (Timer
Expired) (TCHF) (Traffic
Channel)
H3028Ca:Failed Internal
Intra-Cell Handovers (Timer
Expired) (TCHH) (Traffic
Channel)
H3127Ca:Number of
Unsuccessful Outgoing
Internal Inter-Cell
Handovers (Timer Expired)
(TCHF) (Traffic Channel)
H3128Ca:Number of
Unsuccessful Outgoing
Internal Inter-Cell
Handovers (Timer Expired)
(TCHH) (Traffic Channel)
H3327Ca:Failed Outgoing
External Inter-Cell
Handovers (T8 Expiry)
(TCHF) (Traffic Channel)
H3328Ca:Failed Outgoing
External Inter-Cell
Handovers (T8 Expiry)
(TCHH) (Traffic Channel)

GBSS14.0
90
l In the stable state, focus on CM3300:Call Drops on Traffic Channel in Stable State (Error
Indication) and CM3301:Call Drops on Traffic Channel in Stable State (Connection
Failure). Generally, call drops in the stable state as indicated by CM3301:Call Drops on
Traffic Channel in Stable State (Connection Failure) account for the largest proportion of
call drops due to poor Um interface quality.
l In the handover state, focus on H3127Ca:Number of Unsuccessful Outgoing Internal Inter-
Cell Handovers (Timer Expired) (TCHF) (Traffic Channel) and H3128Ca:Number of
Unsuccessful Outgoing Internal Inter-Cell Handovers (Timer Expired) (TCHH) (Traffic
Channel) because inter-cell handovers account for a large proportion.
l Analyzing the counters related to call drops helps determine the main cause of call drops.
Call drop types whose portion increases from a small value to a large value need special
attention.
5.2.3 Types of Call Drops
Classifying call drops into different types helps troubleshoot call drops.
Figure 5-4 describes the types and common causes of call drops.
GBSS14.0
91
Figure 5-4 Procedure for locating call drops

Call Drops on Um Interface in the Stable State
When a call is in the stable state, call drops may occur after a BTS sends the BSC one of the
following messages:
l ERROR INDICATION
GBSS14.0
92
When the BTS sends an I frame, the timer T200 starts. If the BTS does not receive an
acknowledgment message from the BSC before the timer expires, it resends the I frame
for a maximum of 200 times. If the BTS still does not receive an acknowledgment
message, the BTS sends the BSC an ERROR INDICATION message with a cause value
of timer T200 expired (N200+1) times (0x01).
If the BTS detects that the serial numbers of the received I and S frames are out of order,
it sends the BSC an ERROR INDICATION message with a cause value of sequence
error (0x07).
When the BTS receives an unexpected DM frame, the BTS sends the BSC an ERROR
INDICATION with a cause value of unsolicited DM response (0x05).
The call drops indicated by the ERROR INDICATION message are generally caused
by interference or coverage problems, though they may also be caused by inappropriate
antenna installation, TRX faults, or incorrect data configurations.
l CONNECTION FAILURE INDICATION
If the BTS detects that uplink SACCH decoding fails repeatedly within the value
specified by SACCH Multi-Frames, the BTS sends a CONNECTION FAILURE
INDICATION message to the BSC.
The call drops indicated by the ERROR INDICATION message are generally caused
by interference or coverage problems, though they may also be caused by inappropriate
antenna installation, TRX faults, or incorrect data configurations.
l RELEASE INDICATION
In the multi-frame link establishment state, when receiving a DISC frame from an MS,
the BTS sends a RELEASE INDICATION message to the BSC.
The RELEASE INDICATION message is sent during normal release procedures.
Therefore, it does not always indicate a call drop. Call drops indicated by the RELEASE
INDICATION message seldom occur. They may be caused by inappropriate signaling
interaction problems between the MS and the BSS/NSS, not by poor Um interface
quality.
Call Drops on Um Interface in the Handover State
This type of call drop occurs after a BSC delivers a handover command but does not receive an
acknowledgment message before the relevant timer expires.
l Intra-cell handovers
When Intracell HO Allowed is set to YES(YES) by using the MML command SET
GCELLHOBASIC, an interference handover or bad quality handover can be performed.
However, if the signal level of the neighboring cell is low, a large number of intra-cell
handovers may increase the call drop rate.
l Inter-cell handovers
Call drops during inter-cell handovers are generally caused by interference or coverage
problems, though they may also be caused by inappropriate antenna installation, TRX
faults, incorrect neighboring cell configurations, or a large clock frequency offset.
l Inter-BSC handovers
The causes of call drops during inter-BSC handovers are similar to those of intra-BSC
handovers. The main causes are as follows: (1) The neighboring relationship configured
on the BSS is inconsistent with that configured on the NSS; (2) The clock frequency offset
is large. These two factors should also be considered for call drops during inter-RAT
handovers.
GBSS14.0
93
Call Drops Due to No Measurement Report Submitted by the MS
This type of call drop seldom occurs. If a large number of call drops occur because the BSC
does not receive any measurement reports from an MS within a specified period (five minutes
by default), an exception occurs in the interaction between the BSS and the MS. In this case,
check the configuration data related to measurement reports as well as the signaling interaction
between the BSS and the MS. For example, check whether the BTS can decode the extended
measurement reports submitted by the MS.
Call Drops Due to Abis Terrestrial Link Faults
This type of call drop seldom occurs. If there are a large number of such call drops, the BSC
detects that radio signaling links (RSLs) are interrupted because the Abis transmission or the
BSC/BTS LAPD link transmission is faulty. In this case, check the relevant alarms, Abis
transmission, and BSC/BTS LAPD link transmission.
Call Drops Due to Equipment Faults
This type of call drop occurs in cases of abnormal transmission, BSS hardware faults, or incorrect
data configurations. It may also occur in cases of dynamic data configuration (such as frequency
modification or cell deletion) or internal BSC network connection failures. When this type of
call drop occurs, check the relevant alarms, Abis/Ater/A interface transmission, TRX boards,
and BSC DPU/TNU/interface board.
Call Drops Due to Forced Handovers
This type of call drop may occur during handovers triggered by dynamic channel adjustment.
This type of call drop may also occur when MSC-triggered handovers or handovers triggered
by the following causes time out: TRX cooperation, channel preemption, cell/TRX/channel
blocking, or OM. Dynamic channel adjustment, TRX cooperation, and channel preemption are
the most common causes. If there are a large number of such call drops, check whether the data
configuration is correct and whether TRXs become faulty frequently.
5.3 Troubleshooting Call Drops Due to Poor Um Interface
Quality
This section describes how to troubleshoot call drops due to poor Um interface quality.
Symptom
Call drops due to poor Um interface quality consist of call drops for the Um interface in the
stable state and call drops for the Um interface in the handover state.
l With regard to the signaling on the Abis interface, call drops for the Um interface in the
stable state refer to the call drops that occur after the BTS sends an ERROR INDICATION,
CONNECTION FAILURE INDICATION, or RELEASE INDICATION message to the
BSC.
l With regard to the signaling on the Abis interface, call drops for the Um interface in the
handover state refer to the call drops that occur when a handover times out after the BSC
issues a handover command to an MS.
CM33C:Call Drops on Radio Interface (Traffic Channel) indicates the number of call drops due
to poor Um interface quality.
GBSS14.0
94
l The cause of call drops on the Um interface can be identified from the aspects of
interference, uplink and downlink level balance, coverage, antenna system, BTS hardware,
BSC handover parameters, and the neighboring cell configuration for handover. If the call
drops are caused by incorrect BSC handover parameter settings or incorrect neighboring
cell configuration for handover, analyze the problem by referring to 4 Handover
Problems. The relevant descriptions are not included in this section.
l To locate the interference, perform the following operations:
1. Query Receive Quality Measurement Distribution per TRX
(MR.RecvQualOrig.TRX). If the receive quality is poor, for example, if the proportion
of uplink receive quality in receive quality bands 5, 6, and 7 exceeds 20%, there is a
high probability that call drops will occur.
2. Analyze Interference Band Measurement per TRX(MR.Iterf.TRX). If interference
levels occur in the higher-level interference bands, for example, the proportion of
interference levels in interference bands 4 and 5 exceeds 10%, the call drops are caused
by uplink interference.
3. Use either of the following methods to determine whether call drops are caused by
interference. One method is to analyze the signaling on the Abis interface. If the
measurement reports (MRs) before call drops show that both the uplink and downlink
levels are satisfactory but the receive quality is poor, call drops are caused by
interference. The other method is to analyze the TEMS signaling collected when call
drops occur. If the downlink level is satisfactory but the carrier-to-interference ratio
(CIR) is small before call drops occur, the call drops are caused by interference.
Location Procedure
Figure 5-5 shows the procedure for locating call drops due to poor Um interface quality.
GBSS14.0
95
Figure 5-5 Procedure for locating call drops due to poor Um interface quality

1. Check whether there is any interference. For details, see Background Information.
l If the call drops are caused by interference, check whether there are any interference
sources exist onsite or perform drive tests (DTs) to locate the interference source. In
addition, check whether repeaters have been installed or whether installed repeaters are
faulty by referring to the following description. If any interference source is found,
eliminate it by referring to 12 Interference Problems. Then, go to Step 2.
GBSS14.0
96
a. Run the LST GCELLSOFT command to check whether Directly Magnifier BTS
Flag is set to Yes. If Directly Magnifier BTS Flag is set to Yes, the cell is
configured with repeaters. If Directly Magnifier BTS Flag is set to No, check
whether other operators' repeaters are installed near the cell or whether any
repeaters are installed without permission.
b. If repeaters are installed, check whether they are wideband repeaters. If they are
wideband repeaters, check whether the uplink or downlink gain is large. If the
uplink or downlink gain is large, reduce it as required. Shut down the repeaters if
they have great impact on the call drop rate.
c. Check whether repeaters are faulty or whether the uplink or downlink gain is
beyond the normal range. If repeaters are faulty or the uplink or downlink gain is
beyond the normal range, the actual BTS coverage may change, which increases
the call drop rate. If any repeater problem occurs in the cell, the number of MRs
with a large timing advance (TA) value measured for Number of MRs based on
TA per TRX(MR.TaDistribOrig.TRX) is great.
l If call drops are not caused by interference, go to Step 3.
2. Check whether the call drop problem is resolved.
l If yes, no further action is required.
3. Check whether the uplink and downlink levels are balanced.
Query Uplink-and-Downlink Balance Measurement per TRX(MR.BalanceOrig.TRX).
With regard to TRXs, if the proportion of the uplink and downlink level balance class 1 or
11 to all uplink and downlink level balance classes exceeds 30%, the uplink and downlink
levels are unbalanced.
NOTE
Uplink-and-Downlink Balance Measurement per TRX(MR.BalanceOrig.TRX) indicates the statistical
result of MRs. If the MRs before call drops show that the uplink and downlink levels are unbalanced, then
this is the cause of the call drops.
l If no, check whether the equipment transmission and TRX cable connections onsite are
proper, and whether there are any potential risks on the antenna system by referring to
the following description. After the preceding items are checked and the faults are
rectified, go to Step 4.
If dual-transmit antennas are configured, ensure that the tilt and azimuth of the
antennas are the same.
Check whether the jumpers are misconnected by analyzing DT data. If the jumpers
are misconnected, the uplink signal level in the cell is significantly lower than the
downlink signal level, and call drops are likely to occur in a cell far away from the
BTS. In this situation, reconnect the jumpers.
If the feeders are damaged, wet, or distorted, or if the connectors are in poor contact,
both the transmit power and receive sensitivity are reduced. As a result, call drops
occur with a high probability. Locate these kinds of problems by referring to
ALM-4144 TRX VSWR alarm, ALM-2156 TRX VSWR Alarm, or ALM-26529
RF Unit VSWR Threshold Crossed. If any feeder is faulty, immediately replace it.
If the antenna system is faulty, both the call drop rate and handover failure rate are
high, and the uplink and downlink receive quality is totally different or both the
uplink and downlink receive quality is poor.
GBSS14.0
97
5. Check whether there are any coverage problems.
a. Query TCHF Receive Level Measurement per TRX
(MR.RecvLevlOrigFullRate.TRX) or TCHH Receive Level Measurement per TRX
(MR.RecvLevlOrigHalfRate.TRX) to analyze the mapping between the receive
quality and receive levels. If poor receive quality mainly maps to low receive levels,
call drops in the cell may be caused by poor receive quality, which results from
coverage problems.
b. Analyze Number of MRs based on TA per TRX(MR.TaDistribOrig.TRX). If there
are many MRs with a large TA value, the call drops are caused by too-wide coverage
or coverage overlaps. Otherwise, the call drops are caused by weak coverage.
c. Analyze the signaling to locate the cause of the call drops. If the TA value is large
when an MS accesses the network and if the signal level is low when call drops occur,
the call drops are caused by too-wide coverage or coverage overlaps. If the TA value
is small when an MS accesses the network, the call drops are caused by weak coverage.
If the proportion of the sum of TA values 0 through 5 to the sum of all the values is
less than 90%, check for a coverage problem in the cell based on the coverage scenario
and DT result.
l If yes, resolve the problem and go to Step 6.Contact network optimization
engineers to resolve the cell coverage problem. Then, go to Step 6
7. Check the Um interface quality.
Query TCHF Receive Level Measurement per TRX(MR.RecvLevlOrigFullRate.TRX) or
TCHH Receive Level Measurement per TRX(MR.RecvLevlOrigHalfRate.TRX). If the
proportion of receive quality bands 6 and 7 to all receive quality bands exceeds 10%, the
uplink or downlink receive quality is poor.
l If the Um interface quality is poor, request network optimization engineers to optimize
frequency data. Then, go to Step 8.
l If the Um interface quality is satisfactory, go to Step 9.
9. Perform DTs to check whether either of the following problems occur: high receive level
and poor receive quality; low receive level and poor receive quality.
l If yes, request network optimization engineers to analyze and resolve the problem. Then,
go to Step 10.
l If no, return to Procedure for Locating Call Drops to continue the processing.
l If no, return to Procedure for Locating Call Drops to continue the processing.
GBSS14.0
98
Typical Case
Symptom
The call drop rate of CELL3 under a BTS reaches 10%, but the call drop rate and congestion
rate of CELL1 and CELL2 are normal.
Cause Analysis
There is external interference or the coverage is weak.
1. View the traffic statistics. Calls in the cell are dropped because of poor Um interface quality.
2. View and analyze the traffic statistics. The distribution of interference levels in interference
bands is regular, specifically, the interference is strong during peak hours and weak during
off-peak hours.
3. Change the frequencies of CELL3 to ensure that the frequency spacing is 1 MHz or more.
The problem persists, and therefore there is no co-channel or adjacent-channel interference.
4. Perform a frequency scan test to locate the external interference source by using a spectrum
analyzer. The test result shows that there is a constant signal with a center frequency of
904.14 MHz and a spectrum bandwidth of 300 kHz, which is similar to the signal from an
analog spectrum. The signal strength at the divider ports for CELL3, CELL2, and CELL1
is -27 dBm, -40 dBm, and -60 dBm respectively. The higher the signal strength, the greater
the interference. The traffic volume in the daytime is greater than that at night, and therefore
intermodulation probably occurs. The root cause of the problem appears to be an external
interference source with a center frequency of 904 MHz. The interference source cannot
be located after DTs are performed by using the spectrum analyzer. Therefore, all tests
must be performed on the rooftop. The test result shows that the interference source is an
antenna on a repeater. Interrupt the signal and perform the test again. The test result verifies
that the antenna is the source of interference signals.
5. Shut down the repeater. The call drop rate of CELL3 is restored to normal.
5.4 Troubleshooting Call Drops Due to Equipment Faults
This section describes how to troubleshoot call drops due to equipment faults.
Symptom
On the BSC side, call drops due to BSC hardware faults, abnormal internal software processing,
or configuration errors are considered as call drops due to equipment faults. These call drops
are indicated by the cause value equipment failure (0x20) carried in the CLEAR REQ message
in the base station subsystem application part (BSSAP) messages traced on the A interface.
CM334:Call Drops due to Equipment Failure (Traffic Channel) indicates the number of call
drops due to equipment faults on the BSC side.
Call drops due to BTS hardware faults are also considered as call drops due to equipment faults.
BTS hardware faults may deteriorate the Um interface quality or cause coverage problems. This
leads to an increase in the call drop rate.
Call drops due to equipment faults are classified into the following types:
GBSS14.0
99
l Call drops due to faults in the MSC
l Call drops due to BSC or BTS software defects
l Call drops due to BSC or BTS hardware faults
l Call drops due to dynamic configuration
l Call drops due to transmission faults
l Call drops due to insufficient BSC resources
The following alarms are associated with call drops due to equipment faults.
l ALM-2204 TRX Communication Alarm
l ALM-2156 TRX VSWR Alarm
l ALM-4144 TRX VSWR alarm
l ALM-26529 RF Unit VSWR Threshold Crossed
l ALM-3606 DRU Hardware alarm
l ALM-20241 Board Unavailable
l ALM-20243 Board Hardware Fault
l ALM-20254 DSP Unavailable
l ALM-20231 Link Between TDM Switching Boards in Different Subracks Faulty
l ALM-20230 TDM Link Between TDM Switching Board and Service Board Faulty
Location Procedure
Figure 5-6 shows the procedure for locating call drops due to equipment faults.
GBSS14.0
100
Figure 5-6 Procedure for locating call drops due to equipment faults

1. Check whether any of the alarms listed in Background Information are reported.
l If yes, clear the alarms by referring to the Alarm Reference. Then, go to Step 2.
3. Check whether the operations, such as dynamically deleting cells or TRXs and modifying
channel attributes or base station identity codes (BSICs), are performed when call drops
occur.
l If yes, check whether there are no call drops when the relevant operations are not
performed. If there are no call drops, no further action is required. Otherwise, go to
Step 4.
4. Analyze the signaling on the A interface when call drops occur, and check whether the
MSC sends a large number of Reset Circuit messages.
GBSS14.0
101
l If yes, call drops are caused by circuit resetting. Request core network (CN) engineers
to resolve the problem. Then, go to Step 5.
l If no, return to Procedure for Troubleshooting Call Drops to continue the processing.
l If no, return to Procedure for Troubleshooting Call Drops to continue the processing.
Typical Case 1
Symptom
A large number of call drops due to equipment faults occur within a measurement period after
cell BSICs are modified after absolute radio frequency channel number (ARFCN) information
is imported during peak hours.
Cause Analysis
Dynamically deleting cells or TRXs and modifying channel attributes or BSICs may cause call
drops due to equipment faults.
1. Check the traffic statistics measured when call drops occur. Call drops due to equipment
faults occur only in some cells controlled by the BSC.
2. Check for alarms reported on the BSC when the call drops occur. There are no hardware
alarms.
3. Check the BSC operation logs. The cell BSICs are modified when call drops occur. When
a cell BSIC is dynamically modified on the BSC, calls in the cell are released automatically
and measured as call drops due to equipment faults. In conclusion, call drops are caused
by dynamic BSIC modification.
4. You are advised to dynamically delete cells or TRXs and modify channel attributes or
BSICs during off-peak hours.
Typical Case 2
Symptom
A large number of call drops due to equipment faults occur under a BSC in the early morning.
Cause Analysis
Calls on the circuits are dropped after the MSC sends a Reset Circuit message.
1. Check the traffic statistics measured when call drops occur. Call drops due to equipment
faults occur on all BTSs under the BSC.
2. Check for alarms reported on the BSC when the call drops occur. There are no hardware
alarms.
3. Check the operation logs. No configuration operations are performed when call drops occur.
4. Perform the operations provided in the Tracing Messages on the A Interface on the
problematic BSC. The MSC sends a large number of Reset Circuit messages. It is
GBSS14.0
102
determined that call drops due to equipment faults occur because the circuits on the MSC
side are reset.
5. Request MSC engineers to troubleshoot the fault. The call drop problem is resolved.
5.5 Troubleshooting Call Drops Due to Transmission Faults
This section describes how to troubleshoot call drops due to transmission faults.
Symptom
The relevant alarms are reported, and the values of CM333:Call Drops due to Abis Terrestrial
Link Failure (Traffic Channel) or CM334:Call Drops due to Equipment Failure (Traffic Channel)
increase. For the relevant alarms, see Background Information.
l Generally, Abis interface transmission faults may lead to an increase in the value of
CM333:Call Drops due to Abis Terrestrial Link Failure (Traffic Channel), and the Ater/A
interface transmission faults may lead to an increase in the value of CM334:Call Drops due
to Equipment Failure (Traffic Channel).
l Abis/Ater/A transmission link instability may increase the call drop rate. Check the relevant
alarms to determine the link transmission status. If there are a large number of relevant
alarms, contact the transmission engineers. The relevant BSC alarms are as follows:
OML fault alarms
ALM-21807 OML Fault
BTS LAPD alarms
ALM-3052 LAPD alarm
ALM-3572 LAPD alarm
BSC LAPD alarms
ALM-21511 LAPD Link Congestion
ALM-21512 LAPD Link Fault
Optical interface MSP alarms
ALM-21311 MSP Multiplex Section K1/K2 Mismatch
ALM-21312 MSP Multiplex Section K2 Mismatch
ALM-21313 MSP Port Protection Mode Mismatch
Optical Interface Transmission Alarms (ALM-21251 to ALM-21291)
E1/T1 Transmission Alarms (ALM-21201 to ALM-21209)
SS7 Signaling Alarms (ALM-21501 to ALM-21506)
IP transmission alarms
ALM-21345 Ethernet Link Fault
ALM-21346 IP Connectivity Check Failure
ALM-21581 Path Fault
ALM-21343 PPP/MLPPP Link Fault
GBSS14.0
103
ALM-21344 MLPPP Group Failure
ALM-21541 SCTP Link Fault
Location Procedure
None
1. Clear the alarms listed in Background Information by referring to the relevant alarm help
or 11 IP Transmission Faults.
2. Check whether CM333:Call Drops due to Abis Terrestrial Link Failure (Traffic Channel),
CM334:Call Drops due to Equipment Failure (Traffic Channel) or M3330A:Call Drops
Due to Abis Link Failures in Stable Local Switch State return to normal.
l If no, return to Procedure for Locating Call Drops.
Typical Case
Symptom
The value of CM333:Call Drops due to Abis Terrestrial Link Failure (Traffic Channel) is high.
Cause Analysis
Abis transmission links are interrupted intermittently.
1. View the traffic statistics. Call drops due to equipment faults occur mainly on BTS 17.
2. Check the alarms that are generated when the fault occurs. The E1/T1 Remote Alarm and
a large number of TRX LAPD Link Interrupt Alarms are generated. As a result,
transmission is interrupted intermittently, LAPD links are interrupted, and the cell is out
of service, leading to call drops.
3. Rectify the transmission faults, and clear the relevant alarms. The value of CM333:Call
Drops due to Abis Terrestrial Link Failure (Traffic Channel) returns to normal.
5.6 Troubleshooting Call Drops Due to Incorrect Parameter
Settings
This section describes how to troubleshoot call drops due to incorrect parameter settings.
Symptom
The call drop rate increases significantly if MSC- or BSC-level parameters are set incorrectly.
If some MSC-level parameters are set incorrectly, for example, some parameters are set to
different values before and after an MSC cutover, call drops may occur under all BSCs connected
to the MSC. In addition, if the BSC-level parameters are set incorrectly, call drops may occur
in some or all of the cells under the BSC.
GBSS14.0
104
l On the MSC side, the following parameters (mainly referring to timers here) affect the call
drop rate:
T305, T306, T308, and T338
The MSC uses the timers T305, T306, and T338 to monitor on-hook procedures. T308
is used to monitor the resource release procedure. All of these timers must be set during
BSC data configuration. If any is set to an invalid value or too large a value, the MSC
takes a long time to clear a call after the subscriber hangs up. Then, timers such as Radio
Link Timeout and T3103 on the BSC side expire, and the call is measured as dropped,
and the call drop rate increases.
Terminate Short Message Timer
This timer prevents the MSC from repeatedly sending a short message. If this timer is
set to too large a value, the MSC does not clear any short messages received during a
link release. Instead, the MS sends a release message to the BTS, which then sends a
Release Indication message to the BSC. The BSC then sends the MSC a Clear Request
message, requesting the MSC to release the call. As a result, the call drop rate increases.
T310
The MSC uses this timer to monitor incoming calls. The MSC starts this timer upon
receiving a Call Confirm message and stops it upon receiving an Alerting, Connect, or
Disconnect message. If this timer is set to too large a value, the value of the timer
SACCH Multi-Frames or Radio Link Timeout on the BSS side may decrease to 0 in
a poor radio environment. As a result, the MSC releases the call and the call drop rate
increases.
T313
The MSC uses this timer to monitor the call connection procedure. The MSC starts this
timer upon sending a Connect message and stops it upon receiving a Connect ACK
message. If the MSC does not receive a Connect ACK message before the timer expires,
the MSC clears the call. If this timer is set to too large a value, the BSS sends a Clear
Request message to the MSC after the value of the timer SACCH Multi-Frames or
Radio Link Timeout on the BSS side decreases to 0 in the following scenario: The
MSC sends the BSS a Connect message and waits for a Connect ACK message, but the
BSS does not receive the Connect message in a poor radio environment or cannot
correctly decode the message. As a result, the call is dropped and the call drop rate
increases.
T301
This timer specifies the period during which a phone is ringing. The MSC starts this
timer upon receiving an Alerting message and stops it upon receiving a Connect or
Disconnect message. If this timer expires before the MSC receives either message, the
MSC sends the calling MS a Disconnect message containing the cause value #19 user
alerting, no answer, instructing the calling MS to clear the current call. In addition,
the MSC sends the called MS a Disconnect message, containing the cause value #102
recovery on timer expiry or cause value #31 normal, unspecified, instructing the
called MS to clear the current call. If this timer is set to too large a value, the BSC sends
the MSC a Clear Request message before this timer expires due to poor radio
environment or link failures, requesting the MSC to release the current call. As a result,
the call drop rate increases.
T303
The MSC uses this timer to wait for a mobility management (MM) connection. The
MSC starts this timer upon sending a SETUP message and stops it upon receiving a
GBSS14.0
105
Call Confirm or Release Complete message. If this timer expires before the MSC
receives either message, the MSC clears the current call. If this timer is set to too large
a value, the BSS sends the MSC a Clear Request message after the value of the timer
SACCH Multi-Frames or Radio Link Timeout on the BSS side decreases to 0 in a
poor radio environment. As a result, the call is dropped and the call drop rate increases.
Short Message ACK Timer
The MSC starts this timer when the network side sends a short message to an MS. If
the MS does not respond with a CP_ACK message before the timer expires, the MSC
sends the BSC a Clear Command message, instructing the BSC to release radio
resources. If this timer is set to too large a value, the MSC does not release the current
call or clear terrestrial resources and TCH resources over the Um interface after the
Disconnect message is issued. Because the MS does not receive a short message from
the network, the MS sends the BTS a Disconnect message, requesting the BTS to release
layer-2 links. In this case, the BTS sends a Release Indication to the BSC, and then the
BSC sends a Clear Request message to release the current call. As a result, the call drop
rate increases.
l On the BSC side, the following parameters affect the call drop rate:
SACCH Multi-Frames
This parameter determines whether an uplink radio link is faulty. Each time the BTS
fails to decode measurement reports sent by the MS over the SACCH, the value of this
parameter decreases by 1. Each time the BTS successfully decodes measurement reports
sent by the MS over the SACCH, the value of this parameter increases by 2. If the value
of this parameter is 0, the BTS assumes that the uplink radio link is faulty. If the value
of M3101A:Call Drops due to CONN FAIL Received on TCHF (Traffic Channel) in
Stable State (Radio Link Failure) is large, a large number of calls drop due to poor radio
environment. In this case, set this parameter to a larger value.
Radio Link Timeout
This parameter determines the time for disconnecting a call when an MS fails to decode
the messages over the SACCH. Once a dedicated channel is allocated to an MS, the
counter S is enabled and the initial value is set to the value of this parameter. Each time
the MS fails to decode an SACCH message, the counter S decreases by 1. Each time
the MS correctly decodes an SACCH message, the counter S increases by 2. When the
counter S is equal to 0, the downlink radio link is considered as failed. Therefore, when
the voice or data quality deteriorates to an unacceptable situation and cannot be
improved using power control or channel handover, the connection is re-established or
released. If the value of M3101A:Call Drops due to CONN FAIL Received on TCHF
(Traffic Channel) in Stable State (Radio Link Failure) is large, a large number of calls
drop due to poor radio environment. In this case, set this parameter to a larger value.
Minimum Access RXLEV
This parameter specifies the minimum receive level for an MS to access the BSS. If this
parameter is set to a small value, some MSs with low signal levels may attempt to access
the network and call drops are likely to occur. To reduce the call drop rate, set this
parameter to a large value. A large value, however, may affect the call setup success
rate and traffic volume.
CS RACH Min. Access Level
This parameter specifies the signal level threshold for an MS to access the network over
the RACH. If this parameter is set to a small value, some MSs with low signal levels
may attempt to access the network and call drops are likely to occur. To reduce the call
GBSS14.0
106
drop rate, set this parameter to a large value. A large value, however, may decrease the
call setup success rate and paging success rate.
Handover Completion Message Timers
Handover completion message timers consist of T3103A, T3103C, and T8. If any of
these timers is set to a small value, the BSC may receive no message after timers T3103A
and T3103C expire. Therefore, the BSC assumes that a radio link fails in the source
cell. Then, the BSC releases channels in the source cell. As a result, call drops occur.
If the value of CM331:Call Drops on Radio Interface in Handover State (Traffic
Channel) is large, set this parameter to a large value. A large value, however, may lead
to TCH congestion.
T3109
This parameter specifies the period during which a BSC waits for a Release Indication
message after issuing a Channel Release message. If this parameter is set to a small
value, the BSC may release the link before receiving a Release Indication message,
resulting a call drop. To reduce the call drop rate, set this parameter to a value 2s longer
than the value of Radio Link Timeout.
T3111
This parameter specifies the period during which channel deactivation is delayed when
the main signaling link is disconnected. Delaying channel deactivation allows for a
period of time for link reconnection. If this parameter is set to a small value, a channel
may be deactivated before the link has had a chance to reconnect, resulting a call drop.
TCH Traffic Busy Threshold
If the current channel usage reaches or exceeds the threshold specified by this parameter,
TCHHs are preferentially allocated to MSs that have newly accessed the network.
Otherwise, TCHFs are preferentially allocated to MSs that have newly accessed the
network. TCHHs do not have good anti-interference capabilities. Therefore, the call
drop rate may increase if a large number of TCHHs are occupied. Do not set this
parameter to a small value during light congestion.
Call Reestablishment Forbidden
Blind spots caused by tall buildings or abrupt interference may lead to radio link failures
and call drops. This parameter specifies whether an MS can initiate a call re-
establishment procedure to re-establish a dropped call in such a scenario. To reduce the
call drop rate, set this parameter to No to allow call re-establishment. In some scenarios,
allowing call re-establishment greatly reduces the call drop rate. However, call re-
establishment generally takes a long time, and therefore some subscribers may hang up
before the call is re-established successfully.
Handover-related Parameters
If handover-related parameters are not set correctly, handovers may not be performed
in time, leading to call drops. To reduce the call drop rate, modify the handover-related
parameters so that handovers can be performed in time. For details, see
Troubleshooting Handovers.
Power Control Parameters
If the power control level and quality thresholds are set to small values, call drops are
likely to occur because of low signal level and poor signal quality.
T200 and N200
If T200 FACCH/F, T200 FACCH/H, N200 of FACCH/Full Rate, or N200 of
FACCH/Half Rate is set to a small value, the BSC may release data links before a call
is terminated, resulting a call drop. If the value of M3100A:Call Drops due to ERR IND
GBSS14.0
107
Received on TCHF (Traffic Channel) in Stable State (T200 Expired) is large, set T200
and N200 to large values.
Neighboring Relationship
If only some neighboring cells are configured in the BA2 list, no neighboring cells may
be suitable for handovers and signal levels may deteriorate, resulting in call drops.
Therefore, add suitable neighboring cells to the BA2 list based on the drive test data
and electronic map to prevent call drops due to unavailability of neighboring cells.
MAIO
In a cell configured with frequency hopping (FH), if MAIO is set to an incorrect value,
for example, if MAIOs for different TRXs in a cell are set to the same value, frequency
collision can occur during FH, resulting call drops.
Disconnect Handover Protect Timer
This is a BSC soft parameter. After receiving a Disconnect message from an MS, the
BSC cannot hand over the MS within the period specified by this parameter. When this
parameter is not configured, after being handed over to a target cell, an MS cannot hang
up because it does not receive a release acknowledgment message, leading to call drops.
Configuring this parameter enables the MS to hang up in this scenario. Do not set this
parameter to a small value.
Directly Magnifier BTS Flag
If repeaters are installed under a BTS, handovers between repeaters can only be
asynchronous because the repeaters are far apart. If synchronous handovers are
performed, the handovers may fail, resulting in call drops. Therefore, when repeaters
are installed under a BTS, set Directly Magnifier BTS Flag to Yes to prevent
synchronous handovers between cells under the same BTS.
Location Procedure
Figure 5-7 shows the procedure for locating call drops due to incorrect parameter settings.
GBSS14.0
108
Figure 5-7 Procedure for locating call drops due to incorrect parameter settings

1. View the traffic statistics and operation logs to check whether the call drop rate significantly
increases when an MSC cutover is performed or when the related parameters are modified
on the MSC or the BSC.
l If no, Contact Huawei Customer Service Center.
2. Check whether an MSC cutover is performed.
l If yes, ensure that the parameters are set to the same values. Then, go to Step 3.
4. Check whether related parameter settings were modified on the MSC.
GBSS14.0
109
l If yes, view the parameter description to check whether parameter setting modification
may cause call drops. If the parameter setting modification causes any call drops, undo
the parameter setting modification. Then, go to Step 5.
6. Check whether any of the relevant parameter settings are modified on the BSC.
l If yes, view the parameter description to check whether parameter setting modification
may cause call drops. If the parameter setting modification causes any call drops, undo
the parameter setting modification. Then, go to Step 7.
Typical Case
Symptom
After an MSC cutover is performed, the call drop rate increases from 0.4% to 0.7%.
Cause Analysis
Some timers are set to different values before and after the MSC cutover.
1. Analyze the signaling, traffic statistics, and parameter settings. The values of the timers
T310, T313, Short Message ACK Timer, and Terminate Short Message Timer after
the MSC cutover are larger than those before the MSC cutover. Therefore, there is a high
probability that the BSS will release the links. After timers such as Radio Link Timeout
and T3103 on the BSC side expire, the BSC sends a Clear Request message to the MSC.
As a result, the call is dropped and a call drop is measured. Table 5-4 lists the parameter
values before and after the MSC cutover.
Table 5-4 Parameter values before and after the MSC cutover
Timer Value Before the MSC
Cutover (s)
Value After the MSC
Cutover (s)
T310 20 30
T313 10 30
Short Message ACK Timer 15 20
Terminate Short Message
Timer
30 42

2. Set the preceding timers to the values before the MSC cutover.
GBSS14.0
110
6 Access Faults
About This Chapter
This chapter describes how to locate and troubleshoot access faults.
6.1 Access Principles
Access performance reflects how much difficulty MSs have in accessing the network. Poor
access performance may degrade subscriber satisfaction.
6.2 Locating Access Faults
This section describes how to locate access faults.
6.3 Troubleshooting Access Faults Due to Poor Um Interface Quality
This section describes how to troubleshoot access faults due to poor Um interface quality.
6.4 Troubleshooting Low Immediate Assignment Success Rates Due to SDCCH Congestion
This section describes how to troubleshoot low immediate assignment success rates due to
standalone dedicated control channel (SDCCH) congestion.
6.5 Troubleshooting Low Immediate Assignment Success Rates Due to Hardware or
Transmission Faults
hardware or transmission faults.
6.6 Troubleshooting Low Immediate Assignment Success Rates Due to Location Updates of
Problem MSs
location updates of problem MSs.
6.7 Troubleshooting Low Assignment Success Rates Due to TCH Congestion
This section describes how to troubleshoot low assignment success rates due to traffic channel
(TCH) congestion.
6.8 Troubleshooting Low Assignment Success Rates Due to Hardware or Transmission Faults
This section describes how to troubleshoot low assignment success rates due to hardware or
transmission faults.
6.9 Troubleshooting Low Assignment Success Rates Due to Inappropriate BSC Configuration
GBSS14.0
Troubleshooting Guide 6 Access Faults
111
This section describes how to troubleshoot low assignment success rates due to inappropriate
BSC configuration.
GBSS14.0
112
6.1 Access Principles
Access performance reflects how much difficulty MSs have in accessing the network. Poor
access performance may degrade subscriber satisfaction.
Access Faults
l In GSM networks, access faults occur during immediate assignment and assignment.
Access performance is a key counter in reflecting customer experience in the GSM network.
If the access performance is poor, MSs have difficulty in accessing the network, which
could negatively affect subscriber satisfaction. The network access performance improves
with the immediate assignment success rate or assignment success rate.
l RA303G:Success Rate of Immediate Assignments specifies the percentage of MSs
successfully accessing signaling channels. Immediate assignment starts when an MS sends
a channel request message and ends when the MS successfully sets up a channel.
l RCA313:Assignment Success Rate specifies the percentage of MSs successfully initiating
calls on assigned TCHs. Assignment starts when the time a BSC receives an assignment
request message and ends when the BSC receives an assignment completion message.
Access Procedure and Measurement Points
Figure 6-1 shows the access procedure and measurement points.
GBSS14.0
113
Figure 6-1 Access procedure and measurement points

Table 6-1 Measurement point
Measurement Point Description
A1 K3100:Immediate Assignment Requests
A2 K3101:Immediate Assignment Commands
A3 CA303J:Call Setup Indications (Circuit
Service)
A4 CA310:Assignment Requests
A5 CA313:Successful Assignments

6.2 Locating Access Faults
This section describes how to locate access faults.
GBSS14.0
114
6.2.1 Procedure for Locating Access Faults
Before locating access faults, determine whether they occur during immediate assignment or
assignment.
Possible Causes
l The following are the methods for analyzing possible causes of low immediate assignment
rates.
Determine the possible causes of low immediate assignment rates based on the signaling
procedure, as described in Table 6-2.
Table 6-2 Possible causes of low immediate assignment rates
Phase Symptom Possible Cause
SDCCH assignment After receiving random
access requests from MSs,
the BSC sends an
immediate assignment
rejection message because
no standalone dedicated
control channel (SDCCH)
is available.
SDCCH congestion and
equipment faults
Channel activation The BSC sends the
Channel Act message to
the BTS, and the BTS
responds with the Channel
Act Nack message.
Equipment faults
The BSC sends the
Channel Act message to
the BTS, but the BTS does
not respond.
Equipment and
transmission faults
Immediate assignment
delivery
After channels are
activated successfully, the
BSC sends immediate
assignment messages, but
the MSs do not access the
assigned channels. As a
result, the BSC does not
receive any EST IND
messages.
Um interface faults and
MS faults

Use a defined formula to calculate immediate assignment success rates, and determine
the possible causes of low immediate assignment success rates according to the
calculation results. Table 6-3 lists the mapping relationship between user-defined
formulas and possible causes.
GBSS14.0
115
Table 6-3 User-defined formulas for calculating immediate assignment success rates
Formula Possible Cause
Um
Interface
Fault
Channel
Activation
Failure
(Equipmen
t and
Transmissi
on Faults)
SDCCH
Congestion
MS Fault
Immediate
assignment
success rate =
[CA303J:Call
Setup Indications
(Circuit Service)/
K3100:Immediate
Assignment
Requests] x 100%

Immediate
assignment
success rate =
{CA303J:Call
Setup Indications
(Circuit Service)/
[K3100:Immediat
e Assignment
Requests -
(K3101:Immediat
e Assignment
Commands -
CA303J:Call
Setup Indications
(Circuit
Service))]} x
100%
- -
Immediate
assignment
success rate =
[CA303J:Call
Setup Indications
(Circuit Service)/
K3101:Immediate
Assignment
Commands] x
100%
- -

l Possible causes of low assignment success rates
Table 6-4 lists the possible causes of low assignment success rates.
GBSS14.0
116
Table 6-4 Possible causes of low assignment success rates
Counter Possible Cause
CA312:Failed Assignments (Channel
Unavailable)
TCH congestion
A3169A:Failed Assignments (Um Cause) Um interface faults
A3129B:Failed Assignments (First
Assignment, Terrestrial Resource Request
Failed)
Hardware faults, transmission faults, and
incorrect BSC configuration
A3129E:Failed Assignments (CIC
Unavailable)
BSC faults and MSC faults
A3129F:Failed Assignments (CIC
Allocated)
BSC faults and MSC faults
A3129H:Failed Assignments (Clear
Commands Sent By MSC)
Normal release and misoperations of peer
end users

Location Procedure
Check whether immediate assignment success rates or assignment success rates are low
according to counters related to assignment and immediate assignment.
l If immediate assignment success rates are low, locate the problem by referring to Figure
6-2.
l If assignment success rates are low, locate the problem by referring to Figure 6-3.
GBSS14.0
117
Figure 6-2 Procedure for locating low immediate assignment success rates

GBSS14.0
118
Figure 6-3 Procedure for locating low assignment success rates

NOTE
Collect the fault location information by referring to Table 6-5 before contacting Huawei for technical
support.
Table 6-5 Access fault location information
problem occurs in a cell, a BTS, a BSC, or all BSCs under
an MSC).

GBSS14.0
119
2 Operatio
ns before
and after
the
problem
occurs
modification.

3 Faulty
NE
version
For details
about how to
obtain the
BSC and BTS
software
versions that
are used when
the problem
occurs, see 15
Appendix:
How to
Collect Fault
Information.
4 Configur
ation data
script
problem occurs.
For details
about how to
obtain the
configuration
data script, see
15 Appendix:
How to
Collect Fault
Information.
5 Historica
l alarms
Obtain the historical alarms generated within three days
For details
about how to
obtain the
historical
alarms, see 15
Appendix:
How to
Collect Fault
Information.
6 Original
traffic
statistics
Obtain the original traffic statistics measured within two
For details
about how to
obtain the
original traffic
statistics, see
15 Appendix:
How to
Collect Fault
Information.
GBSS14.0
120
7 GCHR
and
GCSR
logs
Obtain the GCHR and GCSR logs generated within two
hours before and after the problem occurs, including the
logs generated for all subracks.
For details
about how to
obtain the
GCHR and
GCSR logs,
see 15
Appendix:
How to
Collect Fault
Information.
8 Common
debuggin
g logs
For details
about how to
obtain the
common
debugging
logs, see 15
Appendix:
How to
Collect Fault
Information.
9 Operatio
n logs
For details
about how to
obtain the
operation logs,
see 15
Appendix:
How to
Collect Fault
Information.
10 Faulty
signaling
single-user signaling of one or two faulty cells when the
problem occurs.
For details
about how to
obtain the
faulty
signaling, see
15 Appendix:
How to
Collect Fault
Information.
about how to
obtain BTS
logs, see 15
Appendix:
How to
Collect Fault
Information.

GBSS14.0
121
6.2.2 Common Causes for Access Faults
This section describes common causes for low immediate assignment success rates and low
assignment success rates.
Common Causes for Low Immediate Assignment Success Rates
Figure 6-4 shows common causes for low immediate assignment success rates.
GBSS14.0
122
Figure 6-4 Common causes for low immediate assignment success rates

l Um interface faults
GBSS14.0
123
The BTS may mistakenly process interference on the Um interface as pseudo-random
access signals. This may lead to immediate assignment failures and standalone
dedicated control channel (SDCCH) congestion.
In a cell configured with multiple TRXs, the combination loss of broadcast control
channel (BCCH) TRXs is different from that of non-BCCH TRXs. Therefore, their
coverage areas are also different. If an SDCCH is configured on a non-BCCH TRX, a
call far away from the serving cell may fail to access the SDCCH when the call is
assigned to the non-BCCH TRX. This leads to a call drop on the SDCCH.
For details about how to troubleshoot this problem, see 6.3 Troubleshooting Access
Faults Due to Poor Um Interface Quality.
l SDCCH congestion
A sharp increase in the traffic volume or incorrect data configuration may lead to
SDCCH congestion, decreasing immediate assignment success rates.
For details about how to troubleshoot this problem, see 6.4 Troubleshooting Low
Immediate Assignment Success Rates Due to SDCCH Congestion.
l TRX and transmission faults
Hardware faults can generally lead to the return of CHAN ACTIV NACK messages.
In a cell configured with multiple TRXs, SDCCH congestion occurs if a faulty TRX is
out of service.
Transmission faults generally lead to channel activation timeout or SDCCH congestion.
Immediate Assignment Success Rates Due to Hardware or Transmission Faults.
l MS faults
Immediate assignment success rates are low in some cells because certain problem MSs
perform location updates or initiate calls in these cells. After sending channel requests
for location updates, the problem MSs fail to set up links on SDCCHs, leading to low
immediate assignment success rates on SDCCHs.
Low immediate assignment success rates because of location updates of problem MSs
are caused by MS faults and cannot be resolved on the BSS side. No layer 3 information
is available due to location update failures and therefore the faulty MS cannot be
determined.
For details about how to locate this problem, see 6.6 Troubleshooting Low Immediate
Assignment Success Rates Due to Location Updates of Problem MSs.
Common Causes of Low Assignment Success Rates
Figure 6-5 shows common causes for low assignment success rates.
GBSS14.0
124
Figure 6-5 Common causes of low assignment success rates

l Um interface faults
If there is inter-network interference and repeater interference or severe intra-network
interference occurs because of insufficient frequencies and tight frequency reuse, MSs
may fail to parse information about the assigned traffic channel (TCH) properly. As a
result, they fail to occupy the TCH, leading to low assignment success rates.
GBSS14.0
125
If the signal level is low due to poor coverage, MSs may fail to parse the assigned TCH
properly. As a result, they fail to occupy the TCH, leading to low assignment success
rates.
For details about how to troubleshoot this problem, see 6.3 Troubleshooting Access
Faults Due to Poor Um Interface Quality.
l TCH congestion
When TCHs are congested and become unavailable, new access requests are rejected,
leading to low assignment success rates.
Assignment Success Rates Due to TCH Congestion.
l TRX and transmission faults
When a TRX or a combiner is faulty, some TCHs become unavailable, leading to low
assignment success rates.
Poor link transmission quality over the Abis interface and unstable transmission links
may also lead to TCH assignment failures.
Assignment Success Rates Due to Hardware or Transmission Faults.
l Incorrect BSC configuration
If the BSC is configured incorrectly and the traffic volume is large, certain resources
may be unavailable during assignment, leading to assignment failures.
Assignment Success Rates Due to Inappropriate BSC Configuration.
l Inconsistent circuit identification code (CIC) status over the A interface
If the circuit management mechanism on the A interface between the MSC and the BSC is
faulty, TCH assignment may be initiated when CICs on the A interface are not idle, leading
to assignment failures. This problem is quite complicated. Therefore, MSC engineers and
BSC engineers need to team up to troubleshoot such problems.
l MSC faults
If the MSC delivers the Clear CMD message during assignment, the assignment fails. To
troubleshoot this problem, contact MSC engineers.
6.3 Troubleshooting Access Faults Due to Poor Um Interface
Quality
This section describes how to troubleshoot access faults due to poor Um interface quality.
Symptom
l The result of signaling tracing over the Abis interface shows that MSs cannot access
channels after the BSC delivers the immediate assignment command during immediate
assignment. As a result, the BSC does not receive link establishment indications from BTSs
and releases local channels. In addition, the immediate assignment success rate calculated
with the following formula decreases: Immediate assignment success rate = (CA303J:Call
Setup Indications (Circuit Service)/K3101:Immediate Assignment Commands) x 100%.
l The result of signaling tracing over the Abis interface shows that the timer specified for
assignment completion responses expires or MSs fail to access new channels after the BSC
delivers the assignment command during assignment. As a result, MSs return to their
GBSS14.0
126
original channels and send assignment failure messages. In addition, the value of
A3169A:Failed Assignments (Um Cause) increases noticeably.
l The access faults over the Um interface can be located from the aspects of interference,
uplink and downlink signal level balance, coverage, antenna system, and BTS hardware.
For details about how to locate interference problems, see Interference Problems.
l The following is the method for troubleshooting interference problems.
1. Check Receive Quality Measurement Distribution per TRX
(MR.RecvQualOrig.TRX). If the receive quality is poor, for example, if the percentage
of uplink receive quality in receive quality bands 5, 6, and 7 exceeds 20%, there is a
high probability that access faults occur.
2. Analyze Interference Band Measurement per TRX(MR.Iterf.TRX). If the percentage
of interference levels in the high interference bands is great, for example, the
percentage of interference levels in interference bands 4 or 5 exceeds 10%, access
faults are caused by uplink interference.
3. Analyze the signaling collected by the TEMS during drive tests (DT) to determine
whether the downlink C/I is normal when MSs access channels. If the signal level is
proper but the C/I is poor, access faults are caused by interference.
Location Procedure
Figure 6-6 shows the procedure for locating access faults due to poor Um interface quality.
GBSS14.0
127
Figure 6-6 Procedure for locating access faults due to poor Um interface quality

1. Check for interference. For details, see Background Information.
l If access faults are caused by interference, check for interference sources onsite or
perform DTs to locate the interference sources. In addition, check whether repeaters
have been installed and, if so, whether they are faulty by using the following procedure.
If any interference source is found, eliminate it by referring to Interference
Problems. Then, go to Step 2.
GBSS14.0
128
a. Run the MML command LST GCELLSOFT to check whether Directly
Magnifier BTS Flag is set to Yes. If Directly Magnifier BTS Flag is set to
Yes, the cell is configured with repeaters. If Directly Magnifier BTS Flag is set
to No, check whether other operators' repeaters are installed near the cell or whether
any repeaters are installed without permission.
b. If repeaters are installed, check whether they are wideband repeaters. If they are
wideband repeaters, check whether the uplink or downlink gain is large. If the
uplink or downlink gain is large, reduce it as required. Shut down the repeaters if
they have great impacts on the access success rate.
c. Check whether the repeaters are faulty or whether the uplink or downlink gain is
beyond the normal range. If either is case, the actual BTS coverage may change,
leading to access faults. If any repeater problems occur in the cell, the number of
MRs with a large timing advance (TA) value measured for Number of MRs based
on TA per TRX(MR.TaDistribOrig.TRX) changes significantly.
l If access faults are not caused by interference, go to Step 3.
2. Check whether the access faults are rectified.
3. Check whether the uplink and downlink signal levels are balanced.
Check Uplink-and-Downlink Balance Measurement per TRX(MR.BalanceOrig.TRX). If
the percentage of the uplink and downlink signal level balance class 1 or 11 to all uplink
and downlink signal level balance classes exceeds 30%, the uplink and downlink signal
levels are unbalanced.
l If no, check whether the transmission equipment and TRX cable connections onsite are
proper, and whether there are any potential risks on the antenna system using the
following procedure. After the preceding items are checked and the faults are rectified,
go to Step 4.
If dual-transmit antennas are configured, ensure that the tilt and azimuth of the
antennas are the same.
Analyze DT data to check whether the jumpers are incorrectly connected. If they
are incorrectly connected, the uplink signal level in the cell is significantly lower
than the downlink signal level and access faults are likely to occur in a cell far away
from the BTS. In this case, reconnect the jumpers.
If the feeders are damaged, wet, or distorted, or if the connectors are not tight, both
the transmit power and receive sensitivity are reduced and access faults occur as a
result. Locate these problems by referring to ALM-4144 TRX VSWR alarm,
ALM-2156 TRX VSWR Alarm, or ALM-26529 RF Unit VSWR Threshold Crossed.
Immediately replace any faulty feeders.
5. Check whether there are any coverage problems.
a. Check TCHF Receive Level Measurement per TRX
(MR.RecvLevlOrigFullRate.TRX) or TCHH Receive Level Measurement per TRX
(MR.RecvLevlOrigHalfRate.TRX) and analyze the mapping between the receive
quality and receive signal levels. If receive quality is generally poor at low receive
GBSS14.0
129
signal levels, access faults in the cell may be caused by poor receive quality, resulting
from coverage problems.
b. Analyze Number of MRs based on TA per TRX(MR.TaDistribOrig.TRX). If many
MRs have large TA values, access faults are caused by wide coverage or coverage
overlap. Otherwise, access faults are caused by weak coverage. If the percentage of
TA values at levels 0 to 5 is less than 90%, check for coverage problems in the cell
based on the coverage scenario and DT result.
l If yes, contact network optimization engineers to resolve the problem, and then go
to Step 6.
7. Check the Um interface quality.
Check TCHF Receive Level Measurement per TRX(MR.RecvLevlOrigFullRate.TRX) or
TCHH Receive Level Measurement per TRX(MR.RecvLevlOrigHalfRate.TRX). If the
percentage of receive quality bands 6 and 7 exceeds 10%, the uplink or downlink receive
quality is poor.
l If the Um interface quality is poor, contact the network optimization department to check
and optimize the frequency planning data. Then, go to Step 8.
l If the Um interface quality is good, go to Step 9.
9. Perform DTs to check whether high receive signal levels with poor receive quality or low
receive signal levels with poor receive quality occurs.
l If yes, contact network optimization engineers to analyze and resolve the problem. Then,
go to Step 10.
l If no, return to Figure 5-3.
l If no, return to Procedure for locating access faults.
Typical Case
Symptom
After a BSC is swapped at a first office application (FOA) site, the immediate assignment success
rates in multiple cells are less than 93% during peak hours due to co-channel and adjacent-
channel interference.
Cause Analysis
The cells work on the same frequency and use the same base transceiver station identity code
(BSIC), leading to interference.
GBSS14.0
130
1. Analyze the signaling traced at the problem site. The signaling shows that most access
attempts fail because the BTS delivers the immediate assignment commands upon receiving
channel requests from MSs, but the MSs do not return any messages. An analysis of the
channel requests shows that the access uplink signal level is about -80 dB and the TA values
are 0 and 1, which are normal. For details about how to parse the TA value and uplink
access signal level from channel request messages, see Figure 6-7.
Figure 6-7 Channel request message

2. The results of multiple DTs show that the downlink quality at the junction of problem cell
A and cell B is poor. The result of frequency scanning at the junction shows that the two
BSICs for the broadcast control channel (BCCH) frequencies at the junction are different
but the signal levels of the BCCH frequencies are similar. This indicates that co-channel
interference occurs. One BCCH frequency belongs to cell A and the other BCCH frequency
belongs to cell B.
3. After the BCCH frequency of cell A is modified, the traffic statistics shows that the
immediate assignment success rate in cell A increases noticeably.
GBSS14.0
131
6.4 Troubleshooting Low Immediate Assignment Success
Rates Due to SDCCH Congestion
standalone dedicated control channel (SDCCH) congestion.
Symptom
The values of CA300J:Channel Requests (Circuit Service) and RR370:Congestion Rate on
SDCCH per CELL (due to Busy) or the values of K3004:Traffic Volume on SDCCH,
K3000:SDCCH Seizure Requests, and K3001:Failed SDCCH Seizures due to Busy SDCCH
increase noticeably, but the immediate assignment success rate decreases.
l SDCCH congestion is probably caused by one of the following causes:
The traffic volume on an SDCCH increases sharply. As a result, new services cannot
be assigned to the SDCCH, leading to an immediate assignment failure.
The configuration data is inappropriate, such as the location area (LA) planning, dual-
band network parameters, and timer settings.
The number of functional SDCCHs decreases because some TRXs carrying SDCCHs
are faulty, but the traffic volume remains unchanged.
l The methods for troubleshooting SDCCH congestion are as follows:
For SDCCH congestion caused by heavy traffic on the SDCCH, expand the capacity.
Alternatively, modify parameters related to location updates and SDCCH dynamic
adjustment.
SDCCH congestion caused by traffic bursts such as group sending of short messages
and location update at the portal of a tunnel cannot be completely resolved. Relieve the
SDCCH congestion by Configuring SDCCH Dynamic Adjustment.
For SDCCH congestion caused by a decrease in the number of functional SDCCHs due
to hardware faults, rectify the hardware faults. For details, see 6.5 Troubleshooting
Low Immediate Assignment Success Rates Due to Hardware or Transmission
Faults.
l The related parameters are as follows:
CELL_RESELECT_OFFSET (CRO)
This parameter specifies the likelihood with which MSs select a cell. If the
communication quality in a cell is poor due to heavy traffic or for other causes, ensure
that MSs do not work in this cell. In this case, if you set PENALTY_TIME (PT) to
31, TEMPORARY_OFFSET (TO) becomes invalid. C2 equals C1 minus CRO. Users
can set CRO as required. The larger the CRO, the less likely MSs are to select the cell.
You can also decrease the value of C2 manually to reduce the likelihood that MSs will
select the cell.
CELL_RESELECT_HYSTERESIS
This parameter specifies whether to perform inter-LA reselection. It prevents an
increase in the network signaling volume due to frequent location updates and reduces
the possibility of losing paging messages. This parameter is generally set to 6. For dual-
GBSS14.0
132
band networks in urban areas belonging to different LAs, the value of this parameter
ranges from 8 to 10.
When the traffic volume in an area is heavy and the signaling flow is overloaded
frequently, increase the CRH of neighboring cells that belong to different LACs in
this area.
When the overlapping coverage of neighboring cells that belong to different LAs is
large, increase the CRH.
When the border coverage of the neighboring cells that belong to different LAs is
poor or the borders are located on high-speed highways or other high-speed areas,
set the CRH to a value ranging from 2 to 6 dB.
Parameters related to SDCCH dynamic adjustment
SDCCH Dynamic Allocation Allowed
When this parameter is set to YES(Yes), dynamic conversion between SDCCHs and
traffic channels (TCH) can be implemented.
Idle SDCCH Threshold N1
When the number of idle SDCCHs in a cell is less than or equal to the value of this
parameter, the BSC uses the channel allocation algorithm to attempt to find a TCHF
that can be converted to an SDCCH. This parameter is one of the conditions for
dynamically converting a TCHF to an SDCCH.
Cell SDCCH Channel Maximum
Before initiating dynamic conversion from the TCH to the SDCCH, the BSC checks
whether the number of SDCCHs in a cell after the conversion will exceed Cell
SDCCH Channel Maximum. If the number will exceed Cell SDCCH Channel
Maximum, the BSC does not initiate the conversion.
TCH Minimum Recovery Time
This parameter specifies the minimum duration for converting an SDCCH back to
a TCH.
Related timers
T3101
Timer T3101 monitors the immediate assignment procedure. Setting timer T3101
to a small value can effectively reduce the SDCCH congestion rate. If timer T3101
is set to a large value, the invalid duration for occupying signaling resources is
prolonged, resulting in waste of signaling resources. To optimize signaling resource
usage, set timer T3101 to a small value, especially when the queuing function is
enabled.
T3122
An MS starts timer T3122 when receiving the IMMEDIATE ASSIGN REJECT
message and sends a new channel request message after timer T3122 expires.
Increasing the value of timer T3122 can prevent the MS from sending channel
request messages frequently when no system resource is available, preventing
increases in the load on random access channels (RACH) and common control
channels (CCCH).
T3212
Timer T3212 monitors the location update period. Appropriately increasing the
value of timer T3212 can minimize the SDCCH load, which becomes heavy due to
periodic location updates.
GBSS14.0
133
T3111
Timer T3111 specifies the connection release delay. This timer is used to delay
channel deactivation after the main signaling link is disconnected. This is to reserve
some time for another disconnection, if necessary. Timer T311 starts when a TCH
is released and when an SDCCH is released. The value of timer T3111 must be the
same as that of timer T3110 on the MS side and is generally two seconds. If timer
T3111 is set to a large value, severe SDCCH congestion may occur.
CS RACH Min. Access Level
If this parameter is set to a small value, a large number of interference signals request
SDCCHs to access the network, leading to the SDCCH congestion. If the parameter is
set to a large value, call failures may occur even when signals are available. Therefore,
set this parameter according to the actual BTS sensitivity, the lowest MS access signal
level, and the interference.
Late Assignment
This function is set on the MSC side. If late assignment is enabled, the calling MS always
occupies the SDCCH when waiting for the called MS to pick up the phone. In this case,
the duration of SDCCH occupation increases. As a result, other MSs may fail to request
the SDCCH, leading to SDCCH congestion.
Minimum Access RXLEV
If this parameter is set to a small value, the requirement for the access signal level is
low. As a result, a large number of MSs attempt to camp on this cell, increasing the cell
load and call drop rate and leading to SDCCH congestion.
TX-integer
When the network traffic volume is heavy, the immediate assignment success rate is
low if the sum of S and T is low. You can adjust the value of T within reason to increase
the sum of S and T. For details about S and T, see the description about TX-integer
contained in the MML command SET GCELLIDLEBASIC.
CELL BAR ACCESS (CBA)
This parameter specifies whether accessing a cell is allowed. 0 indicates that accessing
a cell is allowed, and 1 indicates that accessing a cell is prohibited. This parameter can
be used with cell bar qualify (CBQ) to determine the cell priority.
Table 6-6 Mapping relationship between CBA, CBQ, cell selection, and cell reselection
CBQ CBA Cell Selection
Priority
Cell Reselection
Priority
0 0 Normal Normal
0 1 Prohibited Prohibited
1 0 Low Normal
1 1 Low Normal

Cell Bar Qualify (CBQ)
CBQ affects only cell selection.
GBSS14.0
134
Location Procedure
Figure 6-8 shows the procedure for locating low immediate assignment success rates due to
SDCCH congestion.
Figure 6-8 Troubleshooting low immediate assignment success rates due to SDCCH congestion

1. Check whether no SDCCH is available due to an increase in the traffic volume.
l If yes, modify the relevant parameters according to the parameter description in
Background Information. If the problem persists, expand the capacity to resolve the
problem. If the problem is resolved after capacity expansion, no further action is
required. If the problem persists, go to Step 2.
2. Check whether the value of RR300:SDCCH Availability is too small.
l If yes, rectify hardware and transmission faults according to 6.5 Troubleshooting Low
Immediate Assignment Success Rates Due to Hardware or Transmission Faults.
If the problem is resolved after the hardware and transmission faults are rectified, no
further action is required. If the problem persists, return to Procedure for locating
access faults.
Typical Case
Symptom
GBSS14.0
135
The immediate assignment success rate of a BSC is low. According to the traffic statistics, certain
BTSs are experiencing SDCCH congestion.
Cause Analysis
SDCCH become congested easily when the traffic volume increases sharply. In addition, low
SDCCH availability due to hardware faults may also lead to SDCCH congestion.
1. Check RR300:SDCCH Availability. The SDCCH availability is 100%. Therefore, SDCCH
congestion is not caused by hardware faults.
2. Check K3000:SDCCH Seizure Requests and K3001:Failed SDCCH Seizures due to Busy
SDCCH. The number of SDCCH seizures is about 300 to 400 during peak hours for cells
served by a BTS in S1/1/1 mode. Each cell is configured with eight SDCCHs, which can
process 300 to 400 SDCCH seizures during peak hours. However, SDCCH congestion
occurs dozens of times in each cell during peak hours.
3. Check Counters Related to Call Setup Indication. Most SDCCH seizures are caused by
location updates. Most BTSs experiencing SDCCH congestion are located at the junction
of two LAs along railways. According to the train schedule, four to five trains pass through
the junction at about the time the SDCCHs become congested. When multiple trains pass
through the junction, a large number of location updates occur abruptly during a very short
period, leading to SDCCH congestion.
4. Run the MML command SET GCELLBASICPARA with SDCCH Dynamic Allocation
Allowed for cells served by the BTSs at the junction of two LAs along railways set to YES
(Yes), and reserve redundant SDCCHs. The problem is resolved.
Rates Due to Hardware or Transmission Faults
Symptom
The symptoms of low immediate assignment success rates due to hardware or transmission faults
are as follows:
l According to the signaling tracing over the Abis interface, after successful channel
assignment, the BSC sends a Channel Activation message to the BTS. However, the BTS
responds with a Channel Activation Nack message or does not respond.
l After successful channel activation, the BSC delivers an immediate assignment message
but does not receive an Establish Indication message. The BSC finally releases the call.
l According to the signaling tracing over the Abis interface, after receiving a channel request,
the BSC sends the MS an immediate assignment rejection message due to unavailable
standalone dedicated control channels (SDCCHs). The SDCCHs are unavailable because
the TRX carrying the requested SDCCHs is faulty and reports a large number of Overload
messages.
l For details about the hardware or transmission fault alarms, see Background
Information.
GBSS14.0
136
NOTE
l If the BTS returns a Channel Activation Nack message, check the following performance counters
based on the channel types: R3300B:CHAN ACTIV NACK Messages Sent by BTS in Immediate
Assignment Procedure (SDCCH), R3307B:CHAN ACTIV NACK Messages Sent by BTS in
Immediate Assignment Procedure (TCHF), and R3308B:CHAN ACTIV NACK Messages Sent by
BTS in Immediate Assignment Procedure (TCHH).
l If the BTS does not respond to the channel activation initiated by the BSC, check the following
performance counters based on the channel types: R3300C:Channel Activation Timeouts in Immediate
Assignment Procedure (SDCCH), R3307C:Channel Activation Timeouts in Immediate Assignment
Procedure (TCHF), and R3308C:Channel Activation Timeouts in Immediate Assignment Procedure
(TCHH).
l If the BTS or BSC hardware is faulty, immediate assignment may fail. You can find BTS
or BSC hardware faults by checking the following performance counters and alarms.
The following are the performance counters related to BTS or BSC hardware faults:
RK3255:TRX Usability
RR300:SDCCH Availability
CR330C:Channel Activation Timeouts in Immediate Assignment Procedure
CR330B:CHAN ACTIV NACK Messages Sent by BTS in Immediate Assignment
Procedure
The following are the alarms related to BTS or BSC hardware faults that can result in
access faults:
ALM-21807 OML Fault
ALM-2204 TRX Communication Alarm
ALM-2156 TRX VSWR Alarm
ALM-26529 RF Unit VSWR Threshold Crossed
ALM-3606 DRU Hardware alarm
ALM-20241 Board Unavailable
ALM-20243 Board Hardware Fault
l If transmission faults occur (for example, delay and frame loss), immediate assignment
fails because channel activation times out or the immediate assignment command fails to
be delivered to the MS. You can find transmission faults by checking the following alarms
related to transmission faults that can result in access faults:
OML fault alarms
ALM-21807 OML Fault
BTS LAPD link alarms
ALM-3052 LAPD alarm
ALM-3572 LAPD alarm
BSC LAPD link alarms
GBSS14.0
137
Alarms related to the Multiplex Section Protection (MSP) of optical ports
Location Procedure
Figure 6-9 shows the procedure for locating low immediate assignment success rates due to
GBSS14.0
138
Figure 6-9 Procedure for locating low immediate assignment success rates due to hardware or
transmission faults

1. Check whether any of the hardware fault alarms listed in Background Information are
reported.
l If yes, clear these alarms by referring to the alarm help and go to Step 2.
2. Check whether the immediate assignment success rate returns to normal.
3. According to the signaling tracing over the Abis interface, locate the TRX that reports the
Overload messages and replace the TRX. Then, check whether the immediate assignment
success rate returns to normal.
4. Request transmission device engineers to clear transmission fault alarms. Then, check the
performance counters listed in Background Information to determine whether channel
GBSS14.0
139
activation fails or the timer for waiting for the Establish Indication message expires. If the
immediate assignment success rate returns to normal, no further action is required.
Otherwise, return to Procedure for locating access faults.
Typical Case
Symptom
After a BTS is deployed, almost all SDCCHs are busy, but some traffic channels (TCHs) are
idle. According to the traffic statistics during peak hours, the value of K3001:Failed SDCCH
Seizures due to Busy SDCCH is about one thousand. In addition, a large number of LAPD link
fault alarms and clear alarms are reported at an interval of about ten minutes.
Cause Analysis
Almost all SDCCHs are busy, but some TCHs are idle. Although the possibility of incorrect data
configurations cannot be ruled out as the cause, the problem is more likely to have resulted from
transmission faults, because a large number of LAPD link fault alarms and clear alarms have
been frequently reported.
1. Check the data configurations. The data configurations are correct. Then, exchange the
transmission port on the problem BTS with that on another BTS of the same type. The latter
BTS operates properly, but the problem persists. Therefore, the problem is not caused by
incorrect data configurations or BSC hardware faults.
2. Replace the TMU and TRXs. The problem persists.
3. Request transmission device engineers to test the transmission quality. Error codes are
detected during the transmission. Then, perform transmission testing segment by segment.
A board in the intermediate transmission device is faulty. After the faulty board is replaced,
the problem is resolved.
Rates Due to Location Updates of Problem MSs
location updates of problem MSs.
Symptom
The immediate assignment success rates are low in some cells because of location updates of
problem MSs in these cells. After the problem MSs send channel requests to the BSC because
of location updates, the BSC assigns standalone dedicated control channels (SDCCHs) to the
problem MSs and sends immediate assignment messages to the problem MSs. The problem
MSs, however, do not access these SDCCHs. As a result, a timeout occurs when the BSC waits
for the ESTABLISH INDICATION messages, leading to low SDCCH immediate assignment
success rates.
The characteristics of low immediate assignment success rates due to location updates of
problem MSs are as follows:
GBSS14.0
140
l When the difference between A300F:Channel Requests (Location Updating) and
A3030F:Call Setup Indications (Location Updating) (SDCCH) is similar to A3040:Call
Setup Indications Timed Out (SDCCH), the low immediate assignment success rates are
due to location updates of problem MSs. However, the service type contained in the channel
requests sent by some MSs may not be location updates. In this case, you need to determine
the cause of low immediate assignment success rates based on the other characteristics.
l The immediate assignment success rates may be low during peak hours or during off-peak
hours.
l Calls are not affected. Aside from the immediate assignment success rates of some cells
during certain periods, all key performance indicators (KPIs) are normal. In addition, drive
test results are normal, and no subscribers complain about call drops because the MSs retry
periodically or in other cells if location updates fail.
l There is no interference or co-frequency co-BSIC cell.
l There is no problem such as uplink and downlink signal-level imbalance.
l According to the signaling tracing over the Abis interface, the retry times and retry intervals
of failed location updates meet the network configuration requirements.
Low immediate assignment success rates due to location updates of problem MSs are caused by
MS faults and therefore cannot be resolved on the BSS side.
Location Procedure
None
1. Based on the characteristics described in Background Information, determine whether
the low immediate assignment success rates are due to location updates of problem MSs.
Typical Case
Symptom
A customer complains that the SDCCH immediate assignment success rates in some cells are
low because of location updates.
Cause Analysis
Low SDCCH immediate assignment success rates in some cells may be caused by Um interface
faults, hardware faults, transmission faults, and SDCCH congestion. According to the onsite
symptom, the SDCCH immediate assignment success rates are low only in certain cells and the
immediate assignment failures are due to location updates. Therefore, the problem is most likely
to have resulted from MS faults.
1. Deduce that the problem is caused by MS faults because the problem occurs only in certain
cells.
2. Analyze traffic statistics to check whether the low immediate assignment success rates are
caused by location updates. The difference between A300F:Channel Requests (Location
Updating) and A3030F:Call Setup Indications (Location Updating) (SDCCH) is similar to
GBSS14.0
141
A3040:Call Setup Indications Timed Out (SDCCH), which indicates that the SDCCH setup
failures are due to location updates.
3. Trace the signaling over the Abis interface. Figure 6-10 shows the problem signaling.
According to the time advance (TA) and signal level information in channel requests, the
TA values are small and the signal level values are large. In addition, the uplink signal
strength measured by the BTS is lower than -110 dBm during the period in which the BSS
waits for MSs to access the assigned SDCCHs, which indicates that the MSs do not access
the SDCCHs. As a result, the immediate assignment fails.
NOTE
For details about how to query TA values, see the typical case in 6.3 Troubleshooting Access Faults
Due to Poor Um Interface Quality.
Figure 6-10 Signaling tracing over the Abis interface

4. Analyze the signaling shown in Figure 6-11. According to channel requests, the location
updates are initiated by the same MS. The maximum number of location updates is 4, which
matches the value of MS MAX Retrans.
NOTE
MS MAX Retrans specifies the maximum number of Channel Request messages sent by an MS
during an immediate assignment process. You can query the value of this parameter by running the
MML command LST GCELLCCBASIC and set the value of this parameter by running the MML
command SET GCELLCCBASIC.
GBSS14.0
142
Figure 6-11 Channel Request messages consecutively sent by an MS

6.7 Troubleshooting Low Assignment Success Rates Due to
TCH Congestion
This section describes how to troubleshoot low assignment success rates due to traffic channel
(TCH) congestion.
Symptom
According to the result of signaling tracing over the A interface, the BSC sends the MSC an
assignment failure message containing the cause value of No radio resource available. In
addition, the values of the following counters increase significantly: ZTA3129J:Failed
Assignments per BSC (Channel Unavailable), CA312:Failed Assignments (Channel
Unavailable), and K3011A:Failed TCH Seizures due to Busy TCH (Traffic Channel).
l The following is the formula for calculating the TCH congestion rate:
[K3021:Failed TCH Seizures due to Busy TCH (Signaling Channel) + K3011A:Failed TCH
Seizures due to Busy TCH (Traffic Channel) + K3011B:Failed TCH Seizures in TCH Handovers
due to Busy TCH (Traffic Channel)]/[K3020:TCH Seizure Requests (Signaling Channel) +
GBSS14.0
143
K3010A:TCH Seizure Requests (Traffic Channel) + K3010B:TCH Seizure Requests in TCH
Handovers (Traffic Channel)] x 100%
l If the TCH congestion rate of a cell with a high assignment success rate is greater than 10%,
assignment failures are mainly caused by TCH congestion. The following are the common
causes of TCH congestion in a cell:
The traffic volume in a cell increases.
The cell does not support the half-rate speech versions 1 and 3 in an effort to ensure
speech quality.
Traffic volume in the cell is large because the subscriber density is high or coverage
overlap occurs in the cell.
The traffic volume in the cell sharply increases because emergencies occur or any
neighboring cells are out of service.
The cell is configured with a large number of static packet data channels (PDCHs) or
dynamic PDCHs and processes PS services preferentially.
Some TRXs of the cell are faulty or some channels of the cell are blocked.
Very early assignment is enabled.
l When TCHs are congested, new access requests are rejected because TCHs are unavailable,
decreasing the assignment success rate.
Location Procedure
Figure 6-12 shows the procedure for locating low assignment success rates due to TCH
congestion.
GBSS14.0
144
Figure 6-12 Procedure for locating low assignment success rates due to TCH congestion

GBSS14.0
145
1. Run the MML command LST GCELLCCACCESS to check whether a cell with a low
assignment rate supports the half-rate speech versions 1 and 3. Run the MML command
LST GTRXDEV to check whether TCH Rate Adjust Allow is set to YES(Yes).
l If no, perform the following operations to enable the half-rate speech versions 1 and 3
when the speech quality meets the requirement:
a. Run the MML command SET GCELLCCACCESS with Speech Version set to
HALF_RATE_VER1(Half-rate VER 1) and HALF_RATE_VER3(Half-rate
VER 3).
b. Run the MML command SET GTRXDEV with TCH Rate Adjust Allow set to
YES(Yes).
c. Check whether the assignment success rate returns to normal.
2. Check whether coverage overlap or unbalanced traffic distribution occurs in the cell where
TCHs are congested according to drive test logs and traffic statistics.
l If yes, reduce the cell coverage by performing operations such as decreasing the power,
reducing the antenna tilt, and improving CS RACH Min. Access Level. Then, check
whether the assignment success rate returns to normal. If yes, no further action is
required. If no, go to Step 3.
3. Check whether any neighboring cells are out of service according to alarm logs.
l If yes, resolve the problem of out-of-service cells. Then, check whether the assignment
success rate returns to normal. If yes, no further action is required. If no, go to Step 4.
NOTE
If TCHs become congested abruptly in the cell because of emergencies such as a gathering, no
action is required.
4. Run the MML command LST GTRXCHAN to check whether the cell is configured with
a large number of static packet data channels (PDCHs) or dynamic PDCHs and processes
PS services preferentially.
l If yes, reduce the number of PDCHs. Then, check whether the assignment success rate
returns to normal. If yes, no further action is required. If no, go to Step 5.
5. Run the MML command LST GCELLBASICPARA to check whether TCH Immediate
Assignment is Yes, that is, whether very early assignment is enabled.
l If yes, run the MML command SET GCELLBASICPARA with TCH Immediate
Assignment set to NO(No) to disable very early assignment. Alternatively, perform
capacity expansion. Then, check whether the assignment success rate returns to normal.
If yes, no further action is required. If no, go to Step 6.
6. Check whether RR307:TCH Availability is less than 100%.
l If yes, some TRXs are faulty or some channels are blocked. Check the TRX status or
run the MML command DSP CHNSTAT to check channel status, and rectify TRX or
GBSS14.0
146
channel faults. Then, check whether the assignment success rate returns to normal. If
yes, no further action is required. If no, return to Procedure for locating access
faults.
Typical Case
Symptom
A customer complains that TCHs are congested in some cells during off-peak hours.
Cause Analysis
TCH congestion is generally caused by problems such as improper parameter settings, hardware
faults, and large traffic volumes.
1. Analyze the traffic statistics of one of the cells where TCHs are congested. The cell is
configured with 12 TCHs, and the TCHs are congested twice at a certain time and
R3561:Maximum Number of Busy Channels (TCHF) measured at the time is 12. This
indicates that all TCHs are occupied at the time, resulting in TCH congestion. This indicates
that all TCHs are occupied at the time, resulting in TCH congestion.
2. Analyze the traffic statistics of all cells where TCHs are congested. The traffic volume of
these cells during the measurement period is low but all the TCHs are occupied within a
short period. In this case, TCHs are congested when new calls access these cells, leading
to assignment failures.
3. Check the data configuration of these cells. TCH Rate Adjust Allow are all No.
4. Perform the following operations to resolve the problem:
a. Run the MML command SET GTRXDEV with TCH Rate Adjust Allow set to YES
(Yes).
b. Run the MML command SET GCELLCHMGAD with TCH Traffic Busy
Threshold set to a required value.
c. Run the MML command SET GCELLCHMGBASIC with Enhanced TCH Adjust
Allowed set to YES(Yes).
Hardware or Transmission Faults
This section describes how to troubleshoot low assignment success rates due to hardware or
Symptom
l According to the result of signaling tracing over the A interface, the BSC sends the MSC
an assignment failure message containing the cause value of Equipment failure. In
addition, the values of ZTA312L:Failed Assignments per BSC (Equipment Failure) and
A3129B:Failed Assignments (First Assignment, Terrestrial Resource Request Failed)
increase.
l When TRXs or combiners of a BTS are faulty, or radio frequency (RF) cables are connected
incorrectly, some channels are unavailable, leading to assignment failures. The signaling
GBSS14.0
147
tracing result shows that MSs fail to access traffic channels (TCHs) and send assignment
failure messages on standalone dedicated control channels (SDCCHs).
l When troubleshooting hardware faults, pay attention to BSC alarms such as DPU fault
alarms, TNU fault alarms, Abis/Ater/A interface board fault alarms, and alarms about cable
connections between TNUs on the BSC side.
On the BTS side, pay attention to BTS alarms or check BTS hardware status on the Web
LMT; in addition, check whether the RF cables at a site are properly connected.
The following are the common hardware fault alarms that can result in access faults:
ALM-21807 OML Fault
ALM-2204 TRX Communication Alarm
ALM-3606 DRU Hardware alarm
ALM-20241 Board Unavailable
ALM-20243 Board Hardware Fault
ALM-20254 DSP Unavailable
ALM-20231 Link Between TDM Switching Boards in Different Subracks Faulty
ALM-20230 TDM Link Between TDM Switching Board and Service Board Faulty
l When transmission problems such as delay, frame loss, and LAPD link congestion occur,
channel activation times out or messages for inter-subrack communication of the BSC are
lost, leading to assignment failures. You can verify whether transmission faults occur by
checking transmission fault alarms. The following are the common transmission fault
alarms that can result in access faults:
OML fault alarms
ALM-21807 OML Fault
BTS LAPD link alarms
ALM-3052 LAPD alarm
ALM-3572 LAPD alarm
BSC LAPD link alarms
Alarms related to the MSP of optical ports
GBSS14.0
148
Location Procedure
Figure 6-13 shows the procedure for locating low assignment success rates due to hardware or
Figure 6-13 Procedure for locating low assignment success rates due to hardware or transmission
faults

1. Check whether any of the hardware fault alarms listed in Background Information are
reported.
l If yes, clear these alarms by referring to the alarm reference help and go to Step 2.
2. Perform dialing tests to check whether the assignment success rates return to normal.
3. Check whether any of the transmission fault alarms listed in Background Information are
reported.
GBSS14.0
149
l If yes, contact transmission engineers to clear the transmission fault alarms. Then, go
to Step 4.
4. Perform dialing tests to check whether the assignment success rates return to normal.
Typical Case
Symptom
After the capacity of a BSC is expanded by adding BM subracks, the BSC operates properly.
The assignment success rates decrease after the TNUs on subrack 1 are switched over.
Cause Analysis
This problem occurs after capacity expansion and TNU switchover. Therefore, it is most
probably caused by incorrect cable connections between subracks of the BSC.
1. View historical alarms. The alarm ALM-20231 Link Between TDM Switching Boards in
Different Subracks Faulty is reported when the problem occurs.
2. Check the cable connections between TNUs on different subracks. The cable connections
between TNUs on different subracks are incorrect, as shown in Figure 6-14. Figure
6-15 shows the correct cable connections between TNUs on different subracks.
Figure 6-14 Incorrect cable connections between TNUs on different subracks

GBSS14.0
150
Figure 6-15 Correct cable connections between TNUs on different subracks

3. Correct the cable connections between the TNUs by referring to Figure 6-15. This
correction resolves the problem.
Inappropriate BSC Configuration
This section describes how to troubleshoot low assignment success rates due to inappropriate
BSC configuration.
Symptom
A large number of assignment failures occur during peak hours. The cause value is equipment
failure or requested terrestrial resource unavailable and the values of ZTA312L:Failed
Assignments per BSC (Equipment Failure) and A3129B:Failed Assignments (First Assignment,
Terrestrial Resource Request Failed) increases.
When the number of resources configured for a BSC board exceeds its processing capacity,
requesting call-related circuit resources fails during peak hours, leading to assignment failures.
For details about the processing capacity of BSC boards, see the BSC6900 GSM Hardware
Description.
l If Ater interface resources are insufficient, assignment fails during peak hours and the value
of A3129T:Failed Assignments (No Ater Resource Available) increases.
l If the number of circuit identification code (CICs) over the A interface exceeds the number
of calls that all DPUs support, calls fail to request transcoders (TCs) during peak hours,
leading to assignment failures.
l In Abis over IP mode, assignment fails if the path type of IPPATH is incorrect. If the BTS
are not configured with logical ports, assignment may fail during peak hours.
l In A over IP mode, assignment fails if the media gateway (MGW) IP address carried by an
assignment request delivered by the mobile switching center (MSC) is incorrect.
GBSS14.0
151
l If cable connections between the TNUs on different subracks are not configured, inter-
subrack call assignment fails.
l After A over IP transformation, assignment fails if the BSC is not reset.
Location Procedure
Figure 6-16 shows the procedure for locating low assignment success rates due to inappropriate
BSC configuration
GBSS14.0
152
Figure 6-16 Procedure for locating low assignment success rates due to inappropriate BSC
configuration

GBSS14.0
153
1. Check whether the value of A3129T:Failed Assignments (No Ater Resource Available)
increases.
l If yes, Ater interface resources are insufficient. Check whether the Ater interface
resources are blocked or faulty by referring to Maintaining Ater Interface Resources. If
any Ater interface resources are blocked, unblock them. If any Ater interface resources
are faulty, replace the transmission cables for the faulty Ater timeslots. If the problem
persists, run the MML command ADD ATERCONPATH to add Ater interface
resources. If the problem is resolved, no further action is required. If the problem
persists, go to Step 2.
2. Check whether the number of CICs over the A interface exceeds the number of calls that
all DPUs support.
l If yes, reduce the number of CICs over the A interface or add DPUs. Then, check
whether the problem is resolved. If yes, no further action is required. If no, go to Step
3.
3. If Abis over IP is used, go to Step 4.
If Abis over time division multiplexing (TDM) is used, go to Step 6.
4. In Abis over IP mode, run the MML command LST IPPATH to check whether an IPPATH
with IP path type being EF is configured.
l If no, run the MML command ADD IPPATH to add an IPPATH with IP path type
being EF(EF). Then, check whether the problem is resolved. If yes, no further action
is required. If no, go to Step 5.
5. In Abis over IP mode, if the problem occurs only during peak hours and the value of
A312F:Number of Assignment Failures (No Abis Resource Available) increases
significantly, run the MML command LST IPLOGICPORT to check whether the problem
BTS is configured with logical ports.
l If no, run the MML command ADD IPLOGICPORT to add a logical port. Then, check
whether the problem is resolved. If yes, no further action is required. If no, go to Step
6.
6. Run the MML command LST SRCONPATH to check whether inter-subrack connections
are configured.
l If no, run the MML command ADD SRCONPATH to add inter-subrack connections.
Then, check whether the problem is resolved. If yes, no further action is required. If no,
go to Step 7.
7. If A over IP is used, go to Step 8.
If A over TDM is used, go to Step 10.
8. In A over IP mode, if A over IP transformation is just complete, request transformation
engineers to check whether the BSC is reset after the A over IP transformation.
GBSS14.0
154
l If no, reset the BSC. Then, check whether the problem is resolved. If yes, no further
action is required. If no, go to Step 9.
9. In A over IP mode, run the MML command LST IPRT to check whether the MGW IP
address carried by the assignment request delivered by the MSC is on the destination IP
network segment configured for IP route (IPRT).
l If no, request MSC engineers to check whether the IP data configuration on the MSC
is consistent with that on the BSC. If the IP data configuration is inconsistent, modify
the IP data configuration based on the actual situation. Then, check whether the problem
is resolved. If yes, no further action is required. If no, go to Step 10.
10. Check whether the numbers of resources configured for some BSC boards exceed the
processing capacity of these BSC boards.
l If yes, add BSC boards accordingly and configure resources for the new BSC boards.
Ensure that the numbers of resources configured for the new BSC boards do not exceed
the processing capacity of these BSC boards. Then, check whether the problem is
resolved. If yes, no further action is required. If no, Contact Huawei Customer Service
Center.
Typical Case
Symptom
A BSC uses one POUc as the A interface board and the POUc is configured with more than
7000 CICs. When the traffic volume exceeds 4000 Erl, the assignment success rate decreases
and the value of ZTA312L:Failed Assignments per BSC (Equipment Failure) increases sharply.
Cause Analysis
When the traffic volume exceeds 4000 Erl, the assignment success rate decreases and most
assignment failures are due to equipment faults. Therefore, this problem is mostly probably
caused by inappropriate BSC configuration.
1. Check the traffic statistics collected during the period this problem occurs. The value of
A3129T:Failed Assignments (No Ater Resource Available) is 0 and therefore the problem
is not caused by insufficient Ater interface resources.
2. Check the number of DPUs. DPUs are sufficient.
3. Check inter-subrack connections. Inter-subrack connections are configured.
4. Check data configuration. A POUc is used as the A interface board and is configured with
more than 7000 CICs. The POUc, however, can process a maximum of 3906 CICs. When
3906 CICs over the A interface are occupied, a new call can apply for a CIC over the A
interface successfully but fails to request low voltage differential signal (LVDS) resources
because the LVDS resources are used together with the CICs and the POUc supports a
maximum of 3906 LVDS resources. As a result, the assignment success rate decreases.
5. Reduce the number of CICs configured for the POUc. The problem is resolved.
GBSS14.0
155
7 Voice Problems
About This Chapter
This chapter describes how to locate and troubleshoot voice problems.
7.1 GSM CS Signal Flow
After a CS call is established in the GSM network, the MS and the network communicate with
each other through the CS signal flow. The method of processing the GSM CS signal flow varies
according to the transmission mode adopted on the Abis and A interfaces and the configuration
mode of the BSC6900 subracks.
7.2 Common Voice Problems and Problem Location Methods
This section describes common voice problems and the methods used to locate them.
7.3 Troubleshooting One-Way Audio or No Audio
This section describes how to troubleshoot one-way audio or no audio.
7.4 Troubleshooting Noise
This section describes how to troubleshoot noise.
7.5 Troubleshooting Crosstalk
This section describes how to troubleshoot crosstalk.
7.6 Troubleshooting Echoes
This section describes how to troubleshoot echoes.
7.7 Troubleshooting Discontinuous Voice or Low MOS
This section describes how to troubleshoot discontinuous voice or low mean opinion score
(MOS).
GBSS14.0
Troubleshooting Guide 7 Voice Problems
156
7.1 GSM CS Signal Flow
After a CS call is established in the GSM network, the MS and the network communicate with
each other through the CS signal flow. The method of processing the GSM CS signal flow varies
according to the transmission mode adopted on the Abis and A interfaces and the configuration
mode of the BSC6900 subracks.
NOTE
Select a board according to the board function. For more information, see Boards. All the boards listed in
this chapter are used as examples for your reference.
Abis over TDM and A over TDM
Figure 7-1 shows the CS signal flow in Abis over TDM, Ater over TDM, A over TDM, and
BM/TC separated mode.
NOTE
l The Abis, Ater, and A interface boards can be the EIUa/OIUa/POUc boards. The boards shown in Figure
7-1, Figure 7-2, and Figure 7-3 are only examples.
l The INT in the figure stands for the interface board. You can use different interface boards as required.
Figure 7-1 GSM CS signal flow (1)

As shown in Figure 7-1, the CS signal flow on the uplink is as follows:
1. The uplink CS signals are sent from the BTS to the Abis interface board in the MPS/EPS.
2. The CS signals are demultiplexed in the Abis interface board. Each CS signal uses a 64
kbit/s timeslot and is transmitted to the Ater interface board through the TNUa board.
3. The CS signals are multiplexed in the Ater interface board. Each full-rate CS signal uses a
16 kbit/s sub-timeslot, and each half-rate CS signal uses an 8 kbit/s sub-timeslot. The CS
signals are then transmitted to the Ater interface board in the TCS over the Ater interface.
4. The CS signals are demultiplexed in the Ater interface board of the TCS. Each CS signal
uses a 64 kbit/s timeslot and is transmitted to the DPUc board through the TNUa board.
5. The DPUc board performs speech codec and rate adaptation on the CS signals, which are
converted into 64 kbit/s PCM signals. The 64 kbit/s PCM signals are transmitted to the A
interface board through the TNUa board and then to the MSC Server(MSS) over the A
interface.
The downlink flow is the reverse of the uplink flow.
GBSS14.0
157
Figure 7-2 shows the CS signal flow in Abis over TDM, Ater over IP, A over TDM, and BM/
TC separated mode.

kbit/s timeslot. The CS signals are transmitted to the TNUa board and then to the DPUc
board.
3. The CS signals are converted from TRAU frames to PTRAU frames in the DPUc board.
4. The CS signals are transmitted to the SCUa board and then to the Ater interface board.
uses a 64 kbit/s timeslot and is transmitted to the TNUa board and then to the DPUc board.
7. The DPUc board adjusts the order of PTRAU frames, eliminates jitter, and performs speech
codec and rate adaptation on CS signals, which are converted to 64 kbit/s PCM frames.
The 64 kbit/s PCM frames are transmitted to the TNUa board, to the A interface board, and
then to the MSS over the A interface.
In the case of BM/TC combined mode, the Ater interface does not exist. Figure 7-3 shows the
CS signal flow in Abis over TDM and A over TDM mode.

GBSS14.0
158
kbit/s timeslot and is transmitted to the DPUc board through the TNUa board.
interface board through the TNUa board and then to the MSS over the A interface.
Abis over IP and A over TDM
Figure 7-4 shows the CS signal flow in Abis over IP, Ater over TDM, A over TDM, and BM/
TC separated mode.
NOTE
l The Abis interface board can be the PEUa/FG2a/GOUa/POUc/FG2c/GOUc/FG2d/GOUd board, and the
Ater and A interface boards can be the EIUa/OIUa/POUc board. The boards shown in Figure 7-4, Figure
7-5, and Figure 7-6 are only examples.

2. The CS signals are transmitted from the Abis interface board to the DPUc board through
the SCUa board.
3. The DPUc board reorders PTRAU frames, eliminates jitter, and converts PTRAU frames
into TRAU frames. Then, the TRAU frames are transmitted to the Ater interface board
through the TNUa board.
4. The CS signals are multiplexed in the Ater interface board in the MPS/EPS, and then are
transmitted to the Ater interface board in the TCS.
uses a 64 kbit/s timeslot and is transmitted to the DPUc board through the TNUa board.
interface board through the TNUa board and then to the MSS over the A interface.
GBSS14.0
159
Figure 7-5 shows the CS signal flow in Abis over IP, Ater over IP, A over TDM, and BM/TC
separated mode.

kbit/s timeslot and is transmitted to the Ater interface board through the SCUa board.
uses a 64 kbit/s timeslot and is transmitted to the DPUc board through the SCUa board.
5. The DPUc board adjusts the order of PTRAU frames, eliminates jitter, and performs speech
codec and rate adaptation on CS signals, which are converted to 64 kbit/s PCM frames.
The 64 kbit/s PCM frames are transmitted to the TNUa board, to the A interface board, and
then to the MSS over the A interface.
In the case of BM/TC combined mode, the Ater interface does not exist. Figure 7-6 shows the
CS signal flow in Abis over IP and A over TDM mode.

GBSS14.0
160
2. The CS signals are transmitted to the DPUc board through the SCUa board.
3. The DPUc board reorders PTRAU frames, eliminates jitter, and performs speech codec and
rate adaptation on the PTRAU frames, which are converted into 64 kbit/s PCM frames.
4. The PCM frames are transmitted to the A interface board through the TNUa board, and
then are transmitted to the MSS over the A interface.
Abis over TDM and A over IP
In the case of A over IP, the Ater interface does not exist. Figure 7-7 shows the CS signal flow
in Abis over TDM and A over IP transmission mode.
NOTE
l The Abis interface board can be the EIUa/OIUa/POUc board, and the A interface board can be the FG2a/
GOUa/FG2c/GOUc/POUc/FG2d/GOUd board. The boards shown in Figure 7-7 are only examples.

kbit/s timeslot and is transmitted to the DPUc board through the TNUa board.
3. The DPUc board converts TRAU frames into RTP frames, reorders RTP frames, and
eliminates jitter.
4. The SCUa board transmits the CS signals to the A interface board, which then transmits
the signals to the MSS over the A interface.
Abis over IP and A over IP
In the case of A over IP, the Ater interface does not exist. Figure 7-8 shows the CS signal flow
in Abis over IP and A over IP transmission mode.
GBSS14.0
161
NOTE
l The Abis interface board can be the PEUa/FG2a/GOUa/POUc/FG2c/GOUc/FG2d/GOUd board, and the A
interface board can be the FG2a/GOUa/PEUa/FG2c/GOUc/POUc/FG2d/GOUd board. The boards shown
in Figure 7-8 are only examples.

2. The Abis interface board encapsulates the CS signals in PTRAU frames, which are then
transmitted to the DPUc board through the SCUa board.
3. The DPUc board converts PTRAU frames into RTP frames, reorders RTP frames, and
eliminates jitter.
4. The SCUa board transmits CS signals to the A interface board, and then the A interface
board transmits the signals to the MSS.
7.2 Common Voice Problems and Problem Location
Methods
This section describes common voice problems and the methods used to locate them.
Common Voice Problems
Common voice problems include one-way audio, no audio, noise, crosstalk, echo, discontinuous
voice, low mean opinion score (MOS), and TFO establishment failures.
The causes of the common voice problems are as follows:
l Poor Um interface quality
Voice problems are generally caused by poor Um interface quality, which may be caused
by weak coverage, interference (for example co-channel, adjacent-channel, external, or
intermodulation interference), or frequent cell handovers. Common symptoms of poor Um
interface quality are discontinuous voice and temporarily muted voice.
l Chip faults
GBSS14.0
162
The following chips become faulty with a relatively high probability: DSP chips on the
DPU, as well as TDM chips on the DPU, TNU, or interface boards. Chip faults may lead
to one-way audio or noise.
l Transmission faults
Common symptoms of transmission faults include the following: one-way audio or
crosstalk due to incorrect cable connection or incorrect timeslot connection in the
transmission equipment, noise or long delay in the case of satellite or microwave
transmission, one-way audio due to packet loss on the IP transmission equipment, and
discontinuous voice due to bit errors on the optical transmission equipment.
l A over IP transformation
After A over IP transformation, the transcoder (TC) is moved to the MSC. In A over IP
mode, one-way audio and call drops may easily occur especially when AMR is used or
during handovers due to difficult interconnection between NEs from different vendors.
l Clock exceptions
In Abis/A over TDM mode, frames may be lost or slip during voice transmission if the
BTS/BSC clock source or the GCK board is abnormal.
l Incorrect equipment configurations
Voice problems may easily occur in A over IP mode if equipment is not configured
according to the configuration rules.
Problem Location Methods
l 3.1.3 One-Way Audio Detection
l 3.1.2 External Voice Loopback
l 3.1.1 Querying Call Resource Usage of an MS
l 3.4.1 Tracing CS Domain Messages of a Single Subscriber
l 3.1.4 Crosstalk Detection
l 3.1.5 Optimizing Um Interface Crosstalk
l 3.2.1 Crossed Pair Detection
7.3 Troubleshooting One-Way Audio or No Audio
This section describes how to troubleshoot one-way audio or no audio.
Symptom
When one-way audio occurs, only one party in a call can hear the voice of the other party. When
no audio occurs, neither party can hear the other party's voice.
l One-way audio and no audio are common voice problems. They may be caused by weak
coverage, poor engineering quality, chip faults, or software defects.
l 3.1.3 One-Way Audio Detection detects one-way audio and no audio between a BTS and
the controlling BSC. One-way detection cannot detect one-way audio or no audio on the
Um interface or between the BSC and the MSC.
GBSS14.0
163
Location Procedure
Figure 7-9 shows the procedure for locating one-way audio or no audio.
Figure 7-9 Procedure for locating one-way audio or no audio

NOTE
support.
Table 7-1 One-way audio or no audio problem location information
under an MSC).

GBSS14.0
164
2 Operation
s before
and after
the
problem
occurs
clock source change, dynamic data configuration,
BTS reset, BSC reset, MSC swapping, and MSC data
modification.

3 Faulty NE
version
Obtain the BSC and BTS software versions that are
used when the problem occurs.
For details
about how to
obtain the
BSC and BTS
software
versions that
are used when
the problem
occurs, see 15
Appendix:
How to
Collect Fault
Information.
4 Call
resource
usage of
an MS
Query the call resource usage of the calling or called
MS once a dialing test fails, and save the query result.
For details
about how to
query the call
resource
usage of the
calling or
called MS
once a dialing
test fails, see
3.1.1
Querying
Call
Resource
Usage of an
MS.
5 Loopback
results
Obtain the loopback results. You can perform
loopback tests based on individual needs at least twice
and record the loopback results in table. The loopback
tests are valid only when these loopback results are the
same.
For details
about how to
obtain the
loopback
results, see
3.1.2
External
Voice
Loopback.
GBSS14.0
165
6 One-way
audio logs
Obtain the one-way audio logs generated within the
latest five days.
For details
about how to
obtain the
one-way
audio logs
generated
within the
latest five
days, see 15
Appendix:
How to
Collect Fault
Information.
7 Configura
tion data
script
problem occurs.
For details
about how to
obtain the
configuration
data script
used when the
problem
occurs, see 15
Appendix:
How to
Collect Fault
Information.
8 Historical
alarms
Obtain the historical alarms generated within three
For details
about how to
obtain the
historical
alarms
generated
within three
days before
and after the
problem
occurs, see 15
Appendix:
How to
Collect Fault
Information.
GBSS14.0
166
9 Original
traffic
statistics
Obtain the original traffic statistics measured within
two peak hours before and after the problem occurs.
For details
about how to
obtain the
original traffic
statistics
measured
within two
peak hours
before and
after the
problem
occurs, see 15
Appendix:
How to
Collect Fault
Information.
10 DSP
debugging
logs
Obtain the latest three compressed DPS debugging log
files.
For details
about how to
obtain the
latest three
compressed
DPS
debugging log
files, see 15
Appendix:
How to
Collect Fault
Information.
11 Common
debugging
logs
two hours before and after the problem occurs.
For details
about how to
obtain the
common
debugging
logs generated
within two
hours before
and after the
problem
occurs, see 15
Appendix:
How to
Collect Fault
Information.
GBSS14.0
167
12 Operation
logs
For details
about how to
obtain the
operation logs
generated
within 10 days
before and
after the
problem
occurs, see 15
Appendix:
How to
Collect Fault
Information.
13 BTS logs Obtain all logs for one or two faulty BTSs. For details
about how to
obtain all logs
for one or two
faulty BTSs,
see 15
Appendix:
How to
Collect Fault
Information.

1. If the IP networking mode is used, go to Step 3.
If the TDM networking mode is used, run the MML command SET GCELLSOFT with
Mute Detect Class1 Switch and Mute Detect Class2 Switch set to ENABLE
(ENABLE). Then, check whether the one-way audio logs contain abnormal records.
l If yes, one-way audio or no audio occurs between the BTS and the BSC. In this case,
troubleshoot the fault as follows and then go to Step 2.
If one-way audio occurs frequently on a digital signaling processing (DSP) chip,
replace the board where the DSP chip is located, or run the MML command INH
DSP to disable the DSP chip.
If one-way audio occurs mainly on a certain E1/T1 cable over the Abis interface,
run the MML command CHK E1T1CRS to check whether there are any crossed
pairs.
If one-way audio occurs mainly on a certain TRX, replace the TRX board.
2. Check whether the problem is resolved.
3. Perform mass dialing testing. When one-way audio or no audio occurs, run the MML
command STR CALLRESLOP with Loop Position set to NSSAINTF(NSS Interface
GBSS14.0
168
Unit). Then, determine whether one-way audio or no audio occurs on the NSS or BSS. For
details, see 3.1.2 External Voice Loopback.
l If one-way audio or no audio occurs on the NSS, contact MSC engineers to resolve the
problem.
l If one-way audio or no audio occurs on the BSS, go to Step 4.
4. Run the MML command STR CALLRESLOP with Loop Position set to BTSTRUDSP
(TRU DSP). Then, determine whether one-way audio or no audio occurs over the Um
interface. For details, see 3.1.2 External Voice Loopback.
l If one-way audio or no audio occurs over the Um interface, troubleshoot Um interface
problems such as weak coverage. If the problem persists, Contact Huawei Customer
Service Center.
l If one-way audio or no audio does not occur over the Um interface, Contact Huawei
Customer Service Center.
Typical Case
Symptom
A large number of subscribers experience no audio and some subscribers encounter crosstalk
with a probability of about 30% at a site.
Cause Analysis
The cables between TNUs are not connected properly.
1. Enable one-way audio detection. Ten minutes later, the one-way audio logs show that one-
way audio occurs in calls from subrack 0 to subrack 3.
2. View the historical alarms. ALM-20231 Link Between TDM Switching Boards in Different
Subracks Faulty is generated. The alarm information shows that inter-subrack cables are
not connected properly.
3. Check the cable connections. A cable from subrack 0 is mistakenly connected to subrack
4. When the cable is connected to subrack 3, the no audio and crosstalk problems are
resolved.
7.4 Troubleshooting Noise
This section describes how to troubleshoot noise.
Symptom
One party in a call can hear certain noises, including bubbling sounds, clicking, and metallic
sounds. When the noises are severe, subscribers may not even hear the other party's voice.
l These kinds of noises are generally caused by bit errors, which may be caused by one of
the following factors:
Board, connector, or cable connection faults on the path transmitting voice signals
Improper grounding, interference, or clock faults
GBSS14.0
169
Interference on radio links
Frame losses or slips due to clocks being out of synchronization
Incorrect DIP switch configurations, for example inconsistent impedance
configurations
l The symptoms vary according to the cause of the bit errors.
If the noise is due to line bit errors between the BSC and the MSC, it occurs regularly
and fluctuates slightly, because the pulse code modulation (PCM) sample value is
affected.
If the noise is due to line bit errors on the BSS side, it fluctuates noticeably, because
compressed voice signals are affected. In this case, parties in a call may hear bubbling
sounds, discontinuous voice, or metallic sounds and have difficulty recognizing the
other party's words.
If the noise is due to regular frame losses or slips due to clock problems, it occurs at a
specific time during a call.
l Locating noise is a difficult problem in the telecom industry. Generally, when noises occur,
troubleshooting engineers first determine whether faulty chips are responsible for causing
the noises.
Location Procedure
Figure 7-10 shows the procedure for locating noise.
GBSS14.0
170
Figure 7-10 Procedure for locating noise

NOTE
support.
Table 7-2 Noise problem location information
under an MSC).

GBSS14.0
171
2 Operation
s before
and after
the
problem
occurs
modification.

3 Faulty NE
version
For details
about how to
obtain the
BSC and BTS
software
versions that
are used when
the problem
occurs, see 15
Appendix:
How to
Collect Fault
Information.
4 Call
resource
usage of
an MS
For details
about how to
query the call
resource
usage of the
calling or
called MS
once a dialing
test fails, see
3.1.1
Querying
Call
Resource
Usage of an
MS.
5 Loopback
results
same.
For details
about how to
obtain the
loopback
results, see
3.1.2
External
Voice
Loopback.
GBSS14.0
172
6 Configura
tion data
script
problem occurs.
For details
about how to
obtain the
configuration
data script
used when the
problem
occurs, see 15
Appendix:
How to
Collect Fault
Information.
7 Historical
alarms
For details
about how to
obtain the
historical
alarms
generated
within three
days before
and after the
problem
occurs, see 15
Appendix:
How to
Collect Fault
Information.
8 Original
traffic
statistics
For details
about how to
obtain the
original traffic
statistics
measured
within two
peak hours
before and
after the
problem
occurs, see 15
Appendix:
How to
Collect Fault
Information.
GBSS14.0
173
9 DSP
debugging
logs
Obtain the latest three compressed DSP debugging log
files.
For details
about how to
obtain the
latest three
compressed
DSP
debugging log
files, see 15
Appendix:
How to
Collect Fault
Information.
10 Common
debugging
logs
For details
about how to
obtain the
common
debugging
logs generated
within two
hours before
and after the
problem
occurs, see 15
Appendix:
How to
Collect Fault
Information.
11 Operation
logs
For details
about how to
obtain the
operation logs
generated
within 10 days
before and
after the
problem
occurs, see 15
Appendix:
How to
Collect Fault
Information.
GBSS14.0
174
about how to
obtain all logs
for one or two
faulty BTSs,
see 15
Appendix:
How to
Collect Fault
Information.
13 Voice logs Voice logs generated within latest five days For details
about how to
obtain the
voice logs
generated
within latest
five days, see
15 Appendix:
How to
Collect Fault
Information.

1. If the A interface does not use TDM transmission, go to Step 2. If the A interface uses
TDM transmission and noises occur, enable the noise detection function by referring to
3.1.9 Detecting Noise on the A Interface, and analyze the noise records in the voice logs.
l If a DSP chip frequently experiences noise problems, replace the board where the DSP
chip is installed or run the MML command INH DSP to inhibit the DSP chip.
l If noises occur on a fixed board, switch over or replace the board.
l If noises occur on a fixed TRX, replace the TRX.
2. Determine whether the noise lasts a long time. A noise is considered long if it lasts more
than 10s.
l If the noise lasts a long time, Contact Huawei Customer Service Center.
l If the noise does not last a long time, go to Step 3.
3. Perform mass dialing testing. When the noise occurs, run the MML command STR
CALLRESLOP with Loop Position set to NSSAINTF(NSS Interface Unit). Then,
determine whether the noise occurs on the NSS or BSS. For details, see 3.1.2 External
Voice Loopback.
l If the noise occurs on the NSS, contact MSC engineers to resolve the problem.
l If the noise occurs on the BSS, go to Step 4.
4. Run the MML command DSP CALLRES to query the usage of single-user call resources
and save the results. Then, find out the resource usage regularity. If the noise occurs on a
fixed DSP chip of a specific board, replace the board, or run the MML command INH
DSP to disable the DSP chip.
GBSS14.0
175
5. Perform dialing testing to check whether noise is eliminated.
Typical Case
Symptom
A site experiences noises with a probability of about 2% and the calling/called party can hardly
hear the other party's voice.
Cause Analysis
DSP 7 on the board in slot 11 of subrack 1 is faulty. As a result, a bit in the RAM storage unit
is stored abnormally.
1. Perform dialing tests at the site. The noise occurs three times for every 100 dialing tests.
According to three single-user call resource query results, the noise occurs on DSP 7 on
the board in slot 11 of subrack 1.
2. Run the MML command INH DSP to disable the DSP. Then, perform dialing tests 200
times. The noise does not occur.
3. During off-peak hours, enable DSP 7 on the board in slot 11 of subrack 1, and disable DSPs
on other boards to enable calls to use DSP 7 on the board in slot 11 of subrack 1. The noise
occurs every time DSP 7 is used.
4. Replace the board in slot 11 of subrack 1. The problem is resolved.
7.5 Troubleshooting Crosstalk
This section describes how to troubleshoot crosstalk.
Symptom
The voice of a third party, not involved in a two-party call, may be heard in addition to or instead
of the voice of the speaking party.
Common causes of crosstalk include poor Um interface quality, incorrect cable connections, or
incorrect timeslot connections on a switching board. The most common cause is poor Um
interface quality. The symptoms of crosstalk due to poor Um interface quality are as follows:
l Crosstalk generally begins partway through a call.
l One party in a call experiences poor Um interface quality.
l One party in a call can hear the voice of two other parties.
The BSS crosstalk detection function can only detect crosstalk between a BTS and the controlling
BSC. The crosstalk information is recorded in the one-way audio log file saved in \bam\common
\fam\famlogfmt. This function cannot detect crosstalk between a BTS and an MS or between a
BSC and an MSC.
GBSS14.0
176
Location Procedure
Figure 7-11 shows the procedure for locating crosstalk.
Figure 7-11 Procedure for locating crosstalk

NOTE
support.
Table 7-3 Crosstalk problem location information
under an MSC).

2 Operation
s before
and after
the
problem
occurs
modification.

GBSS14.0
177
3 Faulty NE
version
For details
about how to
obtain the
BSC and BTS
software
versions that
are used when
the problem
occurs, see 15
Appendix:
How to
Collect Fault
Information.
4 Call
resource
usage of
an MS
For details
about how to
query the call
resource
usage of the
calling or
called MS
once a dialing
test fails, see
3.1.1
Querying
Call
Resource
Usage of an
MS.
5 Loopback
results
same.
For details
about how to
obtain the
loopback
results, see
3.1.2
External
Voice
Loopback.
GBSS14.0
178
6 Voice logs Obtain the voice logs generated within the latest five
days.
For details
about how to
obtain the
crosstalk logs
generated
within the
latest five
days, see 15
Appendix:
How to
Collect Fault
Information.
7 Configura
tion data
script
problem occurs.
For details
about how to
obtain the
configuration
data script
used when the
problem
occurs, see 15
Appendix:
How to
Collect Fault
Information.
8 Historical
alarms
For details
about how to
obtain the
historical
alarms
generated
within three
days before
and after the
problem
occurs, see 15
Appendix:
How to
Collect Fault
Information.
GBSS14.0
179
9 Original
traffic
statistics
For details
about how to
obtain the
original traffic
statistics
measured
within two
peak hours
before and
after the
problem
occurs, see 15
Appendix:
How to
Collect Fault
Information.
10 DSP
debugging
logs
files.
For details
about how to
obtain the
latest three
compressed
DPS
debugging log
files, see 15
Appendix:
How to
Collect Fault
Information.
11 Common
debugging
logs
For details
about how to
obtain the
common
debugging
logs generated
within two
hours before
and after the
problem
occurs, see 15
Appendix:
How to
Collect Fault
Information.
GBSS14.0
180
12 Operation
logs
For details
about how to
obtain the
operation logs
generated
within 10 days
before and
after the
problem
occurs, see 15
Appendix:
How to
Collect Fault
Information.
about how to
obtain all logs
for one or two
faulty BTSs,
see 15
Appendix:
How to
Collect Fault
Information.

1. Check whether the crosstalk is due to a problem on the Um interface. For details, see
Background Information.
l If the crosstalk is due to a problem on the Um interface, run the MML command SET
GCELLSOFT with Um Interface Crosstalk Optimization Allowed set to YES
(Allowed). Then, go to Step 2.
l If the crosstalk is not due to a problem on the Um interface, go to Step 3.
3. Enable the 3.1.4 Crosstalk Detection function to check whether the crosstalk logs contain
abnormal records.
l If yes, you are advised to perform a 3.2.1 Crossed Pair Detection to resolve any
problems on the E1/T1 cables allocated to abnormal calls. Then, go to Step 4.
GBSS14.0
181
Typical Case
Symptom
Field engineers at a site receive an average of two customer complaints a day involving crosstalk.
Crosstalk problems, however, do not occur during onsite dialing testing.
Cause Analysis
The quality of the Um interface is poor.
1. Check whether the crosstalk is due to a problem on the Um interface. One party cannot
hear the voice of the other party. Several seconds later, the party hears the voice of two
other parties. This is a common example of Um interface crosstalk.
2. Analyze the traffic statistics for the area where the crosstalk occurs. This area has poor
signal coverage and a large number of call drops occur over the Um interface.
3. Run the MML command SET GCELLSOFT with Um Interface Crosstalk Optimization
Allowed set to YES(Allowed). The problem is resolved.
7.6 Troubleshooting Echoes
This section describes how to troubleshoot echoes.
Symptom
The calling or called party can hear his or her own voice as well as that of the other party.
l Echoes can be either acoustic or electrical.
An acoustic echo occurs when the earphone and microphone of an MS (especially a
low-end MS) are not properly isolated from each other.
An electrical echo occurs when the impedance of the two-wire connector for the hybrid
converter at the public switched telephone network (PSTN) end does not match that of
the four-wire connector and therefore transmitted signals are coupled to the four-wire
connector at the receiving end.
l The BSS side eliminates only acoustic echoes. Electrical echoes must be eliminated by the
universal media gateway (UMG). In A over IP mode, acoustic echoes must also be
eliminated by the UMG because the transcoder (TC) is moved to the UMG.
Location Procedure
Figure 7-12 shows the procedure for locating an echo.
GBSS14.0
182
Figure 7-12 Procedure for locating an echo

NOTE
support.
Table 7-4 Echo problem location information
under an MSC).

2 Operation
s before
and after
the
problem
occurs
modification.

GBSS14.0
183
3 Faulty NE
version
For details
about how to
obtain the
BSC and BTS
software
versions that
are used when
the problem
occurs, see 15
Appendix:
How to
Collect Fault
Information.
4 Call
resource
usage of
an MS
For details
about how to
query the call
resource
usage of the
calling or
called MS
once a dialing
test fails, see
3.1.1
Querying
Call
Resource
Usage of an
MS.
5 Configura
tion data
script
problem occurs.
For details
about how to
obtain the
configuration
data script
used when the
problem
occurs, see 15
Appendix:
How to
Collect Fault
Information.
GBSS14.0
184
6 Historical
alarms
For details
about how to
obtain the
historical
alarms
generated
within three
days before
and after the
problem
occurs, see 15
Appendix:
How to
Collect Fault
Information.
7 Original
traffic
statistics
For details
about how to
obtain the
original traffic
statistics
measured
within two
peak hours
before and
after the
problem
occurs, see 15
Appendix:
How to
Collect Fault
Information.
8 DSP
debugging
logs
files.
For details
about how to
obtain the
latest three
compressed
DPS
debugging log
files, see 15
Appendix:
How to
Collect Fault
Information.
GBSS14.0
185
9 Common
debugging
logs
For details
about how to
obtain the
common
debugging
logs generated
within two
hours before
and after the
problem
occurs, see 15
Appendix:
How to
Collect Fault
Information.
10 Operation
logs
For details
about how to
obtain the
operation logs
generated
within 10 days
before and
after the
problem
occurs, see 15
Appendix:
How to
Collect Fault
Information.
about how to
obtain all logs
for one or two
faulty BTSs,
see 15
Appendix:
How to
Collect Fault
Information.

1. Check whether the A over IP mode is used.
l If yes, contact MSC engineers to resolve the echo problem.
GBSS14.0
186
2. Determine the echo type. If you hear an echo when you use an MS to call another MS, it
is an acoustic echo. If you hear an echo when you use an MS to call a fixed-line phone, it
is an electrical echo.
l If it is an electrical echo, contact MSC engineers to resolve the problem.
l If it is an acoustic echo, go to Step 3.
3. Check whether the MS encountering the echo problem is served by a Huawei BSC.
l If yes, run the MML command SET TCPARA with AEC Switch set to OPEN
(Open) and the other parameters unchanged. Then, go to Step 4.
l If no, contact the related BSC vendor to resolve the problem.
NOTE
Do not change the values of other AEC-related parameters unless otherwise stated.
4. Check whether the echo has been eliminated.
Typical Case
Symptom
A subscriber complains that he always hears an echo when using his MS to call a specific MS
and occasionally hears an echo when calling other MSs.
Cause Analysis
The earphone and microphone of some MSs are not properly isolated from each other.
1. Check the model of the MS the subscriber is using and confirm that the MS is served by a
Huawei BSC.
2. Lab tests show that acoustic echoes occur with a high probability. Determine that it is an
acoustic echo because the earphone and microphone of the MS are not properly isolated
from each other and the subscriber hears an echo when he or she calls another MS.
3. Run the MML command SET TCPARA with AEC Switch set to OPEN(Open).
4. This problem is resolved after AEC is enabled.
7.7 Troubleshooting Discontinuous Voice or Low MOS
This section describes how to troubleshoot discontinuous voice or low mean opinion score
(MOS).
Symptom
l Discontinuous voice
Breaks occur in a call and words are lost. When breaks are severe, one party in the call
cannot hear enough words to understand the other party.
l Low MOS
The MOS does not meet the customer's requirement.
GBSS14.0
187
l MOS
Used to reflect the voice quality of a call, the mean opinion score (MOS) ranges from 1 to
5, where 1 indicates the lowest voice quality and 5 indicates the highest voice quality. A
specialized instrument is required for measuring the MOS, which meets the perceptual
evaluation of speech quality (PESQ) standards.
Location Procedure
l Discontinuous voice
Discontinuous voice is generally caused by poor Um interface quality. During testing,
perform 3.4.1 Tracing CS Domain Messages of a Single Subscriber and analyze the
voice quality and signal level in the measurement reports. If the voice quality is poor or the
signal level is low, check the Um interface. Otherwise, Contact Huawei Customer Service
Center.
l Low MOS
The MOS is affected by various factors, such as handovers, call drops, speech versions,
Um interface coding rate, and Um interface quality. If the MOS obtained after testing does
not meet the customer's requirement, analyze the test report or Contact Huawei Customer
Service Center.
NOTE
support.
Table 7-5 Discontinuous Voice or Low MOS problem location information
under an MSC).

2 Operation
s before
and after
the
problem
occurs
modification.

GBSS14.0
188
3 Faulty NE
version
For details
about how to
obtain the
BSC and BTS
software
versions that
are used when
the problem
occurs, see 15
Appendix:
How to
Collect Fault
Information.
4 Call
resource
usage of
an MS
For details
about how to
query the call
resource
usage of the
calling or
called MS
once a dialing
test fails, see
3.1.1
Querying
Call
Resource
Usage of an
MS.
5 Loopback
results
same.
For details
about how to
obtain the
loopback
results, see
3.1.2
External
Voice
Loopback.
GBSS14.0
189
6 Configura
tion data
script
problem occurs.
For details
about how to
obtain the
configuration
data script
used when the
problem
occurs, see 15
Appendix:
How to
Collect Fault
Information.
7 Historical
alarms
For details
about how to
obtain the
historical
alarms
generated
within three
days before
and after the
problem
occurs, see 15
Appendix:
How to
Collect Fault
Information.
8 Original
traffic
statistics
For details
about how to
obtain the
original traffic
statistics
measured
within two
peak hours
before and
after the
problem
occurs, see 15
Appendix:
How to
Collect Fault
Information.
GBSS14.0
190
9 DSP
debugging
logs
files.
For details
about how to
obtain the
latest three
compressed
DPS
debugging log
files, see 15
Appendix:
How to
Collect Fault
Information.
10 Common
debugging
logs
For details
about how to
obtain the
common
debugging
logs generated
within two
hours before
and after the
problem
occurs, see 15
Appendix:
How to
Collect Fault
Information.
11 Operation
logs
For details
about how to
obtain the
operation logs
generated
within 10 days
before and
after the
problem
occurs, see 15
Appendix:
How to
Collect Fault
Information.
GBSS14.0
191
about how to
obtain all logs
for one or two
faulty BTSs,
see 15
Appendix:
How to
Collect Fault
Information.

The method described in the previous part Location Procedure is recommended when
troubleshooting discontinuous voice and low MOS. If the problems persist, Contact Huawei
Customer Service Center.
Typical Case
Symptom
The proportion of MOSs higher than 2.7 when an MS on a swapped network calls a fixed-line
phone is 90%, which does not meet the required proportion that is higher than 95%.
Cause Analysis
According to the analysis, the BSS products after network swapping have no known defects.
The problem is caused by poor receive quality of the Um interface, frequent handovers, and high
TCHH proportion.
1. Optimize handover parameters to reduce unnecessary handovers, such as ping-pong
handovers. After optimization, the proportion of MOSs higher than 2.7 increases by about
4%.
2. Expand capacity for cells with heavy traffic. After capacity expansion, the TCHH
proportion decreases from 46% to 35%.
3. Optimize the TRXs with low carrier-to-interference ratio (CIR). After optimization, the
proportion of receive quality classes 0 to 4 for the Um interface increases by about 2%.
After the preceding procedure is performed, the proportion of MOSs higher than 2.7 reaches
96.02%.
GBSS14.0
192
8 PS Counter Problems
About This Chapter
This chapter describes how to locate and troubleshoot PS counter problems.
8.1 PS Counters
This section describes the formulas for calculating the values for PS counters.
8.2 Locating PS Counter Problems
This section describes how to locate PS counter problems.
8.3 Troubleshooting Low TBF Establishment Success Rates
This section describes how to troubleshoot low temporary block flow (TBF) establishment
success rates.
8.4 Troubleshooting High TBF Call Drop Rates
This section describes how to troubleshoot high TBF call drop rates.
8.5 Troubleshooting Low Average Throughput at the RLC Layer
This section describes how to troubleshoot low average throughput at the radio link control
(RLC) layer.
8.6 Troubleshooting Low Percentage of High-Rate Coding Schemes to All Coding Schemes
This section describes how to troubleshoot low percentage of high-rate coding schemes to all
coding schemes.
8.7 Troubleshooting High RLC Data Block Retransmission Rates
This section describes how to troubleshoot high radio link control (RLC) data block
retransmission rates.
GBSS14.0
Troubleshooting Guide 8 PS Counter Problems
193
8.1 PS Counters
This section describes the formulas for calculating the values for PS counters.
l PS counters include TBF Establishment Success Rate, TBF Drop Rate, Average
Throughput of RLC, Rate of RLC with High Coding, and Retransmission Rate of RLC
Data Block. The formulas for calculating the values for these counters are as follows:
TBF Establishment Success Rate = [Number of successful TBF establishments] x
{100}/[Number of TBF establishment attempts]
TBF Drop Rate = [Number of intermit transfers] x {100}/[Number of successful TBF
establishments]
Average Throughput of EGPRS or GPRS RLC = ([Throughput of downlink EGPRS or
GPRS RLC data blocks] x {8})/(Transmission duration of RLC data blocks/{1000})*
([Number of PDCHs carrying EGPRS or GPRS TBFs]/[Sampling times of PDCH
measurement])
Rate of RLC with High Coding = [Total number of valid RLC data blocks with high
coding] x {100}/[[Total number of valid RLC data blocks with ALL coding]]
Retransmission Rate of RLC Data Block = ([Total number of RLC data blocks] - [Total
number of valid RLC data blocks]) x {100}/[Total number of RLC data blocks]
l The counters covered in this chapter are as follows:
A9003:Number of Failed Uplink GPRS TBF Establishments due to No Channel
A9103:Number of Failed Downlink GPRS TBF Establishments due to No Channel
A9203:Number of Failed Uplink EGPRS TBF Establishments due to No Channel
A9303:Number of Failed Downlink EGPRS TBF Establishments due to No Channel
A9004:Number of Failed Uplink GPRS TBF Establishments due to MS No Response
A9104:Number of Failed Downlink GPRS TBF Establishments due to MS No Response
A9204:Number of Failed Uplink EGPRS TBF Establishments due to MS No Response
A9304:Number of Failed Downlink EGPRS TBF Establishments due to MS No
Response
A9016:Number of Failed Uplink GPRS TBF Establishments due to Other Cause
A9115:Number of Failed Downlink GPRS TBF Establishments due to Other Cause
A9216:Number of Failed Uplink EGPRS TBF Establishments due to Other Cause
A9315:Number of Failed Downlink EGPRS TBF Establishments due to Other Cause
A9006:Number of Uplink GPRS TBF Abnormal Releases due to N3101 Overflow (MS
No Response)
A9007:Number of Uplink GPRS TBF Abnormal Releases due to N3103 Overflow (MS
No Response)
A9206:Number of Uplink EGPRS TBF Abnormal Releases due to N3101 Overflow
(MS No Response)
(MS No Response)
A9106:Number of Downlink GPRS TBF Abnormal Releases due to N3105 Overflow
A9306:Number of Downlink EGPRS TBF Abnormal Releases due to N3105 Overflow
GBSS14.0
194
A9010:Number of Uplink GPRS TBF Abnormal Releases due to No Channel
A9210:Number of Uplink EGPRS TBF Abnormal Releases due to No Channel
A9109:Number of Downlink GPRS TBF Abnormal Releases due to No Channel
A9309:Number of Downlink EGPRS TBF Abnormal Releases due to No Channel
A9009:Number of Uplink GPRS TBF Abnormal Releases due to FLUSH
A9209:Number of Uplink EGPRS TBF Abnormal Releases due to FLUSH
A9108:Number of Downlink GPRS TBF Abnormal Releases due to FLUSH
A9308:Number of Downlink EGPRS TBF Abnormal Releases due to FLUSH
A9008:Number of Uplink GPRS TBF Abnormal Releases due to SUSPEND
A9208:Number of Uplink EGPRS TBF Abnormal Releases due to SUSPEND
A9107:Number of Downlink GPRS TBF Abnormal Releases due to SUSPEND
A9307:Number of Downlink EGPRS TBF Abnormal Releases due to SUSPEND
R9343:Number of Reclaimed Dynamic PDCHs
R9344:Number of Reclaimed Busy Dynamic PDCHs
8.2 Locating PS Counter Problems
This section describes how to locate PS counter problems.
8.2.1 Principles for Locating PS Counter Problems
This section describes the principles for locating PS counter problems.
The principles for locating PS counter problems are as follows:
l Analyze BSC counters before cell counters, lower-layer links before upper-layer services,
as well as symptoms before traffic models.
l Focus on the correlation between counters and absolute counter values.
l If counters of a certain type are abnormal, analyze the changes in counter values over a
week, and determine whether the counters are abnormal in the entire BSC or only in certain
cells.
If counters are abnormal in the entire BSC, check the BSC equipment, transmission
devices, and network.
If counters are abnormal in certain cells, analyze the problem cells by performing drive
tests and using a signaling analyzer if necessary.
8.2.2 Procedure for Locating PS Counter Problems
This section describes the procedure for locating PS counter problems.
Figure 8-1 shows the procedure for locating PS counter problems.
GBSS14.0
195
Figure 8-1 Procedure for locating PS counter problems

8.3 Troubleshooting Low TBF Establishment Success Rates
This section describes how to troubleshoot low temporary block flow (TBF) establishment
success rates.
GBSS14.0
196
Symptom
TBF establishment success rates do not meet customer requirements and PS calls are difficult
to set up.
TBFs are used to transmit PS services. If TBFs fail to be established, PS services cannot be
performed successfully. The TBF establishment success rate indicates the capacity of a data
service network and the Um interface quality for an MS to access the network.
The possible causes of low TBF establishment success rates are as follows:
l High frame error rate for Abis transmission
l Insufficient channel resources
l Incorrect parameter settings
Location Procedure
Figure 8-2 shows the procedure for locating low TBF establishment success rates.
GBSS14.0
197
Figure 8-2 Procedure for locating low TBF establishment success rates

NOTE
Collect the location information about PS counter problems by referring to Table 8-1 before contacting
Huawei for technical support.
GBSS14.0
198
Table 8-1 Location information about PS counter problems
1 Symptom Provide the start time and end time of the fault,
fault occurs in a cell, a BTS, a BSC, or all BSCs
under an MSC).

2 Operations
before and after
the fault occurs
Provide the operations before and after the fault
occurs, such as board replacement, software
upgrade, clock source change, dynamic data
configuration, BTS reset, BSC reset, MSC
swapping, and MSC data modification.

3 Faulty NE
version
For details
about how
to obtain
the BSC
and BTS
software
versions
that are
used when
the
problem
occurs,
see 15
Appendix
: How to
Collect
Fault
Informati
on.
4 Configuration
data script
fault occurs.
For details
about how
to obtain
the
configurat
ion data
script, see
15
Appendix
: How to
Collect
Fault
Informati
on.
GBSS14.0
199
5 Original traffic
statistics
Obtain the original traffic statistics measured
within three days before and after counters
deteriorate.
For details
about how
to obtain
the
original
traffic
statistics,
see 15
Appendix
: How to
Collect
Fault
Informati
on.
6 GPSR logs Obtain the GPSR logs generated within one peak
hour in one day before and after counters
deteriorate.
For details
about how
to obtain
the GPSR
logs, see
15
Appendix
: How to
Collect
Fault
Informati
on.
7 Common
debugging logs
Obtain the common debugging logs generated
within one peak hour in one day before and after
counters deteriorate.
For details
about how
to obtain
the
common
debugging
logs, see
15
Appendix
: How to
Collect
Fault
Informati
on.
GBSS14.0
200
8 Operation logs Obtain the operation logs generated within three
days before and after counters deteriorate.
For details
about how
to obtain
the
operation
logs, see
15
Appendix
: How to
Collect
Fault
Informati
on.
9 Faulty
signaling
Obtain the signaling on the Um and Gb interface in
two of top N cells when the fault occurs. If there
are no top N cells, select two cells whose counters
deteriorate.
For details
about how
to obtain
the faulty
signaling,
see 15
Appendix
: How to
Collect
Fault
Informati
on.

1. Select the top N cells with lower TBF establishment success rates.
NOTE
Removing these cells can increase the overall TBF establishment success rate.
The following operations should only be performed on the top N cells.
2. Check whether RL9A08:Rate of Transmitted Error Frames is larger than 1%. If yes, bit
errors have occurred during Abis transmission. In this case, contact transmission engineers.
3. Check whether L3188A:MSG DEL IND Messages Sent on Abis Interface is larger than
10. If yes, the CCCH is seriously overloaded. In this case, run the MML command SET
GTRXCHAN to configure extended broadcast control channels (BCCHs).
4. Find out the causes of TBF establishment failures.
TBF establishment failures are generally caused by insufficient channel resources and no
MS response.
l If TBF establishment failures are caused by insufficient channel resources, the values
for the following counters are large:
A9003:Number of Failed Uplink GPRS TBF Establishments due to No Channel
A9103:Number of Failed Downlink GPRS TBF Establishments due to No Channel
A9203:Number of Failed Uplink EGPRS TBF Establishments due to No Channel
GBSS14.0
201
A9303:Number of Failed Downlink EGPRS TBF Establishments due to No Channel
l If TBF establishment failures are caused by no MS response, the values for the following
counters are large:
A9004:Number of Failed Uplink GPRS TBF Establishments due to MS No
Response
A9104:Number of Failed Downlink GPRS TBF Establishments due to MS No
Response
A9204:Number of Failed Uplink EGPRS TBF Establishments due to MS No
Response
A9304:Number of Failed Downlink EGPRS TBF Establishments due to MS No
Response
l If TBF establishment failures are caused by insufficient channel resources, go to Step
5.
l If TBF establishment failures are caused by no MS response, go to Step 6.
5. To troubleshoot TBF establishment failures due to insufficient channel resources, perform
the following steps:
a. Run the MML command LST GTRXCHAN to check whether Channel Type for the
problem cell is set to PDTCH. If no, run the MML command SET GTRXCHAN to
reconfigure the parameter.
b. Run the MML command DSP PSCELL to check whether the value for
R9506:Maximum Number of PDCHs Occupied on DSP reaches the upper limit on
the digital signal processor (DSP) that serves the problem cell. If yes, run the MML
command SET PSCELLTODSP to migrate the problem cell to the DSP with the
smallest value for R9506:Maximum Number of PDCHs Occupied on DSP.
NOTE
l A DSP number consists of the subrack number, slot number, and DSP number.
l A maximum of 48 PDCHs can be activated on one DSP for the DPUd, and a maximum of
110 PDCHs can be activated on one DSP for the DPUg.
c. Run the MML command LST GCELLPSCHM to check whether Maximum Rate
Threshold of PDCHs in a Cell for the problem cell is smaller than 30.
l If yes, run the MML command SET GCELLPSCHM and set Maximum Rate
Threshold of PDCHs in a Cell to 30.
l If the value is larger than or equal to 30, retain the value.
d. Run the MML command LST GTRXBASE to check the values for the following
parameters:
l Maximum Number of PDCH: The recommended value is 8.
l Maximum Number of Occupied Abis Timeslots: The recommended value is
32.
If the two parameters are not set to the recommended values, run the MML command
SET GTRXBASE to reconfigure the parameters.
e. Run the MML command LST GCELLPSCHM to query the values for PDCH
Uplink Multiplex Threshold and PDCH Downlink Multiplex Threshold.
l If the value for PDCH Uplink Multiplex Threshold is smaller than 70, run the
MML command SET GCELLPSCHM and change the value to 70.
GBSS14.0
202
l If the value for PDCH Downlink Multiplex Threshold is smaller than 80, run
the MML command SET GCELLPSCHM and change the value to 80.
l In other cases, retain the original values.
f. Check whether the subrack where the DSP serving the problem cell is located is the
subrack accommodating the Abis interface board.
l Run the MML command DSP PSCELL to query the value for Subrack No., which
is the number of the subrack where the DSP serving the problem cell is located.
l Run the MML command LST GTRX to query the value for Out-BSC Subrack
No., which is the number of the subrack accommodating the Abis interface board.
If the two subrack numbers are different, run the MML command SET
PSCELLTODSP to migrate the problem cell to the DSP that is located in the subrack
accommodating the Abis interface board.
g. Run the MML command LST BSCPSSOFTPARA to check whether Allow E Down
G Up Switch is set to Open. If no, run the MML command SET
BSCPSSOFTPARA to reconfigure the parameter.
CAUTION
Setting Allow E Down G Up Switch to Open may decrease the EDGE download
rate.
6. To troubleshoot TBF establishment failures due to no MS response, perform the following
steps:
a. Set the following parameters:
l If the uplink TBF establishment success rate is low, run the MML command SET
GCELLEGPRSPARA to set Uplink Default MCS Type for the problem cell to
MCS1.
l If the downlink TBF establishment success rate is low, run the MML command
SET GCELLEGPRSPARA to set Downlink Default MCS Type for the problem
cell to MCS2.
b. Check the interference band counters to determine whether interference exists in the
problem cell. If yes, eliminate the interference or change the interfered ARFCN.
c. Check the uplink and downlink quality counters to determine whether the Um interface
quality is poor. If yes, improve the Um interface quality.
7. Optimize network parameters.
l If the uplink TBF establishment success rate is low, perform the following steps:
a. Run the MML command SET GCELLPSBASE to increase T3168 to a value not
more than 2000.
A small value indicates a short interval for an MS to determine a TBF establishment
failure. As a result, when a TBF fails to be established, the average delay for PS
service access decreases, but the TBF establishment success rate in an adverse
radio environment also decreases. In addition, the probability of PS service
reaccess increases. Consequently, the number of reassignments increases, wasting
system resources.
A large value indicates a long interval for an MS to determine a TBF establishment
failure. As a result, when a TBF fails to be established, the average delay for PS
GBSS14.0
203
service access increases, but the TBF establishment success rate in an adverse radio
environment also increases.
b. Run the MML command SET GCELLPSPWPARA to change the values for
ALPHA and GAMMA.
Small values for the two parameters indicate a high output power for MSs and a
strong signal strength received by BTSs, but an increase in cell interference.
A large value indicates a low output power for MSs and a decrease in cell
interference, but a weak signal strength received by BTSs.
Therefore, change the values for these two parameters according to site
requirements. Generally, smaller values are appropriate for densely populated
areas and larger values for remote areas.
c. Run the MML command SET GCELLCCACCESS to increase the value for PS
RACH Min. Access Level. The recommended value is -109.
Increasing the value for PS RACH Min. Access Level improves the TBF
establishment success rate, but decreases the number of admitted subscribers and
the traffic volume.
d. Run the MML command SET GCELLCCACCESS to increase the value for
Random Access Error Threshold. The recommended value is 225.
A small value allows more random access signal errors and easier MS random
access, but leads to a high misreporting rate.
A large value reduces the misreporting rate, but reduces the number of admitted
subscribers and the traffic volume too.
l If the downlink TBF establishment success rate is low, perform the following steps:
a. Run the MML command SET BSCPSSOFTPARA to set Retry Times of
Downlink TBF Reassignment to 4.
A large value increases the downlink TBF establishment success rate, but increases
the congestion rate during peak hours too.
A small value decreases the congestion rate during peak hours, but decreases the
downlink TBF establishment success rate too.
b. Run the MML command LST BSCPSSOFTPARA to check whether Retry
Times of Downlink TBF Polling is set to 5. If no, run the MML command SET
BSCPSSOFTPARA to reconfigure the parameter.
A large value increases the downlink TBF establishment success rate, but increases
the congestion rate during peak hours too.
A small value decreases the congestion rate during peak hours, but decreases the
downlink TBF establishment success rate too.
8. If the problem persists, Contact Huawei Customer Service Center.
Typical Case
Symptom
The field engineers at a site report that the TBF establishment success rate decreases by 5%.
Cause Analysis
Maximum Rate Threshold of PDCHs in a Cell for the problem cell is set to 10.
GBSS14.0
204
1. Analyze related counters. The TBF establishment success rates are lower than 80% for 10
cells.
2. Check the frame error rates for Abis transmission in these cells. The frame error rates are
all lower than 1.
3. Check the causes of TBF establishment failures. All TBF establishment failures are caused
by insufficient channel resources.
4. Check parameter settings. PDCHs are configured, and Allow E Down G Up Switch is set
to Open.
5. Check the counters related to the DSPs serving the problem cells. The value for
R9506:Maximum Number of PDCHs Occupied on DSP is smaller than 48 for all the
problem cells.
6. Check the value for Maximum Rate Threshold of PDCHs in a Cell. The value is 10 for
problem cells but 30 for normal cells.
7. Change the value for Maximum Rate Threshold of PDCHs in a Cell to 30 for the problem
cells. The TBF establishment success rates return to normal.
8.4 Troubleshooting High TBF Call Drop Rates
This section describes how to troubleshoot high TBF call drop rates.
Symptom
The TBF call drop rate indicates network performance stability. If the TBF call drop rate is high
during web browsing, web pages open slowly or even fail to open.
The TBF call drop rate is the ratio of the number of abnormal TBF releases to the number of
TBF establishment successes. The causes of high TBF call drop rates are as follows:
l No MS response due to poor Um interface quality
l Loss of MS uplink messages due to network transmission faults or resource preemption
l No MS response after receiving an indication message due to MS incompatibility with the
network
The causes of abnormal TBF releases are as follows:
l Overflow of N3101, N3103, or N3105
l Cell reselection
l Channel preemption
Location Procedure
Figure 8-3 shows the procedure for locating high TBF call drop rates.
GBSS14.0
205
Figure 8-3 Procedure for locating high TBF call drop rates

NOTE
GBSS14.0
206
under an MSC).

2 Operations
before and after
the fault occurs

3 Faulty NE
version
For details
about how
to obtain
the BSC
and BTS
software
versions
that are
used when
the
problem
occurs,
see 15
Appendix
: How to
Collect
Fault
Informati
on.
4 Configuration
data script
fault occurs.
For details
about how
to obtain
the
configurat
ion data
script, see
15
Appendix
: How to
Collect
Fault
Informati
on.
GBSS14.0
207
5 Original traffic
statistics
deteriorate.
For details
about how
to obtain
the
original
traffic
statistics,
see 15
Appendix
: How to
Collect
Fault
Informati
on.
deteriorate.
For details
about how
to obtain
the GPSR
logs, see
15
Appendix
: How to
Collect
Fault
Informati
on.
7 Common
debugging logs
For details
about how
to obtain
the
common
debugging
logs, see
15
Appendix
: How to
Collect
Fault
Informati
on.
GBSS14.0
208
For details
about how
to obtain
the
operation
logs, see
15
Appendix
: How to
Collect
Fault
Informati
on.
9 Faulty
signaling
deteriorate.
For details
about how
to obtain
the faulty
signaling,
see 15
Appendix
: How to
Collect
Fault
Informati
on.

1. Check whether any cells meet the standard for high TBF call drop rates.
l If yes, select the top N cells with higher TBF call drop rates. The following operations
should only be performed on the top N cells.
l If no, the following operations should be performed on all cells on the network.
2. Check whether the related parameters are set correctly.
l If the EGPRS call drop rate is high, run the MML command LST
GCELLEGPRSPARA to check the values for the following parameters:
Uplink Fixed MCS Type: Check whether this parameter is set to UNFIXED.
Downlink Fixed MCS Type: Check whether this parameter is set to UNFIXED.
Uplink Default MCS Type: Check whether the value for this parameter is smaller
than or equal to MCS2. If the uplink EGPRS TBF call drop rate is high, decrease
the value for this parameter.
Downlink Default MCS Type: Check whether the value for this parameter is
smaller than or equal to MCS6. If the downlink EGPRS TBF call drop rate is high,
decrease the value for this parameter.
If the parameter settings are incorrect, run the MML command SET
GCELLEGPRSPARA to change the settings.
GBSS14.0
209
l If the GPRS call drop rate is high, run the MML command LST GCELLPSCS to check
the values for the following parameters:
Uplink Fixed CS Type: Check whether this parameter is set to UNFIXED.
Downlink Fixed CS Type: Check whether this parameter is set to UNFIXED.
Uplink Default CS Type: Check whether this parameter is set to CS1.
Downlink Default CS Type: Check whether this parameter is set to CS2. If the
downlink GPRS TBF call drop rate is high, decrease the value for this parameter.
l Run the MML command LST GCELLEGPRSPARA to check whether Bep Period
is set to 5. If no, run the MML command SET GCELLPSPWPARA to change the
value for this parameter to 5.
l Run the MML command LST GCELLSTANDARDOPTPARA to check the values
for the following parameters:
Maximum Value of N3101: Check whether the value for this parameter is larger
than or equal to 20.
than or equal to 3.
than or equal to 10.
GCELLSTANDARDOPTPARA to change the settings.
3. For the top N cells with higher TBF call drop rates, check whether the value for
RL9A08:Rate of Transmitted Error Frames is larger than 1%. If the value is larger than
1%, bit errors have occurred during Abis transmission. In this case, contact transmission
engineers.
4. Check the causes of abnormal TBF releases. Abnormal TBF releases are generally caused
by poor Um interface quality, lack of channel resources, or cell reselection.
l If abnormal TBF releases are caused by poor Um interface quality, the values for the
following counters are large:
A9006:Number of Uplink GPRS TBF Abnormal Releases due to N3101 Overflow
(MS No Response)
A9007:Number of Uplink GPRS TBF Abnormal Releases due to N3103 Overflow
(MS No Response)
(MS No Response)
(MS No Response)
A9106:Number of Downlink GPRS TBF Abnormal Releases due to N3105
Overflow
A9306:Number of Downlink EGPRS TBF Abnormal Releases due to N3105
Overflow
l If abnormal TBF releases are caused by lack of channel resources, the values for the
following counters are large:
A9010:Number of Uplink GPRS TBF Abnormal Releases due to No Channel
GBSS14.0
210
A9210:Number of Uplink EGPRS TBF Abnormal Releases due to No Channel
A9109:Number of Downlink GPRS TBF Abnormal Releases due to No Channel
A9309:Number of Downlink EGPRS TBF Abnormal Releases due to No Channel
l If abnormal TBF releases are caused by cell reselection, the values for the following
counters are large:
A9009:Number of Uplink GPRS TBF Abnormal Releases due to FLUSH
A9209:Number of Uplink EGPRS TBF Abnormal Releases due to FLUSH
A9108:Number of Downlink GPRS TBF Abnormal Releases due to FLUSH
A9308:Number of Downlink EGPRS TBF Abnormal Releases due to FLUSH
5. Troubleshoot abnormal TBF releases depending on the causes identified in Step 4.
Co-channel and adjacent-channel interference, frequency collision due to frequency
hopping (FH), or uplink and downlink imbalance may lead to RLC block decoding
failures and N3101/N3103/N3105 overflow, resulting in abnormal TBF releases. In this
case, optimize the frequency planning, FH parameter settings, power control parameter
settings, and transmit power settings. For details, see 5.3 Troubleshooting Call Drops
Due to Poor Um Interface Quality.
l Lack of channel resources
Check whether any boards are faulty. If any boards are faulty, replace the boards.
Check the values for R9343:Number of Reclaimed Dynamic PDCHs and
R9344:Number of Reclaimed Busy Dynamic PDCHs. If the values for the two
counters are large, dynamic PDCHs have been preempted by CS services during
peak hours. In this case, expand the BTS capacity.
l Cell reselection
Check whether the cells and routing areas are properly planned. If no, replan them.
Typical Case
Symptom
The TBF call drop rate at a site increases by 3%.
Cause Analysis
Frequency interference and insufficient channel resources
1. Check that the parameters for the cells with high TBF call drop rates are set to recommended
values.
all lower than 1.
3. Analyze the counters reported by the field engineers. The causes of high TBF call drop
rates are as follows:
l N3105 overflow
The Um interface quality is poor, which may cause interference.
GBSS14.0
211
Check the interference band. Severe interference is detected. Check the frequency
planning. ARFCN 7 experiences interference from a nearby BTS. The related TRX is
configured with PDCHs.
Change the ARFCN, the number of N3105 overflows decreases from several hundred
times to about 30 times.
l Lack of channel resources
The values for R9343:Number of Reclaimed Dynamic PDCHs and R9344:Number of
Reclaimed Busy Dynamic PDCHs for the problem cells are high. The reason is that call
drops occur when TBFs are transmitted over TCHs that are converted from dynamic
PDCHs during peak hours.
As a result, CS and PS channels are congested.
4. Expand the BTS capacity.
8.5 Troubleshooting Low Average Throughput at the RLC
Layer
This section describes how to troubleshoot low average throughput at the radio link control
(RLC) layer.
Symptom
The download rate is low. The values for the following counters do not meet the standard for
low average throughput at the RLC layer.
l TL9333:Average Throughput of Downlink EGPRS RLC
l TL9114:Average Throughput of Downlink GPRS RLC
l TL9232:Average Throughput of Uplink EGPRS RLC
l TL9014:Average Throughput of Uplink GPRS RLC
Throughput is the amount of data transmitted per time unit. The higher the throughput, the higher
the PS transmission rate. The causes of low average throughput at the RLC layer are as follows:
l Insufficient radio resources, such as insufficient packet data traffic channels (PDTCHs),
insufficient idle Abis timeslots and Gb bandwidth in time division multiplexing (TDM)
transmission mode, and insufficient MSs multiplexed on a channel.
l Poor radio environment, such as poor Um interface quality, poor Abis transmission quality,
and poor Gb transmission quality.
l Incorrect parameter settings, such as incorrect settings for PDCH Downlink Multiplex
Threshold, Channel Type, and Bep Period.
l Low MS capabilities, such as low buffer capability, low packet assembly and disassembly
capability, low multislot capability, and low EGPRS service support capability.
Location Procedure
Figure 8-4 shows the procedure for locating low average throughput at the RLC layer.
GBSS14.0
212
Figure 8-4 Procedure for locating low average throughput at the RLC layer

NOTE
GBSS14.0
213
under an MSC).

2 Operations
before and after
the fault occurs

3 Faulty NE
version
For details
about how
to obtain
the BSC
and BTS
software
versions
that are
used when
the
problem
occurs,
see 15
Appendix
: How to
Collect
Fault
Informati
on.
4 Configuration
data script
fault occurs.
For details
about how
to obtain
the
configurat
ion data
script, see
15
Appendix
: How to
Collect
Fault
Informati
on.
GBSS14.0
214
5 Original traffic
statistics
deteriorate.
For details
about how
to obtain
the
original
traffic
statistics,
see 15
Appendix
: How to
Collect
Fault
Informati
on.
deteriorate.
For details
about how
to obtain
the GPSR
logs, see
15
Appendix
: How to
Collect
Fault
Informati
on.
7 Common
debugging logs
For details
about how
to obtain
the
common
debugging
logs, see
15
Appendix
: How to
Collect
Fault
Informati
on.
GBSS14.0
215
For details
about how
to obtain
the
operation
logs, see
15
Appendix
: How to
Collect
Fault
Informati
on.
9 Faulty
signaling
deteriorate.
For details
about how
to obtain
the faulty
signaling,
see 15
Appendix
: How to
Collect
Fault
Informati
on.

1. Check whether any cells meet the standard for low average throughput at the RLC layer.
l If yes, select the top N cells with lower average throughput at the RLC layer. The
following operations should only be performed on the top N cells.
2. Check whether the percentage of high-rate coding schemes to all coding schemes is low.
l If yes, increase the percentage of high-rate coding schemes to all coding schemes. For
details, see 8.6 Troubleshooting Low Percentage of High-Rate Coding Schemes to
All Coding Schemes.
l If the EGPRS throughput is low, run the MML command LST
Uplink Default MCS Type: Check whether the value for this parameter is larger
than or equal to MCS2.
GBSS14.0
216
Downlink Default MCS Type: Check whether the value for this parameter is larger
l If the GPRS throughput is low, run the MML command LST GCELLPSCS to check
the values for the following parameters:
Uplink Default CS Type: Check whether the value for this parameter is larger than
or equal to CS1.
Downlink Default CS Type: Check whether the value for this parameter is larger
than or equal to CS2.
l Run the MML command LST GCELLEGPRSPARA to check whether Bep Period
is set to 5. If no, run the MML command SET GCELLPSPWPARA to change the
value for this parameter to 5.
l Run the MML command LST GCELLPSCHM to query the value for Timer of
Releasing Abis Timeslot.
If the value for Timer of Releasing Abis Timeslot is larger than 15, run the MML
command SET GCELLPSCHM to change the value for this parameter to 15.
If the value for Timer of Releasing Abis Timeslot is smaller than or equal to 15,
retain the value.
l Run the MML command LST GCELLPSCHM to query the value for PDCH
Downlink Multiplex Threshold.
If the value for PDCH Downlink Multiplex Threshold is larger than 80, run the
MML command SET GCELLPSCHM to change the value for this parameter to
80.
If the value for PDCH Downlink Multiplex Threshold is smaller than or equal to
80, retain the value.
l Run the MML command LST BSCPSSOFTPARA to check whether Allow E Down
G Up Switch is set to Open. If yes, run the MML command SET
BSCPSSOFTPARA to change the value for Allow E Down G Up Switch to CLOSE
(Close).
4. For the top N cells with lower average throughput at the RLC layer, check whether the
value for RL9A08:Rate of Transmitted Error Frames is larger than 1%. If yes, bit errors
have occurred during Abis transmission. In this case, contact transmission engineers.
5. Poor Um interface quality may lead to a low bit error probability (BEP). Poor Um interface
quality may be caused by co-channel or adjacent-channel interference, frequency collision
due to frequency hopping (FH), or uplink and downlink imbalance. As a result, high-rate
coding schemes cannot be used, resulting in a decrease in the average throughput at the
RLC layer. In this case, optimize the frequency planning, FH parameter settings, power
control parameter settings, and transmit power settings. For details, see 5.3
Troubleshooting Call Drops Due to Poor Um Interface Quality.
6. If the percentage of high-rate coding schemes to all coding schemes and the number of
available packet data channels (PDCHs) increase, the average throughput at the RLC layer
increases. To prevent an increase in the RLC data retransmission rate and occupation of
GBSS14.0
217
more transmission resources, change the values for the following parameters according to
site requirements.
l Run the MML command SET GCELLPSCHM to increase the value for Maximum
Rate Threshold of PDCHs in a Cell.
Advantage: The number of available PDCHs increases.
Disadvantage: CS services occupy more PDCHs during peak hours and the
percentage of half-rate coding schemes increases, reducing the mean opinion score
(MOS).
l Run the MML command SET BTSIDLETS to add idle Abis timeslots. The formula
for calculating the number of sufficient idle Abis timeslots is as follows: Number of
sufficient idle Abis timeslots = (Number of static PDCHs + Number of TCHFs) x
Maximum Rate Threshold of PDCHs in a Cell x 3
Advantage: Idle Abis timeslots are sufficient and each timeslot uses the high-rate
coding scheme.
Disadvantage: Excessive transmission resources are occupied. In Flex Abis
networking mode, CS services are affected if excessive idle Abis timeslots are added.
l Run the MML command SET BSCPSSOFTPARA to set Support USF Granularity
4 Switch to SUPPORT(Support).
Advantage: If USF granularity 4 is supported, only one data block needs to have its
coding scheme degraded from 8PSK to GMSK and the other three data blocks can
still use high-rate coding schemes, increasing the percentage of high-rate coding
schemes to all coding schemes.
Disadvantage: None.
l Run the MML command SET GCELLPSCHM to set Level of Preempting Dynamic
Channel to LEVEL1(No preempt of CCHs).
Advantage: The number of abnormal temporary block flow (TBF) releases
decreases.
Disadvantage: CS channels may become congested.
l Run the MML command LST BSCPSSOFTPARA to set Level of Preempting
Dynamic Channel to 15.
Advantage: The coding schemes can be adjusted quickly.
Disadvantage: The upload rate may decrease.
Typical Case
Symptom
The average throughput at the RLC layer decreases at a site after a network swap.
Cause Analysis
l High-rate coding schemes cannot be used due to poor Um interface quality.
l High-rate coding schemes cannot be used due to insufficient idle Abis timeslots.
1. Check the settings of the parameters for the cells with low average throughput at the RLC
layer. These parameters are set to recommended values.
GBSS14.0
218
all lower than 1.
3. Perform a drive test to obtain the Tems log and check the Um interface quality of these
cells. The Um interface quality of these cells is poor and the carrier-to-interference (C/I)
ratio is low. After network optimization engineers improve the Um interface quality, the
average throughput at the RLC layer in these cells returns to normal.
4. Query the number of idle Abis timeslots in these cells. The idle Abis timeslots in these cells
are insufficient. After more idle Abis timeslots are added, the average throughput at the
RLC layer in these cells returns to normal.
8.6 Troubleshooting Low Percentage of High-Rate Coding
Schemes to All Coding Schemes
This section describes how to troubleshoot low percentage of high-rate coding schemes to all
coding schemes.
Symptom
The percentage of high-rate coding schemes to all coding schemes indicates data transmission
performance. If this percentage is low during web browsing, web pages open slowly or even fail
to open.
The percentage of EDGE high-rate coding schemes to all coding schemes refers to the ratio of
radio link control (RLC) data blocks that use coding schemes MCS7 through MSC9 (including
MSC6 at certain sites) to all data blocks.
The percentage of GPRS high-rate coding schemes to all coding schemes refers to the ratio of
RLC data blocks that use coding schemes CS3 and CS4 to all data blocks.
A high percentage of high-rate coding schemes to all coding schemes increases the transmission
rate but results in a high probability of retransmission too.
The causes of low percentage of high-rate coding schemes to all coding schemes are as follows:
Poor Um interface quality may lead to a low bit error probability (BEP). In this case, high-
rate coding schemes cannot be used.
Poor Um interface quality may also lead to an automatic switchover to the LA mode, in
which data blocks are segmented and retransmitted. In this case, the percentage of high-
rate coding schemes to all coding schemes decreases.
l Insufficient idle Abis timeslots, which may affect the coding scheme adjustment. In this
case, the percentage of high-rate coding schemes to all coding schemes and the transmission
rate significantly decrease.
l High frame error rates for Abis transmission, which may lead to loss and retransmission of
data blocks. In this case, the percentage of high-rate coding schemes to all coding schemes
decreases.
GBSS14.0
219
l Abnormal temporary block flow (TBF) releases, which may lead to data transmission using
low-rate coding schemes. In this case, the percentage of high-rate coding schemes to all
coding schemes decreases.
Location Procedure
Figure 8-5 shows the procedure for locating low percentage of high-rate coding schemes to all
coding schemes.
GBSS14.0
220
Figure 8-5 Procedure for locating low percentage of high-rate coding schemes to all coding
schemes

GBSS14.0
221
NOTE
under an MSC).

2 Operations
before and after
the fault occurs

3 Faulty NE
version
For details
about how
to obtain
the BSC
and BTS
software
versions
that are
used when
the
problem
occurs,
see 15
Appendix
: How to
Collect
Fault
Informati
on.
4 Configuration
data script
fault occurs.
For details
about how
to obtain
the
configurat
ion data
script, see
15
Appendix
: How to
Collect
Fault
Informati
on.
GBSS14.0
222
5 Original traffic
statistics
deteriorate.
For details
about how
to obtain
the
original
traffic
statistics,
see 15
Appendix
: How to
Collect
Fault
Informati
on.
deteriorate.
For details
about how
to obtain
the GPSR
logs, see
15
Appendix
: How to
Collect
Fault
Informati
on.
7 Common
debugging logs
For details
about how
to obtain
the
common
debugging
logs, see
15
Appendix
: How to
Collect
Fault
Informati
on.
GBSS14.0
223
For details
about how
to obtain
the
operation
logs, see
15
Appendix
: How to
Collect
Fault
Informati
on.
9 Faulty
signaling
deteriorate.
For details
about how
to obtain
the faulty
signaling,
see 15
Appendix
: How to
Collect
Fault
Informati
on.

1. Check whether any cells meet the standard for low percentage of high-rate coding schemes
to all coding schemes.
l If yes, select the top N cells with low percentage of high-rate coding schemes to all
coding schemes. The following operations should only be performed on the top N cells.
l If the percentage of EGPRS high-rate coding schemes to all coding schemes is low, run
the MML command LST GCELLEGPRSPARA to check the values for the following
parameters:
Uplink Default MCS Type: Check whether the value for this parameter is larger
Downlink Default MCS Type: Check whether the value for this parameter is larger
GBSS14.0
224
l If the percentage of GPRS high-rate coding schemes is low, run the MML command
LST GCELLPSCS to check the values for the following parameters:
Uplink Default CS Type: Check whether the value for this parameter is larger than
or equal to CS1.
Downlink Default CS Type: Check whether the value for this parameter is larger
than or equal to CS2.
l Run the MML command LST GCELLPSCS to check whether the thresholds of the
uplink and downlink TBF retransmission rates are set to recommended values. If no,
run the MML command SET GCELLPSCS to set these parameters to recommended
values. For details about the recommended values, see the MML online help.
l Run the MML command LST GCELLPSCS to check whether Bep Period is set to
5. If no, run the MML command SET GCELLPSPWPARA to change the value for
Bep Period to 5.
l Run the MML command LST GCELLPSCHM to query the value for Timer of
Releasing Abis Timeslot. If the value for Timer of Releasing Abis Timeslot is larger
than 15, run the MML command SET GCELLPSCHM to change the value for Timer
of Releasing Abis Timeslot to 15.
l Run the MML command LST BSCPSSOFTPARA to check whether Allow E Down
G Up Switch is set to Open. If yes, run the MML command SET
BSCPSSOFTPARA to change the value for Allow E Down G Up Switch to CLOSE
(Close).
3. For the top N cells with lower percentage of high-rate coding schemes to all coding schemes,
check whether the value for RL9A08:Rate of Transmitted Error Frames is larger than 1%.
If yes, bit errors have occurred during Abis transmission. In this case, contact transmission
engineers.
4. Poor Um interface quality may lead to a low BEP. Poor Um interface quality may be caused
by co-channel or adjacent-channel interference, frequency collision due to FH, or uplink
and downlink imbalance. As a result, high-rate coding schemes cannot be used. In this case,
optimize the frequency planning, FH parameter settings, power control parameter settings,
and transmit power settings. For details, see 5.3 Troubleshooting Call Drops Due to Poor
Um Interface Quality.
5. Run the MML command LST BTSIDLETS to check whether idle Abis timeslots
configured for the BTS are sufficient.
If Number of idle Abis timeslots (Number of static PDCHs + Number of TCHFs) x
Maximum Rate Threshold of PDCHs in a Cell x 3, idle Abis timeslots are sufficient.
If idle Abis timeslots are insufficient, run the MML command SET BTSIDLETS to add
idle Abis timeslots.
6. Check whether there are a large number of abnormal TBF releases. If yes, see 8.4
Troubleshooting High TBF Call Drop Rates.
7. Optimize the following parameters.
NOTE
To prevent an increase in the RLC data retransmission rate, change the values for the following
parameters according to site requirements.
GBSS14.0
225
l Run the MML command SET GCELLPSCHM to increase the value for Maximum
Rate Threshold of PDCHs in a Cell.
Advantage: The number of available PDCHs increases.
Disadvantage: CS services occupy more PDCHs during peak hours and the
percentage of half-rate coding schemes increases, reducing the mean opinion score
(MOS).
l Run the MML command SET BSCPSSOFTPARA to set Support USF Granularity
4 Switch to SUPPORT(Support).
Advantage: If USF granularity 4 is supported, only one data block needs to have its
coding scheme degraded from 8PSK to GMSK and the other three data blocks can
still use high-rate coding schemes, increasing the percentage of high-rate coding
schemes to all coding schemes.
Disadvantage: None.
l Run the MML command SET GCELLPSCHM to set Level of Preempting Dynamic
Channel to LEVEL1(No preempt of CCHs).
Advantage: The number of abnormal TBF releases decreases.
Disadvantage: CS channels may become congested.
l Run the MML command LST BSCPSSOFTPARA to set Level of Preempting
Dynamic Channel to 15.
Advantage: The coding schemes can be adjusted quickly.
Disadvantage: The upload rate may decrease.
Typical Case
Symptom
The percentage of high-rate coding schemes to all coding schemes used at the RLC layer is only
about 74% at a site.
Cause Analysis
High-rate coding schemes cannot be used due to insufficient idle Abis timeslots.
1. Check the settings of the parameters for the cells with low percentage of high-rate coding
schemes to all coding schemes. These parameters are set to recommended values.
all lower than 1.
3. Check the traffic statistics about interference bands as well as uplink and downlink balance
in these cells. The traffic statistics are normal.
4. Query the number of idle Abis timeslots in problem cells. The idle Abis timeslots in these
cells are insufficient. After more idle Abis timeslots are added, the percentage of high-rate
coding schemes to all coding schemes in these cells returns to normal.
GBSS14.0
226
8.7 Troubleshooting High RLC Data Block Retransmission
Rates
This section describes how to troubleshoot high radio link control (RLC) data block
retransmission rates.
Symptom
The RLC data block retransmission rate indicates data transmission performance. If the RLC
data block retransmission rate is high or the percentage of high-rate coding schemes to all coding
schemes is low during web browsing, web pages open slowly or even fail to open.
The RLC data block retransmission rate is the ratio of the number of retransmitted RLC data
blocks to the total number of RLC data blocks. This rate is closely related to the percentage of
high-rate coding schemes to all coding schemes. If the percentage of high-rate coding schemes
to all coding schemes increases, this rate may increase accordingly. Therefore, it is recommended
that these two KPIs be compromised. High RLC data block retransmission rates are also caused
by:
Poor Um interface quality may lead to incorrect RLC data blocks received by MSs. In this
case, the number of RLC data retransmissions increases.
Poor Um interface quality may also lead to an automatic switchover to the LA mode, in
which data blocks are segmented and retransmitted. In this case, the percentage of high-
rate coding schemes to all coding schemes decreases.
l High frame error rates for Abis transmission, which may lead to loss and retransmission of
data blocks, decreasing the percentage of high-rate coding schemes to all coding schemes.
l Abnormally-released unacknowledged data blocks counted into the total number of data
blocks
Location Procedure
Figure 8-6 shows the procedure for locating high RLC data block retransmission rates.
GBSS14.0
227
Figure 8-6 Procedure for locating high RLC data block retransmission rates

NOTE
under an MSC).

GBSS14.0
228
2 Operations
before and after
the fault occurs

3 Faulty NE
version
For details
about how
to obtain
the BSC
and BTS
software
versions
that are
used when
the
problem
occurs,
see 15
Appendix
: How to
Collect
Fault
Informati
on.
4 Configuration
data script
fault occurs.
For details
about how
to obtain
the
configurat
ion data
script, see
15
Appendix
: How to
Collect
Fault
Informati
on.
GBSS14.0
229
5 Original traffic
statistics
deteriorate.
For details
about how
to obtain
the
original
traffic
statistics,
see 15
Appendix
: How to
Collect
Fault
Informati
on.
deteriorate.
For details
about how
to obtain
the GPSR
logs, see
15
Appendix
: How to
Collect
Fault
Informati
on.
7 Common
debugging logs
For details
about how
to obtain
the
common
debugging
logs, see
15
Appendix
: How to
Collect
Fault
Informati
on.
GBSS14.0
230
For details
about how
to obtain
the
operation
logs, see
15
Appendix
: How to
Collect
Fault
Informati
on.
9 Faulty
signaling
deteriorate.
For details
about how
to obtain
the faulty
signaling,
see 15
Appendix
: How to
Collect
Fault
Informati
on.

1. Check whether any cells meet the standard for high RLC data block retransmission rates.
l If yes, select the top N cells with higher RLC data block retransmission rates. The
following operations should only be performed on the top N cells.
l If the EGPRS retransmission rate is high, run the MML command LST
Uplink Fixed MCS Type: The recommended value is UNFIXED.
Downlink Fixed MCS Type: The recommended value is UNFIXED.
Uplink Default MCS Type: The recommended value is MCS2. If the uplink
EGPRS retransmission rate is high, decrease the value for this parameter.
Downlink Default MCS Type: The recommended value is MCS6. If the downlink
EGPRS retransmission rate is high, decrease the value for this parameter.
If the parameters are not set to the recommended values, run the MML command SET
GCELLEGPRSPARA to set the parameters to the recommended values.
l If the GPRS retransmission rate is high, run the MML command LST GCELLPSCS
to check the values for the following parameters:
GBSS14.0
231
Uplink Default CS Type: Check whether this parameter is set to CS1.
Downlink Default CS Type: Check whether this parameter is set to CS2. If the
downlink GPRS retransmission rate is high, decrease the value for this parameter.
l Run the MML command LST GCELLPSPWPARA to check the values for the
following parameters:
ALPHA: Check whether this parameter is set to 0.6.
GAMMA: Check whether this parameter is set to 12.
GCELLPSPWPARA to change the settings.
3. For the top N cells with higher RLC data block retransmission rates, check whether the
value for RL9A08:Rate of Transmitted Error Frames is larger than 1%. If yes, bit errors
have occurred during Abis transmission. In this case, contact transmission engineers.
4. Poor Um interface quality may lead to a low BEP. Poor Um interface quality may be caused
by co-channel or adjacent-channel interference, frequency collision due to frequency
hopping (FH), or uplink and downlink imbalance. As a result, high-rate coding schemes
cannot be used. In this case, optimize the frequency planning, FH parameter settings, power
control parameter settings, and transmit power settings. For details, see 5.3
Troubleshooting Call Drops Due to Poor Um Interface Quality.
5. Check whether there are a large number of abnormal temporary block flow (TBF) releases.
If yes, see 8.4 Troubleshooting High TBF Call Drop Rates.
Typical Case
Symptom
The uplink retransmission rate at a site increased noticeably at 21:00 on January 2 and 13, 2011.
Cause Analysis
According to the traffic statistics, severe interference occurred in the cells with high uplink
retransmission rates at 21:00. All problem cells are P-GSM900 cells.
1. Check whether the parameters for the cells with high RLC data block retransmission rates
are set to recommended values. The parameter settings are correct.
all lower than 1.
3. Analyze the traffic statistics.
The uplink RLC data block retransmission rate and the percentage of interference bands 4
and 5 were high at 21:00 but normal at 20:00 and 22:00.
4. Locate the interference source.
Dot the cells with severe interference on the map. The problem cells are located at county
boundaries.
GBSS14.0
232
5. Optimize the network. The Um interface quality becomes satisfactory and the
retransmission rate problem is resolved.
GBSS14.0
233
9 PS Channel Faults
About This Chapter
This chapter describes how to locate and troubleshoot PS channel faults.
9.1 Identifying PS Channel Faults
This section describes how to identify PS channel faults. You can identify PS channel faults by
monitoring the PS channel status on the LMT or querying the PS channel status using an MML
command.
9.2 Locating PS Channel Faults
This section describes how to locate PS channel faults.
9.3 Troubleshooting PDCH Faults Due to Channel Inactivity
This section describes how to troubleshoot packet data channel (PDCH) faults due to channel
inactivity.
9.4 Troubleshooting PDCH Faults Due to Channel Asynchronization
asynchronization.
GBSS14.0
Troubleshooting Guide 9 PS Channel Faults
234
9.1 Identifying PS Channel Faults
This section describes how to identify PS channel faults. You can identify PS channel faults by
monitoring the PS channel status on the LMT or querying the PS channel status using an MML
command.
Monitoring the PS Channel Status on the LMT
For details, see Monitoring Channel Status.
Querying the PS Channel Status Using an MML Command
Run the MML command DSP PDCH to query the PS channel status of a cell. The PS channels
whose Channel Operation State is Unavailable are faulty.
9.2 Locating PS Channel Faults
This section describes how to locate PS channel faults.
Principles
If the packet data channels (PDCHs) of all cells under a BTS are faulty, check whether the
transmission and operating status of the BTS are normal. If the PDCHs of some cells under
different BTSs are faulty, check whether these cells are assigned to the same digital signal
processor (DSP). If only certain PDCHs are faulty, refer to Troubleshooting PDCH Faults
Due to Channel Inactivity or Troubleshooting PDCH Faults Due to Channel
Asynchronization.
Location Procedure
Figure 9-1 shows the procedure for locating PS channel faults.
GBSS14.0
235
Figure 9-1 Procedure for locating PS channel faults

The procedure for locating PS channel faults is as follows:
1. Determine the fault range. If the PDCHs of all cells under a BTS are faulty, check whether
the transmission and operating status of the BTS and its carriers are normal. If the
GBSS14.0
236
transmission and operating status of the BTS and its carriers are normal but the faults persist,
go to Step 2.
2. Run the DSP PSCELL command to check whether the cells whose PDCHs are faulty are
assigned to the same DSP based on the values of Subrack No., Slot No., and DSP No. in
the command output. If yes, run the SET PSCELLTODSP command to assign these cells
to DSPs carrying light load. If the faults persist, go to Step 3.
CAUTION
Assign the problem cells to different DSPs to ensure that the number of activated channels
on one DSP does not exceed the upper threshold.
3. PS channel faults are generally due to either channel inactivity or channel asynchronization.
For details about how to rectify these faults, see Troubleshooting PDCH Faults Due to
Channel Inactivity and Troubleshooting PDCH Faults Due to Channel
Asynchronization. If the faults persist, go to Step 4
4. Perform Performing a PDCH Loopback Test and rectify the fault that is identified based
on the detection result. If the fault persists, Contact Huawei Customer Service Center.
9.3 Troubleshooting PDCH Faults Due to Channel
Inactivity
inactivity.
Symptom
When monitoring the channel status is enabled on the LMT, the icon under a PDTCH of a cell
is red. When you click on the red icon, detailed information about the channel status is displayed.
If both Applied Bandwidth and Available Bandwidth are 0K as shown in Figure 9-2, the
channel is not activated.
Figure 9-2 Monitor Channel Status tab page

GBSS14.0
237
The most common causes for PDCH faults due to channel inactivity are as follows:
l Cell Um Administration State is Blocked.
l PS cells have not been assigned to a digital signal processor (DSP) and therefore do not
work properly.
l The number of activated channels on the DSP where the cells work has reached the upper
threshold.
l The low voltage differential signal (LVDS) timeslots on the DSP where the cells work are
insufficient.
NOTE
One DPUd is configured with 22 DSPs, where 21 DSPs are configured with 192 LVDS timeslots
each and one DSP is configured with 48 LVDS timeslots. Therefore, you need to query the DSP link
status to determine whether the LVDS timeslots on a DSP are sufficient.
One DPUg supports a maximum of 1024 PDCHs using the coding scheme MCS9. One DPUg is
configured with 14 DSPs, and 64 to 110 PDCHs using the coding scheme MCS9 can be activated on
one DSP. Therefore, you need to run the MML command DSP PDCHNUM to check whether the
number of PDCHs that have been activated on the DSPs for one DPUg reaches the upper limit 1024.
If the number of activated PDCHs reaches 1024, expand the DPUg capacity.
The method for determining which DSP has the lightest load is as follows:
l Run the MML command DSP DSPLINK to query the status of the LVDS timeslots.
l Calculate the number of LVDS timeslots whose Loop State is No Loopback, Allocate
State is Normal and Not Assigned, and Sync State is Synchronized for each DSP. The
DSP with the greatest number of LVDS timeslots with these parameter settings has the
lightest load.
Location Procedure
Figure 9-3 shows the procedure for locating PDCH faults due to channel inactivity.
GBSS14.0
238
Figure 9-3 Procedure for locating PDCH faults due to channel inactivity

NOTE
support.
GBSS14.0
239
Table 9-1 Location information about PDCH faults due to channel inactivity
under an MSC).

2 Operations
before and after
the fault occurs

3 Faulty NE
version
used when the fault occurs.
For details
about how
to obtain
the BSC
and BTS
software
versions
that are
used when
the fault
occurs,
see 15
Appendix
: How to
Collect
Fault
Informati
on.
4 Configuration
data script
fault occurs.
For details
about how
to obtain
the
configurat
ion data
script used
when the
fault
occurs,
see 15
Appendix
: How to
Collect
Fault
Informati
on.
GBSS14.0
240
5 Original traffic
statistics
deteriorate.
For details
about how
to obtain
the
original
traffic
statistics
measured
within
three days
before and
after
counters
deteriorat
e, see 15
Appendix
: How to
Collect
Fault
Informati
on.
6 Common
debugging logs
For details
about how
to obtain
the
common
debugging
logs
generated
within one
peak hour
in one day
before and
after
counters
deteriorat
e, see 15
Appendix
: How to
Collect
Fault
Informati
on.
GBSS14.0
241
For details
about how
to obtain
the
operation
logs
generated
within
three days
before and
after
counters
deteriorat
e, see 15
Appendix
: How to
Collect
Fault
Informati
on.
8 Faulty
signaling
Obtain PS messages on the Abis interface in a faulty
cell traced within 10 minutes.
For details
about how
to obtain
PS
messages
on the
Abis
interface
in a faulty
cell traced
within 10
minutes,
see 15
Appendix
: How to
Collect
Fault
Informati
on.
GBSS14.0
242
9 PS cell
distribution
Obtain the information about PS cell distribution
under one BSC.
For details
about how
to obtain
the
informatio
n about PS
cell
distributio
n under
one BSC,
see 15
Appendix
: How to
Collect
Fault
Informati
on.
10 Channel status Query the status of the BTS channels used when the
fault occurs.
For details
about how
to query
the status
of the BTS
channels
used when
the fault
occurs,
see 15
Appendix
: How to
Collect
Fault
Informati
on.
11 PDCH
loopback result
Save the PDCH loopback result when a PDCH
loopback test starts.
For details
about how
to obtain
the PDCH
loopback
result, see
3.5.2
Performi
ng a
PDCH
Loopbac
k Test.

GBSS14.0
243
1. Run the MML command DSP PSCELL to query whether the cells whose PDCHs are faulty
are properly assigned to a DSP. If Subrack No., Slot No., and DSP No. are all 255 in the
command output, these cells are not properly assigned to a DSP. Run the MML command
SET PSCELLTODSP to assign these cells to a DSP with a light load.
2. Run the MML command DSP PSCELL to check whether Cell Um Administration
State is Blocked. If yes, refer to ALM-21801 GSM Cell out of Service.
3. Check whether the number of activated channels on the DSP has reached the upper
threshold. If yes, run the MML command SET PSCELLTODSP to assign the cells whose
PDCHs are faulty to a DSP with a light load.
NOTE
To check whether the number of activated channels on a DSP has reached the upper threshold,
perform the following steps:
1. Run the MML command DSP PSCELL to query Subrack No., Slot No., and DSP No. of the
cells whose PDCHs are faulty.
2. Run the MML command DSP PDCHNUM to check whether Number of Active Channels of
the DSP serving the cells reaches the upper limit. A maximum of 48 PDCHs can be activated on
one DSP for the DPUd, and a maximum of 110 PDCHs can be activated on one DSP for the
DPUg.
4. If one DSP for the DPUd is configured with 48 LVDS timeslots, the LVDS timeslots on
the DSP are sufficient. To determine whether the LVDS timeslots on a DSP are insufficient,
perform the following steps:
a. Run the MML command DSP PSCELL to query Subrack No., Slot No., and DSP
No. of the cells whose PDCHs are faulty.
b. Run the MML command DSP DSPLINK. If the DSP is configured with 48 LVDS
links and the DSP does not have an LVDS timeslot whose Allocate State is Normal
and Not Assigned, the LVDS timeslots on the DSP are insufficient.
c. Run the MML command SET PSCELLTODSP to assign the cells whose PDCHs
are faulty to a DSP with a light load.
5. If the Abis interface uses TDM transmission, perform a PDCH loopback test and rectify
the fault that is identified based on the loopback result. For details, see 3.5.2 Performing
a PDCH Loopback Test. If the Abis interface does not use TDM transmission, perform
6.
6. If the faults persist, Contact Huawei Customer Service Center.
Typical Case
Symptom
Some PDCHs of a cell at a site are faulty.
Cause Analysis
The number of activated channels on the DSP has reached the upper threshold.
1. Query the cell status. The cell is normal.
2. Check the channel status. Applied Bandwidth and Available Bandwidth are both 0K.
3. Query the DSP where the cell works and the number of static channels on the DSP. The
number of static channels on the DSP exceeds 48.
GBSS14.0
244
4. Manually assign the cell to a DSP with a light load. The channels of the cell are activated
and the PDCH faults are rectified.
9.4 Troubleshooting PDCH Faults Due to Channel
Asynchronization
asynchronization.
Symptom
The query result for the channel status on the LMT is normal. If you refresh the query result,
you may find that some faulty PDCHs sometimes automatically correct themselves. When PS
services are being processed, uploading and downloading data may be interrupted and some
ping packets may be lost. If a PDCH is faulty, detailed information about the channel status is
displayed when you click the red icon under the PDCH. If Applied Bandwidth is inconsistent
with Available Bandwidth as shown in Figure 9-4, the PDCH fault is caused by channel
asynchronization.
Figure 9-4 Monitor Channel Status tab page

l Common causes of channel asynchronization are as follows:
The clock on the GCUa or GCGa is unlocked.
The frame error rate (FER) is high.
The BTS version is not the latest one and has defects.
l To check whether the DTMU clock synchronizes with the BSC clock and to lock the BSC
clock, perform the following steps:
1. On the LMT, choose Device Maintenance > BSC Maintenance > Query BSC Board
ClockStatus, as shown in Figure 9-5.
If Phase-locked loop state of clock source is Lock, the DTMU clock synchronizes
with the BSC clock.
GBSS14.0
245
Figure 9-5 Querying the status of the BSC clock

2. If the DTMU clock does not synchronize with the BSC clock, check historical and
active alarms for clock alarms. If there is a clock alarm, clear it by referring to the
alarm help.
The clock alarms are as follows:
ALM-20204 Clock Signal Inputs Faulty
ALM-20209 Faulty Phase-Locked Loop of the Board Clock
ALM-20208 Clock Reference Source of Main Control Board Unavailable
ALM-20207 Failure in Locking System Clock Source
ALM-20206 Current System Clock Reference Source Status Abnormal
3. On the LMT, choose Device Maintenance > BSC Maintenance > Query BSC Board
Clock Status and select a BTS to query the DTMU clock status, as shown in Figure
9-6.
If Clock Status is Locked, the BSC clock is locked.
Figure 9-6 Querying the status of the DTMU clock

4. If the BSC clock is not locked, run the MML command SET BTSCLKPARA to set
Clock Mode to BSCCLK(Trace BSC Clock).
GBSS14.0
246
5. If the BSC clock cannot be locked for a long time (for example, one day), replace the
DTMU.
Location Procedure
Figure 9-7 shows the procedure for locating PDCH faults due to channel asynchronization.
Figure 9-7 Procedure for locating PDCH faults due to channel asynchronization

NOTE
support.
GBSS14.0
247
Table 9-2 Location information about PDCH faults due to channel asynchronization
under an MSC).

2 Operations
before and after
the fault occurs

3 Faulty NE
version
For details
about how
to obtain
the BSC
and BTS
software
versions
that are
used when
the fault
occurs,
see 15
Appendix
: How to
Collect
Fault
Informati
on.
4 Configuration
data script
fault occurs.
For details
about how
to obtain
the
configurat
ion data
script used
when the
fault
occurs,
see 15
Appendix
: How to
Collect
Fault
Informati
on.
GBSS14.0
248
5 Original traffic
statistics
deteriorate.
For details
about how
to obtain
the
original
traffic
statistics
measured
within
three days
before and
after
counters
deteriorat
e, see 15
Appendix
: How to
Collect
Fault
Informati
on.
6 Common
debugging logs
For details
about how
to obtain
the
common
debugging
logs
generated
within one
peak hour
in one day
before and
after
counters
deteriorat
e, see 15
Appendix
: How to
Collect
Fault
Informati
on.
GBSS14.0
249
For details
about how
to obtain
the
operation
logs
generated
within
three days
before and
after
counters
deteriorat
e, see 15
Appendix
: How to
Collect
Fault
Informati
on.
8 Faulty
signaling
Obtain PS messages on the Abis interface in a faulty
For details
about how
to obtain
PS
messages
on the
Abis
interface
in a faulty
cell traced
within 10
minutes,
see 15
Appendix
: How to
Collect
Fault
Informati
on.
GBSS14.0
250
9 PS cell
distribution
Obtain the information about PS cell distribution
under one BSC.
For details
about how
to obtain
the
informatio
n about PS
cell
distributio
n under
one BSC,
see 15
Appendix
: How to
Collect
Fault
Informati
on.
10 Channel status Query the status of the BTS channels used when the
fault occurs.
For details
about how
to query
the status
of the BTS
channels
used when
the fault
occurs,
see 15
Appendix
: How to
Collect
Fault
Informati
on.
11 PDCH
loopback result
Save the PDCH loopback result when a PDCH
loopback test starts.
For details
about how
to obtain
the PDCH
loopback
result, see
3.5.2
Performi
ng a
PDCH
Loopbac
k Test.

GBSS14.0
251
1. Check whether the BTS version is the latest one. If no, upgrade the BTS to the latest version.
If the faults persist, go to Step 2.
2. Query traffic statistics by referring to RL9A08:Rate of Transmitted Error Frames. If the
frame error rate (FER) is higher than 1%, troubleshoot transmission faults. If the PDCH
faults persist, go to Step 3.
3. Check whether the DTMU clock synchronizes with the BSC clock by referring to
Background Information. If yes, go to Step 4. If no, lock the BSC clock according to the
instructions in Background Information. If the faults persist, go to Step 4.
4. Check whether the Abis interface uses TDM transmission. If the Abis interface uses TDM
transmission, perform a PDCH loopback test and rectify the fault that is identified based
on the loopback result. For details, see 3.5.2 Performing a PDCH Loopback Test. If the
Abis interface does not use TDM transmission, perform Step 5.
5. If the PDCH faults persist, Contact Huawei Customer Service Center.
Typical Case
Symptom
According to the channel status on the LMT at a site, some PDCHs are faulty. After the query
result is refreshed, the channel status returns to normal.
Cause Analysis
The E1 cables are faulty.
1. Check the BTS version at the site. The BTS version is not one of the BTS versions that
have asynchronization problems.
2. Query traffic statistics. The FER over the Abis interface is high and the LAPD Link Interrupt
Alarm is reported.
3. Troubleshoot transmission faults and replace the E1 cables. The PDCH faults are rectified.
GBSS14.0
252
10 Cell PS Service Faults
About This Chapter
This chapter describes how to locate and troubleshoot cell PS service faults.
10.1 Remarks on Cell PS Service Faults
In this chapter, cell PS service faults refer to failures to provide PS services for all subscribers
in a cell. If a cell fails to provide PS services for some subscribers, the MSs used by these
subscribers are probably incompatible with the network. Cell PS service faults of this type can
be rectified with tracing signaling and are not discussed in this document.
10.2 Locating Cell PS Service Faults
This section describes how to locate cell PS service faults.
10.3 Troubleshooting Cell PS Service Faults Due to Gb Interface Issues
This section describes how to troubleshoot cell PS service faults due to Gb interface issues.
10.4 Troubleshooting Cell PS Service Faults Due to Incorrect Data Configurations
This section describes how to troubleshoot cell PS service faults due to incorrect data
configurations.
10.5 Troubleshooting Cell PS Service Faults Due to Hardware Issues
This section describes how to troubleshoot cell PS service faults due to hardware issues.
10.6 Troubleshooting Cell PS Service Faults Due to Incorrect Cable Connections Inside the BSC
This section describes how to troubleshoot cell PS service faults due to incorrect cable
connections inside the BSC.
GBSS14.0
Troubleshooting Guide 10 Cell PS Service Faults
253
10.1 Remarks on Cell PS Service Faults
In this chapter, cell PS service faults refer to failures to provide PS services for all subscribers
in a cell. If a cell fails to provide PS services for some subscribers, the MSs used by these
subscribers are probably incompatible with the network. Cell PS service faults of this type can
be rectified with tracing signaling and are not discussed in this document.
PS services are mobile packet data services developed on the basis of the GSM mobile
communications system. Packet switched entities are added to the GSM mobile communications
system to implement data transmission in packet mode, enabling subscribers to access the
Internet or other packet data networks by using mobile terminals that support packet data
services.
Cells require the following resources to perform PS services: transmission resources, packet data
channels (PDCHs), digital signal processors (DSPs), and Gb interface resources. Cell PS services
will fail if any of these resources are unavailable or insufficient.
10.2 Locating Cell PS Service Faults
This section describes how to locate cell PS service faults.
Principles
Signaling tracing is commonly used to locate cell PS service faults. With tracing signaling, you
can locate the points where cell PS services are congested. Before tracing signaling, you can
troubleshoot the following problems or faults to locate cell PS service faults:
1. Gb interface faults
2. Incorrect data configurations
3. Hardware faults
4. Incorrect cable connections inside the BSC
Figure 10-1 shows the mapping between symptoms and causes of cell PS service faults.
GBSS14.0
254
Figure 10-1 Mapping between symptoms and causes of cell PS service faults

Location Procedure
Figure 10-2 shows the procedure for locating cell PS service faults.
GBSS14.0
255
Figure 10-2 Procedure for locating cell PS service faults

NOTE
support.
Table 10-1 Location information about cell PS service faults
fault occurs in a cell, a BTS, a BSC, or all BSCs under
an MSC).

GBSS14.0
256
2 Operations
before and
after the
fault occurs
modification.

3 Faulty NE
version
For details
about how
to obtain
the BSC
and BTS
software
versions
that are
used when
the fault
occurs, see
15
Appendix
: How to
Collect
Fault
Informati
on.
4 Configurati
on data
script
fault occurs.
For details
about how
to obtain
the
configurat
ion data
script used
when the
fault
occurs, see
15
Appendix
: How to
Collect
Fault
Informati
on.
GBSS14.0
257
5 Operation
logs
Obtain the operation logs generated from one week
before the fault occurs till now.
For details
about how
to obtain
the
operation
logs
generated
from one
week
before the
fault
occurs till
now, see
15
Appendix
: How to
Collect
Fault
Informati
on.
6 Historical
alarms
Obtain the historical alarms generated within two
days before the fault occurs till now.
For details
about how
to obtain
the
historical
alarms
generated
within two
days
before the
fault
occurs till
now, see
15
Appendix
: How to
Collect
Fault
Informati
on.
GBSS14.0
258
7 Common
debugging
logs
Obtain the common debugging logs generated two
hours before and after the fault occurs.
For details
about how
to obtain
the
common
debugging
logs
generated
two hours
before and
after the
fault
occurs, see
15
Appendix
: How to
Collect
Fault
Informati
on.
8 Faulty
signaling
Obtain PS messages on the Um interface as well as
PTP and SIG messages on the Gb interface in a faulty
For details
about how
to obtain
PS
messages
on the Um
interface
as well as
PTP and
SIG
messages
on the Gb
interface
in a faulty
cell traced
within 10
minutes,
see 15
Appendix
: How to
Collect
Fault
Informati
on.
9 MML
command
output
Run the following MML commands and view the
command output.
DSP PSCELL: IDXTYPE=BYBSC;
DSP LINKBTNUTNU:;

GBSS14.0
259
10 Original
traffic
statistics
Obtain the 60-minute original traffic statistics
measured within two days before and after the fault
occurs.
For details
about how
to obtain
the 60-
minute
original
traffic
statistics
measured
within two
days
before and
after the
fault
occurs, see
15
Appendix
: How to
Collect
Fault
Informati
on.

10.3 Troubleshooting Cell PS Service Faults Due to Gb
Interface Issues
This section describes how to troubleshoot cell PS service faults due to Gb interface issues.
Symptom
Cells fail to provide PS services and Cell Gb Administration State is Blocked in the output of
the MML command DSP PSCELL.
Cell PS service faults are sometimes caused by the following issues with the Gb interface:
l The Gb interface is faulty and bearer channel (BC), network server virtual connection/link
(NSVC/NSVL), network service entity (NSE) fault alarms are reported.
l The Gb interface is normal but the SGSN does not respond to some GPRS mobility
management (GMM) signaling.
Location Procedure
Figure 10-3 shows the procedure for locating PS service faults due to Gb interface issues.
GBSS14.0
260
Figure 10-3 Procedure for locating cell PS service faults due to Gb interface issues

1. Run the MML command DSP PSCELL. If Cell Gb Administration State is Blocked,
Cell Activation State is Active, Cell Operation State is Unblocked, and Cell Um
Administration State is Unblocked, the cell PS service faults are caused by Gb interface
issues.
2. Clear the following Gb interface alarms by referring to the alarm help:
l ALM-21385 Gb BC Failure
l ALM-22005 NSE Faulty
l ALM-22003 NSVC Disconnection
l ALM-22004 NSVL Faulty
l ALM-22009 NSVL Dynamic Configuration Procedure Failure
l ALM-22008 PTP BVC Faulty
3. If the faults persist after the Gb interface alarms are cleared, trace PTP message on the Gb
interface in faulty cells. If any of the following exceptions occur, contact SGSN
maintenance engineers for technical support.
l The BSC sends ATTACH REQUEST but does not receive ATTACH ACCEPT from
the SGSN.
l The BSC sends ATTACH REQUEST but receives ATTACH REJECT from the SGSN.
l The BSC sends ACTIVE PDP CONTEXT REQUEST but does not receive ACTIVE
PDP CONTEXT ACCEPT from the SGSN.
l The BSC sends ACTIVE PDP CONTEXT REQUEST but receives PDP REJECT from
the SGSN.
GBSS14.0
261
4. If the faults persist, check data configuration by referring to 10.4 Troubleshooting Cell
PS Service Faults Due to Incorrect Data Configurations.
Typical Case
Symptom
Some cells fail to provide PS services at a site.
Cause Analysis
The NSVC is interrupted because the data configuration on the BSC is inconsistent with that on
the SGSN.
1. Run the MML command DSP PSCELL. The Cell Gb Administration State in the
command output is Blocked.
2. Check for BC, NSVC, and NSE fault alarms on the BSC. The alarm ALM-22003 NSVC
Disconnection is reported.
3. Refer to the alarm help. The alarm is reported because the data configuration on the BSC
is inconsistent with that on the SGSN.
4. Modify the data configurations to ensure that the data configuration is consistent on both
the BSC and the SGSN. The NSVC interruption alarm is cleared.
5. Run the MML command DSP PSCELL. The Cell Gb Administration State in the
command output is Unblocked.
6. The faults are rectified.
10.4 Troubleshooting Cell PS Service Faults Due to Incorrect
Data Configurations
This section describes how to troubleshoot cell PS service faults due to incorrect data
configurations.
Symptom
All or some of the cells under a BSC fail to provide PS services.
In addition to the basic parameters for PS services, pay attention to the following configurations:
l Um Interface Tag, Abis Interface Tag, and A Interface Tag
l The mapping between IPPATH and TRMMAP in Abis over IP mode
Location Procedure
Figure 10-4 shows the procedure for locating cell PS service faults due to incorrect data
configurations.
GBSS14.0
262
Figure 10-4 Procedure for locating cell PS service faults due to incorrect data configurations

1. If all the cells under a BSC fail to provide PS services, run the MML command LST
BSCBASIC to check whether A Interface Tag, Um Interface Tag, and Abis Interface
Tag are all GSM_PHASE_2. If no, run the MML command SET BSCBASIC to modify
the parameter settings.
2. If some IP BTSs under a BSC fail to provide PS services, perform the following operations
to check whether the settings of IPPATH and TRMMAP are correct:
a. Run the MML command LST ADJNODE to query Adjacent Node ID.
b. Based on Adjacent Node ID, run the MML command LST IPPATH to query IP
path type for all IP paths. If no IP path type is QOS, go to Step c. Otherwise, go to
Step 3.
c. Run the MML command LST TRMMAP to query PS high PRI data path and PS
low PRI data path.
d. Check whether the query results of PS high PRI data path and PS low PRI data
path contain IP path type. If neither PS high PRI data path nor PS low PRI data
path contains IP path type, run the MML command ADD TRMMAP to add IP path
type.
3. If the cell PS service faults persist, refer to 10.5 Troubleshooting Cell PS Service Faults
Due to Hardware Issues.
Typical Case
Symptom
GBSS14.0
263
All the cells under a BSC fail to provide PS services.
Cause Analysis
The SI13 message cannot be delivered because the Um interface tag at the BSC level has been
modified. As a result, the PS services fail.
1. View the operation logs. GSM Phase has been modified. The records in the operation logs
are as follows:
Y2011M03D16H09N39S20], [ Y2011M03D16H09N39S21], [/*252862*/SET BSCBASIC:
AREACODE=1, CC=1, AVER=GSM_PHASE_1, UMVER=GSM_PHASE_1,
ABISVER=GSM_PHASE_1, SUPPORTTFOCODECOPTIMIZE=NO;], [Execution succeeded.]
2. Modify Um Interface Tag, Abis Interface Tag and A Interface Tag. The faults are
rectified.
10.5 Troubleshooting Cell PS Service Faults Due to
Hardware Issues
This section describes how to troubleshoot cell PS service faults due to hardware issues.
Symptom
Cells that fail to provide PS services are assigned to the same digital signal processor (DSP) and
board fault alarms are reported.
CS service faults caused by hardware issues are not discussed in this section. The following are
the hardware faults that affect PS services:
l DPUd faults
l Gb interface board faults
l DSP faults
Location Procedure
Figure 10-5 shows the procedure for locating cell PS service faults due to hardware issues.
GBSS14.0
264
Figure 10-5 Procedure for locating cell PS service faults due to hardware issues

1. Check whether the DPUd, FG2a, FG2c, and PEUa report any board fault alarms such as
ALM-20241 Board Unavailable, ALM-20242 Board Subsystem Unavailable, and
ALM-20243 Board Hardware Fault. If yes, clear the alarms by referring to the alarm help.
2. If no, run the MML command DSP PSCELL to check whether PS services fail in other
cells assigned to the same DSP as the problem cell. If the following conditions are met, the
DSP is faulty: 1) All the cells assigned to the DSP fail to provide PS services; 2) After these
cells are assigned to other DSPs by running the MML command SET PSCELLTODSP,
the cells can provide PS services properly.
3. Run the MML command INH DSP to disable the faulty DSP. If multiple DSPs are faulty,
replace the DPUd to reduce the impact on the services of other cells.
4. If the faults persist, refer to 10.6 Troubleshooting Cell PS Service Faults Due to Incorrect
Cable Connections Inside the BSC.
Typical Case
Symptom
Cause Analysis
DSP 10 in slot 8 of subrack 0 is faulty.
GBSS14.0
265
1. View the alarm logs. No board alarms are reported.
2. Run the MML command DSP PSCELL. All problem cells are assigned to DSP 10 in slot
8 of subrack 0 and all cells assigned to that DSP fail to provide PS services.
3. Run the MML command SET PSCELLTODSP to assign all problem cells to other DSPs.
These cells can provide PS services again. If these cells are reassigned to DSP 10 in slot 8
of subrack 0, they fail to provide PS services again. Therefore, DSP 10 in slot 8 of subrack
0 is faulty.
4. Run the MML command INH DSP to disable the faulty DSP because there is no spare
DPUd at the site. The faults are rectified.
10.6 Troubleshooting Cell PS Service Faults Due to Incorrect
Cable Connections Inside the BSC
This section describes how to troubleshoot cell PS service faults due to incorrect cable
Symptom
Some cells fail to provide PS services.
The Abis interface board and the DPUd board serving the same cell may be installed in different
subracks because DPUb boards work as a resource pool. If cable connections between subracks
are abnormal, some cells fail to provide PS services.
Location Procedure
Figure 10-6 shows the procedure for locating cell PS service faults due to incorrect cable
Figure 10-6 Procedure for locating cell PS service faults due to incorrect cable connections
inside the BSC
GBSS14.0
266

1. Run the MML command DSP LINKBTNUTNU to check whether Link Status is
Normal. If no, check that the cables between subracks are connected correctly and securely.
If Link Status is Normal, go to Step 2.
2. Run the MML command DSP PSCELL to query Subrack No. of the subrack that serves
the problem cells. All the problem cells are assigned to a DSP on the subrack. Run the
MML command LST GTRX to query Out-BSC Subrack No., which specifies the number
of the subrack accommodating the Abis interface board. Check whether the values of
Subrack No. and Out-BSC Subrack No. are the same. If no, run the MML command
SET PSCELLTODSP to assign the problem cells to the DSP on the subrack
accommodating the Abis interface board. If the subrack numbers are the same but PS
services still fail, Contact Huawei Customer Service Center.
Typical Case
Symptom
Cause Analysis
The cable connection between port 0 in slot 5 of subrack 0 and port 0 in slot 4 of subrack 1 is
abnormal.
1. Analyze the Abis interface board and service board serving the problem cells. The Abis
interface board is in subrack 1 and the service board is in subrack 0.
2. Run the MML command DSP LINKBTNUTNU to check the cable connections between
subrack 1 and subrack 0. The cable connection between port 0 in slot 5 of subrack 0 and
port 0 in slot 4 of subrack 1 is abnormal.
3. Troubleshoot the cable connection faults in the equipment room. The cable to port 0 in slot
5 of subrack 0 is loose.
4. Tighten the cable. The cable connections between subrack 1 and subrack 0 return to normal
and the faults are rectified.
GBSS14.0
267
11 IP Transmission Faults
About This Chapter
This chapter describes how to locate and troubleshoot IP transmission faults.
11.1 Troubleshooting FE/GE Transmission Faults
This section describes how to troubleshoot fast Ethernet or gigabit Ethernet (FE/GE)
11.2 Troubleshooting IP Layer Faults
This section describes how to troubleshoot IP layer faults.
11.3 Troubleshooting PPP or MLPPP Link Faults
This section describes how to troubleshoot Point-to-Point Protocol (PPP) or Multi-Link Point-
to-Point Protocol (MLPPP) link faults.
11.4 Troubleshooting LAPD Link Faults
This section describes how to troubleshoot Link Access Protocol on the D channel (LAPD) link
faults.
11.5 Troubleshooting SCTP Link Faults
This section describes how to troubleshoot Stream Control Transmission Protocol (SCTP) link
faults.
11.6 Troubleshooting IP Path Problems
This section describes how to troubleshoot IP path problems.
11.7 Troubleshooting DHCP Problems
This section describes how to troubleshoot Dynamic Host Configuration Protocol (DHCP)
problems.
11.8 Troubleshooting IP PM Activation Failures
This section describes how to troubleshoot IP performance monitor (IP PM) activation failures.
11.9 Troubleshooting IP Clock Faults
This section describes how to troubleshoot IP clock faults.
GBSS14.0
Troubleshooting Guide 11 IP Transmission Faults
268
11.1 Troubleshooting FE/GE Transmission Faults
This section describes how to troubleshoot fast Ethernet or gigabit Ethernet (FE/GE)
Symptom
l When FE/GE transmission faults occur, packets may be lost or no packets may be received
by the RX end, and the alarms in Table 11-1 may be reported.
Table 11-1 Alarms related to FE/GE transmission faults
Alarm ID Alarm Name
21345 ALM-21345 Ethernet Link Fault
21346 ALM-21346 IP Connectivity Check
Failure
21347 ALM-21347 IP Address Conflict
21351 ALM-21351 IP Excessive Frame Error
Rate

l When FE/GE transmission faults occur, the query result of the MML command DSP
ETHPORT shows that Link Availability Status is Unavailable.
l There are two types of FE/GE transmission faults:
Physical layer faults
The faults at the physical layer are generally caused by hardware faults. For example,
an Ethernet cable is faulty or Ethernet ports on two interconnected devices are faulty.
Data link layer faults
The faults at the data link layer are generally caused by incorrect VLAN IDs or transport
network interruption.
l Port interworking parameters
The port interworking parameters are ETHPORT SPEED and Auto negotiation. Their
respective settings for both interconnected ports must be consistent based on negotiation.
For example, ETHPORT SPEED for both interconnected ports must be set to either
100M or AUTO, and the settings of Duplex for both interconnected ports must also be
consistent. Table 11-2 lists the recommended values for the two parameters.
Table 11-2 Recommended values for the ETHPORT SPEED and Duplex parameters
ETHPORT SPEED Duplex
Recommended value 1 FE port: 100M; GE port:
1000M
FULL
GBSS14.0
269
ETHPORT SPEED Duplex
Recommended value 2 FE port: 100M; GE port:
1000M
AUTO
Recommended value 3 AUTO AUTO

Run the MML commands DSP ETHPORT and LST ETHPORT to check the settings of
the port interworking parameters. In Abis over IP mode, run the MML command LST
BTSETHPORT to check the settings of the parameters related to interworking between
the BTS and its peer port. Especially, check whether ETHPORT SPEED and Duplex are
consistent for the BTS and its peer port.
l Address Resolution Protocol (ARP)
The BSC and BTS have the same procedure for processing data packets. The BSC or BTS
first queries the next-hop media access control (MAC) address according to the mapping
between the IP routing table and the ARP table, and then sends the ICMP, SCTP, or UDP
packets. If there is no corresponding ARP table, the BSC or BTS sends an ARP request to
query the next-hop MAC address or the peer IP address on the Layer 2 (L2) network. Figure
11-1 shows the procedure for sending an ARP request.
Figure 11-1 Procedure for sending an ARP request
NOTE
l An ARP request is a type of broadcast packet transmitted between two L2 communication nodes.
l On the L2 network, the BSC and BTS send each other ARP requests. On the Layer 3 (L3) network,
the BSC and BTS send ARP requests to their respective gateways.

Location Procedure
l Physical layer faults
Figure 11-2 shows the procedure for locating physical layer faults.
GBSS14.0
270
Figure 11-2 Procedure for locating physical layer faults

l Data link layer faults
Figure 11-3 shows the procedure for locating data link layer faults.
GBSS14.0
271
Figure 11-3 Procedure for locating data link layer faults

NOTE
support.
Table 11-3 Location information about FE/GE transmission faults
an MSC).

2 Operations
before and
after the
fault occurs
modification.

GBSS14.0
272
3 Faulty NE
version
For details
about how
to obtain
the BSC
and BTS
software
versions
that are
used when
the fault
occurs, see
15
Appendix
: How to
Collect
Fault
Informati
on.
4 FE/GE port
status
Run the MML command DSP ETHPORT and view
the command output.

5 Historical
alarms
days before and after the fault occurs.
For details
about how
to obtain
the
historical
alarms
generated
within
three days
before and
after the
fault
occurs, see
15
Appendix
: How to
Collect
Fault
Informati
on.
6 Ethernet
port
information
1. Run the MML commands LST ETHPORT and
LST BTSETHPORT and view the command
output.
2. Have the customer check the working mode of the
FE/GE port that is used to connect the transmission
equipment to the BSC.

GBSS14.0
273
7 Original
traffic
statistics
two days before and after the fault occurs.
For details
about how
to obtain
the
original
traffic
statistics
measured
within two
days
before and
after the
fault
occurs, see
15
Appendix
: How to
Collect
Fault
Informati
on.
8 BTS logs Obtain the BTS logs generated within two hours
before and after the fault occurs.
For details
about how
to obtain
the BTS
logs
generated
within two
hours
before and
after the
fault
occurs, see
15
Appendix
: How to
Collect
Fault
Informati
on.

l Physical layer faults
1. Check whether the Ethernet cable is normal. For example, the maximum transmission
distance of an Ethernet cable is 100 m. If the Ethernet cable is defective, replace it
and check whether the alarms related to FE/GE transmission faults are cleared. If an
optical fiber is used to connect two ports, check whether the optical modules in use
meet the specifications. For example, a 100 Mbit/s optical module is not applicable
GBSS14.0
274
to a 1000 Mbit/s port. Replace any optical modules that do not meet the specifications
and check whether the alarms related to FE/GE transmission faults are cleared. If the
alarms persist, go to Step 2.
2. Run the MML commands DSP ETHPORT and LST ETHPORT to check the
settings of the port interworking parameters. In Abis over IP mode, run the MML
command DSP BTSETHPORT to check the settings of the parameters related to
interworking between the BTS and its peer port. Especially, check whether
ETHPORT SPEED and Duplex are consistent for the BTS and its peer port. If the
settings are inconsistent, correct them and check whether the alarms related to FE/GE
transmission faults are cleared. If the alarms persist, go to Step 3.
3. Check whether the two interconnected ports are normal by using either of the
following fault isolation methods:
a. Connect a PC to the Ethernet port of the BSC or BTS and check whether the
physical layer faults are rectified.
b. Connect a PC to the peer device and check whether the PC indicator that shows
the Ethernet cable connection status is ON.
NOTE
If the alarms related to FE/GE transmission faults are cleared but the PC indicator is OFF, the
peer port is faulty.
If the alarms related to FE/GE transmission faults persist but the PC indicator is ON, errors
may have occurred on the BSC or BTS. If errors occurred on the BSC, switch over the IP
interface boards. If errors occurred on the BTS, replace the faulty interface board.
If the alarms related to FE/GE transmission faults are cleared and the PC can power on properly,
the port of the BSC or BTS and the peer ports are incompatible. Check whether the port
interworking parameter settings for the two interconnected ports are consistent. Correct any
inconsistent settings and check whether the alarms related to FE/GE transmission faults are
cleared.
4. If the alarms persist, Contact Huawei Customer Service Center.
l Data link layer faults
1. Run the MML command DSP ARP to check whether there is an ARP table
corresponding to the next-hop IP address. If there is, the connection between the BSC
and the peer device is normal. Check whether the connection between the peer device
and the next hop is normal. If the connection is not normal, go to Step 2.
2. Run the MML commands DSP ETHVLAN and DSP ETHPORT to query the
number of data packets received and sent on the BSC port twice at a 3s interval, and
record the query results. On the local maintenance terminal (LMT), ping the peer IP
address and run the MML command DSP ARP to check whether there is an ARP
table corresponding to the next-hop IP address. If there is no ARP table corresponding
to the next-hop IP address, the faults occur because the corresponding ARP table fails
to be generated. Run the MML commands DSP ETHVLAN and DSP ETHPORT
again to query the number of data packets received and sent on the BSC. Compare
this query result with the preceding query results to check whether the number of data
packets received and sent on the BSC port increased. If it increased, go to Step 3. If
not, go to Step 4.
3. Have the peer device maintenance engineers check whether VLAN ID has been set
on the BSC side.
If it has, check whether VLAN ID is correctly set. If the setting is incorrect, change
the parameter value and check whether the alarms related to FE/GE transmission
faults are cleared. If the alarms persist, go to Step 4.
GBSS14.0
275
If not, have the peer device maintenance engineers check whether the peer IP
address is set correctly. If the setting is incorrect, change the peer IP address to
ensure that the BSC can communicate with the peer device properly.
4. If the data link layer faults persist, Contact Huawei Customer Service Center.
Typical Case
Symptom
Ongoing services become abnormal after A over IP reconstruction.
Cause Analysis
l The data configurations may be incorrect.
l The FE/GE transmission may fail.
1. Query the data configurations. The data configurations are correct.
2. View the alarm information and check the Ethernet cable. The alarm ALM-21345 Ethernet
Link Fault was reported, but the Ethernet cable is functional.
3. Run the MML command DSP ETHPORT to query the status of the Ethernet port on the
BSC side. The query result shows that Duplex is set to Half and Auto negotiation is set
to Enable. Therefore, the working mode of the peer port may be configured in forcible
mode.
4. Query the status of the peer port. The result shows that Duplex is set to FULL and
ETHPORT SPEED is set to 100M. After Duplex is set to the same value for the two
interconnected ports, ongoing services return to normal.
11.2 Troubleshooting IP Layer Faults
This section describes how to troubleshoot IP layer faults.
Symptom
When the IP layer is faulty, the destination IP address cannot be pinged and the alarms in Table
11-4 may be reported.
Table 11-4 Alarms related to IP layer faults
Alarm ID Alarm Name
21345 ALM-21345 Ethernet Link Fault
21581 ALM-21581 Path Fault

l IP route
Each host or gateway has a routing table that specifies the routes to the destination IP
address. When sending a packet, a host, gateway, or router can obtain a route to the
destination IP address of this packet by checking the corresponding routing table.
GBSS14.0
276
A routing table consists of the destination IP address and the next-hop IP address.
In a routing table, routes are classified into the following types:
Default route: This route is automatically selected when other routes specified in a
routing table are unreachable.
Indirect route: The next hop of this route is a router.
Direct route: The next hop of this route is the destination host.
Location Procedure
Figure 11-4 shows the procedure for locating IP layer faults.
Figure 11-4 Procedure for locating IP layer faults

NOTE
support.
GBSS14.0
277
Table 11-5 Location information about IP layer faults
an MSC).

2 Operations
before and
after the
fault occurs
modification.

3 Faulty NE
version
For details
about how
to obtain
the BSC
and BTS
software
versions
that are
used when
the fault
occurs, see
15
Appendix
: How to
Collect
Fault
Informati
on.
1 Historical
alarms
For details
about how
to obtain
the
historical
alarms
generated
within
three days
before and
after the
fault
occurs, see
15
Appendix
: How to
Collect
Fault
Informati
on.
GBSS14.0
278
2 DSP ARP
command
output
1. Run the MML command DSP ARP and view the
command output.
2. Have transmission engineers check whether there
is a next-hop ARP table between two FE ports on
the BSC side.

3 Number of
packets sent
and received
on an
Ethernet
port
Run the MML commands DSP ETHVLAN and DSP
ETHPORT to query the number of packets sent and
received on an Ethernet port twice at a 3s interval, and
view the command output.

4 DSP IPRT
command
output
Run the MML command DSP IPRT and view the
command output.

5 LST IPRT
command
output
Run the MML command LST IPRT and view the
command output.

6 TRC
IPADDR
command
output
Run the MML command TRC IPADDR with the
original IP address set to the IP address of the FE/GE
port and view the command output.

7 PING IP
command
output
Run the MML command PING IP to ping the IP
address of the gateway on an interface board and view
the command output.
NOTE
Before running the PING IP command, contact the
engineers from the transmission network side to verify that
all devices in the transmission path are allowed to be pinged.
To ping the BTS IP address, run the LST BTSPINGSW
command to query whether the ping switch (turned on by
default) of the BTS is turned on. If the ping switch is not
turned on, run the SET BTSPINGSW command to turn on
the ping switch.

GBSS14.0
279
For details
about how
to obtain
the BTS
logs
generated
within two
hours
before and
after the
fault
occurs, see
15
Appendix
: How to
Collect
Fault
Informati
on.
9 Original
traffic
statistics
If the IP transmission over the Abis interface is
abnormal, run the MML command MOD IPPATH
to change IP path check type to ICMP(ICMP), wait
two hours, and obtain the original traffic statistics.
For details
about how
to obtain
the
original
traffic
statistics
in the
preceding
manner,
see 15
Appendix
: How to
Collect
Fault
Informati
on.

1. Run the MML command PING IP to check whether the destination IP address can be
pinged. If it cannot be pinged, go to Step 2.
NOTE
Before running the PING IP command, contact the engineers from the transmission network side to
verify that all devices in the transmission path are allowed to be pinged. To ping the BTS IP address,
run the LST BTSPINGSW command to query whether the ping switch (turned on by default) of the
BTS is turned on. If the ping switch is not turned on, run the SET BTSPINGSW command to turn
on the ping switch.
2. Run the MML commands DSP IPRT and LST IPRT to query the route information. If
there is no routing table corresponding to the destination IP address, manually configure a
GBSS14.0
280
route to the destination IP address and check whether the alarms related to IP layer faults
are cleared. If the alarms persist, go to Step 3.
3. Run the MML command DSP ARP to check whether there is an ARP table corresponding
to the destination IP address. If not, refer to Procedure for locating data link layer
faults in section 11.1 Troubleshooting FE/GE Transmission Faults. Then check whether
the alarms related to IP layer faults are cleared. If the alarms persist, go to Step 4.
4. Run the MML command TRC IPADDR to confirm how many hops are required for a
route from the source IP address to the destination IP address and to determine at which
hop the route is interrupted. In Abis over IP mode, perform an IP loopback test to check
whether any exceptions occur on the BSC side or on the Abis interface. For details about
how to perform an IP loopback test, see 3.2.4 Performing IP Loopback. Have the
transmission maintenance engineers resolve the problem and check whether the alarms
related to IP layer faults are cleared. If the alarms persist, go to Step 5.
5. Capture relevant packets and Contact Huawei Customer Service Center.
Typical Case
Symptom
Transmission links fail to be set up after the A over IP and signaling data configurations are
complete.
Cause Analysis
1. The BSC boards may be faulty.
2. The data configurations may be incorrect.
1. Query the data configurations and alarm information for the BSC boards. The data
configurations are complete and correct, and no boards report hardware alarms.
2. Have the MSC maintenance engineers check the port interworking parameters. The settings
of these parameters are correct.
3. Ping the IP address of the MSC on the BSC side. The IP address of the MSC cannot be
pinged.
4. Run the MML command TRC IPADDR to query the route information. A router is not
forwarding packets.
5. Determine that relevant routes are not configured on the router. After a route to the
destination IP address is configured, transmission links can be set up successfully.
11.3 Troubleshooting PPP or MLPPP Link Faults
This section describes how to troubleshoot Point-to-Point Protocol (PPP) or Multi-Link Point-
to-Point Protocol (MLPPP) link faults.
Symptom
l When a PPP or MLPPP link is faulty, the link status is abnormal and the alarms in Table
11-6 may be reported.
GBSS14.0
281
Table 11-6 Alarms related to PPP or MLPPP link faults
Alarm ID Alarm Name
11342 ALM-11342 PPP Link Excessive Frame
Error Rate
21343 ALM-21343 PPP/MLPPP Link Fault
21344 ALM-21344 MLPPP Group Failure

l When a PPP or MLPPP link is faulty, the query result of the MML command DSP
PPPLNK or DSP BTSPPPLNK shows that Link state is set to DOWN.
l PPP
PPP is a link layer protocol that supports point-to-point data transmission on full-duplex
synchronous and asynchronous links. It is located at Layer 2 of the IP protocol stack.
In the Huawei BSS system, the PPP technology is used for transmission on the Abis
interface in IP over E1 mode.
l MLPPP
MLPPP is an extensible protocol that supports binding multiple PPP links into a logical
channel, which helps to increase bandwidth. These PPP links belong to an MP group and
this logical channel is an MLPPP link.
In the Huawei BSS system, the MP technology is used for transmission on the Abis interface
in IP over E1 mode.
Location Procedure
Figure 11-5 shows the procedure for locating PPP or MLPPP link faults.
GBSS14.0
282
Figure 11-5 Procedure for locating PPP or MLPPP link faults

NOTE
support.
Table 11-7 PPP/MLPPP link fault location information
under an MSC).

2 Operations
before and
after the
problem
occurs
modification.

GBSS14.0
283
3 Faulty NE
version
For details
about how
to obtain
the BSC
and BTS
software
versions
that are
used when
the
problem
occurs, see
15
Appendix
: How to
Collect
Fault
Informati
on.
4 Historical
alarms
For details
about how
to obtain
the
historical
alarms,
see 15
Appendix
: How to
Collect
Fault
Informati
on.
5 PPP or
MLPPP link
status
Run the following commands and view the command
output: DSP PPPLNK, DSP MPGRP, DSP
MPLNK, DSP BTSPPPLNK, DSP BTSMPGRP,
and DSP BTSMPLNK.

6 Configurati
on data of
the PPP or
MLPPP link
Run the following commands and view the command
output: LST PPPLNK, LST MPGRP, LST
MPLNK, LST BTSPPPLNK, LST BTSMPGRP,
and LST BTSMPLNK.

GBSS14.0
284
7 Link
performance
monitoring
result
Obtain the PPP or MLPPP link performance
monitoring result within 10 minutes when the
problem occurs.
For details
about how
to obtain
the link
performan
ce
monitorin
g result,
see 15
Appendix
: How to
Collect
Fault
Informati
on.
8 Configurati
on data of
the PPP or
MLPPP link
on the
transmission
router
Obtain the configuration data script of the router.
For details
about how
to obtain
BTS logs,
see 15
Appendix
: How to
Collect
Fault
Informati
on.

1. Query the alarm information to check whether E1/T1 transmission is normal. If any of the
alarms listed in Table 11-8 are reported, clear them by referring to the BSC6900 GSM
Alarm Reference. If none of the alarms are reported, go to Step 2.
Table 11-8 Alarms related to E1/T1 transmission faults
Alarm ID Alarm Name
4714 ALM-4714 E1/T1 Local Alarm
4716 ALM-4716 E1/T1 Remote Alarm
GBSS14.0
285
Alarm ID Alarm Name
20201 ALM-20201 1PPS State Abnormal
20202 ALM-20202 Time Information Reception
Abnormal
20203 ALM-20203 Clock Signal Outputs Faulty
20204 ALM-20204 Clock Signal Inputs Faulty
20205 ALM-20205 System Clock Reference
Source Unavailable
20206 ALM-20206 Current System Clock
Reference Source Status Abnormal
20207 ALM-20207 Failure in Locking System
Clock Source
20208 ALM-20208 Clock Reference Source of
Main Control Board Unavailable
20209 ALM-20209 Faulty Phase-Locked Loop of
the Board Clock

2. Query data configurations for PPP or MLPPP links.
l Run the MML command LST PPPLNK or LST BTSPPPLNK to query data
configurations for PPP links.
l Run the MML command LST MPLNK or LST BTSMPLNK to query data
configurations for MLPPP links.
l If the BTS communicates with the BSC using a router, run the MML command LST
BTSPPPLNK or LST BTSMPLNK to query data configurations for PPP or MLPPP
links. Then, query the related PPP or MLPPP parameters on the router, such as the PPP
negotiation duration and check format.
If the data configurations are incorrect, correct them and check whether the alarms related
to PPP or MLPPP link faults are cleared. If the alarms persist, go to Step 3.
3. On the LMT, click Monitor. The Monitor tab page is displayed. In the Monitor
Navigation Tree pane, choose Monitor > Common Monitoring > Link Performance
Monitoring and select the PPP link or MLPPP link whose traffic can be monitored in real
time. Compare the traffic statistics measured at both ends of the PPP link or MLPPP link
to check whether any packets are lost during transmission. If any packets are lost, check
the transport network quality. If no packets are lost, go to Step 4.
4. If the PPP or MLPPP link faults persist, Contact Huawei Customer Service Center.
Typical Case
Symptom
The IP over E1 reconstruction based on the time division multiplexing (TDM) bearer network
fails, and therefore the BTS fails to start up.
Cause Analysis
GBSS14.0
286
In TDM transmission mode, the BTS communicates with the BSC directly and no router is used.
Therefore, the problem may be caused by incorrect BTS data configurations.
1. Query the BTS data configurations. The port number of the PPP link is not the actual number
of the physical port.
2. Change the port number and restart the BTS. The BTS starts up successfully.
11.4 Troubleshooting LAPD Link Faults
This section describes how to troubleshoot Link Access Protocol on the D channel (LAPD) link
faults.
Symptom
l When an extended signaling link (ESL) or operation and maintenance link (OML) is faulty,
the BTS software fails to be loaded. When a radio signaling link (RSL) is faulty, the TRX
software fails to be loaded. In addition, the alarms in Table 11-9 may be reported.
Table 11-9 Alarms related to LAPD link faults
Alarm ID Alarm Name
21511 ALM-21511 LAPD Link Congestion
21512 ALM-21512 LAPD Link Fault

l When LAPD link faults occur, the query result of the MML command DSP LAPDLNK
shows that UsageStatus is set to Faulty or Congested.
LAPD is used for transmission on the Abis interface. LAPD links are categorized into OML,
RSL, ESL, and extended maintenance link (EML).
Location Procedure
l LAPD link or one-way disconnection
Figure 11-6 shows the procedure for locating the source of LAPD link or one-way
disconnection.
GBSS14.0
287
Figure 11-6 Procedure for locating the source of LAPD link or one-way disconnection

l Intermittent LAPD link disconnection or congestion
Figure 11-7 shows the procedure for locating the source of intermittent LAPD link
disconnection or congestion.
GBSS14.0
288
Figure 11-7 Procedure for locating the source of intermittent LAPD link disconnection or
congestion

NOTE
support.
Table 11-10 LAPD link fault location information
under an MSC).

GBSS14.0
289
2 Operations
before and
after the
fault occurs
modification.

3 Faulty NE
version
For details
about how
to obtain
the BSC
and BTS
software
versions
that are
used when
the fault
occurs, see
15
Appendix
: How to
Collect
Fault
Informati
on.
4 Historical
alarms
For details
about how
to obtain
the
historical
alarms,
see 15
Appendix
: How to
Collect
Fault
Informati
on.
5 E1/T1 or FE/
GE port
status
command output: DSP E1T1 and DSP ETHPORT.

6 Configurati
on
information
about the
LAPD link
command output: LST BSCABISPRIMAP and LST
BTSVLAN.

7 LAPD link
status
Run the MML command LST LAPDLNK and view
the command output.

GBSS14.0
290
8 Faulty
signaling
l Obtain the CS messages over the extended
signaling link (ESL) on the Abis interface that are
traced within 10 minutes when the fault occurs.
l Obtain the CS messages over the LAPD link on
the Abis interface that are traced within 10 minutes
when the problem occurs, including messages
over the radio signaling link (RSL), operation and
maintenance link (OML), ESL, and element
management layer (EML) link.
For details
about how
to obtain
the faulty
signaling,
see 15
Appendix
: How to
Collect
Fault
Informati
on.
9 Statistical
result of
interworkin
g packets
sent and
received
over the
LAPD link
Obtain the statistical result of interworking packets
sent and received over the LAPD link from the
command output after the MML command DSP
INTERWPFM is executed.

10 Original
traffic
statistics
For details
about how
to obtain
the
original
traffic
statistics,
see 15
Appendix
: How to
Collect
Fault
Informati
on.
For details
about how
to obtain
BTS logs,
see 15
Appendix
: How to
Collect
Fault
Informati
on.
GBSS14.0
291
12 BTS tracing
result file
Obtain the BTS tracing result file generated when the
problem occurs.
For details
about how
to obtain
the BTS
tracing
result file,
see 3.2.5
BTS
Tracing.

l LAPD link or one-way disconnection
1. Check the status of the FE/GE, E1/T1, or PPP links. If the FE/GE, E1/T1, or PPP links
are faulty, locate and rectify the faults by referring to 11.1 Troubleshooting FE/GE
Transmission Faults or 11.3 Troubleshooting PPP or MLPPP Link Faults and
check whether the alarms related to LAPD link faults are cleared. If the alarms persist,
go to Step 2.
2. Capture relevant packets to determine whether the Dynamic Host Configuration
Protocol (DHCP) process is complete. If the DHCP process failed, locate and rectify
the faults by referring to 11.7 Troubleshooting DHCP Problems and check whether
the alarms related to LAPD link faults are cleared. If the alarms persist, go to Step
3.
3. Run the MML command LST BSCABISPRIMAP or LST BTSVLAN to check
whether the VLAN ID settings for the uplink or downlink LAPD links and
transmission devices are consistent. If the settings are inconsistent, correct them and
check whether the alarms related to LAPD link faults are cleared. If the alarms persist,
go to Step 4.
4. Run the MML command PING IP and use 64-byte, 500-byte, 1460-byte, and 1473-
byte ping packets to ping the destination IP address. Then, set the differentiated
services code point (DSCP) to the value the transport network planned for LAPD
messages.
If pinging the destination IP address fails, run the MML command MOD IPPATH
with IP path check type set to ICMP(ICMP). View the traffic statistics of IP Path
Link Measurement(IPPATH) two hours after the preceding MML command is
executed. If any packets are lost or the transmission delay is long, have the
transmission engineers locate and rectify the faults, and check whether the alarms
related to LAPD link faults are cleared. If the alarms persist, go to Step 5. Table
11-11 lists the requirements for the Abis over IP transmission quality of service (QoS)
on the BSC side.
NOTE
Before running the PING IP command, contact the engineers from the transmission network
side to verify that all devices in the transmission path are allowed to be pinged. To ping the
BTS IP address, run the LST BTSPINGSW command to query whether the ping switch (turned
on by default) of the BTS is turned on. If the ping switch is not turned on, run the SET
BTSPINGSW command to turn on the ping switch.
GBSS14.0
292
Table 11-11 Requirements for the Abis over IP transmission QoS
Counter
s for the
Abis
over IP
Transm
ission
QoS
One-Way Delay
(ms)
One-Way Jitter
(ms)
Packet Loss Rate
(% or 10-x)
Scenari
o
Recom
mended
Value
Maxim
um
Value
Recom
mended
Value
Maxim
um
Value
Recom
mended
Value
Maxim
um
Value
Terrestri
al
transmiss
ion
< 15 ms < 40 ms < 8 ms < 15 ms < 0.05% < 0.1%
Satellite
transmiss
ion
< 300 ms < 350 ms < 20 ms < 40 ms < 0.05%

5. On the LMT, trace LAPD messages on the Abis interface in the CS domain by referring
to Tracing CS Domain LAPD Messages on the Abis Interface. You can enter the BTS
ID alone to trace OML, EML, or RSL messages or enter both the BTS ID and TRX
ID to trace RSL messages. Tracing these messages helps to check whether the
transmission is normal and whether any packets are lost. If the transmission is
abnormal or any packets are lost, have the transmission engineers locate and rectify
the faults and check whether the alarms related to LAPD link faults are cleared. If the
alarms persist, go to Step 6.
6. Run the MML command DSP INTERWPFM to query the number of packets
received, sent, and discarded as measured by the interworking module.
NOTE
The interworking module measures the number of LAPD packets received and sent by the
interface board.
Before this operation, you can run the MML command LST LAPDLNK to query
data configurations for the LAPD links. If the following command is used:
DSP INTERWPFM: SPUSRN=1, SPUSN=0, LNKT=LAPDLNK, LAPDLNKN=0,
PIUSRN=0, PIUSN=16;
The query results are displayed as follows:
+++ PTRM_B012 2011-02-27 10:47:12
O&M #3635
%%DSP INTERWPFM: SPUSRN=1, SPUSN=0, LNKT=LAPDLNK, LAPDLNKN=0, PIUSRN=0,
PIUSN=16;%%
RETCODE = 0 Execution succeeded.
Flow Type = UoIP_FLOW //Indicates that the BSC
sends packets from the UoIP to the quintuple.
Flow Index = 0 //Indicates the stream
index.
Count of received packet = 562 //Indicates the number of
packets sent from the XPU to the interface board.
Count of received byte = 23233 //Indicates the number of
bytes sent from the XPU to the interface board.
GBSS14.0
293
Count of discarded packet = 5 //Indicates the number of
packets discarded on the interface board. In normal cases, the number
should be 0.
Count of discarded byte = 210
Flow Type = FIVE_TUPLE_FLOW //Indicates that the BSC
receives packets from the quintuple to the UoIP.
Flow Index = 25 //Indicates the stream
index.
Count of received packet = 376 //Indicates the number of
packets received on the interface board.
Count of received byte = 23304 //Indicates the number of
bytes received on the interface board.
Count of discarded packet = 0 //Indicates the number of
packets discarded on the interface board. In normal cases, the number
should be 0.
Count of discarded byte = 0
(Number of results = 2)
NOTE
The text following // is a detailed explanation of the query results.
In normal cases, the packet receiving and sending process is integrated. If multiple
query results show that the number of received and sent packets increases, the
transmission is normal. If the number of discarded packets increases, the transmission
is abnormal. In this case, Contact Huawei Customer Service Center.
In the case of one-way LAPD link disconnection (packets can only be sent), if the
query results show that the number of sent packets increases, the BSC has sent packets.
In this case, go to Step 7.
7. In IP over E1/T1 mode, perform an LAPD software or hardware loopback test on the
interface to check whether the fault is caused by faulty NEs or abnormal transmission.
Run the MML command SET E1T1LOP to perform an LAPD software loopback
test. Set the port on the interface board corresponding to the current LAPD link to
local loopback mode and trace LAPD signaling messages. If a packet can be sent
and received properly, the LAPD link between the XPU and the interface board is
normal.
Perform an LAPD hardware loopback test on the intermediate transmission
devices. Connect the TX end to the RX end using an E1/T1 cable and do not connect
the E1/T1 cable to the BTS. Then, trace LAPD signaling messages to locate the
faulty NE.
8. If the fault persists, capture relevant packets and Contact Huawei Customer Service
Center.
l Intermittent LAPD link disconnection or congestion
1. Query the measurement results of K3004:Traffic Volume on SDCCH and
A3039J:SDCCH Seizures for Speech Service to check whether the fault is caused by
a heavy traffic volume. If the traffic volume is heavy, add standalone dedicated control
channels (SDCCHs) or expand the transmission capacity. If the traffic volume is
normal, go to Step 2.
2. Run the MML command DSP LAPDLNK to check the LAPD link status.
a. Current queue length of I frame: If this parameter is set to greater than 90
(default value), the ALM-21511 LAPD Link Congestion alarm is reported.
b. Link status changed cause
c. OverFlow I Frame Count
GBSS14.0
294
If any of the preceding parameters are set incorrectly, Contact Huawei Customer
Service Center. If the parameters are set correctly, go to Step 3.
3. Check the VLAN and DSCP settings for the port used to forward packets on the
transmission device connected to the LAPD link. If the VLAN priority is low or the
DSCP settings are incorrect, some packets are lost during the transmission. Correct
any incorrect settings. If the VLAN priority is normal or the DSCP settings are correct,
go to Step 4.
4. Check the transport network quality.
Run the MML command PING IP and use 64-byte, 500-byte, 1460-byte, and 1473-
byte ping packets to ping the destination IP address.
NOTE
If pinging the destination IP address fails, run the MML command MOD IPPATH
with IP path check type set to ICMP(ICMP). Two hours after the command is
executed, view the traffic statistics of IP Path Link Measurement(IPPATH). If any
packets are lost, the transmission delay is long, or the jitter is large, have the
transmission engineers locate and rectify the faults, and check whether the alarms
related to LAPD link faults are cleared.
NOTE
The following methods can be used to check the transport network quality on the user plane of
the Abis interface. The operation results can serve as reference for checking the transport
network quality on the signaling plane of the Abis interface.
1. Enable the IP Path ping function. Wait for a certain period and run the MML command
DSP IPPATH or query the traffic statistics to check whether any packets are lost, whether
the transmission delay is long, or whether the jitter is large.
2. In IP over FE mode, run the MML command ACT IPPM to activate the IP PM function.
If the packets sent from the BTS to the BSC carry the VLAN ID, only the BTS3900s whose
software versions are BTS3000 V100R009C00SPC079 or later support the IP PM function.
Then, run the MML command DSP IPPM to query the transport network quality in real
time or monitor the transport network quality by querying the following counters:
l T7663:Maximum RTT Delay of IPPM
l T7668:Average TX Bit Rate of IPPM
l T7669:Average TX Packet Rate of IPPM
l T7670:Peak TX Bit Rate of IPPM
l T7671:Peak TX Packet Rate of IPPM
l T7672:Average RX Bit Rate of IPPM
l T7673:Average RX Packet Rate of Peer End of IPPM
l T7674:Peak RX Bit Rate of Peer End of IPPM
l T7675:Peak RX Packet Rate of Peer End of IPPM
l T7676:Average Forward Packet Loss Rate of IPPM
l T7677:Peak Forward Packet Loss Rate of IPPM
l T7678:Forward Jitter Standard Deviation of IPPM
l T7679:Backward Jitter Standard Deviation of IPPM
l T7680:Average RTT Delay of IPPM
If the transport network quality meets the requirements, go to Step 5.
GBSS14.0
295
5. If the fault persists, Contact Huawei Customer Service Center.
Typical Case
Symptom
An RSL disconnects intermittently.
Cause Analysis
l The signaling traffic volume may be heavy.
l Some packets may be lost during transmission.
1. Query the signaling traffic volume. The signaling traffic volume is not heavy.
2. Check whether the uplink and downlink DSCP values for the signaling plane and user plane
are consistent. The uplink and downlink DSCP values for the signaling plane are 46 and
48, but the uplink and downlink DSCP values for CS services on the user plane are 38 and
46. Therefore, some packets are lost during intermediate transmission.
3. Ping the destination IP address. Some packets are lost.
4. Query the measurement results of packets received and sent by the router. Some packets
are lost. Therefore, the router bandwidth is insufficient, and the DSCP and queue priority
settings are incorrect.
5. Increase the router bandwidth and correct the DSCP and queue priority settings. The fault
is rectified.
11.5 Troubleshooting SCTP Link Faults
This section describes how to troubleshoot Stream Control Transmission Protocol (SCTP) link
faults.
Symptom
l There are two types of SCTP link faults:
SCTP link disconnection or one-way disconnection: The TX end sends packets to the
RX end but does not receive any response packets from the RX end.
Unexpected SCTP link disconnection: The SCTP link is intermittently disconnected or
congested.
l When the SCTP link is faulty, the alarms in Table 11-12 may be reported.
Table 11-12 Alarms related to SCTP link faults
Alarm ID Alarm Name
21541 ALM-21541 SCTP Link Fault
21542 ALM-21542 SCTP Link Congestion
22915 EVT-22915 SCTP Link Destination IP
Changeover

GBSS14.0
296
l When the SCTP link is faulty, the query result of the MML command DSP SCTPLNK
shows that Operation state is set to Unavailable or Congestion.
l SCTP
The Stream Control Transmission Protocol (SCTP) is a transport layer protocol used for
reliable transmission between the SCTP user application and a connectionless packet
network (such as the IP network). In the Huawei BSS system, the SCTP technology is
usually used for A over IP.
l To troubleshoot SCTP link faults, trace SCTP messages on the A interface by referring to
Tracing SCTP Messages on the A Interface. SCTP messages are categorized into INIT,
INIT, ACK, DATA, SACK, ABORT, SHUTDOWN, ERROR, COOKIEECHO, and
HEARTBEAT.
l Figure 11-8 shows the message interaction process during an SCTP link setup. The first
four messages are handshake messages, the last four messages are heartbeat messages, and
the rest are data interaction messages.
Figure 11-8 Message interaction process during an SCTP link setup

Location Procedure
l SCTP link or one-way disconnection
Figure 11-9 shows the procedure for locating the source of SCTP link or one-way
disconnection.
GBSS14.0
297
Figure 11-9 Procedure for locating the source of SCTP link or one-way disconnection

l Unexpected SCTP link disconnection
Figure 11-10 shows the procedure for locating the source of unexpected SCTP link
disconnection.
GBSS14.0
298
Figure 11-10 Procedure for locating the source of unexpected SCTP link disconnection

NOTE
support.
Table 11-13 SCTP link fault location information
an MSC).

GBSS14.0
299
2 Operations
before and
after the
fault occurs
modification.

3 Faulty NE
version
For details
about how
to obtain
the BSC
and BTS
software
versions
that are
used when
the fault
occurs, see
15
Appendix
: How to
Collect
Fault
Informati
on.
4 Historical
alarms
For details
about how
to obtain
the
historical
alarms,
see 15
Appendix
: How to
Collect
Fault
Informati
on.
5 Status of the
SCTP link
Run the MML command DSP SCTPLNK and view
the command output.

6 Statistics on
error
packets over
the port
Run the MML command DSP ETHPORT for
consecutive three times to query the status of the
Ethernet ports at an interval of 30s. If the Ethernet
ports are configured in active/standby mode, query
the status of the active and standby ports by running
the preceding commands. Then, view the command
output.

GBSS14.0
300
7 PING IP
command
output
Run the MML command PING IP to ping the IP
address of the FE port on an interface board of the core
network (CN) and view the command output.
NOTE
the ping switch.

8 Faulty
signaling
Obtain the messages over the SCTP link on the A
interface that are traced within 10 minutes when the
fault occurs.
For details
about how
to obtain
the faulty
signaling,
see 15
Appendix
: How to
Collect
Fault
Informati
on.
9 Original
traffic
statistics
For details
about how
to obtain
the
original
traffic
statistics,
see 15
Appendix
: How to
Collect
Fault
Informati
on.
GBSS14.0
301
10 Host
running logs
Obtain the host running logs generated within two
For details
about how
to obtain
the
original
traffic
statistics,
see 15
Appendix
: How to
Collect
Fault
Informati
on.
For details
about how
to obtain
BTS logs,
see 15
Appendix
: How to
Collect
Fault
Informati
on.

l SCTP link disconnection or one-way disconnection
1. Run the MML command PING IP to ping the peer IP address. If the peer IP address
cannot be pinged, check the router and transport network. If the peer IP address can
be pinged, go to Step 2.
NOTE
2. Check whether the transmission devices require all packets sent by the BSC to carry
VLAN IDs. If the packets carry VLAN IDs, run the MML commands LST
VLANID and LST SCTPLNK to check whether the VLAN IDs are correct. If the
VLAN IDs are incorrect, change the parameter value. If the VLAN IDs are correct,
go to Step 3.
3. Run the MML command LST SCTPLNK to check whether the settings of the SCTP
interworking parameters, especially the IP address, port number, and maximum
transmission unit (MTU), for the BSC and the MSCare consistent. In addition, ensure
that the MTU value on the transport network is greater than the MTU values on the
BSC and MSC sides. If the settings of the SCTP interworking parameters are
GBSS14.0
302
inconsistent, correct them. If the settings of the SCTP interworking parameters are
consistent, go to Step 4.
4. Check whether the SCTP link is configured with upper-layer applications, such as
M3UA configuration data. If not, configure upper-layer applications. If the
configurations are incorrect, correct them. If the SCTP link is configured with correct
upper-layer applications, go to Step 5.
5. On the LMT, trace SCTP messages on the A interface by referring to Tracing SCTP
Messages on the A Interface. Set SCTP Link No to the number of the congested SCTP
link and enable the SCTP link tracing function. Compare the traced messages with
normal interaction messages to check whether any packets are lost during
transmission. If any packets are lost during transmission, have the transmission
engineers locate and rectify the faults. If no packets are lost during transmission, go
to Step 6.
6. Analyze the SCTP packets traced in Step 5. If one end does not receive packets,
capture packets on the transmission device close to the other end to check whether the
packets were sent. For example, if the BSC sends an INIT ACK packet but does not
receive the COOKIEECHO packet from the MSC, capture packets on the MSC side
to check whether the COOKIEECHO packet was sent. To capture packets, use the
Ethereal (Wireshark) software or connect a PC to the mirrored port on the switch
installed between the output port and the transport network. If the COOKIEECHO
packet was sent, it may have been lost on the transport network or BSC interface board.
In this case, have the transmission engineers locate and rectify the faults. If no
COOKIEECHO packet was sent, errors may have occurred on the MSC side. In this
case, have the MSC vendor for technical support. If the transmission is normal and
the MSC operates properly, go to Step 7.
l Unexpected SCTP link disconnection
1. Check whether related transmission alarms, such as the FE or E1 fault alarms, are
reported when the problem occurs. If the alarms are reported, optimize the transport
network. If the alarms are not reported, go to Step 2.
2. On the LMT, trace SCTP messages on the A interface by referring to Tracing SCTP
Messages on the A Interface. Compare the traced messages with normal interaction
messages to check whether any packets are lost during transmission. Analyze the
received and sent packets to identify the possible causes. For example, the problem
may occur because heartbeat messages cannot be received or one end sends the Abort
message. If the transmission is abnormal, have the transmission engineers locate and
rectify the faults. If errors occur on an NE, contact the NE vendor for technical support.
If the transmission is normal and the NE operates properly, go to Step 3.
3. Analyze the SCTP messages traced in Step 2. If some packets are lost during
transmission, check whether the FE port attributes for the two ends are consistent by
referring to 11.1 Troubleshooting FE/GE Transmission Faults. If the FE port
attributes are consistent, run the MML command PING IP to calculate the packet loss
rate on the transport network and have the transmission engineers locate and rectify
the faults. If no packets are lost during transmission, go to Step 4.
NOTE
GBSS14.0
303
4. If the SCTP link configurations are correct and the IP addresses of both ends can be
pinged, run the MML command MOD SCTPLNK to initiate link negotiation again.
If the link negotiation fails, go to Step 5.
Typical Case
Symptom
The SCTP link fails to be set up after the A over IP reconstruction and signaling data
configurations are complete.
Cause Analysis
l The BSC boards may be faulty.
l The data configurations may be incorrect.
1. Query the data configurations and alarm information for the BSC boards. The data
configurations are complete and correct, and no boards report hardware alarms.
2. Have the MSC maintenance engineers query the settings of the SCTP interworking
parameters. The number of the SCTP port on the MSC side is not the actual number.
3. Have the MSC maintenance engineers change the number of the SCTP port on the MSC
side. The SCTP link can be set up successfully.
11.6 Troubleshooting IP Path Problems
This section describes how to troubleshoot IP path problems.
Symptom
l When an IP path problem occurs, CS or PS service may fail to be performed and the alarms
in Table 11-14 may be reported.
Table 11-14 Alarms related to IP path problems
Alarm ID Alarm Name
21581 ALM-21581 Path Fault
21582 ALM-21582 Path Congestion
21352 ALM-21352 IP Path Excessive Packet
Loss Rate

l You can run the MML command DSP IPPATH to check whether an IP path problem
occurs. If Operation state in the command result is Unavailable, an IP path problem has
occurred.
An IP path is a logical link carried on the physical link on an IP transport network. Each IP path
is allocated virtual bandwidth. An IP path is used to perform admission control. During network
GBSS14.0
304
access, the system performs admission control based on the service type and bandwidth used by
the IP path.
An IP path manages only the transmission resources occupied by subscriber services.
Location Procedure
Figure 11-11 shows the procedure for locating IP path problems.
Figure 11-11 Procedure for locating IP path problems

NOTE
Collect the problem location information by referring to Table 11-15 before contacting Huawei for
technical support.
Table 11-15 Location information about IP path problems
an MSC).

GBSS14.0
305
2 Operations
before and
after the
problem
occurs
modification.

3 Faulty NE
version
For details
about how
to obtain
the BSC
and BTS
software
versions
that are
used when
the
problem
occurs, see
15
Appendix
: How to
Collect
Fault
Informati
on.
4 Historical
alarms
For details
about how
to obtain
the
historical
alarms,
see 15
Appendix
: How to
Collect
Fault
Informati
on.
5 IP path
status
Run the MML command DSP IPPATH and view the
command output.

6 Routing
table on the
BSC
l Run the MML command DSP IPRT and view the
command output.
l Run the MML command LST IPRT and view the
command output.

GBSS14.0
306
7 PING IP
command
output
Run the MML command PING IP with Source IP
address set to the local IP address of the faulty IP path
and view the command output.
NOTE
the ping switch.

8 Link
performance
monitoring
result
Obtain the link performance result of the IP path
monitored within 10 minutes when the problem
occurs.
For details
about how
to obtain
the link
performan
ce
monitorin
g result,
see 15
Appendix
: How to
Collect
Fault
Informati
on.
9 Original
traffic
statistics
For details
about how
to obtain
the
original
traffic
statistics,
see 15
Appendix
: How to
Collect
Fault
Informati
on.
GBSS14.0
307
10 Host
running logs
Obtain the host running logs generated within two
For details
about how
to obtain
the host
running
logs, see
15
Appendix
: How to
Collect
Fault
Informati
on.
For details
about how
to obtain
BTS logs,
see 15
Appendix
: How to
Collect
Fault
Informati
on.
12 BTS tracing
result file
Obtain the BTS tracing result file generated when the
problem occurs.
For details
about how
to obtain
the BTS
tracing
result file,
see 3.2.5
BTS
Tracing.

1. Check whether the IP path configurations are correct.
l Run the MML command LST IPPATH to check whether Local IP address and Peer
IP address are set correctly.
l Run the MML command DSP IPPATH to check whether the IP path status is normal
and the bandwidth is configured correctly. If Operation state is set to Unavailable or
the remaining bandwidth is insufficient, IP path admission may fail.
If yes, go to Step 2. If no, correct the IP path configuration.
2. Check whether IP route configurations are correct.
l Contact relevant personnel to check configurations for routes to the intermediate route
devices and core network configurations.
GBSS14.0
308
l Run the MML commands LST IPRT and DSP IPRT to query the routing tables for
the interface boards and check whether there is a route to the peer IP address of the IP
path. Before configuring an IP path for a BSC, ensure that the output port is available.
If the output port is unavailable, first configure an IP route. Then, configure an IP path.
If yes, go to Step 3. If no, correct the corresponding configurations.
3. Check whether the end-to-end transmission route corresponding to the IP path is operating
properly.
l Check whether VLAN configurations are correct if VLAN planning data is available.
Check whether the VLAN ID is configured correctly on the BSC side when
configuring an IP path or running the MML command ADD VLANID. You are
advised to run the MML command ADD VLANID to configure a VLAN ID
corresponding to the next-hop IP address and set VLANID Flag to DISABLE
(Disable) for the MML command ADD IPPATH.
Run the MML command SET BTSVLAN to check whether the VLAN IDs for the
CS voice, CS data, high-priority PS, low-priority PS, signaling, or other data packets
are configured correctly.
l Run the MML command PING IP on the LMT to ping the gateway address and peer
IP address of the IP path, respectively. If the peer IP address of the IP path cannot be
pinged, run the MML command TRC IPADDR with Destination IP address set to
the peer IP address of the IP path to locate the problem. For the IP transmission on the
Abis interface, you can check whether the BSC or transmission on the Abis interface is
faulty by performing IP loopback. For details, see 3.2.4 Performing IP Loopback.
NOTE
side to verify that all devices in the transmission path are allowed to be pinged. To ping the BTS
IP address, run the LST BTSPINGSW command to query whether the ping switch (turned on
by default) of the BTS is turned on. If the ping switch is not turned on, run the SET
If yes, go to Step 4. If no, correct configurations or rectify the transmission route fault.
Then, check whether the IP path problem is resolved.
4. If the IP path problem persists, Contact Huawei Customer Service Center.
Typical Case
Symptom
After data is configured for A over IP reconstruction, the signaling becomes normal, but calls
fail to be set up and the BSC sends the assignment failure messages to the core network.
Cause Analysis
l The device boards may be faulty.
l Data configurations may be incorrect.
1. Query data configurations and alarm information about the BSC boards. Data
configurations are complete and correct and no hardware alarms are reported on any boards.
2. Query the status of the IP path and data configurations for the peer core network. The IP
path cannot be used and no route is configured on the peer core network.
3. Configure a route. The IP path problem is resolved.
GBSS14.0
309
11.7 Troubleshooting DHCP Problems
This section describes how to troubleshoot Dynamic Host Configuration Protocol (DHCP)
problems.
Symptom
When a DHCP interaction failure occurs, the BTS software fails to be loaded for an excessive
long period of time
l A BTS can obtain configuration information and set up a cell only when DHCP interaction
is working properly. Upon startup, the BTS sends the BSC a DHCP request. Then, the BSC
responds with a DHCP response that carries the following information: BSC IP address,
BTS IP address, BTS port IP address, extend signaling link (ESL) or layer 2 management
link (L2ML), and VLAN configuration. After receiving the DHCP response from the BSC,
the BTS sets up an ESL and obtains operation and maintenance link (OML) data for follow-
up procedures. Figure 11-12 shows a typical DHCP interaction procedure.
Figure 11-12 Typical DHCP interaction procedure

Location Procedure
Figure 11-13 shows the procedure for locating DHCP problems.
GBSS14.0
310
Figure 11-13 Procedure for locating DHCP problems

NOTE
Collect the problem location information by referring to Table 11-16 before contacting Huawei for
technical support.
GBSS14.0
311
Table 11-16 Location information about DHCP problems
an MSC).

2 Operations
before and
after the
problem
occurs
modification.

3 Faulty NE
version
For details
about how
to obtain
the BSC
and BTS
software
versions
that are
used when
the
problem
occurs, see
15
Appendix
: How to
Collect
Fault
Informati
on.
4 Historical
alarms
For details
about how
to obtain
the
historical
alarms,
see 15
Appendix
: How to
Collect
Fault
Informati
on.
5 E1/T1 or FE/
GE port
status
Run the MML commands DSP E1T1 and DSP
ETHPORT and view the command output.

GBSS14.0
312
6 PPP/
MLPPP link
status
Run the MML commands DSP PPPLNK, DSP
MPGRP, and DSP MPLNK and view the command
output.

7 TRC
IPADDR
command
output
Run the MML command TRC IPADDR and view the
command output.

8 PING IP
command
output
Run the MML command PING IP and view the
command output.
NOTE
the ping switch.

9 BTS ESN Run the MML commands LST BTSESN and DSP
BTSESN and view the command output.

For details
about how
to obtain
BTS logs,
see 15
Appendix
: How to
Collect
Fault
Informati
on.

1. Check whether the transmission at the physical layer is normal. If the FE/GE transmission
is used at the physical layer, locate and rectify the transmission faults by referring to 11.1
Troubleshooting FE/GE Transmission Faults. If the E1/T1 transmission is used at the
physical layer, check whether the alarms in Table 11-17 are reported. If the alarms are
reported, clear them by referring to the BSC6900 GSM Alarm Reference. If the alarms are
not reported, go to Step 2.
Table 11-17 Alarms related to E1/T1 transmission faults
Alarm ID Alarm Name
4714 ALM-4714 E1/T1 Local Alarm
GBSS14.0
313
Alarm ID Alarm Name
4716 ALM-4716 E1/T1 Remote Alarm
20201 ALM-20201 1PPS State Abnormal
20202 ALM-20202 Time Information Reception
Abnormal
20203 ALM-20203 Clock Signal Outputs Faulty
20204 ALM-20204 Clock Signal Inputs Faulty
20205 ALM-20205 System Clock Reference
Source Unavailable
20206 ALM-20206 Current System Clock
Reference Source Status Abnormal
20207 ALM-20207 Failure in Locking System
Clock Source
20208 ALM-20208 Clock Reference Source of
Main Control Board Unavailable
20209 ALM-20209 Faulty Phase-Locked Loop of
the Board Clock

2. Check whether BSC data configurations are correct.
l Run the MML command LST BTSESN to check whether the BTS ESN is configured.
l Run the MML command LST IPRT to check whether route configurations are correct
and complete. In Layer 3 networking, both the route to the BTS and the route to the
BTS gateway must be configured.
l Run the MML command LST BTSIPRT to check whether BTS route configurations
are correct.
l Run the MML command LST BTSVLAN to check whether VLAN IDs are correctly
configured for the packets of different service types. If packets whose service type is
Other Data are not configured with VLAN IDs, IP addresses cannot be pinged. When
this occurs, the ARP table of the peer device may fail to be updated, and the BTS may
fail to trace a clock.
l If the BTS is configured with a VLAN ID, enable the VLAN detection function for the
BSC during remote commissioning.
To enable the BTS detection function, run the MML command SET
BTSOTHPARA to set BTS Detect Switch to OPEN(OPEN). When the BTS detection
function is enabled, the BSC performs addressing based on the BTS IP address and
sends the BTS a UDP packet containing the VLAN ID information. After BTS remote
commissioning is successful, run the MML command SET BTSOTHPARA to set BTS
Detect Switch to CLOSE(CLOSE) to disable the BTS detection function. If data
configurations are incorrect, correct the data configurations. Then, check whether the
alarms are cleared. If the alarms persist, go to Step 3.
3. Check whether the data configurations for transmission devices are correct.
l If the Layer 3 networking mode is used for the Abis interface, ensure that the gateway
router close to the BTS has been configured with DHCP relay data. If the transmission
GBSS14.0
314
device has been commissioned successfully, the DHCP problem may lie in data
configurations.
l Check whether the data configurations for packet transport network (PTN) devices and
Layer 2 switches are correct.
Check whether the port attribute of the PTN device is Access, Tag Aware, or Hybrid.
If the port attribute is Tag Aware, packets with VLAN IDs cannot be sent over the
port.
Check whether VLAN configurations for Layer 2 switches are the same as those for
the BTS.
If the data configurations are incorrect, correct them and check whether the alarms are
cleared. If the alarms persist, go to Step 4.
4. Perform the following operations to check whether the BSC collects statistics on the DHCP
packets reported by an unknown electronic serial number (ESN): Run the MML command
CLR BTSESN. Then, wait for five minutes and run the MML command DSP BTSESN
to query BTS ESNs. If any BTS ESNs are queried, the DHCP problem may result from
incorrect ESN configurations. In this situation, modify the incorrect ESN and check
whether the DHCP problem is resolved. If the DHCP problem persists, go to Step 5.
5. Check whether the BSC or BTS has sent any DHCP packets by capturing packets on the
BSC or BTS mirrored port. If the BSC or BTS has sent a DHCP packet but the packet fails
to be captured at the peer end, contact transmission engineers to identify the reason why
the packets are discarded. Then, check whether the DHCP problem is resolved. If the DHCP
problem persists, go to Step 6.
6. Check whether the BTS sends any DHCP packets or the BSC responds to the BTS after
receiving any DHCP request packets. Record the fault symptom and save the location
information. Then, go to Step 7.
7. If the DHCP problem persists, Contact Huawei Customer Service Center.
Typical Case
Symptom
When a test is performed in Abis over IP, two newly deployed BTSs, BTS B with VLAN 101
and BTS C with VLAN 102, fail to set up links to the BSC. BTS A with VLAN 100, however,
is operating properly. After the data configurations for BTS A and BTS B interchange, BTS B
configured with VLAN 100 operates properly. The gateway addresses of BTS B and BTS C
cannot be pinged, but the gateway address of BTS A can be pinged successfully.
Cause Analysis
l BTS ESN configurations may be incorrect.
l The BTS gateway may not be configured with the DHCP relay function.
l VLAN configurations for transmission devices may be incorrect.
l BSC route configurations may be incorrect.
1. Check whether BTS ESN configurations are correct. If the check result is correct and BTS
B configured with VLAN 100 operates properly after the data configurations for BTS A
and BTS B interchange, the BTS ESN configurations are correct.
2. Check whether the Layer 3 switch is configured with the DHCP relay function. The check
result shows that the Layer 3 switch is configured with the DHCP relay function.
GBSS14.0
315
3. Check the VLAN configurations for the BTS and Layer 3 switch as well as for the signaling
plane on the BSC. The check result shows that VLAN configurations for the three BTSs
are the same except the VLAN IDs and the Layer 3 switch uses the same mechanism to
process VLAN IDs 100, 101, and 102. After the BTS VLAN self-learning switch is turned
on, the DHCP problem persists.
4. Check the BSC route configurations. The check result shows that the route configurations
for BTS A are different from those for BTSs B and C. BTS A is configured with a network
segment route and a BTS route. However, both BTS B and BTS C are configured with a
BTS route. After BTSs B and C are configured with network segment routes, the two BTSs
can set up links to the BSC. A network segment route contains a route to the DHCP relay.
In Layer 3 networking, only unicast DHCP packets can be sent between the DHCP relay
agent (BTS gateway) and the DHCP server (BSC). Use the unicast DHCP Discover packet
as an example. The source IP address of the DHCP Discover packet is the IP address of the
DHCP relay agent and the destination IP address of the DHCP Discover packet is the IP
address of the DHCP server. After receiving a DHCP Discover packet, the DHCP server
needs to send a DHCP Offer packet to the DHCP relay agent. In this situation, the DHCP
server must be configured with a network segment route or with two routes: one route to
the BTS and one route to the DHCP relay agent.
11.8 Troubleshooting IP PM Activation Failures
This section describes how to troubleshoot IP performance monitor (IP PM) activation failures.
Symptom
During IP PM activation, an error message is displayed, indicating that IP PM activation fails.
The activated IP PM is faulty and the ALM-21341 IP PM Activation Failure is reported. During
packet capturing, the BTS or BSC does not receive any IPPM ACT ACK frames after sending
IPPM ACT frames.
l IP PM uses forward monitoring (FM) and backward reporting (BR) frames to monitor
packet loss on paths. The Tx end sends FM frames to the Rx end and notifies the Rx end
of the number of sent packets. Then, the Rx end responds with BR frames and notifies the
Tx end of the number of received packets. The Tx end then calculates the delay, jitter,
packet loss when FM frames are sent from the Tx end to the Rx end, and calculates the
bandwidth change when BR frames are sent from the Rx end to the Tx end. The interval
for sending FM frames or the number of FM frames sent by the Tx end each time can be
specified.
Location Procedure
Figure 11-14 shows the procedure for locating IP PM activation failures.
GBSS14.0
316
Figure 11-14 Procedure for locating IP PM activation failures

NOTE
Collect the failure location information by referring to Table 11-18 before contacting Huawei for technical
support.
Table 11-18 Location information about IP PM activation failures
1 Symptom Provide the start time and end time of the failure,
an MSC).

2 Operations
before and
after the
failure
occurs
Provide the operations before and after the failure
modification.

GBSS14.0
317
3 Faulty NE
version
For details
about how
to obtain
the BSC
and BTS
software
versions
that are
used when
the
problem
occurs, see
15
Appendix
: How to
Collect
Fault
Informati
on.
4 Historical
alarms
For details
about how
to obtain
the
historical
alarms,
see 15
Appendix
: How to
Collect
Fault
Informati
on.
5 PING IP
command
output
command output.
NOTE
the ping switch.

6 TMU
hardware
type of the
BTS
Run the MML command DSP BTSBRD and view the
command output.

GBSS14.0
318
1. Check whether the transmission at the physical layer for GBSS9.0 is normal. In IP over
E1, IP PM is not supported. In IP over FE/GE, check whether FE/GE alarms are reported.
Clear any reported FE/GE alarms. Then, check whether the problem is resolved. If the
problem persists, go to Step 2.
2. Compare the packets captured on the transmission device close to the BTS and BSC to
check whether the DSCP values in the IP PM activation response packets from the BTS
are consistent with those in the IP PM activation request packets from the BSC. During
packet transmission, the intermediate transmission device may modify the DSCP values in
the packets based on the data configurations for the intermediate transmission device. If
the DSCP values are inconsistent, contact maintenance engineers who manage the
intermediate transmission device to modify the data configurations. Then, check whether
the problem is resolved. If the problem persists, go to Step 3.
3. Check whether the BSC sends FM frames and receives BR frames by capturing packets on
the BSC mirrored port, and check whether the BTS sends BR frames and receives FM
frames by capturing packets on the BTS mirrored port. If any sent packets are not received,
contact transmission engineers to locate the problem. Then, check whether the problem is
resolved. If the problem persists, go to Step 4.
Typical Case
Symptom
The IP PM function on the Abis interface fails to be activated.
Cause Analysis
l The DSCP values in packets may be modified by the transmission device.
l Packets may be discarded on the transport network.
1. Check whether packets are discarded on the transport network. The result shows that no
packets are discarded on the transport network.
2. Analyze the captured packets. The DSCP values in the IP PM activation response packets
from the BTS are inconsistent with those in the IP PM activation request packets from the
BSC. During packet transmission, the intermediate transmission device changes the DSCP
values in packets.
3. Modify data configurations for the intermediate transmission device to ensure that DSCP
values in packets cannot be changed.
4. Run the MML command ACT IPPM on the LMT to activate IP PM.
11.9 Troubleshooting IP Clock Faults
This section describes how to troubleshoot IP clock faults.
Symptom
IP clock links may fail to be set up and the BTS may fail to lock the IP clock. When the preceding
faults occur, the alarms in Table 11-19 may be reported.
GBSS14.0
319
Table 11-19 Alarms related to IP clock faults
Alarm ID Alarm Name
26262 ALM-26262 External Clock Reference
Problem
26263 ALM-26263 IP Clock Link Failure

l The recommended Huawei IP clock server versions are as follows:
IPCLK1000 V100R002C01SPC200 and later
The recommended versions apply on the IPCLK1000 V1 or V2 hardware platform.
NOTE
l The recommended versions support only the IEEE 1588v2 protocol.
l After the BTS3900 is upgraded to GBSS9.0, the recommended versions support only the IEEE
1588v2 protocol.
l After the BTS3900 or BTS3012 is upgraded to V900R011C00 in Abis over IP, the IP clock server
version must match the BTS version.
l Digital-to-analog (DA) value
A phase-locked loop (PLL) for clock is a self-compensation system. It controls the voltage
output to adjust the oscillator for generating an output signal based on the DA value. The
DA value is derived from the frequency offset between the clock source and the current
clock.
Location Procedure
l IP Clock Link Setup Failures
Figure 11-15 shows the procedure for locating IP clock link setup failures.
GBSS14.0
320
Figure 11-15 Procedure for locating IP clock link setup failures

l IP Clock Lock Failures
Figure 11-16 shows the procedure for locating IP clock lock failures.
GBSS14.0
321
Figure 11-16 Procedure for locating IP clock lock failures

NOTE
support.
Table 11-20 Location information about IP clock faults
an MSC).

2 Operations
before and
after the
fault occurs
modification.

GBSS14.0
322
3 Faulty NE
version
For details
about how
to obtain
the BSC
and BTS
software
versions
that are
used when
the fault
occurs, see
15
Appendix
: How to
Collect
Fault
Informati
on.
4 Historical
alarms
For details
about how
to obtain
the
historical
alarms,
see 15
Appendix
: How to
Collect
Fault
Informati
on.
5 Configurati
on data
script
fault occurs.
For details
about how
to obtain
the
configurat
ion data
script, see
15
Appendix
: How to
Collect
Fault
Informati
on.
GBSS14.0
323
6 PING IP
command
output
command output.
NOTE
the ping switch.

7 Status of the
clock link
Run the MML command DSP BTSIPCLK and view
the command output.

l IP Clock Link Setup Failures
1. Check whether the BTS IP address can be pinged on the IP clock server LMT. If the
BTS IP address cannot be pinged, rectify the fault by referring to 11.1
Troubleshooting FE/GE Transmission Faults and 11.2 Troubleshooting IP Layer
Faults. Then, check whether the fault is rectified. If the fault persists, go to Step 2.
2. Run the MML command DSP LICUSAGE to check whether the IP clock license is
available. If the IP clock license is not available, apply for a license file. Then, check
whether the fault is rectified. If the fault persists, go to Step 3.
3. Check whether the data configurations for the clock are correct.
Run the MML commands LST BTSIPCLKPARA, DSP BTSCLK, and DSP
BTSBRD on the BSC LMT to check whether Clock Protocol Type is configured
correctly (for example, the 1588v2 precision time protocol (PTP)). Also, check
whether the IP address of the clock source is configured correctly and whether the
Domain values of the two ends are the same. To query the Domain value, run the
MML command DSP PTPPARA on the Huawei IP clock server LMT.
In Layer 3 networking mode, run the MML command LST BTSIPRT on the BSC
LMT to check whether the route to the IP clock server is configured.
If the IP clock servers are configured in active/standby mode, check whether the
routes to the IP clock servers are configured.
Check whether the VLAN configurations for the uplink and downlink are
consistent with those on the transport network.
Run the MML command LST SRVVLANPARA on the IP clock server LMT
to query the VLAN configurations for the downlink.
Run the MML command LST BTSVLAN on the BSC LMT to query the
VLAN configurations for the uplink.
If the VLAN configurations for the uplink and downlink are inconsistent with those
on the transport network, correct the VLAN configurations. Then, check whether
the fault is rectified. If the fault persists, go to Step 4.
4. Check whether the IP clock server is operating properly.
GBSS14.0
324
a. Run the MML command LST SOFTWARE on the IP clock server LMT to
check whether the IP clock version supports the configured clock protocol.
b. Check whether any alarms affecting clock packets are reported.
c. Run the MML command DSP BRD on the IP clock server LMT to check whether
the boards are operating properly.
d. Run the MML command DSP WORKSTATUS on the IP clock server LMT to
check whether the IP clock can send packets only when the server is running.
e. Run the MML command DSP ETHPORT on the IP clock server LMT to check
whether Ethernet ports are normal.
f. Run the MML command DSP ETHMAC on the IP clock server LMT to check
whether the media access control (MAC) address is lost.
If the IP clock server is faulty, rectify the faults. Then, check whether the fault is
rectified. If the fault persists, go to Step 5.
5. Check whether the data configurations for the IP clock server are correct.
a. Run the MML command DSP CLIENTMODE on the IP clock server LMT to
check whether the current client mode, Ethernet port type, and number of BTSs
meet the requirements.
b. In Layer 3 networking mode, run the MML command LST IPRT on the IP clock
server LMT to check whether the route to the client is configured.
If the data configurations for the IP clock server are incorrect, correct them. Then,
check whether the fault is rectified. If the fault persists, go to Step 6.
6. Locate the faulty NE.
Run the MML command DSP BTSIPCLK on the BSC LMT to check the status of
the BTS clock links. An example of the command output is as follows:
DSP BTSIPCLK: IDTYPE=BYID, BTSID=0;
DSP BTSIPCLK Link Status Result
-------------------------------
Client IP Server IP Link State Active State
10.100.2.9 10.100.100.1 DOWN Not Activated
The link status is closely related to the clock packet interaction between the IP clock
and the BTS. Figure 11-17 shows the procedure for clock packet interaction between
the IP clock and BTS.
GBSS14.0
325
Figure 11-17 Procedure for clock packet interaction between the IP clock and BTS

If Link State is UP, link maintenance packets can be sent between the IP clock and
BTS clock. This means that the first four steps shown in the preceding figure are
performed.
The activation status refers to the status of sending or receiving clock synchronization
packets. If clock synchronization packets are sent or received successfully, the link
activation succeeds. This indicates that interactions in Steps 5 through 7 shown in
Figure 11-17 are performed successfully. If no clock synchronization packets are sent
or received, the link activation has failed.
If Link State is DOWN, trace IP clock messages and capture packets on the BTS
mirrored port.
NOTE
To trace IP clock messages, perform the following operations:
1. Log in to the IP clock server LMT, select Trace Management in the maintenance
window, and double-click IPCLK_TRACE.
2. In the displayed window, type the BTS IP address in ClientIP. Type 319 or 320 in
CLIENT PORT to trace packets on any port for five minutes. Port 320 is used to trace
link setup packets and port 319 is used to trace clock packets.
3. Check whether signaling can be traced on the ports and whether any interaction
operations fail to be performed in any step. If any packets fail to be sent, an NE may
be faulty. In this situation, Contact Huawei Customer Service Center. If packets are
sent but fail to be received, the transport network may be faulty. In this situation, locate
the NE that discards packets.
If Link State is UP and Activate State is Not Activated, start message tracing by
using the method shown in Note and check whether Step 5, 6, or 7 shown in Figure
11-17 fails to be performed.
If any packets fail to be sent, certain NEs may be faulty. In this situation, Contact
Huawei Customer Service Center.
If packets are sent but fail to be received, the transport network may be faulty.
In this situation, locate the NE that discards packets.
GBSS14.0
326
CAUTION
Check whether packets are lost on the transmission device close to the BTS or the
transmission device connected to the IP clock server based on the captured packets.
Check whether the BTS has sent any request packets by capturing packets on the
transmission device close to the BTS. You are advised to use Hub to capture packets.
If the BTS has not sent any request packets, contact Huawei for technical support. If
the BTS has sent request packets, certain request packets may be discarded by the
transport network. If there is no Hub or switch between the BTS and the transmission
device, use the Huawei proprietary protocol as the BTS IP clock protocol. Then, check
whether clock packets can be captured on the transmission device that is closest to the
BTS. If any clock packets can be captured, the transmission device may have discarded
some clock packets.
After the preceding operations are performed, the faulty NE can be located. If the
transmission device does not discard any packets, go to Step 7.
l IP Clock Lock Failures
1. Check whether the BTS DA value is correct.
Run the MML command DSP BTSBRD on the BSC LMT to query the DA value. If
the BTS fails to lock the IP clock because of an incorrect DA value and the
ALM-26262 External Clock Reference Problem is reported, run the MML command
SET BTSCLKPARA on the BSC LMT to change the DA value or turn off the trace
range restriction switch. If the fault persists, go to Step 2.
2. Check whether clock synchronization packets are sent successfully.
a. Run the MML command DSP PTPPARA on the IP clock server LMT.
List protocol para
------------------
Cast Mode = Unicast
Domain = 0
Annouce = 1/64hz
Sync = 16hz
Receipt = 3
Priority1 = 128
priority2 = 128
The recommended send rate for clock synchronization packets is 16 Hz. Restart
the IP clock server after setting this parameter.
b. View the messages traced on the IP clock server to check whether clock
synchronization packets are sent successfully. For details, see the description of
IP Clock Link Setup Failures.
c. Run the MML command DSP IPCLKLNK on the IP clock server LMT. View
the number of clock synchronization packets sent on the link specified in the
MML command and check whether clock synchronization packets are sent
successfully.
d. Capture packets on the transmission device close to the IP clock to check whether
clock synchronization packets are sent successfully. If clock synchronization
packets fail to be sent, modify the data configurations or Contact Huawei
Customer Service Center to resolve the IP clock fault. Then, check whether the
fault is resolved. If the fault persists, go to Step 3.
GBSS14.0
327
3. Check whether the quality of service (QoS) indicator of the transport network is
normal and whether the jitter is too large. If the jitter is too large, improve the transport
network quality. Then, check whether the fault is rectified. If the fault is not rectified,
go to Step 4.
Typical Case
Symptom
An IP clock link fails to be set up, but the IP address for the communication between the IP clock
and the BTS can be pinged.
Cause Analysis
l The IP clock version may not be supported.
l Certain NEs may process clock packets abnormally.
l The transmission device may discard packets.
1. Check the IP clock version. The IP clock version meets the requirements.
2. Trace messages on both the IP clock and BTS. The BTS constantly sends the Announce
request messages, but the IP clock does not receive any messages. This indicates that the
Announce request messages fail to be received on the IP clock server. The possible cause
may be that the transmission device discards packets.
3. Locate the faults in NEs. The location result shows that a switch imposes limitations on the
1588v2 clock packets, which results in packet losses. After the limitations are removed,
the BTS locks the IP clock successfully.
GBSS14.0
328
12 Interference Problems
About This Chapter
This chapter describes how to locate and troubleshoot interference problems.
12.1 Interference
Interference affects many aspects of network performance, such as voice quality, network
coverage and capacity, as well as the call drop rate, handover success rate, and congestion rate.
Reducing or eliminating interference is critical to network planning and optimization.
12.2 Locating Interference Problems
This section describes how to locate interference problems.
12.3 Troubleshooting Co-channel or Adjacent-Channel Interference
This section describes how to troubleshoot co-channel or adjacent-channel interference.
12.4 Troubleshooting Intermodulation Interference
This section describes how to troubleshoot intermodulation interference.
12.5 Troubleshooting Interference from the CDMA Network
This section describes how to troubleshoot interference from the CDMA network.
12.6 Troubleshooting External Interference
This section describes how to troubleshoot external interference.
GBSS14.0
Troubleshooting Guide 12 Interference Problems
329
12.1 Interference
Interference affects many aspects of network performance, such as voice quality, network
coverage and capacity, as well as the call drop rate, handover success rate, and congestion rate.
Reducing or eliminating interference is critical to network planning and optimization.
Generation of Interference
To expand the GSM network capacity, frequencies must be reused. Frequency reuse enables
cells that are far enough away from each other to use the same frequency. The distance between
the cells is the reuse distance, and the ratio of the reuse distance to the cell radius is the reuse
factor. Reuse of a large number of frequencies increases the network capacity. However,
interference increases as the reuse distance decreases.
There are two types of interference on the GSM network: internal interference or intra-system
interference, and external interference. Interference caused by frequency reuse is internal
interference. Other types of internal interference include intermodulation, spurious, and blocking
interference. Interference from other network systems, such as CDMA or other radio devices,
is external interference.
NOTE
l Intermodulation interference is when a receiver receives multiple strong signals and the front-end non-
linear components of the receiver have intermodulation products on the available frequency bands.
l Blocking interference is when non-linear signal distortion occurs because both undesired strong
interference signals and desired signals saturate the non-linear components of the receiver.
l Spurious interference is when interference sources cause additive interference to the working frequency
band of a receiver. Additive interference includes out-of-band frequency leakage, amplified noise floor,
and intermodulation signals. Spurious interference decreases the signal-to-noise ratio and increases the
noise floor of the receiver.
Impact of Interference
Strong network interference may have the following impacts on calls:
l Calls fail to be set up even if signals can be received properly. Poor uplink quality leads to
unclear voice signals for the called MS.
l Both originated- and terminated-calls fail to be set up. A call easily drops after the prompt
tone starts.
Strong network interference has the following impacts on traffic statistics:
l Uplink interference is detected by using interference band traffic statistics along with the
interference band thresholds and usage scenarios. For example, if interference band 2 is
recorded in traffic statistics for boundary networks with loose frequency reuse, interference
may occur. If interference band 4 or 5 is recorded in traffic statistics for urban areas with
tight frequency reuse, strong interference may occur.
l The values of RA303G:Success Rate of Immediate Assignments and RCA313:Assignment
Success Rate are small.
l The values of ZTR104C:Call Drop Rate on SDCCH and ZTR304:Call Drop Rate on TCH
per cell(including Handover) are large.
l The value of RH303:Handover Success Rate is small.
GBSS14.0
330
l The measurement results of TCHF Receive Level Measurement and TCHH Receive Level
Measurement show a large proportion of calls with high level and low receive quality.
The drive test results are as follows:
l A large number of call drops occur on the Um interface.
l Frequent handovers occur and the number of failed handovers increases.
l There are a large number of calls with high receive level and low receive quality.
12.2 Locating Interference Problems
This section describes how to locate interference problems.
Principles for Locating Interference Problems
The following are common types of uplink interference on the GSM network:
l Passive intermodulation interference
l Co-channel interference or adjacent-channel interference
l Interference from repeaters
l Interference from the CDMA network
l External interference
Use the interference characteristics to determine the interference type.
The maintenance functions related to interference are as follows:
l 3.3.2 Testing Passive Intermodulation Interference Online
l 3.3.3 Scanning Frequency Spectrum Online
Procedure for Locating Interference Problems
Figure 12-1 shows the procedure for locating interference problems.
GBSS14.0
331
Figure 12-1 Procedure for locating interference problems

NOTE
support.
Table 12-1 Interference problem location information
an MSC).

GBSS14.0
332
2 Operations
before and
after the
problem
occurs
modification.

3 Faulty NE
version
For details
about how
to obtain
the BSC
and BTS
software
versions
that are
used when
the
problem
occurs, see
15
Appendix
: How to
Collect
Fault
Informati
on.
4 Result of an
online
passive
intermodula
tion
interference
test
Obtain the result of an online passive intermodulation
interference test within two hours since the early
morning.
For details
about how
to obtain
the result
of an
online
passive
intermodu
lation
interferen
ce test, see
3.3.2
Testing
Passive
Intermod
ulation
Interfere
nce
Online.
GBSS14.0
333
5 Online
frequency
spectrum
scanning
result
Obtain the result of online frequency spectrum
scanning within two hours since the interference
occurs.
For details
about how
to obtain
the online
frequency
spectrum
scanning
result, see
3.3.3
Scanning
Frequenc
y
Spectrum
Online.

NOTE
Only one of the forth to fifths items in Table 12-1 can be performed in a cell once. These items must be
executed in succession.
12.3 Troubleshooting Co-channel or Adjacent-Channel
Interference
This section describes how to troubleshoot co-channel or adjacent-channel interference.
Symptom
As with intermodulation interference, co-channel interference or adjacent-channel interference
during peak hours greatly differs from that during off-peak hours. However, co-channel or
adjacent-channel interference does not affect the downlink power of interfered cells because
these types of interference are caused by MSs in other cells.
Frequencies must be reused in GSM networks. If a reuse distance is smaller than the cell radius,
co-channel or adjacent-channel interference may occur. Other causes such as clutter reflection
may also lead to co-channel or adjacent-channel interference. If the carrier-to-interference ratio
(C/I) is less than 12 dB or the carrier-to-adjacent ratio (C/A) is less than -6 dB, there is
interference on the networks.
Location Procedure
Perform frequency scan by referring to 3.3.3 Scanning Frequency Spectrum Online and check
whether co- or adjacent-channel interference occurs according to the frequency spectrum
characteristics.
If co- or adjacent-channel interference occurs, locate it by referring to Figure 12-2.
GBSS14.0
334
Figure 12-2 Procedure for locating co-channel or adjacent-channel interference

1. Check whether co-channel or adjacent-channel interference occurs in a cell.
Import the engineering parameters of both serving cell and neighboring cells into a
frequency analysis tool, and use the frequency check function to check whether some
neighboring cells share the same or adjacent ARFCN that causes the strongest interference
with the serving cell.
l If yes, change the ARFCN that causes the strongest interference. Then, go to Step 2.
l If no, perform operations according to section Procedure for Locating Interference
Problems.
2. Check Interference Band Measurement per TRX(MR.Iterf.TRX) and determine whether
the interference band decreases.
l If no, see Procedure for Locating Interference Problems.
Typical Case
Symptom
Dialing tests are conducted by locking the ARFCNs of some cells. The test results show that
voice quality is acceptable for calls that use the traffic channel (TCH) on broadcast control
channel (BCCH) TRXs of the cells but is poor for calls that use the TCHs on non-BCCH TRXs
of the cells.
Cause Analysis
Adjacent-channel interference occurs between the BCCH TRXs and the non-BCCH TRXs. To
resolve this problem, replan the ARFCNs.
GBSS14.0
335
1. Check Interference Band Measurement per TRX(MR.Iterf.TRX) of these cells. The
interference band decreases during off-peak hours whereas the interference band increases
during peak hours. This indicates that the cells are experiencing uplink interference.
2. Perform dummy burst tests in the cells during off-peak hours. The test results show that
the interference band does not increase noticeably, indicating that the adjacent-channel
interference in these cells is the major source of interference.
3. Check the frequency plan. The cells in urban areas use 1x3 frequency reuse mode and
frequency hopping (FH). The ARFCN for the BCCH TRXs of the cells with blocked
ARFCNs is 111. In FH mode, the ARFCNs for the non-BCCH TRXs of the cells are 98,
101, 104, 107, and 110. ARFCN 111 for the BCCH TRXs is adjacent to ARFCN 110 for
the non-BCCH TRXs.
4. Make calls to occupy TCHs on the BCCH TRXs. ARFCN 110 configured for the non-
BCCH TRXs causes little adjacent-channel interference and has little impact on voice
quality.
5. Make calls to occupy TCHs on the non-BCCH TRXs. The BCCH TRXs continuously
transmit signals and therefore the decreasing strength of uplink and downlink signals due
to power control causes strong adjacent-channel interference and greatly impacts voice
quality.
6. Change the hopping sequence for these cells. Voice quality on the non-BCCH TRXs
improves.
12.4 Troubleshooting Intermodulation Interference
This section describes how to troubleshoot intermodulation interference.
Symptom
Passive intermodulation interference is broadband interference caused by the downlink signals
in the BTS antenna system. This type of interference is closely related to BTS downlink transmit
power and cell traffic.
According to the traffic statistics on interference bands, the passive intermodulation interference
is stronger during peak hours than during off-peak hours. However, passive intermodulation
interference cannot be determined simply by the difference in strength between peak and off-
peak hours. Co-channel or adjacent-channel interference or interference from the CDMA
network is also stronger during peak hours than during off-peak hours.
Determine the interference type by referring to 3.3.2 Testing Passive Intermodulation
Interference Online and 3.3.3 Scanning Frequency Spectrum Online.
When two radio frequency (RF) signals are received by a non-linear device or discontinuous
transmission medium, new absolute radio frequency channel numbers (ARFCNs) are generated.
The formula for determining the relationship between input signals and intermodulation products
based on the typical non-linear model is as follows:
x indicates the input signals and f(x) indicates the final products. When two monophonic signals
are used as input signals, new ARFCNs are also generated. Signals from the new ARFCNs are
considered intermodulation products.
GBSS14.0
336
Based on the trigonometric sum-to-product formulas, the intermodulation results of the non-
linear products (X1^2) x X2 and X1 x (X2^2) are as follows: The third-order intermodulation
products are 2f1-f2 and 2f2-f1, the fifth-order intermodulation products are 3f1-2f2 and 3f2-2f1,
or the seventh-order intermodulation products are 4f1-3f2 and 4f2-3f1. The intermodulation
results at other levels are calculated the same way. Generally, the higher the intermodulation
level, the lower the frequencies of the intermodulation products.
The antenna is a passive device used to transmit RF signals. The possible causes of
intermodulation in an antenna system are as follows:
l The antenna connectors are dirty or damaged; the interior silver coating of antenna feeders
is damaged; or metal filings are left in the connectors due to frequent reassembling.
l The antenna connectors are not securely connected or sealed.
l The half-wave dipole sealed in the antenna protective cover is corroded.
l The feeder that connects the antenna connectors to the half-wave dipole is corroded.
l The feeder and jumper are not routed properly. There is stress in the connectors.
Location Procedure
If intermodulation interference occurs, locate it by referring to Figure 12-3.
GBSS14.0
337
Figure 12-3 Procedure for locating intermodulation interference
GBSS14.0
338

1. Check whether any BTS connectors are loose.
Check all the BTS connectors, including the connectors of cables between the combiner
and TRXs, for both the uplink and downlink.
l If yes, tighten the connectors. Screw down the connectors using a wrench turned at an
angle of less than 90 degrees. Then, go to Step 2.
2. Check whether the intermodulation interference is eliminated.
3. Check whether the combiner is faulty.
Check whether the interference affects channel A or channel B of the DDPU. For 3012
series base stations, the DFCU and DDPU implement signal combining. For 3006C series
base stations, the DDPM implements signal combining. For 3900 series base stations, the
signal combining function is integrated into the TRX boards.
l If yes, replace the faulty DDPU. Then, go to Step 4.
5. Check whether the CDMA network filter is faulty.
l If yes, replace the faulty CDMA network filter. Then, go to Step 6.
7. Check whether the surge protector is faulty.
l If yes, replace the faulty surge protector. Then, go to Step 8.
9. Check whether the coupling repeater is faulty.
l If yes, disconnect the faulty coupling repeater from the problem cell. Then, go to Step
10.
l If the coupling repeater is not installed or is faulty, go to Step 11.
11. Check whether the upper jumper, lower jumper, or jumper connector is faulty.
GBSS14.0
339
If there is a spectrum analyzer whose noise floor is less than -90 dBm and whose scanning
speed is less than 0.1s, connect the spectrum analyzer to the uplink output connector of the
combiner. Then, gently shake the antenna jumper for about 30 seconds. Ensure that the
distance between the connector and the shaking point is 20 to 40 cm, the amplitude is 3 to
5 cm, and the frequency is 1 Hz.
l If yes, replace the faulty jumper. Gently shake the connector between the new jumper
and the feeder. If the noise floor of the receive band changes irregularly, reassemble the
feeder connector. Then, go to Step 12.
If the spectrum analyzer does not meet the requirements, replace the uplink and downlink
jumpers, and reassemble the feeder connector. Then, go to Step 12.
13. Check the antenna of the problem cell.
l Switch the antennas of the problem cell and the neighboring cell, or replace the faulty
antenna. Then, go to Step 14.
l If no, the feeder may be faulty but this rarely occurs. If the problem persists after the
faulty antenna is replaced, see Procedure for Locating Interference Problems.
Typical Case
Symptom
As displayed on the site maintenance terminal (SMT), a cell under a BTS working on the 900
MHz frequency band is persistently affected by interference band 5. Traffic statistics collected
for a few weeks also indicate that interference band 5 persists. In addition, cells under another
BTS in the same coverage area of the antenna for the problem cell are also interfered. However,
the interference persists even after the ARFCNs are replanned.
Cause Analysis
The performance of the antenna system deteriorates.
1. Replan frequencies in the problem cell and observe the traffic statistics on frequency
scanning. The interference persists after the frequency replanning, and all three ARFCNs
of the cell are changed. Therefore, there is a low probability that frequency replanning
caused the interference. In addition, the main and diversity signal levels of ARFCNs on all
the frequency bands exceed -80 dBm, which indicates that the interference is not caused
by improper frequency planning.
2. Conduct tests on site. The voltage standing wave ratio (VSWR) and the TRX power are
normal, but the interference persists after the TRXs and DDPUs of the problem cell and a
normal cell are switched. This indicates that the interference is not caused by hardware
faults.
3. Conduct drive tests in the surrounding areas of the BTS. The voice quality is poor (level
7) when a call is set up only in the problem cell. The voice quality is good when a call is
GBSS14.0
340
set up in other cells. This indicates that the interference is not caused by external
interference.
4. Check the antenna system on the rooftop. The horizontal spacing between antennas of the
900 MHz and 1800 MHz cells exceeds 5 m, indicating that the interference is not caused
by antenna spacing. The type of antennas for one 900 MHz cell is different from the other
cells and this type of antenna looks older than others. Therefore, antennas of this type might
be faulty. After the antennas of the problem cell and a normal cell are switched, the
interference disappears from the problem cell but occurs in the normal cell. This indicates
that the interference is caused by faulty antennas.
5. Replace the faulty antennas. The interference is eliminated.
12.5 Troubleshooting Interference from the CDMA
Network
This section describes how to troubleshoot interference from the CDMA network.
Symptom
Interference from the CDMA network is generated when the CDMA downlink signals block the
GSM 900 MHz uplink frequency bands or reach the GSM receivers at GSM uplink receive
frequency bands (885 MHz to 925 MHz).
There is only a slight difference in the level of interference from the CDMA network between
peak hours and off-peak hours. CDMA downlink signals are transmitted at the frequency band
of 870 MHz to 880 MHz. The smaller the uplink absolute radio frequency channel number
(ARFCN) configured for TRXs, the stronger the interference. Figure 12-4 shows an example
of the CDMA interference spectrum scanned using the uplink frequency scanning function.
Figure 12-4 CDMA interference spectrum

GBSS14.0
341
CDMA 800 MHz frequency bands and GSM 900 MHz frequency bands use adjacent
frequencies. If the CDMA network is not sufficiently isolated from GSM BTSs, interference
may be generated. In particular, the CDMA downlink signals are likely to affect GSM 900 MHz
uplink frequency bands, increasing the receive noise floor. The closer the CDMA downlink
signals are to GSM frequency bands, the lower the anti-interference capability of the GSM
network. The smaller the ARFCNs configured for TRXs, the stronger the interference. The types
of CDMA network interference are as follows:
l Blocking interference
Blocking interference, also known as intermodulation interference, is generated when
strong CDMA downlink signals are received by the GSM receivers. This type of
interference is determined by detecting uplink receive signals using a spectrum analyzer.
Generally, if the level of the detected CDMA downlink signals exceeds -20 dBm, GSM
uplink receive quality is affected.
l Tailing interference
Tailing interference, also known as spurious interference, is a type of co-channel
interference generated when CDMA transmit signals are received on GSM uplink
frequency bands. This type of interference can be detected using uplink frequency scanning.
If the noise floor of the TRXs configured with smaller ARFCNs is higher whereas the noise
floor of the TRXs configured with larger ARFCNs is lower, tailing interference or spurious
interference is generated.
To prevent the signals generated on CDMA 800 MHz frequency bands from affecting GSM 900
MHz frequency bands, use one of the following methods:
l Add frequency guard bands.
This optimizes the spurious emission performance of power amplifiers, and the blocking
and intermodulation performance of receivers. This is the optimal method for eliminating
interference from the CDMA network, but the spectrum utilization decreases.
l Increase the antenna isolation.
The antenna isolation is closely related to antenna position, height, downtilt, and polar
diagram.
During installation, the antenna isolation must exceed 50 dB. The formulas for calculating
the horizontal and vertical antenna isolation are as follows:
Horizontal antenna isolation = 22 + 20 x log(dh/) + G1 + G2 + g1 + g2
Vertical antenna isolation = 28 + 40 x log(dV/)
dh indicates the horizontal spacing, dv indicates the vertical spacing, G1 and G2 indicate
the gains of the transmit antenna and receive antenna in the maximum radiation direction,
g1 and g2 indicate the relative gains of the transmit antenna and receive antenna in the
connection direction, and indicates the carrier wavelength.
According to the two formulas, the vertical antenna isolation is generally larger than the
horizontal antenna isolation. Therefore, place the transmit antenna 2 m away from the
receive antenna vertically when CDMA and GSM are co-sited. The relative gains of the
transmit antenna and receive antenna should be as small as possible when CDMA and GSM
are not co-sited or the antennas are installed at the same height. To ensure small relative
gains for the transmit and receive antennas, the main lobes of the two antennas must be
parallel or the back lobes of one antenna must face the other antenna with a horizontal
spacing of 6 m or more.
l Install filters.
GBSS14.0
342
This helps to eliminate spurious interference from the CDMA network, or blocking and
intermodulation interference from the GSM network, but requires additional installation
costs.
Location Procedure
whether interference on the CDMA network occurs according to the frequency spectrum
characteristics.
Figure 12-5 shows the procedure for locating interference from the CDMA network.
Figure 12-5 Procedure for locating interference from the CDMA network

1. Check whether blocking interference is generated.
l If yes, install a CDMA network filter on the GSM BTS. Then, go to Step 2.
2. Check whether the interference from the CDMA network is eliminated.
3. Check whether spurious interference is generated.
l If yes, install a filter or optimize the antenna system on the CDMA network. Then, go
to Step 4.
GBSS14.0
343
4. Check whether the interference from the CDMA network is eliminated.
Typical Case
Symptom
Voice quality deteriorates in several cells under a GSM BTS in a city. According to the traffic
statistics analysis, the high quality indicator (HQI) decreases, the percentage of interference
bands 3 to 5 increases, the radio access success rate decreases, and the call drop rate increases
in these cells. This indicates that the network performance is severely affected.
Cause Analysis
The frequency scanning results show that both E-GSM frequency bands (800 MHz to 890 MHz)
and P-GSM frequency bands (890 MHz to 915 MHz) are affected by interference. The smaller
the ARFCNs configured for TRXs, the stronger the interference. The frequencies of the CDMA
transmit signals range from 870 MHz to 880 MHz and a CDMA antenna is installed 5 m away
from the GSM antenna. Therefore, you determine that the interference in the problem cells is
from the CDMA network.
Install a CDMA network filter on the GSM BTS and perform a dialing test. The dialing test
results show that the voice quality is good, the uplink HQI increases to about 95%, the percentage
of interference bands 3 to 5 decreases noticeably, and the related counters return to normal.
12.6 Troubleshooting External Interference
This section describes how to troubleshoot external interference.
Symptom
External interference is generated irregularly and its sources are difficult to identify. To locate
the sources of external interference, analyze long-term traffic statistics on interference bands to
find out at what time external interference occurs, and scan frequencies when external
interference is most likely to be generated.
l Interference from repeaters
Repeaters are used to extend the BTS coverage during the early phase of network
deployment. However, a repeater may cause interference to BTSs in the following
situations:
The donor antenna and the service antenna are not sufficiently isolated because the
repeaters are not installed properly. This causes self oscillation and affects the BTS.
The intermodulation signal level of repeaters using non-linear wideband amplifiers is
much greater than the standard level. Repeaters working at high power are likely to
cause strong intermodulation interference to neighboring BTSs.
GBSS14.0
344
Cascaded repeaters amplify the same frequency of the transmitted signals, which causes
a delay for signal transmission. If the delay exceeds the specified time window, co-
channel interference is generated.
Repeaters are generally the main cause of external interference, especially in metropolitan
areas.
l Interference from radar stations
The decimeter wave radar of the 1970s or 1980s uses frequencies that are the same as or
adjacent to GSM frequencies. The decimeter wave radar transmits at between tens to
hundreds of kilowatt power, causing a great volume of out-band spurious emissions as well
as interference to neighboring BTSs.
l Interference from cordless telephone sets operating at 900 MHz
In certain areas, the bandwidth for analog 900 MHz cordless telephones is 30 kHz and the
bandwidth for digital 900 MHz cordless telephones is 2 MHz. These telephones transmit
signals between 902 MHz to 920 MHz in frequency hopping (FH) mode. Therefore, if an
outdoor antenna provides high power for these telephones, it may cause interference to
neighboring BTSs.
l Interference from other radio devices or interference generators on the same frequencies
Certain types of radio devices use GSM frequency resources, which may cause interference
to neighboring BTSs.
Location Procedure
whether external interference (such as full-band wideband interference from the interference
unit) occurs according to the frequency spectrum characteristics.
If external interference occurs, locate it by referring to Figure 12-6.
Figure 12-6 Procedure for locating external interference

GBSS14.0
345
1. Check whether there are external interference sources.
Identify the external interference sources by analyzing 24-hour or even 7-day traffic
statistics on uplink interference bands for all the cells.
Signals from one interference source may affect multiple cells. Therefore, traffic statistics
on interference bands for neighboring cells are also required. If the interference affects
multiple cells and is eliminated from multiple cells at the same time, these cells are probably
affected by the same interference source. Knowing this helps locate the interference source.
a. To locate the interference source onsite, perform the following operations: 1. Place a
Yagi antenna and a scanner on a rooftop in a problem cell when the interference is the
strongest. Connect the Yagi antenna to the scanner with the frequency range set to
870 MHz to 915 MHz. 2. Use the Yagi antenna to scan for interference in different
directions and monitor the frequencies of interference signals displayed on the
scanner. 3. Use a compass to locate the source of the strongest interference and keep
a record of the direction. Then, change the Yagi antenna direction to within 30 degrees
of the line indicating the direction of the strongest interference source and observe the
interference amplitude for 2 to 5 minutes. Then, repeat steps 1 through 3 in other
problem cells and use the Yagi antenna to triangulate the location of the source of the
strongest interference.
b. To locate the interference source in the surrounding areas of a problem site, you can
carry a Yagi antenna and a scanner to the most likely location of an interference source.
Search for the interference source in places free of obstacles, such as buildings, to
narrow down the search range. You need to determine whether there are schools,
government offices, or public security agencies in the search area because they may
use interference devices. Then, repeat the preceding operations in all other areas where
interference sources are likely to exist until you find the interference source.
l If yes, eliminate the external interference sources. Then, go to Step 2.
2. Check whether external interference is eliminated.
Typical Case
Symptom
The traffic statistics displayed on the M2000 show that the call drop rate increases noticeably.
The LMT shows that the interference bands for all channels in cell 1 are band 3.
Cause Analysis
This problem is caused by the interference from a television station antenna.
1. Change the absolute radio frequency channel numbers (ARFCNs) and FH groups for the
cell. The problem persists. Therefore, this problem is not caused by co-channel or adjacent-
channel interference.
2. Switch the feeders for cell 1 (a severely interfered cell) and cell 2 (a normal cell) to the
jumper connectors of the DDPU. All the channels in cell 1 can process services properly
GBSS14.0
346
but the interference band in cell 2 changes to band 3. Therefore, the antenna connections
are correct and the problem may be caused by the feeder or antenna configuration.
3. Switch the jumpers for cell 1 and cell 2 to the antenna connectors. All the channels in cell
1 return to normal but all the channels in cell 2 are affected by interference band 3. In
addition, the antenna was only recently installed. Therefore, this problem may be caused
by external interference.
4. A television antenna is installed on the tower where the antenna for cell 1 is located and
the output power of the television antenna was increased from 200 W to 500 W recently.
Power off the television antenna. The interference is eliminated immediately.
GBSS14.0
347
13 Faults on Main and Diversity RX
Channels
About This Chapter
This chapter describes how to locate and troubleshoot faults on main and diversity receive (RX)
channels.
13.1 Principles of Main and Diversity Reception
When main and diversity RX channels are faulty, related alarms are reported.
13.2 Locating Faults on Main and Diversity RX Channels
This section describes how to locate faults on main and diversity RX channels.
13.3 Troubleshooting Faults on Main and Diversity RX Channels Due to Incorrect Data
Configurations
This section describes how to troubleshoot faults on main and diversity RX channels due to
incorrect data configurations.
13.4 Troubleshooting Faults on Main and Diversity RX Channels Due to Incorrect Antenna
Connections
incorrect antenna connections.
13.5 Troubleshooting Faults on Main and Diversity RX Channels Due to Hardware Faults
hardware faults.
GBSS14.0
Troubleshooting Guide 13 Faults on Main and Diversity RX Channels
348
13.1 Principles of Main and Diversity Reception
When main and diversity RX channels are faulty, related alarms are reported.
The alarms related to main and diversity RX channels are ALM-4176 Main receive channel
alarm and ALM-4178 Diversity receive channel alarm. The alarms can be triggered only when
there is a certain amount of traffic. Therefore, do not check for faults on main and diversity RX
channels during off-peak hours, such as in the early morning.
If TRXs are in main and diversity RX mode:
l When the main RX signal level is lower than the diversity RX signal level and the difference
exceeds the upper threshold (32 dB), the alarm ALM-4176 Main receive channel alarm is
reported.
l When the diversity RX signal level is lower than the main RX signal level and the difference
exceeds the upper threshold (32 dB), the alarm ALM-4178 Diversity receive channel alarm
is reported.
Only the main or diversity RX channels receive signals when the alarms related to diversity or
main RX channels are reported. As a result, the BTS coverage decreases.
13.2 Locating Faults on Main and Diversity RX Channels
This section describes how to locate faults on main and diversity RX channels.
Principles of Locating Faults on Main or Diversity RX Channels
When an alarm related to main and diversity RX channels is reported, check for the following
problems or faults:
l Incorrect data configurations
l Incorrect feeder connections
l Hardware faults
Procedure for Locating Faults on Main and Diversity RX Channels
Figure 13-1 shows the procedure for locating faults on main and diversity RX channels.
GBSS14.0
349
Figure 13-1 Procedure for locating faults on main and diversity RX channels

NOTE
support.
Table 13-1 Location information about faults on main or diversity RX channels
1 Symptom Provide the start time and end time of the
fault, specific symptom, and impact range
(whether the fault occurs in a cell, a BTS,
a BSC, or all BSCs under an MSC).

2 Operations
before and
after the fault
occurs
Provide the operations before and after the
fault occurs, such as board replacement,
software upgrade, clock source change,
dynamic data configuration, BTS reset,
BSC reset, MSC swapping, and MSC data
modification.

GBSS14.0
350
3 Faulty NE
version
Obtain the BSC and BTS software
versions that are used when the fault
occurs.
For details about how to
obtain the BSC and
BTS software versions
that are used when the
fault occurs, see 15
Appendix: How to
Collect Fault
Information.
4 Configuratio
n data script
Obtain the configuration data script used
when the fault occurs.
obtain the
configuration data
script, see 15
Appendix: How to
Collect Fault
Information.
5 BTS logs Obtain all logs for all faulty BTSs. For details about how to
obtain BTS logs, see 15
Appendix: How to
Collect Fault
Information.
6 Original
traffic
statistics
Obtain the original traffic statistics
measured within consecutive four hours
during the peak hours when the fault
occurs.
obtain the original
traffic statistics, see 15
Appendix: How to
Collect Fault
Information.
7 Historical
alarms
Obtain the historical alarms generated in
the day when the problem occurs.
obtain the historical
alarms, see 15
Appendix: How to
Collect Fault
Information.

13.3 Troubleshooting Faults on Main and Diversity RX
Channels Due to Incorrect Data Configurations
Symptom
Alarms such as ALM-4176 Main receive channel alarm and ALM-4178 Diversity receive
channel alarm are reported.
GBSS14.0
351
l Single path: One board uses only one path to connect to the antenna.
l Double paths: One board uses two paths to connect to the antenna.
l 1TX or 2TX: One or two paths are used for transmitting signals.
l 2RX: Two paths are used for receiving signals.
l Power boost technology (PBT): One TRX is configured with one carrier. One radio
frequency (RF) signal from the TRX is divided into two small RF signals and then
transmitted to the power amplifier where the signals are combined and amplified.
l Transmit diversity: One baseband signal is divided into two signals to produce a multipath
effect, increasing the downlink RX signal level of an MS.
l 4-way diversity: The 4-way RX signals are transmitted to one carrier.
Location Procedure
Figure 13-2 shows the procedure for locating faults on main and diversity RX channels due to
Figure 13-2 Procedure for locating faults on main and diversity RX channels due to incorrect
data configurations

1. On the LMT, run the MML command LST GTRXDEV to check whether Receive
Mode and Send Mode match the physical connections.
GBSS14.0
352
l If no, run the MML command SET GTRXDEV to modify Receive Mode and Send
Mode according to the antenna configuration table. Then, go to Step 2.
2. Check whether the alarms related to the main and diversity RX channels are cleared.
3. Check whether the data configuration on the LMT matches the physical connections.
l For the BTS3012, check whether the number of paths required by carriers in send mode
is consistent with the number of paths provided by DDPUs. For example, if four paths
are required for a cell configured with four carriers and send mode set to No
Combining but only one DDPU is configured, the data configuration is incorrect. Run
the MML command LST BTSANTFEEDERCONNECT to query the configuration
for antenna connections. If the configuration is inconsistent with the physical
connections, run the MML command SET BTSANTFEEDERCONNECT to modify
the configuration.
l For the BTS3900, check whether the data configuration is consistent with the physical
connections based on TRX type. For example, if the only one carrier on a DRFU is
bound to path 0 on a TRX but the DRFU is actually connected to port TX2 on the TRX,
modify the data configuration or change the physical connections. Run the MML
command LST GTRX to query the TRX data configuration. If the data configuration
is inconsistent with the physical connections, run the MML command RMV
TRXBIND2PHYBRD to delete the binding relationship between the carriers and the
paths on the TRXs. Then, run the MML command ADD TRXBIND2PHYBRD to add
the binding relationship between the carriers and the paths on the TRXs.
l If no, modify the data configuration or change the physical connections. Then, go to
Step 4.
l If yes, return to Procedure for locating main and diversity receive channel faults.
4. Check whether the alarms are cleared.
l If no, return to Procedure for locating main and diversity receive channel faults.
Typical Case
Symptom
A cell under site A is configured with only one carrier and the carrier-related alarms ALM-4176
Main receive channel alarm and ALM-4178 Diversity receive channel alarm are reported.
Cause Analysis
The cell is configured with only one carrier and uses only one path to connect to the antenna.
Therefore, the cell cannot implement 2RX.
On the LMT, run the MML command SET GTRXDEV with Receive Mode set to
INDEPENDENT(Independent Receiver) and Send Mode set to DTIC(Transmit
Independency or Combination).
GBSS14.0
353
Channels Due to Incorrect Antenna Connections
Symptom
channel alarm are reported. The BTSs that report these alarms encounter problems. For example,
the BTS coverage decreases, MSs have difficulty accessing the network, call drops due to
handovers increase, and the packet switched (PS) service rate decreases.
Swapped BTSs are more likely to encounter antenna connection errors than newly deployed
BTSs. Field engineers can use traffic statistics and signaling data in the early phase to locate
such problems.
The following are the performance counters related to main and diversity RX channels:
l S4556:Average Main Level in the Customized MR
l S4557:Average Diversity Level in the Customized MR
The following are the formulas for calculating the main and diversity RX signal levels:
l Main RX signal level (dB) = 10 x log10(S4556) - 120
l Diversity RX signal level (dB) = 10 x log10(S4556) - 120
Location Procedure
GBSS14.0
354
Figure 13-3 Procedure for locating faults on main and diversity RX channels due to incorrect
antenna connections

1. Check whether the cables between the TRXs and the radio frequency (RF) modules are
faulty.
Calculate the main and diversity RX signal levels according to the preceding formulas
mentioned in background information. For the carriers of the TRXs connecting to the same
RF module, if the main RX signal level is different from the diversity RX signal level,
check whether any cables between the TRXs and the RF module are faulty.
l If yes, replace the faulty cables. Then, go to Step 2.
2. Check whether the alarms related to the main and diversity RX channels are cleared.
3. Check whether a jumper or feeder connected to an antenna connector for the RF module
is faulty.
mentioned in background information. For the carriers of all the TRXs connecting to the
GBSS14.0
355
same antenna connector, if the main RX signal level is different from the diversity RX
signal level, check whether a jumper or feeder connected to an antenna connector for the
RF module is faulty.
l If yes, replace the faulty jumper or feeder. Then, go to Step 4.
5. Check whether the antenna connections between two cells are crossed.
mentioned in background information. For the carriers of all the TRXs in two cells under
the same BTS, if the main RX signal level is different from the diversity RX signal level,
check whether the antenna connections between the two cells are crossed pairs.
l If yes, correct the antenna connections. Then, go to Step 6.
Typical Symptoms of Incorrect Antenna Connections
BTS Type Fault Type Symptom
BTS3012 Faults in
cables
between the
TRXs and the
DFCU or
DDPU
For the carriers of some TRXs connected to the DFCU or
DDPU, if the main RX signal level is different from the
diversity RX signal level, the RXM or RXD cables between
the TRXs and the DFCU or DDPU may be faulty.
Faults in the
feeder or
jumper
connected to
an antenna
connector for
the DFCU or
DDPU
For the carriers of all the TRXs connected to the same
antenna connector, the main RX signal level is different
from the diversity RX signal level.
Crossed pairs
between the
main and
diversity RX
channels of
the two cells
For the carriers of all the TRXs in two or more cells under
the same BTS, the main RX signal level is different from
the diversity RX signal level.
GBSS14.0
356
BTS3900 Incorrect
configuration
of the TRX
send and
receive
modes
For all carriers of a TRX connected to an RF module, the
main RX signal level is different from the diversity RX
signal level.
Faults in
antennas
connected to
TRXs
When there are two TRXs in combined-cabinet mode:
l There is a great difference in the RX signal level between
the main and diversity RX channels of only one cell
under the BTS.
l For all carriers of one TRX, the main RX signal level is
lower than the diversity RX signal level; for all carriers
of another TRX, the diversity RX signal level is lower
than the main RX signal level.
When there is only one TRX:
the main and diversity RX channels of only one cell
under the BTS.
l For all carriers of the TRX, the main RX signal level is
different from the diversity RX signal level.
Crossed pairs
between the
main and
diversity RX
channels of
two cells
When there are two TRXs in combined-cabinet mode:
the main and diversity RX channels of two or more cells
under the BTS.
l For all carriers of one TRX, the main RX signal level is
lower than the diversity RX signal level; for all carriers
of another TRX, the diversity RX signal level is lower
than the main RX signal level.
When there is only one TRX:
the main and diversity RX channels of two or more cells
under the BTS.
l For all carriers of the TRX, the main RX signal level is
different from the diversity RX signal level.
BTS3900/
BTS3012
Inappropriate
thresholds for
the RX signal
level of the
main and
diversity RX
channels
For the BTS3012, the threshold is set to 6 dB or larger; for
the BTS3900, the threshold is set to 10 dB or larger.
GBSS14.0
357
Low RX
signal level of
main and
diversity RX
channels
The main and diversity RX signal level is lower than -98
dB. (This can be used as a supplementary method to
determine incorrect antenna connections.)

Typical Case
Symptom
A site frequently encounter problems such as interference, one-way audio, sharp decreases in
the RX signal level, and MS access failures.
Cause Analysis
The feeders for the main and diversity RX channels of the two cells are crossed. As a result, the
main and diversity RX signal level difference exceeds 10 dB.
Location Procedure
1. Query the performance measurement results by choosing MR Measurement(MR) > User
defined MRs per TRX > User defined MRs per TRX >
TRX_EXT_MAIN_RX_AVR_LEV on the M2000.
2. Calculate the main and diversity RX signal levels of the two cells according to the preceding
formulas.
3. Analyze the main and diversity RX signal level of all carriers in the two cells. The main
and diversity RX signal level difference exceeds 10 dB. In addition, the RX signal level of
path A in cell 1 is high and that of path B in cell 1 is low, whereas the RX signal level of
path A in cell 2 is high and that of path B in cell 2 is low. This indicates that the antenna
connections between the two cells are crossed.
4. Check for crossed pairs of feeders onsite and reconnect the feeders. The alarms are cleared.
Channels Due to Hardware Faults
hardware faults.
Symptom
channel alarm are reported.
Location Procedure
hardware faults.
GBSS14.0
358
Figure 13-4 Procedure for locating faults on main and diversity RX channels due to hardware
faults

1. Check whether any BTS boards are faulty
by exchanging the faulty boards with the functional boards.
l If yes, replace the faulty boards. Then, go to Step 2.
2. Check whether the alarms such as ALM-4176 Main receive channel alarm and ALM-4178
Diversity receive channel alarm are cleared.
Typical Case
Symptom
After the capacity expansion from S3 to S3/2, the BTS312 operates properly. During the two
days after capacity expansion, the newly added TRXs report the alarm ALM-4178 Diversity
receive channel alarm every hour or two.
Cause Analysis
The possible causes are as follows:
l The antenna is not connected properly.
l The radio frequency (RF) cables that connect to the diversity RX ports on the TRXs and
the diversity RX cables that connect to the combining and distribution units (CDUs) on the
top of the cabinet are loose or damaged.
l The TRXs are faulty.
l There is multipath interference in the radio environment.
GBSS14.0
359
l The data configuration is incorrect.
Location Procedure
1. Check the data configuration of the newly added TRXs. The data configuration is correct.
2. Check and reconnect all the RF cables, and replace all the diversity RX cables. Then,
perform dialing tests. The alarms persist.
3. Replace the CDUs connected to the TRXs reporting alarms. Then, perform dialing tests.
The alarms persist.
4. Exchange the slots between the TRXs reporting alarms and the TRXs not reporting alarms.
Then, perform dialing tests. The alarms are cleared.
GBSS14.0
360
14 No Traffic
About This Chapter
This chapter describes how to locate and troubleshoot no traffic on 3900 series base stations.
14.1 Introduction to No Traffic
When no traffic occurs, subscribers cannot initiate calls in a normal cell or a normal cell cannot
be occupied.
14.2 Locating No Traffic
This section describes how to locate no traffic.
14.3 Troubleshooting No Traffic Due to No Calls
This section describes how to troubleshoot no traffic due to no calls.
14.4 Troubleshooting No Traffic Due to Transmission or Equipment Faults
This section describes how to troubleshoot no traffic due to transmission or equipment faults.
14.5 Troubleshooting No Traffic Due to Incorrect Data Configurations
This section describes how to troubleshoot no traffic due to incorrect data configurations.
14.6 Troubleshooting No Traffic Due to Poor Um Interface Quality
This section describes how to troubleshoot no traffic due to poor Um interface quality.
14.7 Troubleshooting No Traffic Due to Antenna System Faults
This section describes how to troubleshoot no traffic due to antenna system faults.
14.8 Resetting
This section describes how to perform resetting.
GBSS14.0
Troubleshooting Guide 14 No Traffic
361
14.1 Introduction to No Traffic
When no traffic occurs, subscribers cannot initiate calls in a normal cell or a normal cell cannot
be occupied.
Introduction
When no traffic occurs, a cell or some TRXs serving the cell become faulty. As a result, cell
coverage may be affected. In some cases, subscribers in an area cannot make calls. Therefore,
when no traffic occurs, immediately resolve the problem to minimize the impact.
The alarms associated with no traffic are reported at the TRX level. No traffic may occur in a
BTS, cell, board, or TRX on the board, depending on the cell configurations.
Associated Alarm
For BSC6900 versions earlier than V900R014C00, ALM-28008 Radio Link Failure with
tributary 2 serves as the no traffic alarm. For BSC6900 versions later than V900R014C00, the
diagnosis on no traffic faults is enhanced and the function for independently reporting the alarm
related to no traffic on TRXs is added. For details, see the description of ALM-28009 Carrier
No Traffic.
Whether to report the ALM-28008 Radio Link Failure or ALM-28009 Carrier No Traffic
depends on the setting of the Reporting No Traffic Alarm Independently parameter in the
MML command SET GTRXRLALM. For details, see 3.7.1 Reporting the No Traffic Alarm
Independently and 3.7.2 No-Traffic Self-Healing.
Symptom
Check whether there is no traffic by using the following methods:
l Monitor BTS channel status. If channels in the problem cell cannot be occupied, but
channels in neighboring cells can be occupied, there is no MS to access the cell.
l Obtain feedback from subscribers. If subscribers provide the feedback that cell access is
difficult, MSs have no signals, or MSs cannot access the network, no traffic occurs.
l Determine the fault by checking whether faults lie in some TRXs, all carriers in a cell, or
some channels on a board.
l Run the MML command LST GTRXRLALM to check whether the settings of parameters
for performing self-healing operation for no traffic take effect. If the no traffic problem
persists after self-healing operations are performed, take the following measures to rectify
the fault: locate faults in the antenna system and hardware devices, optimize network
coverage, and eliminate interference.
14.2 Locating No Traffic
This section describes how to locate no traffic.
Principles
Channel resource usage failures caused by special traffic models or board faults may lead to no
traffic. Possible causes are antenna system problems, incorrect data configurations, hardware
GBSS14.0
362
problems, interference, poor Um interface quality, or software problems. You can locate and
troubleshoot the problems based on the live network conditions.
To locate the problems, first determine the search scope, such as site, cell, or TRX according to
the problem feedback information and traffic statistics. If no fault is found after the location
procedure is performed on the site, cell, or TRX, reset the software and hardware to restore
services.
In addition, no traffic may be caused by project reasons. For example, if a project is not complete,
a high-power attenuator can be added to the RF output port to prohibit network access of MSs.
Therefore, before clearing the alarms related to no traffic, have maintenance engineers checked
whether no traffic is caused by this type of reason.
The location procedure involves the following operations:
l Analyzing the counters associated with a cell or TRX
l Analyzing the parameters related to no traffic alarms
l Handling the transmission and equipment alarms
l Checking the parameter settings
l Locating interference
l Resetting the faulty board to check whether the board software is faulty
l Locating antenna system faults
Location Procedure
Figure 14-1 shows the procedure for locating no traffic.
GBSS14.0
363
Figure 14-1 Procedure for locating no traffic

GBSS14.0
364
Table 14-1 No traffic location information
1 Symptom Provide the start time and end time of the fault, specific
symptom, and impact range (whether the fault occurs
in a cell, a BTS, a BSC, or all BSCs under an MSC).

2 Operation
s before
and after
the fault
occurs
modification.

3 Faulty NE
version
For details
about how to
obtain the
BSC and BTS
software
versions that
are used when
the problem
occurs, see 15
Appendix:
How to
Collect Fault
Information.
4 Configura
tion data
script
fault occurs.
For details
about how to
obtain the
configuration
data script, see
15 Appendix:
How to
Collect Fault
Information.
5 Historical
alarms
For details
about how to
obtain the
historical
alarms, see 15
Appendix:
How to
Collect Fault
Information.
GBSS14.0
365
6 Original
traffic
statistics
For details
about how to
obtain the
original traffic
statistics, see
15 Appendix:
How to
Collect Fault
Information.
7 Operation
logs
For details
about how to
obtain the
operation
logs, see 15
Appendix:
How to
Collect Fault
Information.
8 Faulty
signaling
single-user signaling of one or two faulty cells when
the problem occurs.
For details
about how to
obtain the
faulty
signaling, see
15 Appendix:
How to
Collect Fault
Information.
about how to
obtain BTS
logs, see 15
Appendix:
How to
Collect Fault
Information.
10 Channel
status
Obtain the status of faulty cells and BTS channels. For details
about how to
obtain the
channel
status, see 15
Appendix:
How to
Collect Fault
Information.

GBSS14.0
366
14.3 Troubleshooting No Traffic Due to No Calls
This section describes how to troubleshoot no traffic due to no calls.
Symptom
The ALM-28008 Radio Link Failure alarm with Specific Problem of No Traffic on TRX is
reported, or the value of K3014:Traffic Volume on TCH is zero.
This problem may be caused by special coverage conditions. For example, there are no travelers
at a popular tourist attraction during the off-season, no subscribers in certain districts or no
students in schools during holidays, or there is no traffic in some cells in the early morning. In
these conditions, change the settings of the correlated alarm parameters to improve alarm
detection accuracy.
The parameters associated with this alarm are Wireless Link Alarm Flag, Statistical Period
of No-traffic, Begin Time of WLA Detection, End Time of WLA Detection, No Traffic Self-
Healing Period, No Traffic Self-Healing Mode and Reporting No Traffic Alarm
Independently. You can run the LST GTRXRLALM command to query the settings of the
preceding parameters and run the SET GTRXRLALM command to change the settings.
Location Procedure
Figure 14-2 shows the procedure for locating no traffic due to no calls.
Figure 14-2 Procedure for locating no traffic due to no calls

1. Check whether the settings of the correlated alarm parameters are correct.
GBSS14.0
367
Begin Time of WLA Detection, End Time of WLA Detection, and Statistical Period of
No-traffic must be set according to the traffic distribution.
l If the parameter settings are incorrect, change the parameter settings. Then, go to Step
2.
l If they are correct, return to Procedure for locating no traffic.
2. Check whether the no traffic problem is resolved.
l If no, return to Procedure for locating no traffic.
Typical Case
Symptom
The ALM-28008 Radio Link Failure alarm with Specific Problem of No Traffic on TRX is
frequently reported on a BTS3900 and is automatically cleared after a period of time.
Cause Analysis
The site served by the BTS3900 is a school amid summer vacation. The alarm is reported because
no phone calls were made during summer vacation.
1. Trace the RSL signaling on the Abis interface for the problem cell. No channel requests
are reported in the cell. Query the forward and reverse power of the TRX power amplifier.
The forward and reverse power as well as the downlink transmit power of the TRX are
normal.
2. Perform drive tests (DTs). Subscribers can make calls in the area covered by the cell. This
indicates that the BTS is operating properly.
3. Change the settings of the correlated alarm parameters to ensure that the ALM-28008 Radio
Link Failure alarm is not reported during summer vacation.
14.4 Troubleshooting No Traffic Due to Transmission or
Equipment Faults
This section describes how to troubleshoot no traffic due to transmission or equipment faults.
Symptom
When a transmission or equipment fault occurs in a cell, the alarm system reports alarms such
as RF Unit VSWR Threshold Crossed, Trx Temperature Alarm, Transmission alarm, and TRX
Config Mismatch Alarm. In this situation, the cell may be out of service, or the TRX may be
shut down.
Transmission or equipment faults include:
l Faults in the BTS transmission management unit
l BTS TRX faults
l BTS antenna faults
GBSS14.0
368
The following alarms are associated with hardware or antenna faults:
l ALM-26235 RF Unit Maintenance Link Failure
l ALM-26529 RF Unit VSWR Threshold Crossed
l ALM-11272 Hardware Alarm
l ALM-26503 RF Unit Optical Module Transmit/Receive Fault
The following alarms are associated with transmission faults:
l ALM-11280 E1/T1 remote alarm
l ALM-25800 E1/T1 Loss of Signal
l ALM-25803 E1/T1 Loss of Frame Alignment
Location Procedure
Figure 14-3 shows the procedure for locating no traffic due to transmission or equipment faults.
Figure 14-3 Procedure for locating no traffic due to transmission or equipment faults

1. Check whether any alarms associated with no traffic due to transmission or equipment
faults are reported.
l If yes, clear the alarms listed in Background Information by referring to the Alarm
Reference. Then, go to Step 2.
l If none of these alarms are reported, return to Procedure for locating no traffic.
GBSS14.0
369
Typical Case
Symptom
An onsite MRFU has no traffic and reports the ALM-4812 Optic Module Abnormal Alarm and
the ALM-28008 Radio Link Failure with Specific Problem of No Traffic on TRX.
Cause Analysis
The optical module between the MRFU and the BBU is faulty, and therefore the link between
the TRX and the BBU is disconnected.
1. Analyze the RSL signaling on the Abis interface. All calls assigned to the MRFU fail to be
initiated because the MRFU does not receive any link setup indication messages after the
assignment command is delivered.
2. Check the alarms on the BSC LMT. In addition to alarms related to no traffic, alarms related
to optical module faults are also reported. Therefore, assignment failures may be caused
by optical module faults, which leads to alarms related to no traffic.
3. Replace the onsite optical module with a new one. The no traffic problem is resolved.
14.5 Troubleshooting No Traffic Due to Incorrect Data
Configurations
This section describes how to troubleshoot no traffic due to incorrect data configurations.
Symptom
The alarm system reports the ALM-28008 Radio Link Failure alarm with Specific Problem of
No Traffic on TRX.
The ALM-28008 Radio Link Failure is reported if certain parameters are set incorrectly or certain
functions are enabled.
l If mobile country code (MCC), mobile network code (MNC), location area code (LAC),
cell identity (CI), and network parameters are not set correctly, no traffic in a cell may
occur.
l Enabling energy saving functions may result in no traffic. For example, when the intelligent
shutdown of TRX power amplifier function or dynamic cell shutdown function is started,
the BTS checks the traffic volume of a cell or TRX. Upon determining that the traffic
volume of a cell or TRX is low, the BTS powers off the cell or TRX to reduce power
consumption. After the cell or TRX is powered off, there is no traffic in the cell or on the
TRX.
Location Procedure
Figure 14-4 shows the procedure for locating no traffic due to incorrect data configurations.
GBSS14.0
370
Figure 14-4 Procedure for locating no traffic due to incorrect data configuration

1. Check whether the parameters listed in Background Information are set correctly.
l If no, change the parameter settings. Then, go to Step 2.
l If yes, return to Procedure for locating no traffic.
NOTE
If the parameter settings are incorrect, check the items listed in Background Information.
Alternatively, have network operation and maintenance (O&M) engineers checked changes in the
parameter settings before and after the problem occurs. Then, check the changed parameter settings.
Typical Case
Symptom
The traffic volumes of three cells under a BSC at site A suddenly decrease to zero and no channel
requests are reported in these cells. However, the traffic volumes of the cells are restored to
normal after several hours.
Cause Analysis
The dynamic cell shutdown function is enabled.
1. View the traffic statistics. Several hours before no traffic occurs, the number of channel
requests reported in the cell gradually decreases. When the no traffic problem occurs, the
number of channel requests decreases to zero.
2. Analyze the operation logs when the problem occurs and when it is resolved. Before the
problem occurs, the dynamic cell shutdown function is enabled. As a result, the BSC
GBSS14.0
371
constantly checks the cell load. If the cell load is less than Same Coverage Cell Load
Threshold (with the default value of 50%) within Same Coverage Cell Load Stat.
Time, the cell is shut down and has no traffic. After the dynamic cell shutdown function
is disabled, the problem is resolved.
14.6 Troubleshooting No Traffic Due to Poor Um Interface
Quality
This section describes how to troubleshoot no traffic due to poor Um interface quality.
Symptom
If the Um interface quality is poor, an MS may fail to receive an IMM ASS CMD or ASS CMD
message from the BSC, or the BTS cannot decode an EST IND message from an MS. As a result,
the target cell fails to be occupied.
l Interference may deteriorate the signal quality of the target cell. As a result, MSs fail to
occupy channels in the cell even if the downlink receive level of the target cell is favorable.
l Poor coverage on the uplink and downlink may deteriorate the Um interface quality, and
therefore MSs fail to receive the messages from the BTS.
Location Procedure
Figure 14-5 shows the procedure for locating no traffic due to poor Um interface quality.
GBSS14.0
372
Figure 14-5 Procedure for locating no traffic due to poor Um interface quality

1. View the traffic statistics associated with interference bands to check whether there is
interference in the cell.
l If yes, remove the interference source or replace the interfered frequency. Then, go to
Step 2.
3. View the traffic statistics associated with the uplink and downlink signal quality to check
whether the Um interface quality was poor before no traffic occurred.
l If yes, perform network optimization to improve the Um interface quality. Then, go to
Step 4.
GBSS14.0
373
5. Perform operations provided in 14.8 Resetting. Then, go to Step 6.
Typical Case
Symptom
There is no traffic on an onsite TRX and the alarm system reports the ALM-28008 Radio Link
Failure alarm with Specific Problem of No Traffic on TRX. The system occasionally clears
the alarm, but the traffic volume is low.
Cause Analysis
There is severe uplink interference on the frequency used by the problem TRX.
1. Analyze the traffic statistics when the problem occurred. Although few assignment
commands were delivered to the problem TRX, no TCHs were assigned to the MSs.
2. Analyze the RSL signaling on the Abis interface. Channel requests are reported in the cell
and there is traffic in the cell. However, MSs fail to access the assigned TCHs on the
problem TRX, and do not send any link setup indication messages.
3. Check that no operations are performed on the cell before and after the problem occurs.
4. Analyze the traffic statistics associated with the TRX interference bands. Most uplink
interference bands of the TRX are interference band 5 and the TRX is configured in non-
frequency hopping (non-FH) mode.
5. Change the frequency used by the TRX. The problem is resolved. This indicates that the
problem is caused by single-frequency interference.
14.7 Troubleshooting No Traffic Due to Antenna System
Faults
This section describes how to troubleshoot no traffic due to antenna system faults.
Symptom
If the no traffic problem persists after the possible causes of no calls, transmission or equipment
faults, incorrect data configuration, or poor Um interface quality are excluded, the problem may
be caused by antenna system faults.
Antenna system faults refer to incorrect antenna connections and faulty cables to the antenna.
If the antenna system is faulty, the TRXs with no traffic may be bound to the same transmit path.
GBSS14.0
374
l If the antenna system is faulty, the BTS cannot transmit downlink signals properly. As a
result, no coverage or poor coverage problem may occur, or uplink signals cannot be sent
to or decoded by the BTS.
l If the antenna connections are incorrect, the coverage area of the BCCH TRX in the cell
may be different from the coverage areas of non-BCCH TRXs. As a result, MSs fail to
access the assigned TCHs on non-BCCH TRXs after they initially access the TCHs on the
BCCH TRX. This results in no traffic on non-BCCH TRXs.
Location Procedure
Figure 14-6 shows the procedure for locating no traffic due to antenna system faults.
GBSS14.0
375
Figure 14-6 Procedure for locating no traffic due to antenna system faults

Use TEMS or Probe MSs to perform drive tests (DTs). If TEMS or Probe MSs are not available,
use common MSs.
1. Check whether the dialing tests can be performed on the TRX power output port.
Use a TEMS MS to lock the BCCH frequency of the faulty cell and perform dialing tests
on the TRX power output port.
GBSS14.0
376
l If the dialing tests cannot be performed and the frequency cannot be scanned on the
TRX power output port, replace the board with a new one. Then, go to Step 2.
l If the dialing tests can be performed, go to Step 3.
3. Check whether the antenna connections are consistent with configurations.
l If no, correct the antenna connections. Then, go to Step 4.
5. Check whether the antenna tilt is correct and whether the tilt direction is consistent with
the coverage area.
l If no, adjust the antenna tilt. Then, go to Step 6.
7. Check whether the distributed indoor antenna system is powered off or faulty.
l If yes, contact the manufacturer of the distributed indoor antenna system to rectify the
fault. Then, go to Step 8.
9. Check whether the antenna system is faulty.
Use one cable to connect the TRX of cell A to the antenna of cell B and use one cable to
connect the TRX of cell B to the antenna of cell A. If the problem is resolved, the problem
is caused by antenna system faults.
l If yes, reconnect the cables to the antenna system or replace the components in the
antenna system. Then, go to Step 10.
Typical Case
Symptom
The onsite traffic volume suddenly decreases to zero and the ALM-28008 Radio Link Failure
alarm with Specific Problem of No Traffic on TRX is reported on the system and is not cleared
for several days.
GBSS14.0
377
Cause Analysis
The distributed indoor antenna system is powered off, and therefore no downlink signals are
available. As a result, MSs fail to access the network.
1. View the traffic statistics when the problem occurs in the cell. No channel requests are
reported in the cell, but the interference band messages are reported. The downlink transmit
power may be abnormal.
2. Reset the board hardware and software. The problem persists.
3. Perform the dialing tests onsite. No cell signals can be searched for in the coverage area.
4. Locate faults in the distributed indoor antenna system. The antenna connections are correct
and calls can be initiated on the TRX power output port.
5. Locate faults in the distributed indoor antenna system again. Extra power is supplied to the
distributed indoor antenna system. This indicates that no traffic occurs because the
distributed indoor antenna system is powered off.
14.8 Resetting
This section describes how to perform resetting.
CAUTION
Exercise caution when performing resetting because resetting may affect or interrupt services.
Select the module to be reset according to the problem occurrence range.
l If there is no traffic on a BTS, reset the BTS.
l If there is no traffic in a cell, reset the board where the BCCH TRX of the cell is located.
Reset the software first. If the problem persists, reset the hardware.
l If there is no traffic on a TRX, reset the board where the TRX is located. Reset the software
first. If the problem persists, reset the hardware.
To perform resetting, do as follows:
l To reset a BTS, run the RST BTS command with Reset Type set to BTSSOFT(Reset BTS
Software) and Reset Level set to 4-LEVEL(Level-4). For details about the parameter
settings, see the MML Command Reference.
l To reset the board software, run the RST BTSBRD command with Reset Type set to
SOFTWARE(Software Reset). For details about the parameter settings, see the MML
Command Reference.
l To reset the board hardware, run the RST BTSBRD command with Reset Type set to
HARDWARE(Hardware Reset). For details about the parameter settings, see the MML
Command Reference.
If the no traffic problem is caused by software errors, resolve the problem by resetting the
software or hardware. After the problem is resolved, Contact Huawei Customer Service Center
to determine the root cause of the problem.
GBSS14.0
378
15 Appendix: How to Collect Fault
Information
When faults cannot be rectified by referring to this document, collect fault information for
Huawei technical support to quickly troubleshoot the faults. This section describes how to collect
fault information.
Table 15-1 The Method for collecting fault information
Collectio
n Item
Collection Method
Faulty NE
version
1. Run the MML command LST VER to query the BSC software version.
2. Run the MML command DSP BTSBRD with Information Type set to
BASEINFO(Basic Information) and BTS Index set to the index of the BTS
to query the BTS software version.
Data
configurat
ion script
1. Run the MML command EXP CFGMML to export the BSC data
configuration script.
2. After this command is executed, obtain the data configuration script from
the specified path.
l If Export File Path and File Name are not specified, the default save
path is \bam\version_X\ftp\export_cfgmml\. The default format of the
file name is CFGMML-BSCX-YYYYMMDDHHMMSS.txt, where X
refers to the BSC ID.
l If Export File Path and File Name are specified, the value of Export
File Path must be an existing path on the OMU and the value of File
Name must be unique.
Historical
alarms
1. Run the MML command COL LOG with Log File Type set to
HISTORY_ALARM(History Alarm File) to obtain the historical alarm
file.
2. Run the MML command LST LOGRSTINFO to query the path in which
the historical alarm file (with the default name ALARM_INFO.zip) is
saved.
3. Obtain the historical alarm file from the queried path. The default save path
is \bam\version_X\ftp\COLLOGINFO\ALM-LOG\.
GBSS14.0
Troubleshooting Guide 15 Appendix: How to Collect Fault Information
379
Collectio
n Item
Collection Method
Operation
logs
1. Run the MML command COL LOG with Log File Type set to OPT_LOG
(Operation Logs) to collect operation logs.
the operation log file (with the default name OperateLog.zip) is saved.
3. Obtain the operation log file from the queried path. The default save path is
\bam\version_X\ftp\COLLOGINFO\OPT-LOG\.
Common
debugging
logs
DEBUG_LOG(The Common Debug Log) to collect common debugging
logs.
the common debugging log file is saved.
The format of the file name is BSC0000_[DEBG]XXLog Start time_End
time.log.zip, where XX indicates the subrack number. For example,
BSC0000_[DEBG]00Log20101203102457_20101203113504.log.zip
indicates that the common debugging logs were recorded for subrack 0
between 10:24:57 and 11:35:04 on December 3, 2010.
3. Obtain the common debugging log file from the queried path. The default
save path is \bam\common\fam\famlogfmt\.
GCHR
and GCSR
logs
2G_CHR_LOG(The CHR Log for GSM) and GCSR_LOG(The CHR
Log for Single User of GSM CS) to collect GCHR and GCSR logs,
respectively.
2. Run the MML command LST LOGRSTINFO to query the paths in which
the GCHR and GCSR log files are saved.
l The format of the file name is BSC0000_[GCHR]XXLog Start
time_End time.log.zip, where XX indicates the subrack number. For
example, BSC0000_[GCHR]
00Log20101203102457_20101203113504.log.zip indicates that GCHR
logs were recorded for subrack 0 between 10:24:57 and 11:35:04 on
December 3, 2010.
l The format of the file name is BSC0000_[GCSR]XXLog Start
time_End time.log.zip, where XX indicates the subrack number. For
example, BSC0000_[GCSR]
00Log20101203102457_20101203113504.log.zip indicates that GCSR
logs were recorded for subrack 0 between 10:24:57 and 11:35:04 on
December 3, 2010.
3. Obtain the GCHR and GCSR log files from the queried paths.
l The default save path of the GCHR log file is \bam\common\fam
\famlogfmt\gchr\.
l The default save path of the GCSR log file is \bam\common\fam
\famlogfmt\.
GBSS14.0
380
Collectio
n Item
Collection Method
Host
running
logs
1. Run the MML command COL LOG with Log File Type set to HOST_LOG
(The Running Log of the Host) to collect host running logs.
the host running log file is saved.
The format of the file name is BSC0000_XXLog Start time_End
BSC0000_00Log20101203102457_20101203113504.log.zip indicates that
host running logs were recorded for subrack 0 between 10:24:57 and
11:35:04 on December 3, 2010.
3. Obtain the host running log file from the queried path. The default save path
is \bam\common\fam\famlog\.
GPSR
logs
1. Run the MML command COL LOG with Log File Type set to GPSR_LOG
(The CHR Log for Single User of GSM PS) to collect GPSR logs.
the GPSR log file is saved.
The format of the file name is BSC0000_[GPSR]XXLog Start time_End
BSC0000_[GPSR]00Log20101203102457_20101203113504.log.zip
indicates that GPSR logs were recorded for subrack 0 between 10:24:57 and
11:35:04 on December 3, 2010.
3. Obtain the GPSR log file from the queried path. The default save path is
\bam\common\fam\famlogfmt\gphr\.
DSP
debugging
logs
DSP_DEBUG_LOG(The Debug Log of DSP) to collect DSP debugging
logs.
the DSP debugging log file is saved.
The format of the file name is BSC0000_[MDSP]XXLog Start time_End
BSC0000_[MDSP]00Log20101203102457_20101203113504.log.zip
indicates that DSP debugging logs were recorded for subrack 0 between
10:24:57 and 11:35:04 on December 3, 2010.
3. Obtain the DSP debugging log file from the queried path. The default save
path is \bam\common\fam\famlogfmt\.
GBSS14.0
381
Collectio
n Item
Collection Method
Voice logs 1. Run the MML command COL LOG with Log File Type set to
2G_UNILATERAL_CONNECT(The Unilateral Connection Log for
GSM) to collect voice logs.
NOTE
Information about crosstalk , one-way audio and noise is logged together.
the voice log file is saved.
The format of the file name is BSC0000_[CDIG]XXLog Start time_End
BSC0000_[CDIG]00Log20101203102457_20101203113504.log.zip
indicates that voice logs were recorded for subrack 0 between 10:24:57 and
11:35:04 on December 3, 2010.
3. Obtain the voice log file from the queried path. The default save path is \bam
\common\fam\famlogfmt\.
BTS logs 1. Run the MML command STR BTSLOG with Log Type set to COMLOG
(Common Log), Board Type set to TMU(TMU/DTMU), and BTS
Index set to an appropriate value to collect BTS logs.
NOTE
All BTS logs need to be collected. Therefore, you do not need to set the start or end
time.
2. Obtain the compressed BTS log file from \bam\common\bts\log
\btscmplog on the OMU. The format of the file name is BTS name_Board
type_Board number.lzp.
Fault
signaling
1. Log in to the BSC local maintenance terminal (LMT) and click the Trace
tab. The Trace tab page is displayed.
2. Choose Trace > GSM Services from Trace Navigation Tree to trace
messages. For details about how to trace messages, see BSC6900 GSM LMT
User Guide.
Original
traffic
statistics
PFM_RESULT(Performance Result File) to obtain the traffic statistics
result file.
NOTE
The period that you set to collect original traffic statistics cannot exceed 6 hours. If the
period you set is longer than 6 hours, the system automatically collects traffic statistics
within only the first 6 hours.
the traffic statistics result file (with the default name PFM-LOG.zip) is
saved.
3. Obtain the traffic statistics result file from the queried path. The default save
path is \bam\version_X\ftp\COLLOGINFO\PFM-LOG\.
PS cell
distributio
n
Run the MML command DSP PSCELL with Index Type set to BYBSC(By
BSC) to obtain the information about PS cell distribution of an entire BSC.
GBSS14.0
382
Collectio
n Item
Collection Method
BTS
distributio
n
Run the MML command LST BTS with List Type set to ALL(All BTS) to
obtain the information about BTS distribution of an entire BSC.
Channel
status
Run the MML command DSP CHNSTAT with Object Type set to SITE
(Site) and BTS Index set to an appropriate value to obtain the channel status
information.
NOTE
For details about menu operations, see 3.5.1 Monitoring Channel Status.

NOTE
version_X indicates the active workspace of the OMU, which can be queried by running the MML
command LST OMUAREA.
GBSS14.0
383

GBSS14.0 Troubleshooting Guide (02) (PDF) - en

Caricato da

Informazioni sul documento

Descrizione originale:

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

GBSS14.0 Troubleshooting Guide (02) (PDF) - en

Caricato da

Copyright:

Formati disponibili

GBSS14.

Potrebbero piacerti anche