Professional Documents
Culture Documents
GBSS13.0 Troubleshooting Guide (02) (PDF) - EN PDF
GBSS13.0 Troubleshooting Guide (02) (PDF) - EN PDF
Troubleshooting Guide
Issue
02
Date
2012-06-25
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 the warranty of any kind, express or implied.
Website:
http://www.huawei.com
Email:
support@huawei.com
Issue 02 (2012-06-25)
GBSS13.0
Troubleshooting Guide
Product Version
The following table lists the product versions related to this document.
Product Name
Product Version
BSC6900
V900R013C00
BSC6000
V900R013C00
BTS3900/BTS3900A/DBS3900
BTS3012/BTS3012AE/BTS3012II/
BTS3006C/BTS3002E
BTS3900B/BTS3900E
BTS30/BTS312/BTS3012A
Intended Audience
This document is intended for:
l
Maintenance engineers
Field engineers
Organization
1 Change in the GBSS Troubleshooting Guide
Issue 02 (2012-06-25)
ii
GBSS13.0
Troubleshooting Guide
Conventions
Symbol Conventions
Issue 02 (2012-06-25)
iii
GBSS13.0
Troubleshooting Guide
The symbols that may be found in this document are defined as follows.
Symbol
Description
Indicates a hazard with a high level of risk, which if not
avoided, will result in death or serious injury.
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
Boldface
Italic
Courier New
Command Conventions
The command conventions that may be found in this document are defined as follows.
Issue 02 (2012-06-25)
Convention
Description
Boldface
Italic
[]
{ x | y | ... }
iv
GBSS13.0
Troubleshooting Guide
Convention
Description
[ x | y | ... ]
{ x | y | ... }*
[ x | y | ... ]*
GUI Conventions
The GUI conventions that may be found in this document are defined as follows.
Convention
Description
Boldface
>
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
Key 1, Key 2
Mouse Operations
The mouse operations that may be found in this document are defined as follows.
Issue 02 (2012-06-25)
Action
Description
Click
Double-click
GBSS13.0
Troubleshooting Guide
Issue 02 (2012-06-25)
Action
Description
Drag
Press and hold the primary mouse button and move the
pointer to a certain position.
vi
GBSS13.0
Troubleshooting Guide
Contents
Contents
About This Document.....................................................................................................................ii
1 Change in the GBSS Troubleshooting Guide.........................................................................1
2 Troubleshooting Procedure.........................................................................................................2
2.1 Troubleshooting Flowchart.................................................................................................................................3
2.2 Collecting Fault Information..............................................................................................................................3
2.3 Determining a Fault Type...................................................................................................................................6
2.3.1 Fault Types................................................................................................................................................6
2.3.2 Methods for Determining a Fault Type.....................................................................................................7
2.4 Identifying Fault Causes.....................................................................................................................................8
2.5 Troubleshooting Faults.......................................................................................................................................9
2.5.1 Overview...................................................................................................................................................9
2.5.2 Methods for Troubleshooting Faults.........................................................................................................9
2.5.3 Follow-up Procedure...............................................................................................................................10
vii
GBSS13.0
Troubleshooting Guide
Contents
4 Handover Problems.....................................................................................................................41
4.1 Handover Principles.........................................................................................................................................42
4.1.1 Handover Procedure................................................................................................................................42
4.1.2 Handover Success Rate...........................................................................................................................44
4.2 Locating Handover Problems...........................................................................................................................47
4.2.1 Principles.................................................................................................................................................47
4.2.2 Procedure for Locating Handover Problems...........................................................................................47
4.3 Troubleshooting Handover Problems Due to Hardware Faults........................................................................52
4.4 Handover Problems Due to Incorrect Data Configurations..............................................................................55
4.5 Troubleshooting Handover Problems Due to Traffic Congestion in the Target Cell.......................................59
4.6 Troubleshooting Handover Problems Due to Poor Um Interface Quality.......................................................61
4.7 Troubleshooting Handover Problems Due to NE Faults..................................................................................65
4.8 Troubleshooting Handover Problems Due to Inappropriate Inter-BSC/Inter-MSC/Inter-RAT Interaction
................................................................................................................................................................................68
5 Call Drops.....................................................................................................................................73
5.1 Call Drop Rate..................................................................................................................................................74
5.2 Locating Call Drops..........................................................................................................................................75
5.2.1 Procedure for Locating Call Drops..........................................................................................................75
5.2.2 Counters Related to Call Drops...............................................................................................................79
5.2.3 Types of Call Drops.................................................................................................................................81
5.3 Troubleshooting Call Drops Due to Poor Um Interface Quality......................................................................84
5.4 Troubleshooting Call Drops Due to Equipment Faults....................................................................................89
5.5 Troubleshooting Call Drops Due to Transmission Faults................................................................................93
5.6 Troubleshooting Call Drops Due to Incorrect Parameter Settings...................................................................94
6 Access Faults...............................................................................................................................101
6.1 Access Principles............................................................................................................................................103
6.2 Locating Access Faults...................................................................................................................................104
6.2.1 Procedure for Locating Access Faults...................................................................................................105
6.2.2 Common Causes for Access Faults.......................................................................................................112
6.3 Troubleshooting Access Faults Due to Poor Um Interface Quality...............................................................116
6.4 Troubleshooting Low Immediate Assignment Success Rates Due to SDCCH Congestion..........................122
6.5 Troubleshooting Low Immediate Assignment Success Rates Due to Hardware or Transmission Faults
..............................................................................................................................................................................126
Issue 02 (2012-06-25)
viii
GBSS13.0
Troubleshooting Guide
Contents
6.6 Troubleshooting Low Immediate Assignment Success Rates Due to Location Updates of Problem MSs
..............................................................................................................................................................................130
6.7 Troubleshooting Low Assignment Success Rates Due to TCH Congestion..................................................133
6.8 Troubleshooting Low Assignment Success Rates Due to Hardware or Transmission Faults........................137
6.9 Troubleshooting Low Assignment Success Rates Due to Inappropriate BSC Configuration.......................141
8 PS Counter Problems................................................................................................................183
8.1 PS Counters....................................................................................................................................................184
8.2 Locating PS Counter Problems.......................................................................................................................185
8.2.1 Principles for Locating PS Counter Problems.......................................................................................185
8.2.2 Procedure for Locating PS Counter Problems.......................................................................................185
8.3 Troubleshooting Low TBF Establishment Success Rates..............................................................................186
8.4 Troubleshooting High TBF Call Drop Rates..................................................................................................195
8.5 Troubleshooting Low Average Throughput at the RLC Layer......................................................................202
8.6 Troubleshooting Low Percentage of High-Rate Coding Schemes to All Coding Schemes...........................209
8.7 Troubleshooting High RLC Data Block Retransmission Rates.....................................................................217
9 PS Channel Faults......................................................................................................................224
9.1 Identifying PS Channel Faults........................................................................................................................225
9.2 Locating PS Channel Faults...........................................................................................................................225
9.3 Troubleshooting PDCH Faults Due to Channel Inactivity.............................................................................227
9.4 Troubleshooting PDCH Faults Due to Channel Asynchronization................................................................234
11 IP Transmission Faults...........................................................................................................258
11.1 Troubleshooting FE/GE Transmission Faults..............................................................................................259
11.2 Troubleshooting IP Layer Faults..................................................................................................................266
11.3 Troubleshooting PPP or MLPPP Link Faults...............................................................................................271
11.4 Troubleshooting LAPD Link Faults.............................................................................................................276
11.5 Troubleshooting SCTP Link Faults..............................................................................................................285
Issue 02 (2012-06-25)
ix
GBSS13.0
Troubleshooting Guide
Contents
12 Interference Problems.............................................................................................................316
12.1 Interference...................................................................................................................................................317
12.2 Locating Interference Problems....................................................................................................................318
12.3 Troubleshooting Co-channel or Adjacent-Channel Interference..................................................................321
12.4 Troubleshooting Intermodulation Interference.............................................................................................323
12.5 Troubleshooting Interference from the CDMA Network.............................................................................328
12.6 Troubleshooting External Interference.........................................................................................................331
14 No Traffic..................................................................................................................................348
14.1 Introduction to No Traffic............................................................................................................................349
14.2 Locating No Traffic......................................................................................................................................349
14.3 Troubleshooting No Traffic Due to No Calls...............................................................................................354
14.4 Troubleshooting No Traffic Due to Transmission or Equipment Faults......................................................355
14.5 Troubleshooting No Traffic Due to Incorrect Data Configurations.............................................................357
14.6 Troubleshooting No Traffic Due to Poor Um Interface Quality..................................................................359
14.7 Troubleshooting No Traffic Due to Antenna System Faults........................................................................361
14.8 Resetting.......................................................................................................................................................365
Issue 02 (2012-06-25)
GBSS13.0
Troubleshooting Guide
02 (2012-06-25)
This is the second commercial release of GBSS13.0.
Compared with issue 01 (2012-01-05) of GBSS13.0, this issue does not include any new topics.
Compared with issue 01 (2012-01-05) of GBSS13.0, this issue incorporates the following
changes:
content
Description
Compared with issue 01 (2012-01-05) of GBSS13.0, this issue does not excludes any topics.
01 (2012-01-05)
This is the first commercial release of GBSS13.0.
Issue 02 (2012-06-25)
GBSS13.0
Troubleshooting Guide
2 Troubleshooting Procedure
Troubleshooting Procedure
Issue 02 (2012-06-25)
GBSS13.0
Troubleshooting Guide
2 Troubleshooting Procedure
GBSS13.0
Troubleshooting Guide
2 Troubleshooting Procedure
Fault symptoms
Operations performed on the equipment before the fault occurs and the operation results
Alarms generated when the fault occurs and the associated alarms
Measures taken after the fault occurs and the effects of measures
Obtain the symptoms, time, place, and frequency of the fault from the subscribers and
technical support engineers.
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.
Monitor the board indicator status and alarms reported on the LMT to understand the
software and hardware operating status.
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.
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.
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.
Issue 02 (2012-06-25)
GBSS13.0
Troubleshooting Guide
2 Troubleshooting Procedure
Color
Status
Description
RUN
Green
ON
OFF
There is no power
supply, or the board is
faulty.
OFF
There is no alarm.
ON or blinking
ON
OFF
ON
OFF
OFF
There is no data
transmission over the
Ethernet port.
Blinking
There is data
transmission over the
Ethernet port.
ALM
Red
ACT
Green
Green
Green
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.
Issue 02 (2012-06-25)
GBSS13.0
Troubleshooting Guide
2 Troubleshooting Procedure
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.
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.
For details about how to how to trace the signaling messages, see the BSC6900 GSM LMT User
Guide.
CS voice problems
CS service faults
Handover problems
Call drops
Access problems
PS service faults
PS counter problems
PS channel faults
No PS service available in a cell
Equipment faults
IP transmission faults
Interference
Main diversity receive channel faults
No traffic
Issue 02 (2012-06-25)
GBSS13.0
Troubleshooting Guide
2 Troubleshooting Procedure
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.
Monitoring
Monitoring is a common method for determining fault ranges. You can observe alarms,
indicator status, and LMT panel status.
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
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.
Regularity identification
Identifying problem regularity helps to narrow the fault range. When narrowing the fault
range, consider the following factors:
Issue 02 (2012-06-25)
1.
2.
3.
4.
5.
GBSS13.0
Troubleshooting Guide
2 Troubleshooting Procedure
6.
7.
Whether an enabled feature is abnormal, such as Flex TSC, downlink power control,
or BCCH power consumption reduction
8.
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.
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.
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.
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
Issue 02 (2012-06-25)
GBSS13.0
Troubleshooting Guide
2 Troubleshooting Procedure
board indicators and error messages is available. Therefore, it is easy to identify the causes
of subsystem faults.
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
After a fault is rectified, review the troubleshooting process, record the key points, and
provide preventive and improvement measures.
NOTE
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.
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:
Issue 02 (2012-06-25)
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.
GBSS13.0
Troubleshooting Guide
2 Troubleshooting Procedure
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.
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.
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.
If the fault persists, collect fault location information and Contact Huawei Customer Service
Center.
Issue 02 (2012-06-25)
10
GBSS13.0
Troubleshooting Guide
Issue 02 (2012-06-25)
11
GBSS13.0
Troubleshooting Guide
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.
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.
Function Description
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
Issue 02 (2012-06-25)
12
GBSS13.0
Troubleshooting Guide
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
Issue 02 (2012-06-25)
13
GBSS13.0
Troubleshooting Guide
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 MSCoriented 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 may lead to loopback tests of the channels used by other
subscribers on the same 64 Kbit/s timeslot.
Procedure
l
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.
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.
Issue 02 (2012-06-25)
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.
Huawei Proprietary and Confidential
Copyright Huawei Technologies Co., Ltd.
14
GBSS13.0
Troubleshooting Guide
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
TDM
interface
board
IP/HDLC
interface
board
TDM
interface
board
IP/HDLC
interface
board
Cannot hear A or
self
Issue 02 (2012-06-25)
15
GBSS13.0
Troubleshooting Guide
Subscriber A
Subscriber B
TDM
interface
board
IP/HDLC
interface
board
TDM
interface
board
IP/HDLC
interface
board
Cannot hear A or
self
TDM
interface
board
IP/HDLC
interface
board
TDM
interface
board
IP/HDLC
interface
board
Cannot hear A or
self
Issue 02 (2012-06-25)
Interface
Board Type
16
GBSS13.0
Troubleshooting Guide
Subscriber A
Subscriber B
TDM
interface
board
IP/HDLC
interface
board
TDM
interface
board
IP/HDLC
interface
board
Cannot hear A or
self
Non-IP BTS
IP BTS
Non-IP BTS
IP BTS
Cannot hear A or
self
TMU/PTU (MSC
Direction)
Interface
Board Type
Function Description
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.
Issue 02 (2012-06-25)
17
GBSS13.0
Troubleshooting Guide
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.
2.
2.
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.
1.
2.
Operation Results
l
Issue 02 (2012-06-25)
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.
Huawei Proprietary and Confidential
Copyright Huawei Technologies Co., Ltd.
18
GBSS13.0
Troubleshooting Guide
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.
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
AbisSlotNo
AbisPort
TNURack
TNUSlot
TNUPort
TcSubRackNo
TC subrack number
TcSlotNo
TC slot number
TcDspNo
TC DSP number
A interface
Acic
CIC number
Ater interface
AterLinkNo
TNU
TC resources
Function Description
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.
Issue 02 (2012-06-25)
19
GBSS13.0
Troubleshooting Guide
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 oneway 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.
Function Description
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).
Function Description
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.
Issue 02 (2012-06-25)
20
GBSS13.0
Troubleshooting Guide
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.
Function Description
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.
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.
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.
Function Description
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,
Issue 02 (2012-06-25)
21
GBSS13.0
Troubleshooting Guide
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.
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
Issue 02 (2012-06-25)
22
GBSS13.0
Troubleshooting Guide
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
DPC
CIC
NOTE
The information is unavailable in TC/BM combined mode.
Issue 02 (2012-06-25)
23
GBSS13.0
Troubleshooting Guide
Function Description
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
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).
Issue 02 (2012-06-25)
24
GBSS13.0
Troubleshooting Guide
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 selfloopback 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.
0
15
0
(Number of results = 1)
---
Issue 02 (2012-06-25)
Check Result
Not Cross
END
25
GBSS13.0
Troubleshooting Guide
Function Description
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.
2.
In the Monitor Navigation Tree, choose Monitor > Common Monitoring. Then, doubleclick 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
26
GBSS13.0
Troubleshooting Guide
Function Description
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.
1.
Run the MML command DSP BTSETHPORT to query the status of an Ethernet port.
Procedure
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.
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.
Function Description
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.
Issue 02 (2012-06-25)
Run the MML command SET BTSIPLOPTST to set IP loopback parameters for the BTS
to be tested.
Huawei Proprietary and Confidential
Copyright Huawei Technologies Co., Ltd.
27
GBSS13.0
Troubleshooting Guide
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.
Function Description
This section describes how to detect the interference band of an idle channel to monitor the
interference conditions on the channel.
Procedure
l
On the LMT, click Device Maintenance. The Device Maintenance tab page is
displayed.
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.
Issue 02 (2012-06-25)
28
GBSS13.0
Troubleshooting Guide
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
Function Description
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.
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.
Issue 02 (2012-06-25)
29
GBSS13.0
Troubleshooting Guide
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.
Function Description
This function applies to the scenario when a timeslot on a non-broadcast control channel (nonBCCH) 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.
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), halfrate 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.
Issue 02 (2012-06-25)
30
GBSS13.0
Troubleshooting Guide
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
Function Description
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.
Issue 02 (2012-06-25)
31
GBSS13.0
Troubleshooting Guide
Procedure
1.
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
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.
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.
Issue 02 (2012-06-25)
Click Submit.
Huawei Proprietary and Confidential
Copyright Huawei Technologies Co., Ltd.
32
GBSS13.0
Troubleshooting Guide
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-10 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.
Function Description
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
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-11.
Issue 02 (2012-06-25)
33
GBSS13.0
Troubleshooting Guide
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.
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-12 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.
Issue 02 (2012-06-25)
34
GBSS13.0
Troubleshooting Guide
Function Description
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.
Issue 02 (2012-06-25)
2.
On the BTS Maintenance tab page, choose BTS Maintenance > Monitor Channel
Status. The Monitor Channel Status tab page is displayed.
3.
On the Monitor Channel Status tab page, set the relevant parameters. Then, click
Start.
35
GBSS13.0
Troubleshooting Guide
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.
Operation Results
Figure 3-13 shows an example of the results of monitoring channel status.
Figure 3-13 Monitoring channel status
The various channel statuses on the Monitor Channel Status tab page are described as follows:
l
Subordinate Channel indicates that a channel sharing the same TRX as the current channel
is transmitting power. This is a normal state.
Issue 02 (2012-06-25)
36
GBSS13.0
Troubleshooting Guide
Right-click the channel to be queried. The detailed information about the channel is displayed,
as shown in Figure 3-14.
Figure 3-14 Channel status monitoring result
Function Description
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
l
Issue 02 (2012-06-25)
On the LMT, click Device Maintenance. The Device Maintenance tab page is
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-15.
Huawei Proprietary and Confidential
Copyright Huawei Technologies Co., Ltd.
37
GBSS13.0
Troubleshooting Guide
Function Description
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
l
Issue 02 (2012-06-25)
On the LMT, click Device Maintenance. The Device Maintenance tab page is
displayed.
Huawei Proprietary and Confidential
Copyright Huawei Technologies Co., Ltd.
38
GBSS13.0
Troubleshooting Guide
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-16.
Function Description
This function is used to query the board clock information and clock type of a BTS.
Procedure
l
Issue 02 (2012-06-25)
39
GBSS13.0
Troubleshooting Guide
Issue 02 (2012-06-25)
40
GBSS13.0
Troubleshooting Guide
4 Handover Problems
Handover Problems
Issue 02 (2012-06-25)
41
GBSS13.0
Troubleshooting Guide
4 Handover Problems
Issue 02 (2012-06-25)
42
GBSS13.0
Troubleshooting Guide
4 Handover Problems
An MS sends a measurement report to BTS 1 (the source BTS) on the SACCH over the
Um interface.
2.
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.
Issue 02 (2012-06-25)
43
GBSS13.0
Troubleshooting Guide
4 Handover Problems
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.
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.
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.
Formula
Handover success rate = Number of successful handovers/Number of handover requests
Radio handover success rate = Number of successful handovers/Number of handover commands
Issue 02 (2012-06-25)
44
GBSS13.0
Troubleshooting Guide
4 Handover Problems
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
Issue 02 (2012-06-25)
45
GBSS13.0
Troubleshooting Guide
4 Handover Problems
Figure 4-3 Measurement points in the signaling procedure for inter-BSC handovers
The formulas for calculating the various handover success rates are as follows:
l
Radio handover success rate = (C1: CH323:Number of Successful Incoming Internal InterCell Handovers + C3)/(B1: CH321: Number of Incoming Internal Inter-Cell Handover
Responses + B3)
Issue 02 (2012-06-25)
46
GBSS13.0
Troubleshooting Guide
4 Handover Problems
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.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 in a cell, focus on data configuration, frequency, and the
hardware of the problem cell.
2.
3.
4.
5.
6.
Common Procedure
Figure 4-4 shows the common procedure for locating handover problems.
Issue 02 (2012-06-25)
47
GBSS13.0
Troubleshooting Guide
4 Handover Problems
NOTE
Collect the problem location information by referring to Table 4-1 before contacting Huawei for technical
support.
Issue 02 (2012-06-25)
48
GBSS13.0
Troubleshooting Guide
4 Handover Problems
Item
Description
Symptom
Operations
before and
after the
problem
occurs
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.
Configurati
on data
script
For details
about how
to obtain
the
preceding
informatio
n, see 15
Appendix
: How to
Collect
Fault
Informati
on.
Issue 02 (2012-06-25)
Remarks
49
GBSS13.0
Troubleshooting Guide
4 Handover Problems
No.
Item
Description
Remarks
Historical
alarms
For details
about how
to obtain
the
historical
alarms,
see 15
Appendix
: How to
Collect
Fault
Informati
on.
Original
traffic
statistics
For details
about how
to obtain
the
original
traffic
statistics,
see 15
Appendix
: How to
Collect
Fault
Informati
on.
Issue 02 (2012-06-25)
Operation
logs
For details
about how
to obtain
the
operation
logs, see
15
Appendix
: How to
Collect
Fault
Informati
on.
50
GBSS13.0
Troubleshooting Guide
4 Handover Problems
No.
Item
Description
Remarks
Faulty
signaling
For details
about how
to obtain
the faulty
signaling,
see 15
Appendix
: How to
Collect
Fault
Informati
on.
GCHR and
GCSR logs
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 yes, go to Step 3.
l If no, go to 4.8 Troubleshooting Handover Problems Due to Inappropriate InterBSC/Inter-MSC/Inter-RAT Interaction. Then, check whether the handover problem
is resolved.
If yes, no further action is required.
If no, go to Step 3.
3.
Check whether any hardware alarms have been reported for the problem cell.
l If no, go to Step 4.
Issue 02 (2012-06-25)
51
GBSS13.0
Troubleshooting Guide
4 Handover Problems
5.
6.
7.
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
Issue 02 (2012-06-25)
52
GBSS13.0
Troubleshooting Guide
4 Handover Problems
the LAPD_OML to a BTS is interrupted, or that the handshake between the BSC and a
BTS expired.
l
Location Procedure
Figure 4-5 shows the procedure for locating handover problems due to hardware faults.
Issue 02 (2012-06-25)
53
GBSS13.0
Troubleshooting Guide
4 Handover Problems
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.
l If yes, go to Step 2.
l If no, go to Step 3.
2.
3.
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.
Troubleshooting Procedure
1.
Issue 02 (2012-06-25)
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.
Huawei Proprietary and Confidential
Copyright Huawei Technologies Co., Ltd.
54
GBSS13.0
Troubleshooting Guide
4 Handover Problems
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.
Symptom
l
The signal quality in the serving cell is poor. Handovers often cannot be initiated, and the
call drop rate is high.
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.
If the P/N criterion is set inappropriately, PBGT handovers often fail, and the handover
success rate is less than 98%.
Background Information
l
Issue 02 (2012-06-25)
55
GBSS13.0
Troubleshooting Guide
4 Handover Problems
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
Location Procedure
Figure 4-6 shows the procedure for locating handover problems due to incorrect data
configurations.
Issue 02 (2012-06-25)
56
GBSS13.0
Troubleshooting Guide
4 Handover Problems
Figure 4-6 Procedure for locating handover problems due to incorrect data configurations
Troubleshooting Procedure
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.
Issue 02 (2012-06-25)
57
GBSS13.0
Troubleshooting Guide
4 Handover Problems
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.
If yes, no further action is required.
If no, go to Step 2.
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 no, go to Step 3.
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.
If yes, no further action is required.
If no, go to Step 3.
3.
4.
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.
l If yes, go to Step 6.
l If no, run the MML command SET GCELLHOBASIC to change the value. Then,
check whether the handover problem is resolved.
If yes, no further action is required.
If no, go to Step 6.
6.
Typical Case
Symptom
Issue 02 (2012-06-25)
58
GBSS13.0
Troubleshooting Guide
4 Handover Problems
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.
Troubleshooting Procedure
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.
4.
5.
6.
Change the corresponding data of all neighboring cells. The handover problem is resolved.
Symptom
A handover to the target cell fails because the TCH congestion rates are high over several periods.
Background Information
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.
The network optimization parameters are set inappropriately, which causes a large number
of MSs to camp on the cell.
The handover parameters are set inappropriately, which causes a large number of MSs to
hand over to the cell.
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:
Issue 02 (2012-06-25)
59
GBSS13.0
Troubleshooting Guide
4 Handover Problems
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
Troubleshooting Procedure
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.
l If yes, go to Step 2.
l If no, go to Step 3.
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.
If yes, no further action is required.
Issue 02 (2012-06-25)
60
GBSS13.0
Troubleshooting Guide
4 Handover Problems
If no, go to Step 3.
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 yes, no further action is required.
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.
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.
3.
4.
Troubleshooting Procedure
1.
2.
Check whether the cell coverage and MS signals in the cell are normal.
a.
b.
3.
4.
5.
61
GBSS13.0
Troubleshooting Guide
4 Handover Problems
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.
Background Information
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
Interference band 2: -98 to -90 dBm
Interference band 3: -90 to -87 dBm
Interference band 4: -87 to -85 dBm
Interference band 5: -85 to -47 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.
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:
Issue 02 (2012-06-25)
62
GBSS13.0
Troubleshooting Guide
4 Handover Problems
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
Issue 02 (2012-06-25)
63
GBSS13.0
Troubleshooting Guide
4 Handover Problems
Troubleshooting Procedure
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 no, go to Step 2.
l If yes, remove the interference source or change the frequency by referring to
Background Information. Then, check whether the handover problem is resolved.
If yes, no further action is required.
If no, go to Step 2.
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 yes, go to Step 3.
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.
If yes, no further action is required.
If no, go to Step 3.
3.
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.
Troubleshooting Procedure
1.
2.
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.
Issue 02 (2012-06-25)
64
GBSS13.0
Troubleshooting Guide
5.
4 Handover Problems
Replace the CDU. If the incoming handover success rate exceeds 95%, the handover
problem is resolved.
Symptom
Handover failures occur in most cells under a BSC, but there are no top N cells with sluggish
performance.
Background Information
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.
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
Issue 02 (2012-06-25)
65
GBSS13.0
Troubleshooting Guide
4 Handover Problems
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
Troubleshooting Procedure
1.
Run the MML command DSP CLK to check whether Phase-locked loop state of current
clock is set to Trace.
l If yes, go to Step 2.
l If no, set Phase-locked loop state of current clock to Trace by referring to
Background Information. Then, check whether the handover problem is resolved.
If yes, no further action is required.
If no, go to Step 2.
2.
Typical Case
Symptom
There are 140 BTSs served by a BSC. The TMU clocks for 27 of the 140 BTSs are in the pullin 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.
Troubleshooting Procedure
Issue 02 (2012-06-25)
66
GBSS13.0
Troubleshooting Guide
1.
4 Handover Problems
2.
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 upperlevel 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.
6.
Issue 02 (2012-06-25)
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%.
67
GBSS13.0
Troubleshooting Guide
4 Handover Problems
Symptom
l
Background Information
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.
Cell data associated with handovers to the target BSC is configured incorrectly.
Location Procedure
Figure 4-11 shows the procedure for locating handover problems due to inappropriate interBSC, inter-MSC, or inter-RAT interaction.
Issue 02 (2012-06-25)
68
GBSS13.0
Troubleshooting Guide
4 Handover Problems
Figure 4-11 Procedure for locating handover problems due to inappropriate inter-BSC, interMSC, or inter-RAT interaction
Troubleshooting Procedure
1.
Run the MML command DSP CLK to check whether the BSC properly traces the upperlevel 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.
Issue 02 (2012-06-25)
69
GBSS13.0
Troubleshooting Guide
4 Handover Problems
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 yes, go to Step 3.
l If no, correct the neighboring cell configurations. Then, check whether the handover
problem is resolved.
If yes, no further action is required.
If no, go to Step 3.
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 yes, go to Step 4.
l If no, correct the data configurations. Then, check whether the handover problem is
resolved.
If yes, no further action is required.
If no, go to Step 4.
4.
Check whether the encryption procedure causes handover failures according to the
signaling procedure.
l If no, go to Step 5.
l If yes, adjust the encryption parameters or encryption procedure of the MSC or BSC.
Then, check whether the handover problem is resolved.
If yes, no further action is required.
If no, go to Step 5.
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 yes, go to Step 6.
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.
If yes, no further action is required.
If no, go to Step 6.
6.
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.
Troubleshooting Procedure
Issue 02 (2012-06-25)
70
GBSS13.0
Troubleshooting Guide
4 Handover Problems
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.
Troubleshooting Procedure
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
Issue 02 (2012-06-25)
71
GBSS13.0
Troubleshooting Guide
4 Handover Problems
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.
Issue 02 (2012-06-25)
Change the encryption algorithm on vendor M's MSC. The handover problem is resolved.
72
GBSS13.0
Troubleshooting Guide
5 Call Drops
Call Drops
Issue 02 (2012-06-25)
73
GBSS13.0
Troubleshooting Guide
5 Call Drops
Formula
See the online help for the formulas for calculating the following counters associated with call
drops:
l
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.
Issue 02 (2012-06-25)
74
GBSS13.0
Troubleshooting Guide
5 Call Drops
75
GBSS13.0
Troubleshooting Guide
5 Call Drops
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.
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
Issue 02 (2012-06-25)
76
GBSS13.0
Troubleshooting Guide
5 Call Drops
NOTE
Collect the problem location information by referring to Table 5-1 before contacting Huawei for technical
support.
Issue 02 (2012-06-25)
No.
Item
Description
Symptom
Operatio
ns before
and after
the
problem
occurs
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.
Configur
ation data
script
For details
about how to
obtain the
configuration
data script, see
15 Appendix:
How to
Collect Fault
Information.
Historica
l alarms
For details
about how to
obtain the
historical
alarms, see 15
Appendix:
How to
Collect Fault
Information.
Remarks
77
GBSS13.0
Troubleshooting Guide
Issue 02 (2012-06-25)
5 Call Drops
No.
Item
Description
Remarks
Original
traffic
statistics
For details
about how to
obtain the
original traffic
statistics, see
15 Appendix:
How to
Collect Fault
Information.
GCHR
and
GCSR
logs
For details
about how to
obtain the
GCHR and
GCSR logs,
see 15
Appendix:
How to
Collect Fault
Information.
Common
debuggin
g logs
For details
about how to
obtain the
common
debugging
logs, see 15
Appendix:
How to
Collect Fault
Information.
Operatio
n logs
For details
about how to
obtain the
operation logs,
see 15
Appendix:
How to
Collect Fault
Information.
10
Faulty
signaling
For details
about how to
obtain the
faulty
signaling, see
15 Appendix:
How to
Collect Fault
Information.
78
GBSS13.0
Troubleshooting Guide
5 Call Drops
No.
Item
Description
Remarks
11
BTS logs
For details
about how to
obtain BTS
logs, see 15
Appendix:
How to
Collect Fault
Information.
Issue 02 (2012-06-25)
79
GBSS13.0
Troubleshooting Guide
5 Call Drops
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)
CM3300:Call Drops on
Traffic Channel in Stable
State (Error Indication)
CM3301:Call Drops on
Traffic Channel in Stable
State (Connection Failure)
CM3302:Call Drops on
Traffic Channel in Stable
State (Release Indication)
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)
Issue 02 (2012-06-25)
80
GBSS13.0
Troubleshooting Guide
5 Call Drops
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.
In the handover state, focus on H3127Ca:Number of Unsuccessful Outgoing Internal InterCell 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.
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.
Issue 02 (2012-06-25)
81
GBSS13.0
Troubleshooting Guide
5 Call Drops
ERROR INDICATION
Huawei Proprietary and Confidential
Copyright Huawei Technologies Co., Ltd.
82
GBSS13.0
Troubleshooting Guide
5 Call Drops
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
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.
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.
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.
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.
Issue 02 (2012-06-25)
83
GBSS13.0
Troubleshooting Guide
5 Call Drops
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.
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.
Issue 02 (2012-06-25)
84
GBSS13.0
Troubleshooting Guide
5 Call Drops
Background Information
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.
2.
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.
Issue 02 (2012-06-25)
85
GBSS13.0
Troubleshooting Guide
5 Call Drops
Figure 5-5 Procedure for locating call drops due to poor Um interface quality
Troubleshooting Procedure
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.
Issue 02 (2012-06-25)
86
GBSS13.0
Troubleshooting Guide
5 Call Drops
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.
3.
l If yes, go to Step 5.
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.
4.
Issue 02 (2012-06-25)
87
GBSS13.0
Troubleshooting Guide
5 Call Drops
b.
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
l If no, go to Step 7.
6.
7.
8.
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.
88
GBSS13.0
Troubleshooting Guide
5 Call Drops
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.
Troubleshooting Procedure
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.
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.
Background Information
Call drops due to equipment faults are classified into the following types:
Issue 02 (2012-06-25)
89
GBSS13.0
Troubleshooting Guide
5 Call Drops
The following alarms are associated with call drops due to equipment faults.
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.
Issue 02 (2012-06-25)
90
GBSS13.0
Troubleshooting Guide
5 Call Drops
Figure 5-6 Procedure for locating call drops due to equipment faults
Troubleshooting Procedure
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.
l If no, go to Step 3.
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.
l If no, go to Step 4.
4.
Issue 02 (2012-06-25)
Analyze the signaling on the A interface when call drops occur, and check whether the
MSC sends a large number of Reset Circuit messages.
Huawei Proprietary and Confidential
Copyright Huawei Technologies Co., Ltd.
91
GBSS13.0
Troubleshooting Guide
5 Call Drops
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.
5.
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.
Troubleshooting Procedure
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.
Troubleshooting Procedure
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
Issue 02 (2012-06-25)
92
GBSS13.0
Troubleshooting Guide
5 Call Drops
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.
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.
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).
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-4102 TRX LAPD Link Interrupt Alarm
ALM-2114 TRX LAPD Link Interrupt Alarm
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
Issue 02 (2012-06-25)
93
GBSS13.0
Troubleshooting Guide
5 Call Drops
Location Procedure
None
Troubleshooting Procedure
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 yes, no further action is required.
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.
Troubleshooting Procedure
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.
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.
Issue 02 (2012-06-25)
94
GBSS13.0
Troubleshooting Guide
5 Call Drops
Background Information
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
Issue 02 (2012-06-25)
95
GBSS13.0
Troubleshooting Guide
5 Call Drops
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
Issue 02 (2012-06-25)
96
GBSS13.0
Troubleshooting Guide
5 Call Drops
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 reestablishment 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 reestablishment 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
Issue 02 (2012-06-25)
97
GBSS13.0
Troubleshooting Guide
5 Call Drops
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.
Issue 02 (2012-06-25)
98
GBSS13.0
Troubleshooting Guide
5 Call Drops
Figure 5-7 Procedure for locating call drops due to incorrect parameter settings
Troubleshooting Procedure
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 yes, go to Step 2.
l If no, Contact Huawei Customer Service Center.
2.
3.
4.
Issue 02 (2012-06-25)
99
GBSS13.0
Troubleshooting Guide
5 Call Drops
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.
l If no, go to Step 6.
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.
l If no, Contact Huawei Customer Service Center.
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.
Troubleshooting Procedure
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
2.
Issue 02 (2012-06-25)
Timer
T310
20
30
T313
10
30
15
20
30
42
Set the preceding timers to the values before the MSC cutover.
Huawei Proprietary and Confidential
Copyright Huawei Technologies Co., Ltd.
100
GBSS13.0
Troubleshooting Guide
6 Access Faults
Access Faults
Issue 02 (2012-06-25)
101
GBSS13.0
Troubleshooting Guide
6 Access Faults
This section describes how to troubleshoot low assignment success rates due to inappropriate
BSC configuration.
Issue 02 (2012-06-25)
102
GBSS13.0
Troubleshooting Guide
6 Access Faults
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.
Issue 02 (2012-06-25)
103
GBSS13.0
Troubleshooting Guide
6 Access Faults
Description
A1
A2
A3
A4
CA310:Assignment Requests
A5
CA313:Successful Assignments
Issue 02 (2012-06-25)
104
GBSS13.0
Troubleshooting Guide
6 Access Faults
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
Channel activation
Equipment faults
Equipment and
transmission faults
Immediate assignment
delivery
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.
Issue 02 (2012-06-25)
105
GBSS13.0
Troubleshooting Guide
6 Access Faults
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%
Issue 02 (2012-06-25)
106
GBSS13.0
Troubleshooting Guide
6 Access Faults
Possible Cause
TCH congestion
Um interface faults
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.
If assignment success rates are low, locate the problem by referring to Figure 6-3.
Issue 02 (2012-06-25)
107
GBSS13.0
Troubleshooting Guide
6 Access Faults
Figure 6-2 Procedure for locating low immediate assignment success rates
Issue 02 (2012-06-25)
108
GBSS13.0
Troubleshooting Guide
6 Access Faults
NOTE
Collect the fault location information by referring to Table 6-5 before contacting Huawei for technical
support.
Issue 02 (2012-06-25)
No.
Item
Description
Symptom
Remarks
109
GBSS13.0
Troubleshooting Guide
Issue 02 (2012-06-25)
6 Access Faults
No.
Item
Description
Operatio
ns before
and after
the
problem
occurs
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.
Configur
ation data
script
For details
about how to
obtain the
configuration
data script, see
15 Appendix:
How to
Collect Fault
Information.
Historica
l alarms
For details
about how to
obtain the
historical
alarms, see 15
Appendix:
How to
Collect Fault
Information.
Original
traffic
statistics
For details
about how to
obtain the
original traffic
statistics, see
15 Appendix:
How to
Collect Fault
Information.
Remarks
110
GBSS13.0
Troubleshooting Guide
Issue 02 (2012-06-25)
6 Access Faults
No.
Item
Description
Remarks
GCHR
and
GCSR
logs
For details
about how to
obtain the
GCHR and
GCSR logs,
see 15
Appendix:
How to
Collect Fault
Information.
Common
debuggin
g logs
For details
about how to
obtain the
common
debugging
logs, see 15
Appendix:
How to
Collect Fault
Information.
Operatio
n logs
For details
about how to
obtain the
operation logs,
see 15
Appendix:
How to
Collect Fault
Information.
10
Faulty
signaling
For details
about how to
obtain the
faulty
signaling, see
15 Appendix:
How to
Collect Fault
Information.
11
BTS logs
For details
about how to
obtain BTS
logs, see 15
Appendix:
How to
Collect Fault
Information.
111
GBSS13.0
Troubleshooting Guide
6 Access Faults
Issue 02 (2012-06-25)
112
GBSS13.0
Troubleshooting Guide
6 Access Faults
Figure 6-4 Common causes for low immediate assignment success rates
Issue 02 (2012-06-25)
Um interface faults
113
GBSS13.0
Troubleshooting Guide
6 Access Faults
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.
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.
Issue 02 (2012-06-25)
114
GBSS13.0
Troubleshooting Guide
6 Access Faults
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.
Issue 02 (2012-06-25)
115
GBSS13.0
Troubleshooting Guide
6 Access Faults
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.
For details about how to troubleshoot this problem, see 6.7 Troubleshooting Low
Assignment Success Rates Due to TCH Congestion.
MSC faults
If the MSC delivers the Clear CMD message during assignment, the assignment fails. To
troubleshoot this problem, contact MSC engineers.
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%.
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
Issue 02 (2012-06-25)
116
GBSS13.0
Troubleshooting Guide
6 Access Faults
original channels and send assignment failure messages. In addition, the value of
A3169A:Failed Assignments (Um Cause) increases noticeably.
Background Information
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.
2.
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.
Issue 02 (2012-06-25)
117
GBSS13.0
Troubleshooting Guide
6 Access Faults
Figure 6-6 Procedure for locating access faults due to poor Um interface quality
Troubleshooting Procedure
1.
Issue 02 (2012-06-25)
118
GBSS13.0
Troubleshooting Guide
6 Access Faults
a.
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.
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 yes, go to Step 5.
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.
4.
5.
Issue 02 (2012-06-25)
119
GBSS13.0
Troubleshooting Guide
6 Access Faults
signal levels, access faults in the cell may be caused by poor receive quality, resulting
from coverage problems.
b.
6.
7.
8.
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.
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 adjacentchannel interference.
Cause Analysis
The cells work on the same frequency and use the same base transceiver station identity code
(BSIC), leading to interference.
Troubleshooting Procedure
Issue 02 (2012-06-25)
120
GBSS13.0
Troubleshooting Guide
1.
6 Access Faults
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.
Issue 02 (2012-06-25)
121
GBSS13.0
Troubleshooting Guide
6 Access Faults
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.
Background Information
l
Issue 02 (2012-06-25)
122
GBSS13.0
Troubleshooting Guide
6 Access Faults
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.
Issue 02 (2012-06-25)
123
GBSS13.0
Troubleshooting Guide
6 Access Faults
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
Normal
Normal
Prohibited
Prohibited
Low
Normal
Low
Normal
Issue 02 (2012-06-25)
124
GBSS13.0
Troubleshooting Guide
6 Access Faults
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
Troubleshooting Procedure
1.
2.
Typical Case
Symptom
Issue 02 (2012-06-25)
125
GBSS13.0
Troubleshooting Guide
6 Access Faults
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.
Troubleshooting Procedure
1.
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.
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.
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.
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.
For details about the hardware or transmission fault alarms, see Background
Information.
Issue 02 (2012-06-25)
126
GBSS13.0
Troubleshooting Guide
6 Access Faults
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).
Background Information
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-4144 TRX VSWR alarm
ALM-26529 RF Unit VSWR Threshold Crossed
ALM-3606 DRU Hardware alarm
ALM-20241 Board Unavailable
ALM-20243 Board Hardware Fault
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-4102 TRX LAPD Link Interrupt Alarm
ALM-2114 TRX LAPD Link Interrupt Alarm
ALM-3052 LAPD alarm
ALM-3572 LAPD alarm
BSC LAPD link alarms
ALM-21511 LAPD Link Congestion
Issue 02 (2012-06-25)
127
GBSS13.0
Troubleshooting Guide
6 Access Faults
Location Procedure
Figure 6-9 shows the procedure for locating low immediate assignment success rates due to
hardware or transmission faults.
Issue 02 (2012-06-25)
128
GBSS13.0
Troubleshooting Guide
6 Access Faults
Figure 6-9 Procedure for locating low immediate assignment success rates due to hardware or
transmission faults
Troubleshooting Procedure
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.
l If no, go to Step 3.
2.
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.
l If yes, no further action is required.
l If no, go to Step 4.
4.
Issue 02 (2012-06-25)
Request transmission device engineers to clear transmission fault alarms. Then, check the
performance counters listed in Background Information to determine whether channel
Huawei Proprietary and Confidential
Copyright Huawei Technologies Co., Ltd.
129
GBSS13.0
Troubleshooting Guide
6 Access Faults
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.
Troubleshooting Procedure
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.
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.
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.
Background Information
The characteristics of low immediate assignment success rates due to location updates of
problem MSs are as follows:
Issue 02 (2012-06-25)
130
GBSS13.0
Troubleshooting Guide
6 Access Faults
The immediate assignment success rates may be low during peak hours or during off-peak
hours.
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.
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
Troubleshooting Procedure
1.
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.
Troubleshooting Procedure
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
Issue 02 (2012-06-25)
131
GBSS13.0
Troubleshooting Guide
6 Access Faults
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.
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.
Issue 02 (2012-06-25)
132
GBSS13.0
Troubleshooting Guide
6 Access Faults
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).
Background Information
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) +
Issue 02 (2012-06-25)
133
GBSS13.0
Troubleshooting Guide
6 Access Faults
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.
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.
Issue 02 (2012-06-25)
134
GBSS13.0
Troubleshooting Guide
6 Access Faults
Figure 6-12 Procedure for locating low assignment success rates due to TCH congestion
Issue 02 (2012-06-25)
135
GBSS13.0
Troubleshooting Guide
6 Access Faults
Troubleshooting Procedure
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 yes, go to Step 2.
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.
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.
l 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.
l If no, go to Step 4.
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.
l 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.
l If no, go to Step 6.
6.
Issue 02 (2012-06-25)
136
GBSS13.0
Troubleshooting Guide
6 Access Faults
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.
l 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.
Troubleshooting Procedure
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.
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).
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.
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
Issue 02 (2012-06-25)
137
GBSS13.0
Troubleshooting Guide
6 Access Faults
tracing result shows that MSs fail to access traffic channels (TCHs) and send assignment
failure messages on standalone dedicated control channels (SDCCHs).
Background Information
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-4144 TRX VSWR 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
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-4102 TRX LAPD Link Interrupt Alarm
ALM-2114 TRX LAPD Link Interrupt Alarm
ALM-3052 LAPD alarm
ALM-3572 LAPD alarm
BSC LAPD link alarms
ALM-21511 LAPD Link Congestion
ALM-21512 LAPD Link Fault
Alarms related to the MSP of optical ports
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
Issue 02 (2012-06-25)
138
GBSS13.0
Troubleshooting Guide
6 Access Faults
Location Procedure
Figure 6-13 shows the procedure for locating low assignment success rates due to hardware or
transmission faults.
Figure 6-13 Procedure for locating low assignment success rates due to hardware or transmission
faults
Troubleshooting Procedure
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.
l If no, go to Step 3.
2.
Perform dialing tests to check whether the assignment success rates return to normal.
l If yes, no further action is required.
l If no, go to Step 3.
3.
Issue 02 (2012-06-25)
Check whether any of the transmission fault alarms listed in Background Information are
reported.
Huawei Proprietary and Confidential
Copyright Huawei Technologies Co., Ltd.
139
GBSS13.0
Troubleshooting Guide
6 Access Faults
l If yes, contact transmission engineers to clear the transmission fault alarms. Then, go
to Step 4.
l If no, return to Procedure for locating access faults.
4.
Perform dialing tests to check whether the assignment success rates return to normal.
l If yes, no further action is required.
l If no, return to Procedure for locating access faults.
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.
Troubleshooting Procedure
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
Issue 02 (2012-06-25)
140
GBSS13.0
Troubleshooting Guide
6 Access Faults
3.
Correct the cable connections between the TNUs by referring to Figure 6-15. This
correction resolves the problem.
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.
Background Information
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.
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.
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.
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.
Issue 02 (2012-06-25)
141
GBSS13.0
Troubleshooting Guide
6 Access Faults
If cable connections between the TNUs on different subracks are not configured, intersubrack call assignment fails.
Location Procedure
Figure 6-16 shows the procedure for locating low assignment success rates due to inappropriate
BSC configuration
Issue 02 (2012-06-25)
142
GBSS13.0
Troubleshooting Guide
6 Access Faults
Figure 6-16 Procedure for locating low assignment success rates due to inappropriate BSC
configuration
Issue 02 (2012-06-25)
143
GBSS13.0
Troubleshooting Guide
6 Access Faults
Troubleshooting Procedure
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.
l If no, 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.
l If no, go to Step 3.
3.
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 yes, go to Step 5.
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 yes, go to Step 6.
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 yes, go to Step 7.
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.
8.
Issue 02 (2012-06-25)
144
GBSS13.0
Troubleshooting Guide
6 Access Faults
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 yes, go to Step 10.
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.
l 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.
Troubleshooting Procedure
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.
3.
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.
Issue 02 (2012-06-25)
145
GBSS13.0
Troubleshooting Guide
7 Voice Problems
Voice Problems
Issue 02 (2012-06-25)
146
GBSS13.0
Troubleshooting Guide
7 Voice Problems
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.
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.
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 MSS over the A interface.
147
GBSS13.0
Troubleshooting Guide
7 Voice Problems
Figure 7-2 shows the CS signal flow in Abis over TDM, Ater over IP, A over TDM, and BM/
TC separated mode.
Figure 7-2 GSM CS signal flow (2)
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. 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.
5.
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.
6.
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 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.
Issue 02 (2012-06-25)
148
GBSS13.0
Troubleshooting Guide
7 Voice Problems
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 DPUc board through the TNUa board.
3.
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 MSS over the A interface.
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.
l The INT in the figure stands for the interface board. You can use different interface boards as required.
The uplink CS signals are sent from the BTS to the Abis interface board in the MPS/EPS.
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.
5.
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.
6.
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 MSS over the A interface.
Issue 02 (2012-06-25)
149
GBSS13.0
Troubleshooting Guide
7 Voice Problems
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 SCUa 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 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.
150
GBSS13.0
Troubleshooting Guide
7 Voice Problems
1.
The uplink CS signals are sent from the BTS to the Abis interface board in the MPS/EPS.
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.
l The Abis interface board can be the EIUa/OIUa/POUc board, and the A interface board can be the FG2a/
GOUa/FG2c/GOUc/FG2d/GOUd/POUc board. The boards shown in Figure 7-7 are only examples.
l The INT in the figure stands for the interface board. You can use different interface boards as required.
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 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.
151
GBSS13.0
Troubleshooting Guide
7 Voice Problems
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/FG2d/GOUd/POUc board. The boards shown
in Figure 7-8 are only examples.
l The INT in the figure stands for the interface board. You can use different interface boards as required.
The uplink CS signals are sent from the BTS to the Abis interface board in the MPS/EPS.
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 the CS signals to the A interface board, and then the A interface
board transmits the signals to the MSS over the A interface.
l
Issue 02 (2012-06-25)
Chip faults
Huawei Proprietary and Confidential
Copyright Huawei Technologies Co., Ltd.
152
GBSS13.0
Troubleshooting Guide
7 Voice Problems
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.
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.
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.
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.
Background Information
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.
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.
Issue 02 (2012-06-25)
153
GBSS13.0
Troubleshooting Guide
7 Voice Problems
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
Collect the problem location information by referring to Table 7-1 before contacting Huawei for technical
support.
Issue 02 (2012-06-25)
No.
Item
Description
Symptom
Remarks
154
GBSS13.0
Troubleshooting Guide
Issue 02 (2012-06-25)
7 Voice Problems
No.
Item
Description
Operation
s before
and after
the
problem
occurs
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.
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.
Loopback
results
For details
about how to
obtain the
loopback
results, see
3.1.2
External
Voice
Loopback.
Remarks
155
GBSS13.0
Troubleshooting Guide
Issue 02 (2012-06-25)
7 Voice Problems
No.
Item
Description
Remarks
One-way
audio logs
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.
Configura
tion data
script
For details
about how to
obtain the
configuration
data script
used when the
problem
occurs, see 15
Appendix:
How to
Collect Fault
Information.
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.
156
GBSS13.0
Troubleshooting Guide
Issue 02 (2012-06-25)
7 Voice Problems
No.
Item
Description
Remarks
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
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.
157
GBSS13.0
Troubleshooting Guide
7 Voice Problems
No.
Item
Description
Remarks
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
For details
about how to
obtain all logs
for one or two
faulty BTSs,
see 15
Appendix:
How to
Collect Fault
Information.
Troubleshooting Procedure
1.
2.
3.
Issue 02 (2012-06-25)
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
Huawei Proprietary and Confidential
Copyright Huawei Technologies Co., Ltd.
158
GBSS13.0
Troubleshooting Guide
7 Voice Problems
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.
Troubleshooting Procedure
1.
Enable one-way audio detection. Ten minutes later, the one-way audio logs show that oneway 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.
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.
Background Information
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
Issue 02 (2012-06-25)
159
GBSS13.0
Troubleshooting Guide
7 Voice Problems
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.
Figure 7-10 Procedure for locating noise
Issue 02 (2012-06-25)
160
GBSS13.0
Troubleshooting Guide
7 Voice Problems
NOTE
Collect the problem location information by referring to Table 7-2 before contacting Huawei for technical
support.
Issue 02 (2012-06-25)
No.
Item
Description
Symptom
Operation
s before
and after
the
problem
occurs
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.
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.
Remarks
161
GBSS13.0
Troubleshooting Guide
Issue 02 (2012-06-25)
7 Voice Problems
No.
Item
Description
Remarks
Loopback
results
For details
about how to
obtain the
loopback
results, see
3.1.2
External
Voice
Loopback.
Configura
tion data
script
For details
about how to
obtain the
configuration
data script
used when the
problem
occurs, see 15
Appendix:
How to
Collect Fault
Information.
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.
162
GBSS13.0
Troubleshooting Guide
Issue 02 (2012-06-25)
7 Voice Problems
No.
Item
Description
Remarks
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.
DSP
debugging
logs
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.
163
GBSS13.0
Troubleshooting Guide
7 Voice Problems
No.
Item
Description
Remarks
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.
12
BTS logs
For details
about how to
obtain all logs
for one or two
faulty BTSs,
see 15
Appendix:
How to
Collect Fault
Information.
Troubleshooting Procedure
1.
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 2.
2.
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 3.
3.
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.
4.
Issue 02 (2012-06-25)
164
GBSS13.0
Troubleshooting Guide
7 Voice Problems
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.
Troubleshooting Procedure
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.
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.
Background Information
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
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.
Location Procedure
Figure 7-11 shows the procedure for locating crosstalk.
Issue 02 (2012-06-25)
165
GBSS13.0
Troubleshooting Guide
7 Voice Problems
NOTE
Collect the problem location information by referring to Table 7-3 before contacting Huawei for technical
support.
Issue 02 (2012-06-25)
No.
Item
Description
Symptom
Operation
s before
and after
the
problem
occurs
Remarks
166
GBSS13.0
Troubleshooting Guide
Issue 02 (2012-06-25)
7 Voice Problems
No.
Item
Description
Remarks
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.
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.
Loopback
results
For details
about how to
obtain the
loopback
results, see
3.1.2
External
Voice
Loopback.
167
GBSS13.0
Troubleshooting Guide
Issue 02 (2012-06-25)
7 Voice Problems
No.
Item
Description
Remarks
Crosstalk
logs
For details
about how to
obtain the
crosstalk logs
generated
within the
latest five
days, see 15
Appendix:
How to
Collect Fault
Information.
Configura
tion data
script
For details
about how to
obtain the
configuration
data script
used when the
problem
occurs, see 15
Appendix:
How to
Collect Fault
Information.
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.
168
GBSS13.0
Troubleshooting Guide
Issue 02 (2012-06-25)
7 Voice Problems
No.
Item
Description
Remarks
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
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.
169
GBSS13.0
Troubleshooting Guide
7 Voice Problems
No.
Item
Description
Remarks
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
For details
about how to
obtain all logs
for one or two
faulty BTSs,
see 15
Appendix:
How to
Collect Fault
Information.
Troubleshooting Procedure
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.
2.
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.
l If no, Contact Huawei Customer Service Center.
4.
Issue 02 (2012-06-25)
170
GBSS13.0
Troubleshooting Guide
7 Voice Problems
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.
Troubleshooting Procedure
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.
Symptom
The calling or called party can hear his or her own voice as well as that of the other party.
Background Information
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.
Issue 02 (2012-06-25)
171
GBSS13.0
Troubleshooting Guide
7 Voice Problems
NOTE
Collect the problem location information by referring to Table 7-4 before contacting Huawei for technical
support.
Issue 02 (2012-06-25)
No.
Item
Description
Symptom
Operation
s before
and after
the
problem
occurs
Remarks
172
GBSS13.0
Troubleshooting Guide
Issue 02 (2012-06-25)
7 Voice Problems
No.
Item
Description
Remarks
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.
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.
Configura
tion data
script
For details
about how to
obtain the
configuration
data script
used when the
problem
occurs, see 15
Appendix:
How to
Collect Fault
Information.
173
GBSS13.0
Troubleshooting Guide
Issue 02 (2012-06-25)
7 Voice Problems
No.
Item
Description
Remarks
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.
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.
DSP
debugging
logs
For details
about how to
obtain the
latest three
compressed
DPS
debugging log
files, see 15
Appendix:
How to
Collect Fault
Information.
174
GBSS13.0
Troubleshooting Guide
7 Voice Problems
No.
Item
Description
Remarks
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.
11
BTS logs
For details
about how to
obtain all logs
for one or two
faulty BTSs,
see 15
Appendix:
How to
Collect Fault
Information.
Troubleshooting Procedure
1.
Issue 02 (2012-06-25)
175
GBSS13.0
Troubleshooting Guide
2.
7 Voice Problems
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.
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.
Troubleshooting Procedure
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.
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.
Low MOS
The MOS does not meet the customer's requirement.
Issue 02 (2012-06-25)
176
GBSS13.0
Troubleshooting Guide
7 Voice Problems
Background Information
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.
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
Collect the problem location information by referring to Table 7-5 before contacting Huawei for technical
support.
Issue 02 (2012-06-25)
177
GBSS13.0
Troubleshooting Guide
7 Voice Problems
Issue 02 (2012-06-25)
No.
Item
Description
Symptom
Operation
s before
and after
the
problem
occurs
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.
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.
Remarks
178
GBSS13.0
Troubleshooting Guide
Issue 02 (2012-06-25)
7 Voice Problems
No.
Item
Description
Remarks
Loopback
results
For details
about how to
obtain the
loopback
results, see
3.1.2
External
Voice
Loopback.
Configura
tion data
script
For details
about how to
obtain the
configuration
data script
used when the
problem
occurs, see 15
Appendix:
How to
Collect Fault
Information.
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.
179
GBSS13.0
Troubleshooting Guide
Issue 02 (2012-06-25)
7 Voice Problems
No.
Item
Description
Remarks
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.
DSP
debugging
logs
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.
180
GBSS13.0
Troubleshooting Guide
7 Voice Problems
No.
Item
Description
Remarks
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.
12
BTS logs
For details
about how to
obtain all logs
for one or two
faulty BTSs,
see 15
Appendix:
How to
Collect Fault
Information.
Troubleshooting Procedure
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.
Troubleshooting Procedure
1.
Issue 02 (2012-06-25)
181
GBSS13.0
Troubleshooting Guide
7 Voice Problems
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%.
Issue 02 (2012-06-25)
182
GBSS13.0
Troubleshooting Guide
8 PS Counter Problems
PS Counter Problems
Issue 02 (2012-06-25)
183
GBSS13.0
Troubleshooting Guide
8 PS Counter Problems
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]
Issue 02 (2012-06-25)
184
GBSS13.0
Troubleshooting Guide
8 PS Counter Problems
Analyze BSC counters before cell counters, lower-layer links before upper-layer services,
as well as symptoms before traffic models.
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.
Issue 02 (2012-06-25)
185
GBSS13.0
Troubleshooting Guide
8 PS Counter Problems
Issue 02 (2012-06-25)
186
GBSS13.0
Troubleshooting Guide
8 PS Counter Problems
Symptom
TBF establishment success rates do not meet customer requirements and PS calls are difficult
to set up.
Background Information
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
Location Procedure
Figure 8-2 shows the procedure for locating low TBF establishment success rates.
Issue 02 (2012-06-25)
187
GBSS13.0
Troubleshooting Guide
8 PS Counter Problems
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.
Issue 02 (2012-06-25)
188
GBSS13.0
Troubleshooting Guide
8 PS Counter Problems
Issue 02 (2012-06-25)
No.
Item
Description
Symptom
Operations
before and after
the fault occurs
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.
Configuration
data script
For details
about how
to obtain
the
configurat
ion data
script, see
15
Appendix
: How to
Collect
Fault
Informati
on.
Remarks
189
GBSS13.0
Troubleshooting Guide
Issue 02 (2012-06-25)
8 PS Counter Problems
No.
Item
Description
Remarks
Original traffic
statistics
For details
about how
to obtain
the
original
traffic
statistics,
see 15
Appendix
: How to
Collect
Fault
Informati
on.
GPSR logs
For details
about how
to obtain
the GPSR
logs, see
15
Appendix
: How to
Collect
Fault
Informati
on.
Common
debugging logs
For details
about how
to obtain
the
common
debugging
logs, see
15
Appendix
: How to
Collect
Fault
Informati
on.
190
GBSS13.0
Troubleshooting Guide
8 PS Counter Problems
No.
Item
Description
Remarks
Operation logs
For details
about how
to obtain
the
operation
logs, see
15
Appendix
: How to
Collect
Fault
Informati
on.
Faulty
signaling
For details
about how
to obtain
the faulty
signaling,
see 15
Appendix
: How to
Collect
Fault
Informati
on.
Troubleshooting Procedure
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.
Issue 02 (2012-06-25)
191
GBSS13.0
Troubleshooting Guide
8 PS Counter Problems
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 is 48 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
A DSP number consists of the subrack number, slot number, and DSP number.
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.
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.
Issue 02 (2012-06-25)
192
GBSS13.0
Troubleshooting Guide
8 PS Counter Problems
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.
7.
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.
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
service access increases, but the TBF establishment success rate in an adverse radio
environment also increases.
b.
Issue 02 (2012-06-25)
Run the MML command SET GCELLPSPWPARA to change the values for
ALPHA and GAMMA.
Huawei Proprietary and Confidential
Copyright Huawei Technologies Co., Ltd.
193
GBSS13.0
Troubleshooting Guide
8 PS Counter Problems
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.
b.
8.
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.
Troubleshooting Procedure
1.
Issue 02 (2012-06-25)
Analyze related counters. The TBF establishment success rates are lower than 80% for 10
cells.
Huawei Proprietary and Confidential
Copyright Huawei Technologies Co., Ltd.
194
GBSS13.0
Troubleshooting Guide
8 PS Counter Problems
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.
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.
Background Information
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
Cell reselection
Channel preemption
Location Procedure
Figure 8-3 shows the procedure for locating high TBF call drop rates.
Issue 02 (2012-06-25)
195
GBSS13.0
Troubleshooting Guide
8 PS Counter Problems
Figure 8-3 Procedure for locating high TBF call drop rates
NOTE
Collect the location information about PS counter problems by referring to Table 8-2 before contacting
Huawei for technical support.
Issue 02 (2012-06-25)
196
GBSS13.0
Troubleshooting Guide
8 PS Counter Problems
Issue 02 (2012-06-25)
No.
Item
Description
Symptom
Operations
before and after
the fault occurs
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.
Configuration
data script
For details
about how
to obtain
the
configurat
ion data
script, see
15
Appendix
: How to
Collect
Fault
Informati
on.
Remarks
197
GBSS13.0
Troubleshooting Guide
Issue 02 (2012-06-25)
8 PS Counter Problems
No.
Item
Description
Remarks
Original traffic
statistics
For details
about how
to obtain
the
original
traffic
statistics,
see 15
Appendix
: How to
Collect
Fault
Informati
on.
GPSR logs
For details
about how
to obtain
the GPSR
logs, see
15
Appendix
: How to
Collect
Fault
Informati
on.
Common
debugging logs
For details
about how
to obtain
the
common
debugging
logs, see
15
Appendix
: How to
Collect
Fault
Informati
on.
198
GBSS13.0
Troubleshooting Guide
8 PS Counter Problems
No.
Item
Description
Remarks
Operation logs
For details
about how
to obtain
the
operation
logs, see
15
Appendix
: How to
Collect
Fault
Informati
on.
Faulty
signaling
For details
about how
to obtain
the faulty
signaling,
see 15
Appendix
: How to
Collect
Fault
Informati
on.
Troubleshooting Procedure
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.
Issue 02 (2012-06-25)
199
GBSS13.0
Troubleshooting Guide
8 PS Counter Problems
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.
If the parameter settings are incorrect, run the MML command SET
GCELLEGPRSPARA to change the settings.
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.
Maximum Value of N3103: Check whether the value for this parameter is larger
than or equal to 3.
Maximum Value of N3105: Check whether the value for this parameter is larger
than or equal to 10.
If the parameter settings are incorrect, run the MML command SET
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)
A9206:Number of Uplink EGPRS TBF Abnormal Releases due to N3101 Overflow
(MS No Response)
A9207:Number of Uplink EGPRS TBF Abnormal Releases due to N3103 Overflow
(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
Issue 02 (2012-06-25)
200
GBSS13.0
Troubleshooting Guide
8 PS Counter Problems
6.
Typical Case
Symptom
The TBF call drop rate at a site increases by 3%.
Cause Analysis
Frequency interference and insufficient channel resources
Troubleshooting Procedure
1.
Check that the parameters for the cells with high TBF call drop rates are set to recommended
values.
2.
Check the frame error rates for Abis transmission in these cells. The frame error rates are
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.
Issue 02 (2012-06-25)
201
GBSS13.0
Troubleshooting Guide
8 PS Counter Problems
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.
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
Background Information
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.
Poor radio environment, such as poor Um interface quality, poor Abis transmission quality,
and poor Gb transmission quality.
Incorrect parameter settings, such as incorrect settings for PDCH Downlink Multiplex
Threshold, Channel Type, and Bep Period.
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.
Issue 02 (2012-06-25)
202
GBSS13.0
Troubleshooting Guide
8 PS Counter Problems
Figure 8-4 Procedure for locating low average throughput at the RLC layer
NOTE
Collect the location information about PS counter problems by referring to Table 8-3 before contacting
Huawei for technical support.
Issue 02 (2012-06-25)
203
GBSS13.0
Troubleshooting Guide
8 PS Counter Problems
Issue 02 (2012-06-25)
No.
Item
Description
Symptom
Operations
before and after
the fault occurs
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.
Configuration
data script
For details
about how
to obtain
the
configurat
ion data
script, see
15
Appendix
: How to
Collect
Fault
Informati
on.
Remarks
204
GBSS13.0
Troubleshooting Guide
Issue 02 (2012-06-25)
8 PS Counter Problems
No.
Item
Description
Remarks
Original traffic
statistics
For details
about how
to obtain
the
original
traffic
statistics,
see 15
Appendix
: How to
Collect
Fault
Informati
on.
GPSR logs
For details
about how
to obtain
the GPSR
logs, see
15
Appendix
: How to
Collect
Fault
Informati
on.
Common
debugging logs
For details
about how
to obtain
the
common
debugging
logs, see
15
Appendix
: How to
Collect
Fault
Informati
on.
205
GBSS13.0
Troubleshooting Guide
8 PS Counter Problems
No.
Item
Description
Remarks
Operation logs
For details
about how
to obtain
the
operation
logs, see
15
Appendix
: How to
Collect
Fault
Informati
on.
Faulty
signaling
For details
about how
to obtain
the faulty
signaling,
see 15
Appendix
: How to
Collect
Fault
Informati
on.
Troubleshooting Procedure
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.
l If no, the following operations should be performed on all cells on the network.
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 no, go to Step 3.
3.
Issue 02 (2012-06-25)
206
GBSS13.0
Troubleshooting Guide
8 PS Counter Problems
Downlink Default MCS Type: Check whether the value for this parameter is larger
than or equal to MCS6.
If the parameter settings are incorrect, run the MML command SET
GCELLEGPRSPARA to change the settings.
l If the GPRS throughput is low, 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 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.
If the parameter settings are incorrect, run the MML command SET
GCELLEGPRSPARA to change the settings.
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
Issue 02 (2012-06-25)
207
GBSS13.0
Troubleshooting Guide
8 PS Counter Problems
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.
7.
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 insufficient idle Abis timeslots.
Troubleshooting Procedure
1.
Issue 02 (2012-06-25)
Check the settings of the parameters for the cells with low average throughput at the RLC
layer. These parameters are set to recommended values.
Huawei Proprietary and Confidential
Copyright Huawei Technologies Co., Ltd.
208
GBSS13.0
Troubleshooting Guide
8 PS Counter Problems
2.
Check the frame error rates for Abis transmission in these cells. The frame error rates are
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.
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.
Background Information
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:
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.
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.
Issue 02 (2012-06-25)
209
GBSS13.0
Troubleshooting Guide
8 PS Counter Problems
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.
Issue 02 (2012-06-25)
210
GBSS13.0
Troubleshooting Guide
8 PS Counter Problems
Figure 8-5 Procedure for locating low percentage of high-rate coding schemes to all coding
schemes
Issue 02 (2012-06-25)
211
GBSS13.0
Troubleshooting Guide
8 PS Counter Problems
NOTE
Collect the location information about PS counter problems by referring to Table 8-4 before contacting
Huawei for technical support.
Issue 02 (2012-06-25)
No.
Item
Description
Symptom
Operations
before and after
the fault occurs
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.
Configuration
data script
For details
about how
to obtain
the
configurat
ion data
script, see
15
Appendix
: How to
Collect
Fault
Informati
on.
Remarks
212
GBSS13.0
Troubleshooting Guide
Issue 02 (2012-06-25)
8 PS Counter Problems
No.
Item
Description
Remarks
Original traffic
statistics
For details
about how
to obtain
the
original
traffic
statistics,
see 15
Appendix
: How to
Collect
Fault
Informati
on.
GPSR logs
For details
about how
to obtain
the GPSR
logs, see
15
Appendix
: How to
Collect
Fault
Informati
on.
Common
debugging logs
For details
about how
to obtain
the
common
debugging
logs, see
15
Appendix
: How to
Collect
Fault
Informati
on.
213
GBSS13.0
Troubleshooting Guide
8 PS Counter Problems
No.
Item
Description
Remarks
Operation logs
For details
about how
to obtain
the
operation
logs, see
15
Appendix
: How to
Collect
Fault
Informati
on.
Faulty
signaling
For details
about how
to obtain
the faulty
signaling,
see 15
Appendix
: How to
Collect
Fault
Informati
on.
Troubleshooting Procedure
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 no, the following operations should be performed on all cells on the network.
2.
Issue 02 (2012-06-25)
214
GBSS13.0
Troubleshooting Guide
8 PS Counter Problems
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 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 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.
If the parameter settings are incorrect, run the MML command SET
GCELLEGPRSPARA to change the settings.
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.
To prevent an increase in the RLC data retransmission rate, change the values for the following
parameters according to site requirements.
Issue 02 (2012-06-25)
215
GBSS13.0
Troubleshooting Guide
8 PS Counter Problems
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.
8.
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.
Troubleshooting Procedure
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.
2.
Check the frame error rates for Abis transmission in these cells. The frame error rates are
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.
Issue 02 (2012-06-25)
216
GBSS13.0
Troubleshooting Guide
8 PS Counter Problems
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.
Background Information
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:
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.
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.
Issue 02 (2012-06-25)
217
GBSS13.0
Troubleshooting Guide
8 PS Counter Problems
Figure 8-6 Procedure for locating high RLC data block retransmission rates
NOTE
Collect the location information about PS counter problems by referring to Table 8-5 before contacting
Huawei for technical support.
Issue 02 (2012-06-25)
No.
Item
Description
Symptom
Remarks
218
GBSS13.0
Troubleshooting Guide
Issue 02 (2012-06-25)
8 PS Counter Problems
No.
Item
Description
Operations
before and after
the fault occurs
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.
Configuration
data script
For details
about how
to obtain
the
configurat
ion data
script, see
15
Appendix
: How to
Collect
Fault
Informati
on.
Remarks
219
GBSS13.0
Troubleshooting Guide
Issue 02 (2012-06-25)
8 PS Counter Problems
No.
Item
Description
Remarks
Original traffic
statistics
For details
about how
to obtain
the
original
traffic
statistics,
see 15
Appendix
: How to
Collect
Fault
Informati
on.
GPSR logs
For details
about how
to obtain
the GPSR
logs, see
15
Appendix
: How to
Collect
Fault
Informati
on.
Common
debugging logs
For details
about how
to obtain
the
common
debugging
logs, see
15
Appendix
: How to
Collect
Fault
Informati
on.
220
GBSS13.0
Troubleshooting Guide
8 PS Counter Problems
No.
Item
Description
Remarks
Operation logs
For details
about how
to obtain
the
operation
logs, see
15
Appendix
: How to
Collect
Fault
Informati
on.
Faulty
signaling
For details
about how
to obtain
the faulty
signaling,
see 15
Appendix
: How to
Collect
Fault
Informati
on.
Troubleshooting Procedure
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 no, the following operations should be performed on all cells on the network.
2.
Issue 02 (2012-06-25)
221
GBSS13.0
Troubleshooting Guide
8 PS Counter Problems
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.
6.
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.
Troubleshooting Procedure
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.
2.
Check the frame error rates for Abis transmission in these cells. The frame error rates are
all lower than 1.
3.
4.
Issue 02 (2012-06-25)
222
GBSS13.0
Troubleshooting Guide
5.
Issue 02 (2012-06-25)
8 PS Counter Problems
Optimize the network. The Um interface quality becomes satisfactory and the
retransmission rate problem is resolved.
223
GBSS13.0
Troubleshooting Guide
9 PS Channel Faults
PS Channel Faults
Issue 02 (2012-06-25)
224
GBSS13.0
Troubleshooting Guide
9 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.
Issue 02 (2012-06-25)
225
GBSS13.0
Troubleshooting Guide
9 PS Channel Faults
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
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.
Issue 02 (2012-06-25)
226
GBSS13.0
Troubleshooting Guide
9 PS Channel Faults
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.
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
Background Information
The most common causes for PDCH faults due to channel inactivity are as follows:
l
PS cells have not been assigned to a digital signal processor (DSP) and therefore do not
work properly.
The number of activated channels on the DSP where the cells work has reached the upper
threshold.
The low voltage differential signal (LVDS) timeslots on the DSP where the cells work are
insufficient.
Issue 02 (2012-06-25)
227
GBSS13.0
Troubleshooting Guide
9 PS Channel Faults
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.
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.
Issue 02 (2012-06-25)
228
GBSS13.0
Troubleshooting Guide
9 PS Channel Faults
Figure 9-3 Procedure for locating PDCH faults due to channel inactivity
NOTE
Collect the fault location information by referring to Table 9-1 before contacting Huawei for technical
support.
Issue 02 (2012-06-25)
229
GBSS13.0
Troubleshooting Guide
9 PS Channel Faults
Table 9-1 Location information about PDCH faults due to channel inactivity
Issue 02 (2012-06-25)
No.
Item
Description
Symptom
Operations
before and after
the fault occurs
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.
Configuration
data script
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.
Remarks
230
GBSS13.0
Troubleshooting Guide
Issue 02 (2012-06-25)
9 PS Channel Faults
No.
Item
Description
Remarks
Original traffic
statistics
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.
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.
231
GBSS13.0
Troubleshooting Guide
Issue 02 (2012-06-25)
9 PS Channel Faults
No.
Item
Description
Remarks
Operation logs
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.
Faulty
signaling
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.
232
GBSS13.0
Troubleshooting Guide
9 PS Channel Faults
No.
Item
Description
Remarks
PS cell
distribution
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
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.
Troubleshooting Procedure
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.
Issue 02 (2012-06-25)
233
GBSS13.0
Troubleshooting Guide
9 PS Channel Faults
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.
5.
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.
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.
Troubleshooting Procedure
1.
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.
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.
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
Issue 02 (2012-06-25)
234
GBSS13.0
Troubleshooting Guide
9 PS Channel Faults
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
Background Information
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.
Issue 02 (2012-06-25)
235
GBSS13.0
Troubleshooting Guide
9 PS Channel Faults
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.
4.
If the BSC clock is not locked, run the MML command SET BTSCLKPARA to set
Clock Mode to BSCCLK(Trace BSC Clock).
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.
Issue 02 (2012-06-25)
236
GBSS13.0
Troubleshooting Guide
9 PS Channel Faults
Figure 9-7 Procedure for locating PDCH faults due to channel asynchronization
NOTE
Collect the fault location information by referring to Table 9-2 before contacting Huawei for technical
support.
Table 9-2 Location information about PDCH faults due to channel asynchronization
Issue 02 (2012-06-25)
No.
Item
Description
Symptom
Remarks
237
GBSS13.0
Troubleshooting Guide
Issue 02 (2012-06-25)
9 PS Channel Faults
No.
Item
Description
Operations
before and after
the fault occurs
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.
Configuration
data script
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.
Remarks
238
GBSS13.0
Troubleshooting Guide
Issue 02 (2012-06-25)
9 PS Channel Faults
No.
Item
Description
Remarks
Original traffic
statistics
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.
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.
239
GBSS13.0
Troubleshooting Guide
Issue 02 (2012-06-25)
9 PS Channel Faults
No.
Item
Description
Remarks
Operation logs
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.
Faulty
signaling
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.
240
GBSS13.0
Troubleshooting Guide
9 PS Channel Faults
No.
Item
Description
Remarks
PS cell
distribution
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
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.
Troubleshooting Procedure
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.
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.
4.
Issue 02 (2012-06-25)
241
GBSS13.0
Troubleshooting Guide
9 PS Channel Faults
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.
Troubleshooting Procedure
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.
Issue 02 (2012-06-25)
242
GBSS13.0
Troubleshooting Guide
10
Issue 02 (2012-06-25)
243
GBSS13.0
Troubleshooting Guide
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.
3.
Hardware faults
4.
Background Information
Figure 10-1 shows the mapping between symptoms and causes of cell PS service faults.
Issue 02 (2012-06-25)
244
GBSS13.0
Troubleshooting Guide
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.
Issue 02 (2012-06-25)
245
GBSS13.0
Troubleshooting Guide
NOTE
Collect the fault location information by referring to Table 10-1 before contacting Huawei for technical
support.
Issue 02 (2012-06-25)
No.
Item
Description
Symptom
Remarks
246
GBSS13.0
Troubleshooting Guide
Issue 02 (2012-06-25)
No.
Item
Description
Operations
before and
after the
fault occurs
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.
Configurati
on data
script
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.
Remarks
247
GBSS13.0
Troubleshooting Guide
Issue 02 (2012-06-25)
No.
Item
Description
Remarks
Operation
logs
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.
Historical
alarms
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.
248
GBSS13.0
Troubleshooting Guide
No.
Item
Description
Remarks
Common
debugging
logs
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.
Faulty
signaling
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.
MML
command
output
Issue 02 (2012-06-25)
249
GBSS13.0
Troubleshooting Guide
No.
Item
Description
Remarks
10
Original
traffic
statistics
For details
about how
to obtain
the 60minute
original
traffic
statistics
measured
within two
days
before and
after the
fault
occurs, see
15
Appendix
: How to
Collect
Fault
Informati
on.
Symptom
Cells fail to provide PS services and Cell Gb Administration State is Blocked in the output of
the MML command DSP PSCELL.
Background Information
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.
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.
Issue 02 (2012-06-25)
250
GBSS13.0
Troubleshooting Guide
Figure 10-3 Procedure for locating cell PS service faults due to Gb interface issues
Troubleshooting Procedure
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.
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.
Issue 02 (2012-06-25)
251
GBSS13.0
Troubleshooting Guide
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.
Troubleshooting Procedure
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.
Symptom
All or some of the cells under a BSC fail to provide PS services.
Background Information
In addition to the basic parameters for PS services, pay attention to the following configurations:
l
Location Procedure
Figure 10-4 shows the procedure for locating cell PS service faults due to incorrect data
configurations.
Issue 02 (2012-06-25)
252
GBSS13.0
Troubleshooting Guide
Figure 10-4 Procedure for locating cell PS service faults due to incorrect data configurations
Troubleshooting Procedure
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:
3.
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.
If the cell PS service faults persist, refer to 10.5 Troubleshooting Cell PS Service Faults
Due to Hardware Issues.
Typical Case
Symptom
Issue 02 (2012-06-25)
253
GBSS13.0
Troubleshooting Guide
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.
Symptom
Cells that fail to provide PS services are assigned to the same digital signal processor (DSP) and
board fault alarms are reported.
Background Information
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
DSP faults
Location Procedure
Figure 10-5 shows the procedure for locating cell PS service faults due to hardware issues.
Issue 02 (2012-06-25)
254
GBSS13.0
Troubleshooting Guide
Figure 10-5 Procedure for locating cell PS service faults due to hardware issues
Troubleshooting Procedure
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
Some cells fail to provide PS services at a site.
Cause Analysis
DSP 10 in slot 8 of subrack 0 is faulty.
Troubleshooting Procedure
Issue 02 (2012-06-25)
255
GBSS13.0
Troubleshooting Guide
1.
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.
Symptom
Some cells fail to provide PS services.
Background Information
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
connections inside the BSC.
Figure 10-6 Procedure for locating cell PS service faults due to incorrect cable connections
inside the BSC
Issue 02 (2012-06-25)
256
GBSS13.0
Troubleshooting Guide
Troubleshooting Procedure
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
Some cells fail to provide PS services at a site.
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.
Troubleshooting Procedure
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.
Issue 02 (2012-06-25)
257
GBSS13.0
Troubleshooting Guide
11 IP Transmission Faults
11
IP Transmission Faults
Issue 02 (2012-06-25)
258
GBSS13.0
Troubleshooting Guide
11 IP Transmission Faults
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
21346
21347
21351
When FE/GE transmission faults occur, the query result of the MML command DSP
ETHPORT shows that Link Availability Status is Unavailable.
Background Information
l
Recommended value 1
Issue 02 (2012-06-25)
ETHPORT SPEED
Duplex
FULL
259
GBSS13.0
Troubleshooting Guide
11 IP Transmission Faults
ETHPORT SPEED
Duplex
Recommended value 2
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
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
Issue 02 (2012-06-25)
260
GBSS13.0
Troubleshooting Guide
11 IP Transmission Faults
Issue 02 (2012-06-25)
261
GBSS13.0
Troubleshooting Guide
11 IP Transmission Faults
NOTE
Collect the fault location information by referring to Table 11-3 before contacting Huawei for technical
support.
Issue 02 (2012-06-25)
No.
Item
Description
Symptom
Operations
before and
after the
fault occurs
Remarks
262
GBSS13.0
Troubleshooting Guide
11 IP Transmission Faults
No.
Item
Description
Remarks
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.
FE/GE port
status
Historical
alarms
Ethernet
port
information
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.
Issue 02 (2012-06-25)
263
GBSS13.0
Troubleshooting Guide
11 IP Transmission Faults
No.
Item
Description
Remarks
Original
traffic
statistics
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.
BTS logs
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.
Troubleshooting Procedure
l
Issue 02 (2012-06-25)
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
Huawei Proprietary and Confidential
Copyright Huawei Technologies Co., Ltd.
264
GBSS13.0
Troubleshooting Guide
11 IP Transmission Faults
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.
l
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.
Issue 02 (2012-06-25)
265
GBSS13.0
Troubleshooting Guide
11 IP Transmission Faults
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
Troubleshooting Procedure
1.
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.
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
21581
Background Information
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.
Issue 02 (2012-06-25)
266
GBSS13.0
Troubleshooting Guide
11 IP Transmission Faults
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
Collect the fault location information by referring to Table 11-5 before contacting Huawei for technical
support.
Issue 02 (2012-06-25)
267
GBSS13.0
Troubleshooting Guide
11 IP Transmission Faults
Issue 02 (2012-06-25)
No.
Item
Description
Symptom
Operations
before and
after the
fault occurs
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.
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.
Remarks
268
GBSS13.0
Troubleshooting Guide
Issue 02 (2012-06-25)
11 IP Transmission Faults
No.
Item
Description
DSP ARP
command
output
Number of
packets sent
and received
on an
Ethernet
port
DSP IPRT
command
output
LST IPRT
command
output
TRC
IPADDR
command
output
PING IP
command
output
BTS logs
Remarks
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.
269
GBSS13.0
Troubleshooting Guide
11 IP Transmission Faults
No.
Item
Description
Remarks
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.
Troubleshooting Procedure
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.
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
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.
Typical Case
Symptom
Transmission links fail to be set up after the A over IP and signaling data configurations are
complete.
Cause Analysis
1.
Issue 02 (2012-06-25)
270
GBSS13.0
Troubleshooting Guide
2.
11 IP Transmission Faults
Troubleshooting Procedure
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.
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.
Table 11-6 Alarms related to PPP or MLPPP link faults
Alarm ID
Alarm Name
11342
21343
21344
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.
Background Information
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.
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.
Issue 02 (2012-06-25)
271
GBSS13.0
Troubleshooting Guide
11 IP Transmission Faults
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.
Figure 11-5 Procedure for locating PPP or MLPPP link faults
NOTE
Collect the fault location information by referring to Table 11-7 before contacting Huawei for technical
support.
Issue 02 (2012-06-25)
No.
Item
Description
Symptom
Remarks
272
GBSS13.0
Troubleshooting Guide
Issue 02 (2012-06-25)
11 IP Transmission Faults
No.
Item
Description
Operations
before and
after the
problem
occurs
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.
Historical
alarms
For details
about how
to obtain
the
historical
alarms,
see 15
Appendix
: How to
Collect
Fault
Informati
on.
PPP or
MLPPP link
status
Configurati
on data of
the PPP or
MLPPP link
Remarks
273
GBSS13.0
Troubleshooting Guide
11 IP Transmission Faults
No.
Item
Description
Remarks
Link
performance
monitoring
result
For details
about how
to obtain
the link
performan
ce
monitorin
g result,
see 15
Appendix
: How to
Collect
Fault
Informati
on.
Configurati
on data of
the PPP or
MLPPP link
on the
transmission
router
BTS logs
For details
about how
to obtain
BTS logs,
see 15
Appendix
: How to
Collect
Fault
Informati
on.
Troubleshooting Procedure
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
Issue 02 (2012-06-25)
Alarm ID
Alarm Name
4714
4716
274
GBSS13.0
Troubleshooting Guide
2.
11 IP Transmission Faults
Alarm ID
Alarm Name
20201
20202
20203
20204
20205
20206
20207
20208
20209
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
Issue 02 (2012-06-25)
275
GBSS13.0
Troubleshooting Guide
11 IP Transmission Faults
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.
Troubleshooting Procedure
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.
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
21512
When LAPD link faults occur, the query result of the MML command DSP LAPDLNK
shows that UsageStatus is set to Faulty or Congested.
Background Information
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
Issue 02 (2012-06-25)
276
GBSS13.0
Troubleshooting Guide
11 IP Transmission Faults
Figure 11-6 Procedure for locating the source of LAPD link or one-way disconnection
Issue 02 (2012-06-25)
277
GBSS13.0
Troubleshooting Guide
11 IP Transmission Faults
Figure 11-7 Procedure for locating the source of intermittent LAPD link disconnection or
congestion
NOTE
Collect the fault location information by referring to Table 11-10 before contacting Huawei for technical
support.
Issue 02 (2012-06-25)
No.
Item
Description
Symptom
Remarks
278
GBSS13.0
Troubleshooting Guide
Issue 02 (2012-06-25)
11 IP Transmission Faults
No.
Item
Description
Operations
before and
after the
fault occurs
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.
Historical
alarms
For details
about how
to obtain
the
historical
alarms,
see 15
Appendix
: How to
Collect
Fault
Informati
on.
E1/T1 or FE/
GE port
status
Configurati
on
information
about the
LAPD link
LAPD link
status
Remarks
279
GBSS13.0
Troubleshooting Guide
11 IP Transmission Faults
No.
Item
Description
Remarks
Faulty
signaling
For details
about how
to obtain
the faulty
signaling,
see 15
Appendix
: How to
Collect
Fault
Informati
on.
Issue 02 (2012-06-25)
Statistical
result of
interworkin
g packets
sent and
received
over the
LAPD link
10
Original
traffic
statistics
For details
about how
to obtain
the
original
traffic
statistics,
see 15
Appendix
: How to
Collect
Fault
Informati
on.
11
BTS logs
For details
about how
to obtain
BTS logs,
see 15
Appendix
: How to
Collect
Fault
Informati
on.
280
GBSS13.0
Troubleshooting Guide
11 IP Transmission Faults
Troubleshooting Procedure
l
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.
3.
4.
Run the MML command PING IP and use 64-byte, 500-byte, 1460-byte, and 1473byte 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.
Table 11-11 Requirements for the Abis over IP transmission QoS
Issue 02 (2012-06-25)
Counter
s for the
Abis
over IP
Transm
ission
QoS
One-Way Delay
(ms)
One-Way Jitter
(ms)
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%
281
GBSS13.0
Troubleshooting Guide
11 IP Transmission Faults
Counter
s for the
Abis
over IP
Transm
ission
QoS
One-Way Delay
(ms)
One-Way Jitter
(ms)
Scenari
o
Recom
mended
Value
Maxim
um
Value
Recom
mended
Value
Maxim
um
Value
Recom
mended
Value
Satellite
transmiss
ion
< 300 ms
< 350 ms
< 20 ms
< 40 ms
< 0.05%
Maxim
um
Value
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.
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
Issue 02 (2012-06-25)
282
GBSS13.0
Troubleshooting Guide
11 IP Transmission Faults
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
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.
l
If the fault persists, capture relevant packets and Contact Huawei Customer Service
Center.
2.
Run the MML command DSP LAPDLNK to check the LAPD link status.
a.
b.
c.
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.
Issue 02 (2012-06-25)
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.
Huawei Proprietary and Confidential
Copyright Huawei Technologies Co., Ltd.
283
GBSS13.0
Troubleshooting Guide
11 IP Transmission Faults
4.
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
Typical Case
Symptom
An RSL disconnects intermittently.
Cause Analysis
l
Troubleshooting Procedure
Issue 02 (2012-06-25)
284
GBSS13.0
Troubleshooting Guide
11 IP Transmission Faults
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.
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.
Symptom
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
21542
22915
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.
Background Information
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.
Issue 02 (2012-06-25)
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,
Huawei Proprietary and Confidential
Copyright Huawei Technologies Co., Ltd.
285
GBSS13.0
Troubleshooting Guide
11 IP Transmission Faults
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.
Location Procedure
l
Issue 02 (2012-06-25)
286
GBSS13.0
Troubleshooting Guide
11 IP Transmission Faults
Figure 11-9 Procedure for locating the source of SCTP link or one-way disconnection
Issue 02 (2012-06-25)
287
GBSS13.0
Troubleshooting Guide
11 IP Transmission Faults
Figure 11-10 Procedure for locating the source of unexpected SCTP link disconnection
NOTE
Collect the fault location information by referring to Table 11-13 before contacting Huawei for technical
support.
Issue 02 (2012-06-25)
No.
Item
Description
Symptom
Remarks
288
GBSS13.0
Troubleshooting Guide
Issue 02 (2012-06-25)
11 IP Transmission Faults
No.
Item
Description
Operations
before and
after the
fault occurs
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.
Historical
alarms
For details
about how
to obtain
the
historical
alarms,
see 15
Appendix
: How to
Collect
Fault
Informati
on.
Status of the
SCTP link
Statistics on
error
packets over
the port
Remarks
289
GBSS13.0
Troubleshooting Guide
Issue 02 (2012-06-25)
11 IP Transmission Faults
No.
Item
Description
PING IP
command
output
Faulty
signaling
For details
about how
to obtain
the faulty
signaling,
see 15
Appendix
: How to
Collect
Fault
Informati
on.
Original
traffic
statistics
For details
about how
to obtain
the
original
traffic
statistics,
see 15
Appendix
: How to
Collect
Fault
Informati
on.
10
Host
running logs
For details
about how
to obtain
the
original
traffic
statistics,
see 15
Appendix
: How to
Collect
Fault
Informati
on.
Remarks
290
GBSS13.0
Troubleshooting Guide
11 IP Transmission Faults
No.
Item
Description
Remarks
11
BTS logs
For details
about how
to obtain
BTS logs,
see 15
Appendix
: How to
Collect
Fault
Informati
on.
Troubleshooting Procedure
l
Issue 02 (2012-06-25)
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.
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
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
Huawei Proprietary and Confidential
Copyright Huawei Technologies Co., Ltd.
291
GBSS13.0
Troubleshooting Guide
11 IP Transmission Faults
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.
7.
l
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.
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.
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
Troubleshooting Procedure
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.
Issue 02 (2012-06-25)
292
GBSS13.0
Troubleshooting Guide
11 IP Transmission Faults
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
21582
21352
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.
Background Information
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
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.
Issue 02 (2012-06-25)
293
GBSS13.0
Troubleshooting Guide
11 IP Transmission Faults
NOTE
Collect the problem location information by referring to Table 11-15 before contacting Huawei for
technical support.
Issue 02 (2012-06-25)
No.
Item
Description
Symptom
Operations
before and
after the
problem
occurs
Remarks
294
GBSS13.0
Troubleshooting Guide
No.
Item
Description
Remarks
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.
Historical
alarms
For details
about how
to obtain
the
historical
alarms,
see 15
Appendix
: How to
Collect
Fault
Informati
on.
IP path
status
Routing
table on the
BSC
PING IP
command
output
Issue 02 (2012-06-25)
11 IP Transmission Faults
295
GBSS13.0
Troubleshooting Guide
Issue 02 (2012-06-25)
11 IP Transmission Faults
No.
Item
Description
Remarks
Link
performance
monitoring
result
For details
about how
to obtain
the link
performan
ce
monitorin
g result,
see 15
Appendix
: How to
Collect
Fault
Informati
on.
Original
traffic
statistics
For details
about how
to obtain
the
original
traffic
statistics,
see 15
Appendix
: How to
Collect
Fault
Informati
on.
10
Host
running logs
For details
about how
to obtain
the host
running
logs, see
15
Appendix
: How to
Collect
Fault
Informati
on.
296
GBSS13.0
Troubleshooting Guide
11 IP Transmission Faults
No.
Item
Description
Remarks
11
BTS logs
For details
about how
to obtain
BTS logs,
see 15
Appendix
: How to
Collect
Fault
Informati
on.
Troubleshooting Procedure
1.
2.
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
Issue 02 (2012-06-25)
297
GBSS13.0
Troubleshooting Guide
11 IP Transmission Faults
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.
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.
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
Troubleshooting Procedure
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.
Symptom
When a DHCP interaction failure occurs, the BTS software fails to be loaded for an excessive
long period of time
Background Information
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 followup procedures. Figure 11-12 shows a typical DHCP interaction procedure.
Issue 02 (2012-06-25)
298
GBSS13.0
Troubleshooting Guide
11 IP Transmission Faults
Location Procedure
Figure 11-13 shows the procedure for locating DHCP problems.
Figure 11-13 Procedure for locating DHCP problems
Issue 02 (2012-06-25)
299
GBSS13.0
Troubleshooting Guide
11 IP Transmission Faults
NOTE
Collect the problem location information by referring to Table 11-16 before contacting Huawei for
technical support.
Issue 02 (2012-06-25)
No.
Item
Description
Symptom
Operations
before and
after the
problem
occurs
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.
Historical
alarms
For details
about how
to obtain
the
historical
alarms,
see 15
Appendix
: How to
Collect
Fault
Informati
on.
Remarks
300
GBSS13.0
Troubleshooting Guide
11 IP Transmission Faults
No.
Item
Description
Remarks
E1/T1 or FE/
GE port
status
PPP/
MLPPP link
status
TRC
IPADDR
command
output
PING IP
command
output
BTS ESN
10
BTS logs
For details
about how
to obtain
BTS logs,
see 15
Appendix
: How to
Collect
Fault
Informati
on.
Troubleshooting Procedure
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
Issue 02 (2012-06-25)
Alarm ID
Alarm Name
4714
4716
20201
301
GBSS13.0
Troubleshooting Guide
2.
11 IP Transmission Faults
Alarm ID
Alarm Name
20202
20203
20204
20205
20206
20207
20208
20209
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
device has been commissioned successfully, the DHCP problem may lie in data
configurations.
Issue 02 (2012-06-25)
302
GBSS13.0
Troubleshooting Guide
11 IP Transmission Faults
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.
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
The BTS gateway may not be configured with the DHCP relay function.
Troubleshooting Procedure
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.
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
Issue 02 (2012-06-25)
303
GBSS13.0
Troubleshooting Guide
11 IP Transmission Faults
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.
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.
Background Information
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.
Issue 02 (2012-06-25)
304
GBSS13.0
Troubleshooting Guide
11 IP Transmission Faults
NOTE
Collect the failure location information by referring to Table 11-18 before contacting Huawei for technical
support.
Issue 02 (2012-06-25)
No.
Item
Description
Symptom
Operations
before and
after the
failure
occurs
Remarks
305
GBSS13.0
Troubleshooting Guide
11 IP Transmission Faults
No.
Item
Description
Remarks
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.
Historical
alarms
For details
about how
to obtain
the
historical
alarms,
see 15
Appendix
: How to
Collect
Fault
Informati
on.
PING IP
command
output
TMU
hardware
type of the
BTS
Troubleshooting Procedure
1.
Issue 02 (2012-06-25)
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.
306
GBSS13.0
Troubleshooting Guide
11 IP Transmission Faults
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.
4.
Typical Case
Symptom
The IP PM function on the Abis interface fails to be activated.
Cause Analysis
l
Troubleshooting Procedure
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.
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.
Issue 02 (2012-06-25)
307
GBSS13.0
Troubleshooting Guide
11 IP Transmission Faults
Alarm Name
26262
26263
Background Information
l
Location Procedure
l
Issue 02 (2012-06-25)
308
GBSS13.0
Troubleshooting Guide
11 IP Transmission Faults
Issue 02 (2012-06-25)
309
GBSS13.0
Troubleshooting Guide
11 IP Transmission Faults
NOTE
Collect the fault location information by referring to Table 11-20 before contacting Huawei for technical
support.
Issue 02 (2012-06-25)
No.
Item
Description
Symptom
Operations
before and
after the
fault occurs
Remarks
310
GBSS13.0
Troubleshooting Guide
Issue 02 (2012-06-25)
11 IP Transmission Faults
No.
Item
Description
Remarks
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.
Historical
alarms
For details
about how
to obtain
the
historical
alarms,
see 15
Appendix
: How to
Collect
Fault
Informati
on.
Configurati
on data
script
For details
about how
to obtain
the
configurat
ion data
script, see
15
Appendix
: How to
Collect
Fault
Informati
on.
PING IP
command
output
311
GBSS13.0
Troubleshooting Guide
11 IP Transmission Faults
No.
Item
Description
Status of the
clock link
Remarks
Troubleshooting Procedure
l
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.
Issue 02 (2012-06-25)
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.
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.
Huawei Proprietary and Confidential
Copyright Huawei Technologies Co., Ltd.
312
GBSS13.0
Troubleshooting Guide
11 IP Transmission Faults
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.
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.
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
Issue 02 (2012-06-25)
313
GBSS13.0
Troubleshooting Guide
11 IP Transmission Faults
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
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.
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.
7.
l
Issue 02 (2012-06-25)
314
GBSS13.0
Troubleshooting Guide
11 IP Transmission Faults
2.
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.
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.
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
Troubleshooting Procedure
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.
Issue 02 (2012-06-25)
315
GBSS13.0
Troubleshooting Guide
12 Interference Problems
12
Interference Problems
Issue 02 (2012-06-25)
316
GBSS13.0
Troubleshooting Guide
12 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.
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 nonlinear 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.
Both originated- and terminated-calls fail to be set up. A call easily drops after the prompt
tone starts.
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.
The values of ZTR104C:Call Drop Rate on SDCCH and ZTR304:Call Drop Rate on TCH
per cell(including Handover) are large.
Issue 02 (2012-06-25)
317
GBSS13.0
Troubleshooting Guide
12 Interference Problems
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.
There are a large number of calls with high receive level and low receive quality.
External interference
Background Information
The maintenance functions related to interference are as follows:
l
Issue 02 (2012-06-25)
318
GBSS13.0
Troubleshooting Guide
12 Interference Problems
NOTE
Collect the problem location information by referring to Table 12-1 before contacting Huawei for technical
support.
Issue 02 (2012-06-25)
No.
Item
Description
Symptom
Remarks
319
GBSS13.0
Troubleshooting Guide
Issue 02 (2012-06-25)
12 Interference Problems
No.
Item
Description
Operations
before and
after the
problem
occurs
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.
Result of an
online
passive
intermodula
tion
interference
test
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.
Remarks
320
GBSS13.0
Troubleshooting Guide
12 Interference Problems
No.
Item
Description
Remarks
Online
frequency
spectrum
scanning
result
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.
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.
Background Information
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.
Issue 02 (2012-06-25)
321
GBSS13.0
Troubleshooting Guide
12 Interference Problems
Troubleshooting Procedure
1.
2.
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.
Troubleshooting Procedure
Issue 02 (2012-06-25)
322
GBSS13.0
Troubleshooting Guide
12 Interference Problems
1.
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 nonBCCH 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.
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 offpeak 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.
Background Information
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.
Issue 02 (2012-06-25)
323
GBSS13.0
Troubleshooting Guide
12 Interference Problems
Based on the trigonometric sum-to-product formulas, the intermodulation results of the nonlinear 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.
The feeder that connects the antenna connectors to the half-wave dipole is corroded.
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.
Issue 02 (2012-06-25)
324
GBSS13.0
Troubleshooting Guide
12 Interference Problems
Issue 02 (2012-06-25)
325
GBSS13.0
Troubleshooting Guide
12 Interference Problems
Troubleshooting Procedure
1.
2.
3.
4.
5.
6.
7.
8.
9.
326
GBSS13.0
Troubleshooting Guide
12 Interference Problems
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.
l If no, go to Step 13.
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.
12. Check whether the intermodulation interference is eliminated.
l If yes, no further action is required.
l If no, go to Step 13.
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.
14. Check whether the intermodulation interference is eliminated.
l If yes, no further action is required.
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.
Troubleshooting Procedure
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
Issue 02 (2012-06-25)
327
GBSS13.0
Troubleshooting Guide
12 Interference Problems
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.
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
Issue 02 (2012-06-25)
328
GBSS13.0
Troubleshooting Guide
12 Interference Problems
Background Information
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.
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
l
Issue 02 (2012-06-25)
Install filters.
Huawei Proprietary and Confidential
Copyright Huawei Technologies Co., Ltd.
329
GBSS13.0
Troubleshooting Guide
12 Interference Problems
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
Perform frequency scan by referring to 3.3.3 Scanning Frequency Spectrum Online and check
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
Troubleshooting Procedure
1.
2.
3.
Issue 02 (2012-06-25)
330
GBSS13.0
Troubleshooting Guide
12 Interference Problems
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.
Troubleshooting Procedure
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.
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.
Background Information
l
Issue 02 (2012-06-25)
331
GBSS13.0
Troubleshooting Guide
12 Interference Problems
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, cochannel interference is generated.
Repeaters are generally the main cause of external interference, especially in metropolitan
areas.
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
Perform frequency scan by referring to 3.3.3 Scanning Frequency Spectrum Online and check
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
Issue 02 (2012-06-25)
332
GBSS13.0
Troubleshooting Guide
12 Interference Problems
Troubleshooting Procedure
1.
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.
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.
Troubleshooting Procedure
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 adjacentchannel 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
Issue 02 (2012-06-25)
333
GBSS13.0
Troubleshooting Guide
12 Interference Problems
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.
Issue 02 (2012-06-25)
334
GBSS13.0
Troubleshooting Guide
13
Issue 02 (2012-06-25)
335
GBSS13.0
Troubleshooting Guide
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.
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.
Hardware faults
Issue 02 (2012-06-25)
336
GBSS13.0
Troubleshooting Guide
Figure 13-1 Procedure for locating faults on main and diversity RX channels
NOTE
Collect the fault location information by referring to Table 13-1 before contacting Huawei for technical
support.
Issue 02 (2012-06-25)
No.
Item
Description
Symptom
Operations
before and
after the fault
occurs
Remarks
337
GBSS13.0
Troubleshooting Guide
No.
Item
Description
Remarks
Faulty NE
version
Configuratio
n data script
BTS logs
Original
traffic
statistics
Historical
alarms
Symptom
Alarms such as ALM-4176 Main receive channel alarm and ALM-4178 Diversity receive
channel alarm are reported.
Issue 02 (2012-06-25)
338
GBSS13.0
Troubleshooting Guide
Background Information
l
Single path: One board uses only one path to connect to the antenna.
Double paths: One board uses two paths to connect to the antenna.
1TX or 2TX: One or two paths are used for transmitting signals.
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.
Transmit diversity: One baseband signal is divided into two signals to produce a multipath
effect, increasing the downlink RX signal level of an MS.
Location Procedure
Figure 13-2 shows the procedure for locating faults on main and diversity RX channels due to
incorrect data configurations.
Figure 13-2 Procedure for locating faults on main and diversity RX channels due to incorrect
data configurations
Troubleshooting Procedure
1.
Issue 02 (2012-06-25)
On the LMT, run the MML command LST GTRXDEV to check whether Receive
Mode and Send Mode match the physical connections.
Huawei Proprietary and Confidential
Copyright Huawei Technologies Co., Ltd.
339
GBSS13.0
Troubleshooting Guide
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.
l If yes, go to Step 3.
2.
Check whether the alarms related to the main and diversity RX channels are cleared.
l If yes, no further action is required.
l If no, go to Step 3.
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.
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.
Troubleshooting Procedure
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).
Issue 02 (2012-06-25)
340
GBSS13.0
Troubleshooting Guide
Symptom
Alarms such as ALM-4176 Main receive channel alarm and ALM-4178 Diversity receive
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.
Background Information
The following are the performance counters related to main and diversity RX channels:
l
The following are the formulas for calculating the main and diversity RX signal levels:
l
Location Procedure
Figure 13-3 shows the procedure for locating faults on main and diversity RX channels due to
incorrect antenna connections.
Issue 02 (2012-06-25)
341
GBSS13.0
Troubleshooting Guide
Figure 13-3 Procedure for locating faults on main and diversity RX channels due to incorrect
antenna connections
Troubleshooting Procedure
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.
l If no, go to Step 3.
2.
Check whether the alarms related to the main and diversity RX channels are cleared.
l If yes, no further action is required.
l If no, go to Step 3.
3.
Check whether a jumper or feeder connected to an antenna connector for the RF module
is faulty.
Calculate the main and diversity RX signal levels according to the preceding formulas
mentioned in background information. For the carriers of all the TRXs connecting to the
Issue 02 (2012-06-25)
342
GBSS13.0
Troubleshooting Guide
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.
l If no, go to Step 5.
4.
5.
Check whether the antenna connections between two cells are crossed.
Calculate the main and diversity RX signal levels according to the preceding formulas
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.
l If no, return to Procedure for locating main and diversity receive channel faults.
6.
Issue 02 (2012-06-25)
BTS Type
Fault Type
Symptom
BTS3012
Faults in
cables
between the
TRXs and the
DFCU or
DDPU
Faults in the
feeder or
jumper
connected to
an antenna
connector for
the DFCU or
DDPU
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.
343
GBSS13.0
Troubleshooting Guide
BTS Type
Fault Type
Symptom
BTS3900
Incorrect
configuration
of the TRX
send and
receive
modes
Faults in
antennas
connected to
TRXs
Crossed pairs
between the
main and
diversity RX
channels of
two cells
BTS3900/
BTS3012
Issue 02 (2012-06-25)
344
GBSS13.0
Troubleshooting Guide
BTS Type
Fault Type
Symptom
Low RX
signal level of
main and
diversity RX
channels
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.
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.
Symptom
Alarms such as ALM-4176 Main receive channel alarm and ALM-4178 Diversity receive
channel alarm are reported.
Location Procedure
Figure 13-4 shows the procedure for locating faults on main and diversity RX channels due to
hardware faults.
Issue 02 (2012-06-25)
345
GBSS13.0
Troubleshooting Guide
Figure 13-4 Procedure for locating faults on main and diversity RX channels due to hardware
faults
Troubleshooting Procedure
1.
2.
Check whether the alarms such as ALM-4176 Main receive channel alarm and ALM-4178
Diversity receive channel alarm are cleared.
l If yes, no further action is required.
l If no, Contact Huawei Customer Service Center.
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 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.
Issue 02 (2012-06-25)
346
GBSS13.0
Troubleshooting Guide
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.
Issue 02 (2012-06-25)
347
GBSS13.0
Troubleshooting Guide
14 No Traffic
14
No Traffic
Issue 02 (2012-06-25)
348
GBSS13.0
Troubleshooting Guide
14 No Traffic
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
The ALM-28008 Radio Link Failure alarm with Specific Problem of No Traffic on TRX is
associated with no traffic. This alarm is reported when a TRX does not detect any traffic (no
calls can be set up in a cell) during a consecutive period of time. The alarm is cleared when a
call accesses the network successfully.
Run the SET GTRXRLALM command on the LMT to set Begin Time of WLA Detection,
End Time of WLA Detection, and Statistical Period of No-traffic based on the actual traffic
distribution.
Symptom
Check whether there is no traffic by using the following methods:
l
Obtain the traffic statistics measured for a BTS or cell, including cell KPIs, Immediate
Assignment Measurement per Cell(CALL.ImmAss.CELL), and Channel Seizure
Measurement per TRX(CALL.ChanOccupy.TRX), and analyze the time when no traffic
occurs, random access in cells, TCH assignment, and TCH handover. Based on the
preceding analysis, check whether no traffic occurs in a cell, on the BCCH, or on other
channels.
Monitoring 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 network.
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.
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
problems, interference, poor Um interface quality, or software problems. You can locate and
troubleshoot the problems based on the live network conditions.
Issue 02 (2012-06-25)
349
GBSS13.0
Troubleshooting Guide
14 No Traffic
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
Locating interference
Resetting the faulty board to check whether the board software is faulty
Location Procedure
Figure 14-1 shows the procedure for locating no traffic.
Issue 02 (2012-06-25)
350
GBSS13.0
Troubleshooting Guide
14 No Traffic
Issue 02 (2012-06-25)
351
GBSS13.0
Troubleshooting Guide
14 No Traffic
Issue 02 (2012-06-25)
No.
Item
Description
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).
Operation
s before
and after
the fault
occurs
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.
Configura
tion data
script
For details
about how to
obtain the
configuration
data script, see
15 Appendix:
How to
Collect Fault
Information.
Historical
alarms
For details
about how to
obtain the
historical
alarms, see 15
Appendix:
How to
Collect Fault
Information.
Remarks
352
GBSS13.0
Troubleshooting Guide
Issue 02 (2012-06-25)
14 No Traffic
No.
Item
Description
Remarks
Original
traffic
statistics
For details
about how to
obtain the
original traffic
statistics, see
15 Appendix:
How to
Collect Fault
Information.
Operation
logs
For details
about how to
obtain the
operation
logs, see 15
Appendix:
How to
Collect Fault
Information.
Faulty
signaling
For details
about how to
obtain the
faulty
signaling, see
15 Appendix:
How to
Collect Fault
Information.
BTS logs
For details
about how to
obtain BTS
logs, see 15
Appendix:
How to
Collect Fault
Information.
10
Channel
status
For details
about how to
obtain the
channel
status, see 15
Appendix:
How to
Collect Fault
Information.
353
GBSS13.0
Troubleshooting Guide
14 No Traffic
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.
Background Information
The parameters associated with this alarm are Wireless Link Alarm Flag, Statistical Period
of No-traffic, Begin Time of WLA Detection, and End Time of WLA Detection. 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
Troubleshooting Procedure
1.
Check whether the settings of the correlated alarm parameters are correct.
Begin Time of WLA Detection, End Time of WLA Detection, and Statistical Period of
No-traffic must be set according to the traffic distribution.
Issue 02 (2012-06-25)
354
GBSS13.0
Troubleshooting Guide
14 No Traffic
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.
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.
Troubleshooting Procedure
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.
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.
Background Information
Transmission or equipment faults include:
l
355
GBSS13.0
Troubleshooting Guide
14 No Traffic
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
Troubleshooting Procedure
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.
2.
Issue 02 (2012-06-25)
356
GBSS13.0
Troubleshooting Guide
14 No Traffic
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.
Troubleshooting Procedure
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.
Symptom
The alarm system reports the ALM-28008 Radio Link Failure alarm with Specific Problem of
No Traffic on TRX.
Background Information
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.
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.
Issue 02 (2012-06-25)
357
GBSS13.0
Troubleshooting Guide
14 No Traffic
Figure 14-4 Procedure for locating no traffic due to incorrect data configuration
Troubleshooting Procedure
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.
2.
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.
Troubleshooting Procedure
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
Issue 02 (2012-06-25)
358
GBSS13.0
Troubleshooting Guide
14 No Traffic
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.
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.
Background Information
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.
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.
Issue 02 (2012-06-25)
359
GBSS13.0
Troubleshooting Guide
14 No Traffic
Figure 14-5 Procedure for locating no traffic due to poor Um interface quality
Troubleshooting Procedure
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.
l If no, go to Step 3.
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.
Issue 02 (2012-06-25)
360
GBSS13.0
Troubleshooting Guide
14 No Traffic
l If no, go to Step 5.
4.
5.
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.
Troubleshooting Procedure
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 nonfrequency 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.
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.
Issue 02 (2012-06-25)
361
GBSS13.0
Troubleshooting Guide
14 No Traffic
Background Information
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.
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.
Issue 02 (2012-06-25)
362
GBSS13.0
Troubleshooting Guide
14 No Traffic
Figure 14-6 Procedure for locating no traffic due to antenna system faults
Troubleshooting Procedure
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.
Issue 02 (2012-06-25)
363
GBSS13.0
Troubleshooting Guide
14 No Traffic
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.
2.
3.
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.
l If yes, go to Step 7.
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.
l If no, go to Step 9.
8.
9.
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.
Issue 02 (2012-06-25)
364
GBSS13.0
Troubleshooting Guide
14 No Traffic
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.
Troubleshooting Procedure
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.
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 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.
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 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.
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.
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.
Issue 02 (2012-06-25)
365
GBSS13.0
Troubleshooting Guide
15
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.
Data
configurat
ion script
1. Run the MML command EXP CFGMML to export the BSC data
configuration script.
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.
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\.
Issue 02 (2012-06-25)
366
GBSS13.0
Troubleshooting Guide
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.
2. Run the MML command LST LOGRSTINFO to query the path in which
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
1. Run the MML command COL LOG with Log File Type set to
DEBUG_LOG(The Common Debug Log) to collect common debugging
logs.
2. Run the MML command LST LOGRSTINFO to query the path in which
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
1. Run the MML command COL LOG with Log File Type set to
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\.
Issue 02 (2012-06-25)
367
GBSS13.0
Troubleshooting Guide
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.
2. Run the MML command LST LOGRSTINFO to query the path in which
the host running log file is saved.
The format of the file name is BSC0000_XXLog Start time_End
time.log.zip, where XX indicates the subrack number. For example,
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.
2. Run the MML command LST LOGRSTINFO to query the path in which
the GPSR log file is saved.
The format of the file name is BSC0000_[GPSR]XXLog Start time_End
time.log.zip, where XX indicates the subrack number. For example,
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
1. Run the MML command COL LOG with Log File Type set to
DSP_DEBUG_LOG(The Debug Log of DSP) to collect DSP debugging
logs.
2. Run the MML command LST LOGRSTINFO to query the path in which
the DSP debugging log file is saved.
The format of the file name is BSC0000_[MDSP]XXLog Start time_End
time.log.zip, where XX indicates the subrack number. For example,
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\.
Issue 02 (2012-06-25)
368
GBSS13.0
Troubleshooting Guide
Collectio
n Item
Collection Method
One-way
audio or
crosstalk
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 one-way audio and crosstalk logs.
NOTE
Information about crosstalk and one-way audio is logged together.
2. Run the MML command LST LOGRSTINFO to query the path in which
the one-way audio and crosstalk log file is saved.
The format of the file name is BSC0000_[CDIG]XXLog Start time_End
time.log.zip, where XX indicates the subrack number. For example,
BSC0000_[CDIG]00Log20101203102457_20101203113504.log.zip
indicates that one-way audio and crosstalk logs were recorded for subrack 0
between 10:24:57 and 11:35:04 on December 3, 2010.
3. Obtain the one-way audio and crosstalk 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.
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
1. Run the MML command COL LOG with Log File Type set to
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.
2. Run the MML command LST LOGRSTINFO to query the path in which
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
Issue 02 (2012-06-25)
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.
369
GBSS13.0
Troubleshooting Guide
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.
Issue 02 (2012-06-25)
370