UMTS Troubleshooting PS Problems 201111

HUAWEI TECHNOLOGIES CO., LTD.
www.huawei.com
Huawei Confidential
Security Level: internal
:40-47pt
:26-30pt
:
:
FrutigerNext LT Medium
: Arial

:35-47pt
:
:24-28pt
:
:

2014/9/7
z00053452
c00105727
2011-8-24
GSM Skill Promotion
Troubleshooting PS Problems
Background
For a long time, the troubleshooting for PS problems is not as well-developed as that for CS
and voice problems. Many maintenance personnel do not have an in-depth understanding of PS
and know very limited troubleshooting means. With the increase of PS services, PS problems
become increasingly serious. Based on the maintenance personnel's experience in handling PS
problems, this document summarizes troubleshooting guidelines and typical cases and aims to
provide guidance for PS troubleshooting.
The document is revised according to the advice of trainees in the first training course.
PS problems are grouped into the following categories by symptom:
Rate-related problems: low CQT/DT download rate, slow Web browsing, ping timeout
Counter-related problems: low TBF establishment success rate, high call drop rate, high
congestion rate, high RLC retransmission rate, low throughput
Resource-related problems: PDCH and Gb interface resource-related problems
This document describes how to troubleshoot these problems.

Page 3
Rate-Related Problems
Symptom

During a CQT/DT, the FTP download rate is low or interruptions occur in FTP
download.
Web browsing is slow or failures occur.
It takes a long time to ping through the peer end.
Failures occur in certain services, such as withdraws from an ATM.
Page 4
Page 5
Background Information
Because GPRS is based on wireless transmission, it has lower bandwidth and longer delay than wired transmission. Moreover, the
delay and bandwidth of GPRS may change suddenly. Therefore, large packets need to be segmented into small ones for transmission.
According to TCP/IP, the traffic of the FTP service as a user process is broken down into RLC/MAC data blocks on the wireless
interface for transmission (therefore, the RLC/MAC throughput is usually higher than FTP throughput). Then the data is transmitted to
the peer end by burst. The following figure shows the data splitting and encapsulation.

The figure above shows the function of the PCU in IP data download. Rate-related signaling is also analyzed layer by layer
according to the process in the figure.
Whether the IP data is consecutive and correct > Whether the LLC-PDU is consecutive and correct > Whether the RLC/MAC is
consecutive and correct
Because most rate-related problems on the live network are low-rate IP transmission, it is recommended that the readers of this
document have a common knowledge about TCP/IP.
Page 6
Factors affecting rate
Terminal: capability for packet assembly and disassembly, multislot capability,
support for EGPRS, correctness of account opening information, and correctness of
SIM card registration information.
Resource: PDTCH resource (number of supported PDTCHs based on the multislot
capability of the MS), Abis timeslot resource (TDM transmission adopted),
bandwidth resource of the GB interface (TDM transmission adopted), and support
for high-rate coding scheme adjustment.
Environment: quality of the Um interface, transmission quality of the Abis and Gb
interfaces, and number of MSs multiplexed on a channel.
Parameter configuration: threshold of channel multiplexing, channel type, BEP
adjustment period, and EDGE downlink and GPRS uplink multiplexing.
Upstream NEs of the Gb interface: FTP server failure and congestion on the SGSN.
Page 7
Troubleshooting guidelines
For rate-related problems, first know the test type.
For a DT, you are advised to perform a CQT in the
cell involved in the DT. If the result of the CQT is
normal, the device is running properly. In this case,
the poor rate of the DT may be caused by network
optimization factors, such as cell reselection,
network coverage, and interference. Based on the
affecting factors in CQT, follow the troubleshooting
guidelines on the right to solve rate-related
problems.
Low PS rate
End
Terminal factors?
Perform troubleshooting
operations for terminal-
related faults
Resource factors?
Upstream NEs
of the Gb interface?
Environmental factors?
Parameter settings?
operations for resource-
related faults
operations for environment-
related faults
operations for parameter-
related faults
operations for upstream NE-
related faults
Contact Huawei support
engineer
NO
YES
NO
NO
NO
NO
YES
YES
YES
YES
Page 8
Terminal factors
Terminal factors include the multislot capability of an MS, SIM card registration information, and settings on the test PC. To
determine the factor causing the low download rate, you can replace the MS, or test the SIM card or the portable device.
1. Select an appropriate terminal.
The multislot capability of a terminal determines the channel resources supported by the terminal. For details, see the following
table.

You can view the multislot capability of an MS in the PACKET RES REQUEST, ATTACH REQUEST, or downlink
data blocks.
Page 9
In a PACKET RES REQUEST message, the fields in red boxes indicate the multislot capability.
As shown in the following example, the multislot capabilities of both GPRS and EGPRS are 10.

In an ATTACH REQUEST message, the fields in red boxes indicate the multislot capability. As
shown in the following example, the multislot capability of GPRS is 12 and that of EGPRS is 12.

Page 10
In a downlink data block, the fields in red boxes indicate the multislot capability. As shown in the
following example, the multislot capabilities of both GPRS and EGPRS are 8.

Page 11
Terminal factors
2. Make sure that the SIM card registration information is
correct.
When an MS is used to access the Internet, it first
performs PDP activation. During the activation, the MS
and the GGSN negotiate the QoS, which includes the
levels of reliability, delay, peak throughput, and average
throughput.
The peak throughput defines the maximum transmission
rate of all PDP context messages. The average
throughput indicates the average transmission rate of
data on the GPRS network before the PDP context is
successfully activated. You can obtain the SIM card
registration information of an MS by running the MML
command LST GPRS in the HLR.
The configurations on the right are recommended for
MSs.

Page 12
Terminal factors
2. Make sure that the account opening information is correct.
You can also obtain the account opening information of an MS from the ACTIVE PDP
CONTEXT ACCEPT message, as shown in the following figure.

For the description of related fields, refer to 3GPP protocol 24008.
Page 13
Terminal factors
3. Test the settings of a portable device.
Disconnect all the other network connections of the portable device.
When an EDGE MS dials up successfully, the core network assigns a dynamic IP address to the dialing terminal and adds the
default route 0.0.0.0. Certain software on the portable device may send data packets to the network through this route and
occupy the uplink bandwidth. Therefore, make sure that all the other network connections of the portable device are
disconnected before dialing up.
End the tasks that may lead to network access.
When an EDGE MS dials up successfully, all network access tasks inside the laptop, the peer end of the core network, send
data packets to the external network, occupying the limited bandwidth and posing adverse impact on device performance.
Therefore, it is recommended to end all network access tasks (including various automatic update programs and antivirus
programs) before performance tests. In this way, you can ensure that the FTP service occupies the network bandwidth
exclusively and the test result reflects the transmission performance.
Modify the registry in the OS of the portable device and optimize the following settings at the TCP layer.
a) Under [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters], create DWORD field
TcpWindowSize and set the value to dword:0000ffff; create DWORD field SackOpts and set the value to
dword:00000001.
b) Change the MTU at the TCP layer to 1500.
Under [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NdisWan\Protocols\0], create DWORD field
ProtocolType, and set the value to dword:00000800; create DWORD field PPPProtocolType, and set the value to
dword:00000021; create DWORD field ProtocolMTU, and set the value to dword:000005DC.

Page 14
Resource factors
Resource factors include PDCH resource, Abis idle timeslot (TDM networking), and Gb interface resource.
The PDCH bears the control signaling of the RLC layer and RLC data. The transmission rate of a single PDCH is limited.
The download of an MS usually occupies four downlink PDTCHs. If the available PDTCHs are insufficient, the bandwidth is
affected and the download rate becomes lower. The following factors may affect the number of available PDCHs.
Heavy CS traffic results in handover failures in dynamic channels. It is recommended to add static PDCH or expand the
capacity.
Certain PDCHs are faulty or synchronization failures occur. For troubleshooting steps, see the troubleshooting for channel
failures in "Resource-related Problems"
The maximum ratio threshold of PDCHs in a cell is improperly set.
The number of activated PDCHs on the DSP reaches the upper limit. Run the MML command SET PSCELLTODSP to
transfer excess cells to an idle DSP.
Coding scheme with MCS7/MCS8/MCS9 requires channels to be bound to more idle timeslots. If idle timeslots are
insufficient, coding rate may fail to be optimized, resulting in lower download rate. The following table lists the mapping
between coding schemes and 16 kbit/s timeslots of each channel.

Page 15
Resource factors
If the Gb interface resources are insufficient, stop-flow (certain data is discarded on the Gb interface, resulting in
flow interruption) may occur on the Gb interface at traffic peaks during busy hours. Therefore, the transmission
resource usage of the Gb interface must be no more than 80%.
In GBFR networking, you can check the usage of Gb transmission resources by the following traffic
measurement:
Measurement of BC Performance > BC Measurement
Number of Times that the Uplink of the BC Is Overloaded (1279369427)
Number of Times that the Downlink of the BC Is Overloaded BC (1279369428)
In GB IP networking, you can check the usage of Gb transmission resources by the following traffic
measurement:
Calculate the NSVL sending bandwidth usage based on the following formula:
[L9804]*{8}/(Traffic measurement period x 64 kbit/s x Number of license timeslots x 1024)
Calculate the NSVL receiving bandwidth usage based on the following formula:
[L9805]*{8}/(Traffic measurement period x 64 kbit/s x Number of license timeslots x 1024)
L9804: Total Number of bytes of transmitted NS PDUs on NSVL
L9805: Total Number of bytes of received NS PDUs on NSVL
Measurement unit: Measurement of NSVL Performance > NSVL Capability Measurement

Page 16
Environmental factors
Environmental factors include the quality of the Um interface, the transmission quality of the Abis interface and Gb interface, and
multiplexing of MSs.
The quality of the Um interface covers the receive level, C/I, uplink/downlink balance, and interference distribution. The quality
of the Um interface affects the rate in the following aspects:
Different coding schemes require varied quality of the Um interface. A higher coding rate requires better quality of the Um
interface. Therefore, when the quality of the Um interface is poor, data can only be transmitted with coding scheme with
MCS1/MCS2/MCS3/MCS4. The following table lists the mapping between coding schemes and quality of the Um interface.

Poor quality of the Um interface results in higher retransmission rate of RLC/MAC data blocks. In this way, even if MCS9 is
adopted for transmission, the overall download rate is lower due to the retransmission of a large amount of data.
Therefore, to ensure the required download rate, make sure that the Um interface is qualified.

Page 17
The stability of the G-Abis interface mainly affects the status of PDCH primary and secondary links. If the transmission of
the G-Abis interface is unstable, the available PDCH resources may be insufficient and the transmission of RLC/MAC data
blocks may be incorrect, reducing the download rate.
Common causes for synchronization failures are as follows:
Clocks are not locked, including the BTS and GGCU clocks.
Transmission introduces severe clock drifts.
High BER causes intermittent channel interruptions.
Other causes for synchronization failures include:
The PDCH cannot receive uplink data because of incorrect connections of internal BSC links.
The timeslot netlist of the BSC is inconsistent with that of the BTS.

For cells with high G-Abis FER, you can use the signaling analyzer or loopback to test the transmission.

Page 18
Transmission quality of the Gb interface
The Gb interface, between the BSS and the SGSN, transmits data at multiple upper protocol layers. If upper-layer data is not
encrypted, you can locate NU out-of-sequence, and TCP/IP packet loss and out-of-sequence of LLC data packets by analyzing
the signaling on the Gb interface.
In Gb over Fr networking, devices are connected using E1 cables, and usually no switching devices are deployed. Therefore,
you need to ensure only correct cable connection, data configuration, and stable transmission.
Gb Over IP networking is more flexible and may involve multiple routers or switches. Therefore, Gb Over IP networks probably
experience IP packet loss, out-of-sequence, and data distribution delay. On such networks, it is easy to capture packets on all
transmission nodes. By comparing captured packets, you can rapidly locate the NEs where packet out-of sequence and loss
occur.
MTUs can be configured on the switching and forwarding devices throughout Gb Over IP networks. If an IP packet is larger
than the MTU, the packet is first fragmented for transmission and then reassembled at the receiving end. Currently, if the
SGSN fragments an IP packets into three or more LLC packets, the BSC cannot reassemble the fragments into one IP packet.
Therefore, the size of the original IP packet or the MTU needs to be configured properly. In common cases, the MTU is
changed (to 1400 usually) on the SGSN, ensuring correct assembly by the BSC and transmission efficiency of the Gb interface.
The transmission quality of the Gb interface can be checked by the ping command on the BSC. In common cases, it takes
dozens of milliseconds to ping through the peer end. If it takes longer, the packet transmission performance is adversely
affected.

Page 19
Environmental factors include the quality of the Um interface, the transmission quality of the Abis
interface and Gb interface, and multiplexing of MSs.
Multiplexing of MSs
A single PDCH provides fixed bandwidth. The lower the PDCH multiplexing threshold, MSs
obtain more sufficient resources, and the download rate is higher.
MML commands: SET GCELLPSCHM: IDTYPE=BYID, CELLID=xx, DWNDYNCHNTRANLEV=xx;
If an EDGE MS and a GPRS MS multiplex the same PDCH, the EDGE MS needs to use the
same modulation mode (GMSK) as the GPRS MS to schedule the uplink data blocks of the
GPRS MS. Therefore, the downlink coding scheme of the EDGE MS must be MCS1-MCS4,
resulting in lower download rate. To increase the download rate, you need run the MML
command: SET BSCPSSOFTPARA: FORBIDEDGU=OPEN/CLOSE to disable the E-down and
G-up switch.

Page 20
Parameter setting
Parameter setting is to increase the download rate at the cost of certain resources based on default
parameters. Therefore, comprehensive assessment is required before parameter adjustment to
find the balance between the download rate and resources. For details, refer to the following
attachment.

Page 21
Upstream NEs of the Gb interface
Upstream NE factors of the Gb interface mainly include:
Continuity of N(U). Both N(U) out-of-sequence and packet losses cause failures in
reassembling LLC PDUs into upper-layer IP data packets, resulting in low download rate.
If N(U) is discontinuous, you need to trace signaling on both the SGSN and PCU to determine
whether the SGSN or intermediate transmission device causes N(U) out-of-sequence. Then
troubleshoot the responsible device.
Stability of upper-layer servers. The PCU is only the bearing channel. If upper-layer
application data is not delivered timely, the download rate must be low.
The stability of the server can be checked only based on the data on the Gb interface. To locate
such problems, you must have an in-depth understanding about upper-layer service
protocols. The first choice is to try several download servers on the live network. If the fault
occurs only on a certain server, it is the target.

Page 22
Upstream NEs of the Gb interface
You can check N(U) out-of-sequence or packet losses by tracing the messages of a single user on the BSC. The
following examples show the information about N(U) out-of-sequence or packet losses.
N(U) out-of-sequence

N(U) packet losses

To check TCP/IP packet losses, you need to have a clear understanding of TCP/IP
Case Analysis
Case 1
Symptom:
During the test in a certain cell of office A, it is found that the proportion of MCS9 data blocks does
not reach 100%, resulting in low throughput in CQT.

Conclusion:
The losses of data packets or blocks on the Gb interface result in low throughput in the CQT/DT.
Discussion:
What is the analysis procedure for the low download rate?
How to confirm the packet losses on the Gb interface?

Page 23
Page 24
Case Analysis
Case 2
Symptom:
In a Brazil office, end users complain that web browsing is slow or even failures occur when they
use MSs to access the Internet through GPRS. According to the packet analysis on the core
network, the SGSN receives error packets that fail in checksum authentication.

Conclusion:
The problem is caused by the incorrect settings of parameters in QoS negotiation during PDP
activation.
Discussion:
Which parameters do you need to pay attention to during the activation of a SIM card?

Page 25
Counter-Related Problems
Low TBF Establishment Success Rate Fault Symptom
The final goal of packet services is to enable the MS to access data networks. As the key NE of packet service
transmission, the BSC implements the establishment of the data transmission link, that is, TBF. The access to
data services relies on the establishment of the transmission link. The TBF establishment success rate reveals
the capabilities for allowing MSs to access networks, such as the network capacity and quality of the Um
interface.
The TBF establishment success rate can be classified into the uplink and downlink TBF establishment success rates.
The calculation formulas are as follows:
Uplink TBF Establishment Success Rate={[Number of Successful Uplink GPRS TBF Establishments]+[Number
of Successful Uplink EGPRS TBF Establishments]} x {100%}/
{[Number of Uplink GPRS TBF Establishment Attempts]+[Number of Uplink EGPRS TBF Establishment Attempts]}
Downlink TBF Establishment Success Rate={[Number of Successful Downlink GPRS TBF
Establishments]+[Number of Successful Downlink EGPRS TBF Establishments]} x {100%}/
{[Number of Downlink GPRS TBF Establishment Attempts]+[Number of Downlink EGPRS TBF Establishment
Attempts]}
The TBF establishment success rate reflects user accessibility. If the TBF establishment success rate is low, end
users feel it difficult to access packet services.
Page 26
Low TBF Establishment Success Rate Background
Information
Temporary Block Flow (TBF): A TBF is the physical connection between two RR peer entities. It supports unidirectional
transmission of LLC PDUs on the PDCH and comprises many RLC/MAC data blocks with LLC PDUs. A TBF can be
interpreted as a connection between an MS and a BSC. The connection exists only during data transmission. When
transmission ends, the connection is released.
Uplink State Flag (USF): The USF is contained in the header of the RLC/MAC data block on each downlink PDCH. The USF
is used to enable different MSs to share the same uplink PDCH. To be simple, the transmission time of each uplink RLC/MAC
data block on an MS is determined by the network side. The network side notifies the MS to transmit uplink RLC/MAC data
block according to the USF carried by the corresponding downlink data block.
N3101: In dynamic uplink assignment mode, the network side enables multiple MSs to share one uplink channel according to
the USFs carried by downlink data blocks. After assigning USFs to uplink TBFs, the network side starts the N3101 counter.
The network side waits for the uplink data sent by MSs to suit the reserved uplink RLC data block corresponding to each USF.
If the uplink RLC data block sent by an MS is valid, the network side resets the N3101 counter; otherwise, it increases the
count of the N3101 counter. When the counter overflows, the current uplink TBF is released abnormally.
N3103: When the uplink transmission ends, if receiving the last RLC data block, the network side sends a Packet Uplink
Ack/Nack message (FAI=1) to the MS and starts the N3103 counter. If the network side does not receive the Packet Control
Ack message within the specific time, the network side increases the count of the N3103 counter and re-sends a Packet
Uplink Ack/Nack message. When the counter overflows, the network side starts the T3169 timer. When the timer times out,
the current TBF is released abnormally.
Page 27
Low TBF Establishment Success Rate Background
Information
The establishment of a TBF falls into the following types:
Uplink TBF
One-phase access on the CCCH
Two-phase access on the CCCH
Uplink access on the PACCH
Downlink TBF
TBF establishment on the CCCH
TBF establishment in the uplink
TBF establishment in the downlink
For related establishment procedures, refer to the GBSS Signaling Analysis Guide.
Page 28
Low TBF Establishment Success Rate Influence factor
The causes for low TBF establishment success rate are as follows:
High Abis EFR
Insufficient channel resources
Poor quality of the Um interface
Improper parameter settings

Page 29
Low TBF Establishment Success
Rate Fault Locating Method
Troubleshooting Procedure:
Step 1: Locate the top N cells according to their TBF
establishment rates. (The top N cells are those with the
lowest TBF establishment success rates. The TBF
establishment success rates of other cells reach the
standard.)
Step 2: Make sure that the RL9A08: Rate of Transmitted
Error Frames value of top N cells is lower than 1%. If no, bit
errors occur on the current Abis interface. Contact the
transmission engineer to rectify the fault.
Step 3: Make sure that the L3188A: MSG DEL IND
Messages Sent on Abis Interface value of top N cells is
smaller than 10. If no, the CCCH is severely overloaded. In
this case, you can use the MML command SET
GTRXCHAN to configure extended BCCH.

Modify related
channel parameters
Optimize the quality
of the Um interface
Troubleshoot
transmission-related
faults
Configure extended
BCCH
Low TBF
establishment
success rate
G-Abis EFR > 1%?
YES
YES
YES
NO
NO
NO
Sort out top N cells
Problem solved?
YES
Contact Huawei
support engineer
NO
Problem solved?
Problem solved?
Problem solved?
Start
End
NO
NO
NO
YES
YES
YES
L3188A > 10? Problem solved? YES
NO
YES
NO
Insufficient
channel resources?
No responses from
mobile phones?
Page 30
Low TBF Establishment Success Rate Fault Locating Method
Step 4: For TBF establishment failures caused by insufficient channel resources, make sure that static channels are configured,
the number of activated DSP channel is lower than the upper limit, the maximum ratio threshold of PDCHs in the cell, maximum
PDCHs of the carrier, maximum number of Abis timeslots, and PDCH multiplexing threshold are appropriate, the Abis interface
board and DSP for the top N cells are located on the same device, and the Allow E Down G Up Switch function is disabled.
Step 5: For TBF establishment failures caused by no responses from MSs, make sure that the default coding schemes of uplink
and downlink are not too high, the cell does not suffer from severe interference, and the Um interface of the cell has satisfactory
receive quality.
Step 6: If the fault persists after the preceding steps are completed, adjust network parameters according to the following steps:
If both the uplink TBF establishment success rate and the assignment success rate on the PACCH are low, increase the T3168 to a
value smaller than 2000.
If a large number of TBF establishment failures are caused by no responses from MSs, increase PS RACH Min. Access Level to -109.
However, this operation will result in fewer access users and lower traffic. In addition, increase Random Access Error Threshold
to 225. Note that a smaller value indicates easier access of MSs (because random access signal errors are more tolerant) but
higher false negative rate; a larger value indicates lower false negative rate but fewer access users and lower traffic.
If the downlink TBF establishment success rate is low, change the value of Retry Times of Downlink TBF Reassignment to 4, and
that of Retry Times of Downlink TBF Polling to 5.
Impact: If the parameter is set to a too large value, the downlink establishment success rate can be increased, but more congestions
occur during peak hours.

Page 31
High TBF Drop Rate Fault Symptom
The TBF drop rate is a KPI reflecting the network retainability and closely related to user
experience. If the TBF drop rate is high when a user is browsing Web pages, the user feels that
Web browsing is slow, intermittent, or fails.
The TBF drop rate is classified into the uplink and downlink TBF drop rates. The calculation
formulas are as follows:
Uplink TBF Drop Rate={[Number of Uplink GPRS TBF Abnormal Releases due to N3101
Overflow (MS No Response)]+[Number of Uplink GPRS TBF Abnormal Releases due to N3103
Overflow (MS No Response)]+[Number of Uplink EGPRS TBF Abnormal Releases due to
N3101 Overflow (MS No Response)]+[Number of Uplink EGPRS TBF Abnormal Releases due
to N3103 Overflow (MS No Response)]} x {100%}/{[Number of Successful Uplink GPRS TBF
Establishments]+[Number of Successful Uplink EGPRS TBF Establishments]}
Downlink TBF Drop Rate={[Number of Downlink GPRS Intermit Transfers]+[Number of
Downlink EGPRS Intermit Transfers]} x {100%}/{[Number of Successful Downlink GPRS TBF
Establishments]+[Number of Successful Downlink EGPRS TBF Establishments]}
Page 32
High TBF Drop Rate Influence Factor
The TBF drop rate is the proportion of the TBF abnormal release times to TBF
establishment success times. This counter is affected by three factors: poor quality
of the Um interface (results in MSs' response failures to network instructions),
network transmission and resource occupation (results in uplink data losses for
MSs), and compatibility of MSs (after receiving instruction messages, MSs give no
response). The causes for a high TBF drop rate are as follows:
N3101/N3103/N3105 overflow
SUSPEND process
Cell reselection
Channel occupation
Page 33
Modify related
parameters
Expand cell
capacity
Optimize the
quality of the Um
interface
Troubleshoot
transmission-
related faults
Plan the routing
area reasonably
Contact Huawei
support engineer
NO
YES
Locate fault cause category
(Traffic measurement)
High TBF drop rate
Problem solved?
NO
End
NO
YES
Problem solved?
NO
YES
YES
Insufficient
resources?
FLUSH_LL?
YES
YES
YES
Problem solved?
Problem solved?
Problem solved?
NO
NO
NO
YES
YES
YES
NO
NO
NO
Poor
quality of the Um
interface?
Normal G-Abis
EFR?
Check parameter
settings
High TBF Drop Rate Fault
Locating Method
Step 1: Locate the top N cells according to their TBF
drop rates.
Step 2: Check parameter configurations:
Make sure that the uplink and downlink coding scheme is
not fixed to coding scheme with MCS7/MCS8/MCS9.
Set Bep Period to 5.
The value of the N3101 counter is not smaller than 20,
that of the N3103 counter is not smaller than 3, and that
of the N3105 counter is not smaller than 10.
Step 3: Make sure that the RL9A08: Rate of
Transmitted Error Frames value of top N cells is lower
than 1%. If no, bit errors occur on the current Abis
interface. Contact the transmission engineer to rectify the
fault.

Page 34
High TBF Drop Rate Fault Locating Method
Step 4: Locate the causes for abnormal TBF releases based on certain counters. These counters are distributed in the following
four measurement units of GSM cell-based performance measurement set: Downlink GPRS TBF Establish and Release
Capability Measurement, Downlink EGPRS TBF Establish and Release Capability Measurement, Uplink EGPRS TBF Establish
and Release Capability Measurement, and Uplink GPRS TBF Establish and Release Capability Measurement. The causes for
abnormal TBF release are as follows:
Poor quality of the Um interface: The values of A9006, A9007, A9206, A9207, A9106, and A9306 are large.
Insufficient resource: The values of A9010, A9210, A9109, and A9309 are large.
FLUSH_LL: The values of A9009, A9209, A9108, and A9308 are large.
SUSPEND: The values of A9008, A9208, A9107, and A9307 are large.
Step 5: Optimize parameter settings according to the causes for abnormal TBF release.
Poor quality of the Um interface: If intra-frequency interference, frequency collision caused by frequency hopping, or
uplink/downlink imbalance occurs, the transmission of RLC data blocks on the Um interface is affected severely. As a result, MSs
cannot decode RLC data blocks and N3101/N2103/N3103 overflows, further leading to abnormal TBF release. In this case, you
can optimize frequency planning, frequency hopping, power control, and transmit power parameters to solve this problem.
Insufficient resources: The problem may be caused by hardware factors. You can view board alarms. If a board is faulty, you can
replace the board to solve the problem. Another cause is that the voice service is busy and occupies dynamic PDCH. In this case,
the values of R9343 and R9344 are large. Consider expanding capacity to solve the problem.
If FLUSH_LL causes a large amount of abnormal TBF release, you can check the planning of cells and routing areas.

Page 35
High RLC Retransmission Rate Fault Symptom
RLC retransmission rate is a KPI reflecting data transmission performance and closely related
to user experience. If the RLC retransmission rate is high or coding scheme with
MCS7/MCS8/MCS9 accounts for only a small proportion when a user is browsing Web pages,
the user feels that Web browsing is slow, intermittent, or fails.
The retransmission rate is classified into GPRS RLC and EGPRS retransmission rates. The
calculation formulas are as follows:
Retransmission Rate of Uplink GPRS RLC Data Blocks=([Total Number of Uplink GPRS RLC
Data Blocks]- [Number of Valid Uplink RLC Data Blocks Using CS1] - [Number of Valid Uplink
RLC Data Blocks Using CS2]- [Number of Valid Uplink RLC Data Blocks Using CS3]- [Number
of Valid Uplink RLC Data Blocks Using CS4]) x {100%}/[Total Number of Uplink GPRS RLC
Data Blocks]
Retransmission Rate of Downlink GPRS RLC Data Blocks=([Total Number of Downlink GPRS
RLC Data Blocks]- [Total Number of Valid Downlink RLC Data Blocks Using CS1]- [Total
Number of Valid Downlink RLC Data Blocks Using CS2]- [Total Number of Valid Downlink RLC
Data Blocks Using CS3]- [Total Number of Valid Downlink RLC Data Blocks Using CS4]) x
{100%}/[Total Number of Downlink GPRS RLC Data Blocks]

Page 36
High RLC Retransmission Rate Fault Symptom
Retransmission Rate of Uplink EGPRS RLC Data Blocks= ([Total Number of Uplink EGPRS
RLC Data Blocks]- [Total Number of Valid Uplink EGPRS MCS1 RLC Data Blocks]- [Total
Number of Valid Uplink EGPRS MCS2 RLC Data Blocks]- [Total Number of Valid Uplink
EGPRS MCS3 RLC Data Blocks]- [Total Number of Valid Uplink EGPRS MCS4 RLC Data
Blocks]- [Total Number of Valid Uplink EGPRS MCS5 RLC Data Blocks]- [Total Number of
Valid Uplink EGPRS MCS6 RLC Data Blocks]- [Total Number of Valid Uplink EGPRS MCS7
RLC Data Blocks]- [Total Number of Valid Uplink EGPRS MCS8 RLC Data Blocks]- [Total
Number of Valid Uplink EGPRS MCS9 RLC Data Blocks]) x {100%}/[Total Number of Uplink
EGPRS RLC Data Blocks]
Retransmission Rate of Downlink EGPRS RLC Data Blocks= ([Total Number of Downlink
EGPRS RLC Data Blocks]- [Total Number of Valid Downlink EGPRS MCS1 RLC Data Blocks]-
[Total Number of Valid Downlink EGPRS MCS2 RLC Data Blocks]- [Total Number of Valid
Downlink EGPRS MCS3 RLC Data Blocks]- [Total Number of Valid Downlink EGPRS MCS4
RLC Data Blocks]- [Total Number of Valid Downlink EGPRS MCS5 RLC Data Blocks]- [Total
Number of Valid Downlink EGPRS MCS6 RLC Data Blocks]- [Total Number of Valid Downlink
EGPRS MCS7 RLC Data Blocks]- [Total Number of Valid Downlink EGPRS MCS8 RLC Data
Blocks]- [Total Number of Valid Downlink EGPRS MCS9 RLC Data Blocks]) x {100%}/[Total
Number of Downlink EGPRS RLC Data Blocks]
Page 37
High RLC Retransmission Rate Influence Factor
The retransmission rate refers to the proportion of retransmitted RLC data blocks to all RLC
data blocks. This counter is closely related to the rate of coding scheme with
MCS7/MCS8/MCS9. You are advised to assess the two counters simultaneously because the
assessment of only one counter makes no sense. The increase of the rate of coding scheme
with MCS7/MCS8/MCS9 may lead to more retransmissions. To lower the retransmission rate,
you can use more low-rate coding schemes, but this results in lower rate of coding scheme with
MCS7/MCS8/MCS9. Therefore, the two counters should be weighted together on site. The
causes for high retransmission rate are as follows:
Poor quality of the Um interface: If the Um interface is of poor quality, MSs report low BEP
values. Consequently, coding scheme with MCS7/MCS8/MCS9 cannot be used. Moreover, the
system may automatically switch to the LA mode and segment data blocks for retransmission,
affecting the rate of coding scheme with MCS7/MCS8/MCS9.
High EFR of Abis transmission: If the Abis transmission EFR is high, data blocks may be lost
or retransmitted, affecting the rate of coding scheme with MCS7/MCS8/MCS9.
Unconfirmed data blocks in abnormal release are counted in the number of all data blocks,
affecting the retransmission rate.

Page 38
High RLC Retransmission
Rate Fault Locating Method
Step 1: Sort out top N cells according to their
RLC retransmission rates.
Make sure that the uplink and downlink
coding scheme is not fixed to coding scheme
with MCS7/MCS8/MCS9.
Make sure that the value of ALPHA is 0.6 and
that of GAMMA is 12. If no, run the MML
command SET GCELLPSPWPARA to rectify
the fault.
Step 3: Make sure that the RL9A08: Rate of
Transmitted Error Frames value of top N cells
is lower than 1%. If no, bit errors occur on the
current Abis interface. Contact the transmission
engineer to rectify the fault.

Enter related
troubleshooting
procedure
Modify related
parameters
Optimize the Um
interface
Check the
transmission
Contact Huawei
support engineer
NO
YES
Low RLC throughput
Problem solved?
NO
Problem solved?
End
NO
NO
YES
YES
NO
Problem solved?
Problem solved?
NO
NO
YES
YES
YES
Problem solved?
YES
YES
NO
YES
NO
Low high-
encoding rate
Proper
parameter
configurations?
Proper
transmission EFR on
the G-Abis
interface?
Poor Um
interface quality?
Page 39
High RLC Retransmission Rate Fault Locating Method
Step 4: Check the parameters of frequency planning, frequency hopping, power control, and transmit
power. If the Um interface is of poor quality, for example, adjacent-frequency interference and co-
channel interference, frequency collision caused by frequency hopping, or uplink and downlink
performance imbalance occurs, the BEP reported by the MS is low and the coding scheme cannot be
improved.
Step 5: Check whether large amount of TBF abnormal release exists. If yes, rectify the fault according
to the troubleshooting procedure of call drop rate.

Page 40
Low RLC Throughput Fault Symptom
When the RLC throughput is low, the values of the following counters are abnormal. The
download rate of the end user is low.
TL9014:Average Throughput of Uplink GPRS RLC
TL9333:Average Throughput of Downlink EGPRS RLC
TL9114:Average Throughput of Downlink GPRS RLC
TL9232:Average Throughput of Uplink EGPRS RLC

Page 41
Low RLC Throughput Influence Factor
Throughput refers to the traffic passing the device in a unit time. The throughput is in proportion
to the PS rate. The higher the throughput, the higher the PS rate. The influence factors of the
throughput are as follows:
Resource: PDTCH resource (number of supported PDTCHs based on the multislot capability
of the MSs), Abis timeslot resource (TDM transmission adopted), bandwidth resource of the Gb
interface (TDM transmission adopted), and number of multiplexed MSs
Environment: Um interface quality, Abis transmission quality, and Gb interface transmission
quality
Parameter configuration: threshold of channel multiplexing, channel type, and BEP period
MS: cache capability, packet assembly and disassembly capability, multislot capability, and
support for EGPRS
Page 42
Low RLC Throughput Fault
Locating Method
Step 1: Locate the top N cells according to their RLC
throughput values.
Make sure that the uplink and downlink coding schemes
are not fixed to MCS1/MCS2/MCS3/MCS4.
Set Bep Period to 5.
Make sure that the value of Timer of Releasing Abis
Timeslot is not smaller than 15.
Make sure that the value of PDCH Downlink Multiplex
Threshold is not greater than 80.
Make sure that Allow E Down G Up Switch is disabled.
Step 3: Make sure that the RL9A08: Rate of Transmitted
Error Frames value of top N cells is lower than 1%. If no,
bit errors occur on the current Abis interface. Contact the
transmission engineer to rectify the fault.

Modify related
parameters
Optimize the Um
interface
Check the
transmission
Contact Huawei
support engineer
NO
YES
Low RLC
throughput
Problem solved?
NO
Problem solved?
End
NO
NO
YES
YES
NO
Problem solved?
Problem solved?
NO
NO
YES
YES
YES
YES
NO
Parameter
configuration proper?
Proper
transmission EFR
on the G-Abis
interface?
Poor Um
interface quality?
Page 43
Low RLC Throughput Fault Locating Method
Step 4: Check the parameters of frequency planning, frequency hopping, power control, and transmit
power. If the Um interface is of poor quality, for example, adjacent-frequency interference and co-
channel interference, frequency collision caused by frequency hopping, or uplink and downlink
performance imbalance occurs, the BEP reported by the MS is low and the coding scheme cannot be
improved.
Step 5: The RLC-layer average throughput formula indicates that increasing the coding rate and
activated PDCHs of the cell improves the RLC-layer average throughput but requires more resources
and increases RLC retransmission rate. Therefore, adjust the parameters according to the actual
situation. You can increase the RLC-layer average throughput by the following methods:
Increase the value of Maximum Rate Threshold of PDCHs in a Cell. Note that if the voice service is
also busy, the CS will preempt more PDCHs and half-rate channel ratio will increase, which affects the
MOS.
Increase the number of Abis idle timeslots. Note that this occupies extra transmission resources. In
FLEX ABIS networking, the CS domain service will be affected if the number of idle timeslots is too
large.
Enable Support USF Granularity 4 Switch.
Configure Level of Preempting Dynamic Channel so that channels cannot be preempted.
Set the RRBP period of the EGRPS TBF RLC downlink data block to 15.

Page 44
Low RLC Throughput Case Analysis
[Symptom]
After network migration of office A, the throughput becomes lower.
[Cause Analysis]
Um interface quality is poor and cannot support the coding scheme.
Abis idle timeslots are inadequate and therefore coding scheme with MCS7/MCS8/MCS9 is not
supported.
[Troubleshooting Procedure]
Check the parameter health of the cells whose throughput is low. All parameters are set to the
recommended values and no exception occurs.
Check the Abis transmission frame error rate of such cells. The rates are all below 1.
Obtain the TEMS log through drive test. The Um interface quality of certain cells is poor and
the C/I value is low. After the network optimization engineers optimize the Um interface quality,
the throughput meets the standard.
Check the Aibs idle timeslot number of such cells. Abis idle timeslots are inadequate. After
Abis idle timeslots are added, the throughput meets the standard.

Page 45
High TBF Congestion Rate Fault Symptom
TBF congestion refers to the situation where the current PDCH resources cannot meet service
requirements and TBF establishment failures and call drops occur. Check the BSC-level counter
S9206:Number of Failed PDCH Assignments Due to BSC Congestion. If the counter is of a
large value in certain periods of time, PDCH congestion occurs on the BSC during such periods.
Locate the congested cells according to the congestion periods and the following cell-level traffic
measurement counters:
A9003: Number of Failed Uplink GPRS TBF Establishments due to No Channel
A9103: Number of Failed Downlink GPRS TBF Establishments due to No Channel
A9203: Number of Failed Uplink EGPRS TBF Establishments due to No Channel
A9303: Number of Failed Downlink EGPRS TBF Establishments due to No Channel
During TBF establishment, if no PDCH resource is available, the value of counter S9206:Number
of Failed PDCH Assignments Due to BSC Congestion is increased by 1. Then the preceding
counter values are measured according to the cell of the TBF establishment requirement, uplink
and downlink traffic, and service type.
Page 46
High TBF Congestion Rate Influence Factor
The influence factors of the TBF congestion rate are as follows:
No static PDCHs
Improper maximum ratio threshold of PDCHs in a cell
High CS service volume
Abnormal PDCH status
Activated PDCHs of the DSP reaching the upper limit
Abis timeslot resources reaching the upper limit
Activated PDCHs exceeding the threshold specified by the license
Switch for E-down and G-up disabled
Page 47
High TBF Congestion Rate Fault
Locating Method
Step 1: Check the configuration of static PDCH. If no static
PDCH is configured, no PS service is processed in the cell, and
no PDCH is available, the BSC rejects MS access due to PDCH
unavailability after the MS sends the first channel request. The
failure is counted in counter S9206:Number of Failed PDCH
Assignments Due to BSC Congestion. Then, the BSC
converts idle TCHs to PDCHs and the MS can access the BSC
successfully with the next attempt.
Step 2: Set parameter Maximum Rate Threshold of PDCHs in
a Cell to the maximum PDCH ratio of the cell. The total number
of available TCHs and PDCHs of a cell is fixed. PDCH ratio =
Number of available PDCHs/(Number of available TCHs/F +
Available static PDCHs). This parameter refines the PDCH ratio.
The default value is 30. If the parameter value is too small,
available PDCHs of the cell are of a small number, which causes
PDCH congestion.

TBF congestion
Static PDCH configured?
High CS service volume?
Proper PDCHs?
End
YES
YES
NO
YES
NO
NO
NO
NO
Modify the PDCH ratio in a
cell
Configure Static PDCHs
Expand the carrier
Check the transmission
Migrate the cells to idle
DSPs
Expand Aibs transmission
capacity
Expand license capacity
Enable the E-down and G-up
switch Modify PDCH
multiplexing threshold
Contact R&D engineers
Problem solved?
Problem solved?
Problem solved?
Problem solved?
Problem solved?
Problem solved?
Problem solved?
Problem solved?
NO
NO
NO
NO
YES
NO
NO
NO
YES
NO
YES
NO
YES
NO
YES
NO
YES
YES
YES
YES
YES
YES
YES
YES
Proper PDCH ratio in a
cell?
Activated PDCHs on
the DSP reaching the
upper limit?
Abis resources
reaching the upper
limit?
Activated PDCHs
reaching the threshold
specified by the license?
Proper setting of the
E-down and G-up switch and
PDCH multiplexing
threshold?
Page 48
High TBF Congestion Rate Fault Locating Method
Step 3: If the CS service volume in the cell is large, TCHs cannot be converted to PDCHs. Therefore, PS service
congestion occurs due to inadequate PDCHs. Analyze the following counters to determine whether the PDCH congestion
is caused by the large CS service volume:
If the AR9321 value and the number of static PDCHs configured for the cell are equal or have a difference less than 1, the
static PDCHs are always occupied. If the AR9323 value is less than 1, dynamic PDCHs are seldom occupied. If the value
of R9304:Maximum Number of Available PDCHs is much less than that in non-congestion period, the CS service
volume is large and occupies most TCHs. Therefore, the PS service cannot apply for converting TCHs to PDCHs, causing
PDCH congestions.
Step 4: Check the following counters to view the PDCH status:
RL9A08: transmission frame error rate. If the value is larger than 1%, the link is unstable.
R9305: minimum number of available PDCHs. If static PDCHs are configured but the R9305 value remains 0 during the
congestion period, static PDCHs are unavailable and channel status was abnormal.
R473: carrier out-of-service duration. Unstable Abis interface links cause abnormal carriers and the R473 value is not 0.
When the channel status of the carrier is improper, PDCHs and TCHs are unavailable, which causes PDCH congestions.
If the PDCH status is improper, check the status of transmission and carrier.

Page 49
Step 5: Check the number of activated PDCHs. If the number reaches the upper limit of the DSP, the service volumes
of certain cells become large.
The counter for dynamic PDCH activation is R9346, which indicates the number of requests that should have been sent for
applying dynamic PDCHs (because the number of activated channels reaches the upper limit). This counter reflects the
number of failed dynamic PDCH applications caused by channel number threshold. If the counter of a cell is not 0,
resource congestion occurs on the DSP of the cell.
There is no counter for collecting the number of failed static PDCHs due to board specification (which seldom occurs). The
counter for measuring DSP performance resource can be used. For example, if R9501: Maximum Number of PDCHs
Activated on DSP = R9502: Minimum Number of PDCHs Activated on DSP = 48, the static PDCH number on the
DSP is 48.
Note the 22nd DSP, on which the number of activated channels is generally less than 48. If the R9501 value is equal to the
R9502 value, the static PDCH number on the DSP reaches the upper limit.
It is recommended to migrate a part of the cells on the DSP to an idle DSP.
Step 6: Check the usage of Aibs timeslot resources. PDCH activation occupies at least one Abis time slot. A dynamic
PDCH cannot be activated if no Abis timeslot is available.
In this case, check R9347: Number of Dynamic PDCH Requests Without Application Attempts Because No Abis
Timeslot is Available for Use. When launching the packet service, the MS applies for dynamic channels. If no Aibs
resource is available, the application fails and this counter increases by 1.
If Abis timeslot resources reach the upper limit, expand the Abis transmission capacity.

Page 50
Step 7: Check the number of activated PDCHs. If the number exceeds the threshold specified by the
license, an ALM-20259 alarm ALM-20259 Number of Resources Used Exceeding Alarm
Threshold Specified by License is generated and the alarm resource item is the PDCH resource.
After the threshold specified by the license is exceeded, only one PDCH is allowed for cells that have
activated no PDCHs. Other cells are not allowed to activate dynamic PDCHs. Therefore, congestion
may occur due to PDCH insufficiency.
In this case, expand the license capacity.
Step 8: Check the switch of E-down and G-up. If the switch is enabled, EGPS downloading and GPRS
uploading are allowed to use the same channel, which increases uplink access channels for the
GPRS service in the cell but lowers EGPRS rate.
Step 9: Check the configuration of PDCH multiplexing threshold. The lower the threshold, the more
resources that can be obtained by the MS, which increases the downloading rate but occupies more
resources. The higher the threshold, the more MSs multiplexed on one channel, which saves PDCH
resources but lowers the downloading rate.
When PDCH congestion occurs, you can increase the PDCH multiplexing threshold to allow the
access of more MSs.

Page 51
High TBF Congestion Rate Case Analysis
Case 1
Symptom
On December 24, 2010, an Indian office reported that the S9206 value was large.
Location Process
Traffic measurement shows that cells 848 and 456 cannot establish TBF because no resource is
available. In addition, the number of TBF abnormal release times of these cells reaches half of the
S9206.
Configuration analysis shows that no static PDCHs are configured in these cells.
Conclusion
PDCH congestion occurs because no static PDCH is available. After the static PDCHs are configured, the counter recovers.
Discussion Guide
Locate the fault by analyzing traffic measurement and configurations.
Check the configuration of dynamic PDCHs in the cell.
Check the configurations of maximum ratio threshold of PDCHs in the cell and maximum PDCHs of
the carrier.
Check dynamic PDCH availability when the cell is busy.

Page 52
Resource-Related Problems
PDCH Fault Fault Symptom
PDCH resource faults mainly include two situations: PDCH faults and out of PDCHs. The fault can be located by
the following methods:
Check the monitoring channel status. Enable channel monitoring by WEBLMT on the BSC6900. If the channel
color is red, a fault occurs on the channel.

Query the channel status by the MML command. Run the DSP PDCH command to query channel status of a
cell. The result shows that the channel is unavailable.

Page 53
PDCH Fault Influence Factor
Generally, a PDCH fault can be caused by the following factors:
A fault occurs on the transmission.
The version of the BTS is old.
The management status of the Um interface is closed.
PS cells are not distributed and cannot properly operate.
The number of activated channels on the DSP of the cell reaches the upper limit.
LVDS resources on the DSP of the cell are inadequate. According to board specifications, one
DPUP board hosts 22 DSPs, 21 of which have 192 LVDS timeslots respectively. (You can use
the MML command to query the DSP link status ID and match the DSP link status. Then you
can run the DSP DSPLINK command to query the specified DSP.) The rest DSP has only 48
LVDS timeslots. Therefore, you need to query the link status of this DSP to check whether
LVDS timeslots are inadequate.
The clock is unlocked.
Page 54
PDCH Fault Fault Locating
Method
Step 1: Determine the fault range. If the channels of all
cells of the BTS are faulty, check the status of
transmission, BTS, and carrier.
Step 2: Check whether the faulty cells belong to the
same DSP. If yes, migrate the cells to idle DSPs. To
avoid the number of activated channels on one DSP
exceeding the threshold, do not migrate the cells to the
same DSP. After the migration, check whether the fault is
rectified.
Step 3: The old BTS version contains certain out-of-
channel bugs. Check whether the BTS is of the latest
version. If no, update the BTS version.
Step 4: Run the MML command DSP PSCELL to query
Cell Um Administration State and rectify the fault
according to the handling procedure for ALM-21801
GSM Cell out of Service.

NO
Start
A PDCH fault occurs
Mainstream
BTS version?
End
NO
NO
NO
NO
DSPs
Check the transmission
Upgrade the version
Check the BTS or Abis
status
DSPs
Migrate the cells to DSPs
with sufficient LVDS
resources
Trace Abis interface signaling of the
PS service and feed back information
to R&D engineers
Problem solved?
Problem solved?
Problem solved?
Problem solved?
Problem solved?
Problem solved?
YES
NO
YES
NO
YES
NO
YES
YES
NO
YES
NO
YES
YES
YES
YES
YES
YES
PDCHs of all cells
belonging to the station
faulty?
All faulty cells belong to
the same DSP?
Um management status
closed?
Activated PDCHs
on the DSP exceeding the
upper limit?
Adequate LVDS resources
on the DSP?
Page 55
PDCH Fault Fault Locating Method
Step 5: Use the following methods to check whether the number of activated channels on the DSP
exceeds the upper limit:
Run the MML command DSP PSCELL to query Subrack No, Slot No., and DSP No of the cell.
Run the MML command DSP PDCHNUM to check the number of activated channels on the DSP. If
the number is 48, the activated channels on the DSP reach the upper limit.
If activated channels on the DSP reach the upper limit, run the MML command SET PSCELLTODSP
to migrate the cells to an idle DSP.
Step 6: When LVDS insufficiency generally occurs on the DSP having 48 LVDS timeslots, you can
locate the fault by the following methods:
Run the MML command DSP PSCELL to query Subrack No, Slot No., and DSP No of the cell.
Run the MML command DSP DSPLINK to check whether the number of LVDS timeslots is 48 and all
LVDS timeslots are used (that is, no link is in the unallocated state).
If no LVDS timeslot is available, run the MML command SET PSCELLTODSP to migrate cells to an
idle DSP.
Step 7: If the fault persists after the preceding steps, trace the signaling of the Abis interface and send
the information to the R&D personnel.

Page 56
PDCH Fault Case Analysis
Case 1
Symptom
Certain PDCHs in a cell of office A are faulty.
Cause Analysis
The number of activated channels on the DSP reaches the upper limit and therefore channels
cannot be activated.
Troubleshooting Procedure
Check the cell status. The cell status is normal.
Check the channel status. The requested bandwidth and available bandwidth of the channel are
both OK.
Check the DSP of the cell and number of static channels on the DSP. The total number of static
channels is larger than 48.
Manually migrate the cells to an idle DSP. After the migration, channels are activated and the
fault is rectified.

Page 57
PDCH Fault Case Analysis
Case 2
Symptom
A PDCH fault is detected through channel status monitoring in office A. After the status is
refreshed, the fault is rectified.
Cause Analysis
The E1 cable is faulty, which causes the PDCH fault.
Check the BTS version. Certain versions contain synchronization failure bugs, but the version
in use is not one of these versions.
Traffic measurement shows that the transmission error frame rate of the Abis interface is high
and an LAPD interruption alarm is generated.
Check transmission lines. After the E1 cable is replaced, the fault is rectified.

Page 58
Gb Interface Resource Fault Fault Symptom
The Gb interface is the standard interface for connecting the BSC and SGSN.
After the PCU is built in the BSC, the PCU does not work as an independent NE. The Gb
interface is added as an external interface of the BSC. The Gb interface connects the control
plane and data plane of the wireless side in the PS domain and core network side.
Common Gb interface faults include the BC fault, NSVC fault, NSVL fault, and NSE fault.
Page 59
Gb Interface Resource Fault Influence Factor
Generally, a Gb interface fault can be caused by the following factors:
A board of the BSC is faulty.
The BSC configuration is different from the SGSN configuration.
A transmission fault occurs.
The SGSN is faulty.

Page 60
Gb Interface Resource Fault
Fault Locating Method
A Gb interface fault may involve multiple NEs. Therefore,
check the BSC first, and then the transmission
between the BSC and other NEs. The procedure is
as follows:
Check whether a board of the BSC is faulty.
Check whether the BSC configuration is different
from the SGSN configuration.
Check whether a fault occurs on the transmission.
Check whether the SGSN is faulty.
If the fault cannot be located after the preceding
steps, trace the signaling to locate the faulty NE.
The following pages describe the Gb interface faults
in details.

A Gb interface
fault occurs
Proper
transmission?
Contact R&D
engineers
YES
YES
YES
YES
NO
NO
NO
NO
Start
End
Problem solved?
Problem solved?
NO
NO
YES
YES
Problem solved?
Problem solved?
NO
NO
YES
YES
Replace the
faulty board
Modify
configurations
Check the
transmission
Check the
SGSN
SGSN working
properly?
Faulty board on
the BSC?
BSC and SGSN
configuration data
consistent?
Page 61
Gb Interface Resource Fault Fault Locating Method
When a BC fault occurs, an ALM-21385 Gb BC Failure alarm is generated. In normal cases, the BSC sends the STATUS_ENQUIRY_SIG
message to the SGSN to detect the BC link status. The SGSN returns the STATUS_SIG message to indicate that the link works properly. When
the BSC sends the STATUS_ENQUIRY_SIG message for N393 times and receives no response for N392 times, the BSC sets the BC status to
faulty. The values of N392 and N393 are specified by the MML command ADD BC when the BC is added.
The procedure for troubleshooting a BC fault is as follows:
Step 1: On the BSC maintenance console, check whether a fault alarm is generated on the Gb interface board corresponding to the BC. If an
alarm is generated, replace the Gb interface board. If the alarm does not exist or the fault is not rectified after board replacement, go to step 2.
Step 2: Run the MML command LST E1T1 to check whether the port configuration is identical with that of the transmission device. The
configurations of working mode, frame structure, and line coding scheme should be identical. Run the MML command LST BC to check the
negotiated configuration data of the BSC and SGSN is identical. The configurations of carrier timeslot and frame relay protocol type should be
identical. If the configurations are different, modify them according to the actual network planning. If the fault persists after modification, go to
step 3.
Step 3: Run the MML command DSP E1T1 to check the port status of E1/T1. If the result shows that the port is faulty, the transmission is
abnormal. You can locate the transmission fault through transmission alarms on the BSC and alarms on the transmission network management
system. Contact the transmission engineer to rectify the fault. If the fault persists after the transmission recovers, go to step 4.
Step 4: If the transmission is normal, check on the SGSN maintenance console whether a fault alarm is generated on the corresponding
interface board or an overloading alarms is generated. If an alarm exists, contact the SGSN maintenance engineer to rectify the fault. If the fault
persists after the SGSN recovers, go to step 5.
Step 5: If the fault persists after the preceding steps, contact the R&D personnel.

Page 62
Troubleshooting an NSVC fault:
When an NSVC fault occurs, an ALM-22003 NSVC Disconnection alarm is generated. In normal cases, the BSC and SGSN exchange the Alive PDU
message over each NSVC. The peer returns the Alive PDU ACK message, which indicates that the link is normal. If no response is received
within the specified period of time, the BSC sends the other Alive PDU message. If the peer still does not respond, the BSC sets the NSVC
status to faulty.
The procedure for troubleshooting an NSVC fault is as follows:
Step 1: When the transmission is abnormal, generally a BC fault alarm is generated. If a BC fault alarm is detected, rectify the fault according to
the BC fault troubleshooting procedure. If the NSVC fault persists when no BC fault alarm exists or the BC fault is rectified, go to step 2.
Step 2: Check the transmission fault alarm. If such an alarm is detected, rectify the fault according to the transmission fault troubleshooting
procedure. If the fault persists when no transmission fault alarm exists or the transmission fault is rectified, go to step 3.
Step 3: Check the fault alarm of the Gb interface board. If such an alarm is detected on the BSC, replace the interface board or switch over the
active and standby boards. If the fault persists when no fault alarm of the Gb interface board exists or the Gb interface board is replaced, go to
step 4.
Step 4: Check the consistency of the BSC and SGSN configuration data. Run the LST NSVC command to check NSE Identifier, NSVC
Identifier, and The Identifier of Data Link Connection. The configurations of such parameters should be consistent with those on the SGSN.
If the configurations are different, modify them according to the actual network planning. If the fault persists after the parameters are
synchronized, go to step 5.
Step 5: Check the DIP switch setting of the Gb interface board on the BSC. The setting should meet the requirements of the actual physical
transmission. For detailed operation procedure, refer to BSC6900 GSM Product Documentation > BSC6900 GSM Installation Guide > Installing
and Setting the Boards > DIP Switches on the BSC6900 Boards. If the fault persists after the setting meets the requirements of the actual
physical transmission, go to step 6.
Step 6: On the SGSN maintenance console, check whether the interface board fault or overloading alarm exists on the SGSN. If yes, contact the
SGSN maintenance engineer to rectify the fault. If no, trace NS-layer signaling on the SGSN and contact Huawei support engineer and SGSN
maintenance engineer to rectify the fault.

Page 63
Troubleshooting an NSVL fault:
NSVL faults occur in the GBIP networking. When an NSVL fault occurs, an ALM-22004 NSVL Faulty alarm is generated. In
normal cases, the BSC and SGSN exchange the Alive PDU message over each NSVL after the NSE starts working.
The peer returns the Alive PDU ACK message, which indicates that the link is normal. If no response is received within
the specified period of time, the BSC sends the other Alive PDU message. If the peer still does not respond, the BSC
sets the NSVC status to faulty.
The procedure for troubleshooting an NSVL fault is as follows:
Step 1: On the BSC maintenance console, check whether a board fault alarm exists. If yes, replace the faulty board. If
the fault persists when no board fault alarm exists or the board is replaced, go to step 2.
Step 2: Run the MML commands LST NSVLLOCAL and LST NSVLREMOTE to check NSE Identifier, IP Address,
UDP Port No, Remote IP Address, and Remote UDP Port No. The configuration of such parameters should be
identical with that on the SGSN. If no, modify the parameters according to actual network planning. If the fault persists
after the parameters are synchronized, go to step 3.
Step 3: On the BSC maintenance console, run the MML command DSP ETHPORT to check Link Availability Status.
If the link is unavailable, ask the transmission engineer to examine transmission device. If the fault persists after the
transmission recovers, go to step 4.
Step 4: On the BSC maintenance console, run the MML command PING IP to ping the IP address of the remote NSVL.
If the remote NSVL cannot be pinged through, ask the transmission engineer to check the configurations of the switch
or router. If the fault persists after the remote NSVL can be pinged through, go to step 5.
Step 5: On the SGSN maintenance console, check whether the interface board fault or overloading alarm exists on the
SGSN. If yes ask the SGSN support personnel to rectify the fault. If the fault persists after the SGSN recovers, go to
step 6.
Step 6: If the fault persists after the preceding steps, contact the R&D personnel.

Page 64
Troubleshooting an NSE fault:
When an NSE fault occurs, an ALM-22005 NSE Faulty alarm is generated. In normal cases, the BSC
sends the BVC RESET message to the SGSN after the NSE starts working. The message informs the
SGSN of the NSE configurations on the BSC. The SGSN returns the BSC BVC RESET ACK message
to inform the BSC that the reset is normal. Then the BSC sets the NSE status to normal. If the BSC
does not receive the BSC BVC RESET ACK message from the SGSN, the BSC sets the NSE status
to faulty.
The procedure for troubleshooting an NSE fault is as follows:
Step 1: When all NSVCs/NSVLs of the NES are faulty, the NSE fails. Therefore, when an NSE fault occurs, check the
NSVCs/NSVLs. If the NSVCs/NSVLs are faulty, rectify the fault according to the NSVC/NSVL fault troubleshooting
procedure.
Step 2: On the SGSN maintenance console, check whether a board fault or overloading alarm exists on the SGSN. If
the board is faulty or overloaded, the BSC BVC RESET ACK message cannot be sent to the BSC.
Step 3: On the BSC, trace the SIG message on the Gb interface. Run the MML command RST SIGBVC to reset the
SIGBVC. If only the BVC RESET message is received and the BVC RESET ACK message is unavailable, ask the
SGSN maintenance engineer to rectify the fault. If the BVC RESET ACK message is available, feed back the message
to Huawei support engineer. (Note: After the SIGBVC is reset, the NSE may recover. If the NES recovers, you can
locate the faulty NE through only BSC logs.)

Page 65
Gb Interface Resource Fault Case Analysis
Case 1
Symptom
An interruption occurs on the Gb interface of office A. An ALM-21385 alarm is generated, indicating that a
Gb interface bearer channel fault occurs.
Cause Analysis
The transmission is abnormal, causing the BC fault.
(1) Check operation logs. No operations are implemented on site when the fault occurs. Based on
experience, such a fault is generally caused by transmission failures.
(2) Check the alarms on the BSC and SGSN. No board fault alarm is detected.
(3) Check the configurations. The BSC and SGSN configurations are identical. Therefore, it can be
determined that the transmission is faulty.
(4) Instruct the onsite engineer to check the transmission. A transmission device fails.

Page 66
Case 2
Symptom
Four NSVC links are configured on the BSC in office A. The BC status is normal, but the status of the
NSVC marked as B is abnormal.
Cause Analysis
The BSC initiates the NSVC reset procedure, but the SGSN does not respond. As a result, the NSVC is
abnormal.
(1) Query the operation and alarm logs of the fault occurrence time. No operations are implemented on
site, and no transmission or board fault alarm is generated.
(2) Check BSC and SGSN configuration data. The NSVC identifier, NSE identifier, and data link
connection identifier configurations of the BSC are identical with those of the SGSN.
(3) Check the DIP switch setting of the board. The value is 75 ohm, which is identical with the actual
physical transmission.
(4) Trace the NS-layer signaling on the SGSN. The SGSN receives the Alive PDU message but does not
send the Alive PDU ACK message. Ask the SGSN maintenance engineer to locate the fault and it is
determined that the SGSN is faulty.

Page 67
Case 3
Symptom
After product upgrade, an NSVL fault occurs in office A.
Cause Analysis
A router configuration fault is detected. The fault is rectified after the configuration is modified.
(1) On the BSC maintenance console, run the MML command DSP ETHPORT to check link status. The
link is available.
(2) Check on the BSC maintenance console. No alarm of the Gb interface board fault is detected.
(3) Check on the SGSN maintenance console. No interface board fault alarm or overloading alarm is
detected.
(4) On the BSC maintenance console, run the MML command PING IP to ping the remote NSVL. The
remote NSVL cannot be pinged trough.
(5) Instruct the transmission engineer to check router configurations. A configuration fault is detected.
After the configuration is modified, the fault is rectified.

Page 68
Case 4
Symptom
An NSE fault occurs in office A.
Cause Analysis
An internal fault occurs on the SGSN. As a result, the SGSN cannot respond to the BVC RESET message
sent from the BSC.
(1) Check BSC alarm logs. No NSVL fault alarm is generated.
(2) Check the SGSN. No board fault alarm or overloading alarm is detected.
(3) Trace the signaling of the BSC and SGCN. The SGSN receives the BVC RESET message but does
not send the BSC BVC RESET ACK message.
(4) Instruct the SGSN maintenance engineer to check the SGSN. An SGSN internal fault is detected.

Page 69
References
GPRS protocols

UMTS Troubleshooting PS Problems 201111

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

UMTS Troubleshooting PS Problems 201111

Încărcat de

Drepturi de autor:

Formate disponibile

HUAWEI TECHNOLOGIES CO., LTD.

S-ar putea să vă placă și