Troubleshooting Guide To HSPA

RAN10 Troubleshooting Guide to HSPA Throughput Problems INTERNAL
Doc. Code Product Name WCDMA-RAN-
Usage For internal use Product Version RAN10

WCDMA UMTS
Prepared By Document Version RAN10
Maintenance Department
RAN10 Troubleshooting Guide to HSPA

Throughput Problems
Huawei Technologies Co., Ltd.
Transmission Group of UMTS

Prepared By Date 2009-03-09
Maintenance Department
Reviewed By Date
Reviewed By Date
Approved By Date 2009-03-09
2016-03-24 Huawei Confidential Page 1 of 61

Revision Record
Date Version Description Author
2008-11-31 1.0 The initial draft was complete. Zhang Xu, Jiang Guiping
2009-02-05 1.1 The process for identifying problems was Zhang Xu

optimized according to the review
comments.
2009-02-26 1.2 The idea of identifying problems was Xia Cuichun
optimized based on case study.
2009-03-09 1.3 Description errors were corrected based on Xia Cuichun
the document test and review comments
2016-03-24 Huawei Confidential Page ii of 61

Contents
1 Troubleshooting Process for HSPA Throughput Problems ................................................. 7

2 HSDPA Throughput Problems .................................................................................................. 9
2.1 Low or Fluctuating HSDPA Throughput ........................................................................................................ 10
2.1.1 Symptom ............................................................................................................................................... 10
2.1.2 Troubleshooting Procedures .................................................................................................................. 12
2.1.3 Information Collection List ................................................................................................................... 31
2.2 Zero HSDPA Throughput ............................................................................................................................... 31
2.2.1 Symptom ............................................................................................................................................... 31
3 HSUPA Throughput Problems ................................................................................................. 39

3.1 Low or Fluctuating HSUPA Throughput ........................................................................................................ 40
3.1.1 Symptom ............................................................................................................................................... 40
3.2 Failure to Establish the HSUPA Service ......................................................................................................... 51
3.2.1 Symptom ............................................................................................................................................... 51
3.3 Failure to Establish an HSUPA 5.76 Mbit/s Service ...................................................................................... 56
3.3.1 Symptom ............................................................................................................................................... 56

Figures
Figure 1-1 Troubleshooting process for HSPA throughput problems .................................................................... 7
Figure 2-1 Stable HSDPA throughput close to the theoretical value ................................................................... 10
Figure 2-2 Stable HSDPA throughput below the theoretical value ...................................................................... 11
Figure 2-3 HSDPA throughput that fluctuates regularly...................................................................................... 11
Figure 2-4 HSDPA throughput that fluctuates irregularly ................................................................................... 12
Figure 2-5 NEs involved in and major sections of HSDPA data transmission .................................................... 12
Figure 2-6 Service type and maximum uplink/downlink bit rate in the RAB assignment message .................... 14
Figure 2-7 UE capability reported in the RRC_CONNECT_SETUP_CMP message ......................................... 15
Figure 2-8 CQI reported by the UE and traced by the Probe .............................................................................. 17
Figure 2-9 HS-PDSCH code resources configured on the RNC ......................................................................... 18
Figure 2-10 License regarding HS-PDSCH code resource and 16QAM configured on the Node B .................. 18
Figure 2-11 Number of users in the cell traced on the RNC LMT ...................................................................... 19
Figure 2-12 Use of code tree in the cell traced on the RNC LMT....................................................................... 20
Figure 2-13 Downlink transmit power of the TRX in a cell traced on the RNC LMT ........................................ 21
Figure 2-14 Available power for HSPA configured on the RNC LMT................................................................ 21
Figure 2-15 Information about the RLC BO and allocated bandwidth for flow control viewed from the CDT file
by using the tracing review tool ........................................................................................................................... 22
Figure 2-16 Actively sending packets to a UE by using the RNC CDT .............................................................. 25
Figure 2-17 Allocated bandwidth for HSDPA IUB flow control and the RLC throughput obtained by using the
UMAT tool ........................................................................................................................................................... 26
Figure 2-18 HSDPA flow control algorithm selected on the Node B LMT ......................................................... 28
Figure 2-19 Allocated bandwidth for HSDPA IUB flow control and the data spending throughput at the RLC
layer (do not match) obtained by using the UMAT tool ....................................................................................... 29
Figure 2-20 UMAT tool used to obtain the times for which the RLC sending window on the RNC is full ........ 30
Figure 2-21 Curve of changes in the times for which the RLC sending window on the RNC is full .................. 30
Figure 2-22 Zero HSDPA throughput .................................................................................................................. 32
Figure 2-23 Normal signaling process for PDP activation .................................................................................. 33

Figure 2-24 Obtaining the number of SDUs received by the RLC layer by using the UMAT tool ..................... 34

Figure 2-25 Trend of changes in the number of SDUs received by the RLC layer ............................................. 35
Figure 2-26 Statistics on downlink FP packets that are sent from the RNC and are obtained from the CDT by
using the UMAT tool ............................................................................................................................................ 36
Figure 2-27 Information about allocated bandwidth for flow control in the messages displayed by the RNC
CDT...................................................................................................................................................................... 37
Figure 3-1 HSUPA data transmission rate that is stable but lower than the theoretical value ............................. 40
Figure 3-2 Low and fluctuating HSUPA data transmission rate .......................................................................... 41
Figure 3-3 NEs involved in and major sections of HSUPA data transmission .................................................... 42
Figure 3-4 Enabling the function of tracing the transmit power of the UE on the RNC LMT ............................ 43
Figure 3-5 Enabling the function of tracing RTWP of a cell on the RNC LMT .................................................. 44
Figure 3-6 RTWP information about a cell traced in real time ............................................................................ 44
Figure 3-7 Parameter setting of background noise queried on the RNC LMT .................................................... 45
Figure 3-8 RTWP of a zero-loaded cell observed on the RNC LMT .................................................................. 45
Figure 3-9 Check result of the LST LR command executed on the Node B LMT .............................................. 47
Figure 3-10 Number of licensed CEs as queried on the Node B LMT ................................................................ 48
Figure 3-11 Number of current CEs used by a cell as queried on the Node B LMT ........................................... 49
Figure 3-12 Enabling the function of tracing uplink throughput and bandwidth on the RNC LMT ................... 50
Figure 3-13 Bearer type in the RRC_RB_SETUP message ................................................................................ 51
Figure 3-14 RRC CONNECTION SETUP REQ message .................................................................................. 52
Figure 3-15 HSUPA status of the cell checked on the RNC LMT ...................................................................... 52
Figure 3-16 MBR information in the RAB ASSIGNMENT REQ message ........................................................ 53
Figure 3-17 Query result of the LST FRCCHLTYPEPARA command ............................................................... 54

Figure 3-18 Admission process for the RAN 10 ................................................................................................. 55
Figure 3-19 Limited uplink CE resources indicated by the messages displayed by the RNC CDT .................... 55
Figure 3-20 E-DCH bearer used without supporting the rate of 5.76 Mbit/s ...................................................... 56
Figure 3-21 E-DCH bearer with support for the rate of 5.76 Mbit/s ................................................................... 57
Figure 3-22 HSUPA capability level of a UE indicated in the RRC_CONNECT_REQ_CMP message ............ 57
Figure 3-23 Control items related to the HSUPA 5.76 Mbit/s service in the RNC license .................................. 58
Figure 3-24 Control item related to the HSUPA 5.76 Mbit/s service in the license on the Node B .................... 59
Figure 3-25 Query result of the LST FRCCHLTYPEPARA command executed on the RNC LMT .................. 60
Figure 3-26 Query result of the LST CORRMALGOSWITCH command executed on the RNC LMT ............. 60
Figure 3-27 Query result of the LST FRC command executed on the RNC LMT .............................................. 61

Tables
Table 2-1 Capabilities of HSDPA UEs ................................................................................................................ 15
Table 2-2 Minimum CQI values corresponding to the theoretical throughputs of various HSDPA UEs ............. 16
Table 2-3 HSDPA flow control algorithms supported by the Node B in the version RAN 10 ............................ 27
Table 3-1 Rules on used uplink CEs for different rates (SF) ............................................................................... 48

Troubleshooting Guide to Data Transmission Problems Regarding HSPA INTERNAL
1 Troubleshooting Process for HSPA

Throughput Problems
This chapter describes the detailed process for collecting information required for identifying
high-speed packet access (HSPA) throughput problems and for handling the problems.
Figure 1-1 Troubleshooting process for HSPA throughput problems

This document is intended for readers who:

1. Are familiar with the basic principles of WCDMA/HSPA.
2. Know the signaling process for establishing the WCDMA packet switching (PS) service.
3. Know how to query configuration and trace logs on the RNC LMT.
4. Can analyze CDT files on the RNC by using the UMAT tool.
5. Know the basic mechanism of data transmission regarding TCP and RLC.

2 HSDPA Throughput Problems
This chapter mainly describes how to handle two types of HSDPA throughput problems. This
chapter is guidance for on-site engineers in preliminarily analyzing problems and collecting
required information for identifying the problems.
 One problem is that the download throughput is low or fluctuates. The history
maintenance data shows that this problem occurs frequently and widely. The following
factors contribute to this problem:
− Unstable transmission quality. The symptom is loss of packets, delay jitter, or
duplicate packets on the IU or IUB interface.
− Poor or fluctuating quality of wireless signals on the air interface. The symptom is
that the UE reports a low channel quality indicator (CQI) that does not meet the test
requirement.
− Limited radio resources. The symptom is that the downlink power, transmission
resources on the IU/IUB interface, or downlink code resources are limited.
− Improper parameter settings. The parameter settings on the radio access network
(RAN) or core network (CN) side cannot meet the test requirement.
− Mismatch of or a performance defect in the user equipment (UE) driver. The
symptom is that the UE does not act according to the protocol.
− Abnormal performance of the computer that is used for the test. The symptom is a
high load on the CPU.
− Performance defect or restriction of the FTP server, including the software on the
server, that is used for the test.
− Version defect of the product or restriction of the board capability in the early period.
− Mutual influence caused by data transmission that is performed by other users
simultaneously.
 The other problem is that the download throughput is zero.
This problem seldom occurs and is caused by an improper operation during the test, data
limitation at the source end (the user plane fails because the server is abnormal),
incorrect parameter settings, or improper UE driver.
This chapter describes the symptom of each problem so that the on-site engineers can judge
the problems they encounter, check the problems, and collect required information. Then this
chapter provides the idea of analyzing the problem and the detailed process for checking and
handling the problem. Finally, this chapter lists all the information required for analyzing the
problem. The document annexed to this Troubleshooting Guide provides the general tools
required for analyzing HSDPA throughput problems and the user guide to these tools.

 This chapter focuses on the idea of analyzing HSDPA throughput problems. The throughput indexes
of the mainstream UEs of HSDPA category 8 are provided for reference.
 The normal throughput is close to the theoretical value and keeps stable. The low throughput
mentioned in this document indicates that the throughput does not reach the maximum theoretical
throughput supported by the device capability or configured resources.
 To identify problems related to product defects, you may require additional information that is not
completely covered in the information collection guide provided in this document.
2.1 Low or Fluctuating HSDPA Throughput

2.1.1 Symptom
After the HSDPA bearer is established successfully, the FTP download throughput does not
reach the expected requirement (stable throughput) or does not keep stable at a level close to
the maximum theoretical value (fluctuating throughput). This problem has four symptoms.
Symptom 1: The HSDPA throughput is close to the theoretical value and keeps stable, as
shown in Figure 2-1.When testing a specified position of a commercial network, you can infer
that the HSDPA throughput is normal if the throughput keeps stable above 6.3 Mbit/s. During
a demonstration or competitive test, the HSDPA throughput should be stable at 6.5 Mbit/s in
the case of a single thread and 7.0 Mbit/s in the case of multiple threads. The algorithm and
parameters should be adjusted to meet the requirement for the ultimate throughput. This is not
covered in this document.
Figure 2-1 Stable HSDPA throughput close to the theoretical value
Symptom 2: The HSDPA throughput is low and relatively stable, as shown in Figure 2-2 .The
cause is limitation on the throughput that the user subscribes to, incorrect throughput
limitation through the AT command, or limitation on the radio resources (codes, power, or
transmission resources).

Figure 2-2 Stable HSDPA throughput below the theoretical value
Symptom 3: The HSDPA throughput fluctuates regularly. That is, the HSDPA throughput
rises or drops in a stepwise way, or fluctuates in a square-wave way and occasionally reaches
the theoretical value during the fluctuation, as shown in Figure 2-3.The cause is that the
parameter settings or algorithm characteristics do not match in certain environments.
Figure 2-3 HSDPA throughput that fluctuates regularly
Symptom 4: The HSDPA throughput fluctuates irregularly. Such fluctuation often occurs.
The HSDPA throughput occasionally reaches the theoretical value but fluctuates sharply, as
shown in Figure 2-4.This problem has many causes, and you need to check the FTP server
and the UE in the end-to-end manner.

Figure 2-4 HSDPA throughput that fluctuates irregularly
2.1.2 Troubleshooting Procedures

Before analyzing a problem, you need to know all the NEs involved in HSDPA data
transmission and the matters worthy of attention in an overall perspective.
Figure 2-5 NEs involved in and major sections of HSDPA data transmission
The process for data transmission over FTP is as follows:

1. The laptop originates a request for establishing a dialup connection. The signaling
process is complete, and the service bearer and PDP context are successfully established.
2. The FTP client software on the laptop originates the TCP connection process (the data
packet is processed in the same way as the control signaling) and the packet reaches the
UE.
3. The UE NAS layer sends the packet to the RLC and MAC layers, and then to the Node B
through the physical layer.
4. The Node B encapsulates the MAC PDU in an FP frame and sends the FP frame to the
RNC through the IUB transmission equipment.

5. The RNC decapsulates the FP frame, transmits the packet to the upper layer, and sends
an acknowledgement packet to the peer end at the RLC layer. In addition, the RNC sends
the packet to the CN through GTP-U.
6. The CN sends the data to application (FTP) server. In this way, the packet from the UE
reaches the FTP server.
7. The FTP server sends a downlink packet to the CN through the TCP sending window.
The packet is sent to the RNC and stored in the RLC buffer.
8. The Node B allocates a certain bandwidth to the RNC for flow control based on the
channel quality indicator (CQI) on the air interface, size of the RLC buffer occupancy
(BO), user priority by using the HSDPA flow control algorithm. An initial bandwidth is
allocated when the service is established.
9. The RNC sends the data in the RLC BO to the RLC sending window (the UE is also
required to send an acknowledgement packet at the RLC layer) and transfers the data to
the lower layer based on the allocated bandwidth. The data is sent to the Node B in the
form of downlink FP frames.
10. The Node B provides the hybrid automatic repeat request (HARQ) function and sends
the data to the UE through the downlink data layer.
11. The UE receives the MAC-HS PDU, decapsulates the PDU, and sends the data to the
upper layer. Finally, the UE sends the data to the laptop (application) through USB/PPP.
Downlink data transmission is complete.
This document describes the complete process for identifying a problem, and focuses on the
idea of analyzing data transmission problems and the relationship between factors. Therefore,
this document is intended for engineers who are inexperienced in identifying HSPA problems.
This arrangement may be irrational for experienced engineers. You can skip certain steps as
required and confirm or identify the abnormal points directly from the core step, for example,
step 4. In this way, problems can be identified quickly.
Before analyzing a problem, you need to check the RNC or Node B for relevant alarms on the site. In
this way, you can identify the problem quickly.
Step 1 Check the signaling process (mandatory).

When identifying problems, you often find that the subscription information about a USIM
card is improper (the maximum bit rate in the subscription information is small), the CN
limits the throughput, an AT command is used during the dialup to limit the throughput, or the
UE capability is not supported. These factors may limit the maximum throughput available to
a user and can often be found in the signaling process. Therefore, when the HSDPA
throughput is low and stable, you need to check whether the signaling process is normal
during the service establishment. If the HSDPA throughput fluctuates but can reach the
theoretical value, you know that the user throughput is not limited in any section and can skip
this step.
You need to view the MaxBitRate cell in the RANAP_RAB_ASSIGNMENT_REQ message
to check whether the maximum uplink and downlink bit rates assigned by the CN meet the
test requirement.

Figure 2-6 Service type and maximum uplink/downlink bit rate in the RAB assignment message
If the maximum bit rates assigned by the CN are smaller than the theoretical value, the on-site
engineer needs to check the following items:
 Whether an AT command is executed on the laptop to limit the throughput
 Subscription information about the tested USIM card on the HLR
 Maximum throughput allowed by the CN (SGSN/GGSN)
If the maximum bit rates assigned by the CN are the theoretical ones, you need to view the
hsdsch-physical-layer-category cell (identifies the UE capability) in the
RRC_CONNECT_SETUP_CMP message that the UE sends to the network during the service
establishment to check whether the UE capability meets the test requirement.

Figure 2-7 UE capability reported in the RRC_CONNECT_SETUP_CMP message
The information in Figure 2-7 indicates that the UE is of HSDPA category 7 and supports a
throughput of 7.2 Mbit/s. Table 2-1 lists other UE types and the relevant capabilities at the
physical layer.
Table 2-1 Capabilities of HSDPA UEs
UE Type Supported Largest TB Supported Highest Rate at the

Physical Layer (Mbit/s)
11, 12 3630 1.8

1–6 7298 3.6
7, 8 14411 7.2
9 20251 10
10 27952 14.4
If the sdsch-physical-layer-category reported by the UE does not meet the theoretical

throughput, it is recommended that you use another UE with high capability instead for the
test.
If the UE capability meets the theoretical throughput but the HSDPA throughput is close to
384 kbit/s, the cause is that the service is carried by DCH because the HSDPA service in the
cell is not activated or is in abnormal state. In this case, check whether the cell is activated
and available. Otherwise, proceed with step 2 below.
Step 2 Check the quality on the air interface (mandatory).

In this step, check the downlink quality on the air interface. The uplink quality on the air
interface is checked in step 5 and step 6.
HSDPA introduces the HS-DSCH in the downlink direction and uses the link adaptation
mechanism instead of the power control mechanism. That is, the UE measures the quality in
the common pilot channel and reports the CQI to the Node B. The Node B schedules the size
of the TB that can be transmitted in the current transmission time interval (TTI) based on the
reported CQI and other resource conditions. The reported CQI value determines the maximum
rate on the air interface available to the UE.
If the CQI reported by the UE is smaller than the target value and fluctuates, the throughput
on the HSDPA air interface must fluctuate. Therefore, you need to check whether the reported
CQI keeps stable at a level above the theoretical throughput. Table 2-2 lists the required
minimum CQI values for different theoretical throughput values. For a UE of category 8, if
the throughput at the physical layer reaches 7.2 Mbit/s, the CQI reported by the UE must
reach 25.
Table 2-2 Minimum CQI values corresponding to the theoretical throughputs of various HSDPA
UEs
HSDPA UE Supported Number of Required Minimum
Category Throughput at Required CQI for the Peak
the Physical HS-PDSCH Codes Throughput
Layer
Cat12 1.8 Mbit/s 5 18

Cat6 3.6 Mbit/s 5 22
Cat8 7.2 Mbit/s 10 25
Cat10 14.4 Mbit/s 15 26
You can trace changes in the CQI reported by the UE during the HSDPA data transmission
through the Probe or the server tracing software provided by the UE. Quality information
about the wireless air interface can be directly obtained from the HSDPA link
statistics. Figure 2-8 shows that the CQI reported by the current UE is 27 and meets the
requirement mentioned above.

Figure 2-8 CQI reported by the UE and traced by the Probe
 If the CQI reported by the UE during the HSDPA data transmission is smaller than the
target value and fluctuates, ask the on-site network planning engineer to optimize the
wireless environment or use another tested line. During the optimization, the on-site
network planning engineer should check whether the loss on the downlink path is too
large due to the unstable connection to a device, whether strong co-channel interference
occurs, and whether the downlink load is already high.
 If the CQI meets the requirement mentioned above but the HSDPA throughput does not
meet the requirement, proceed with the next step.
The CQI is obtained by measuring the Ec/N0 in the downlink common pilot channel. If the log on the
UE cannot be obtained, the signal-to-noise ratio and received signal code power of the cell in the
connection performance monitoring on the RNC LMT can be used for reference. CQI=Ec/N0*K + MPO
Step 3 Check radio resources (mandatory).

This step is performed for two purposes. One purpose is to check whether the configuration of
all resources (including OVSF, power, and IUB transmission equipment) meets the test
requirement. The other purpose is to consider whether other users of a high priority contend
for resources during the test. The second purpose applies to a commercial network and is
worthy of your attention during the acceptance test of the commercial network.
1. OVSF resource
Check the sufficiency of the configured OVSF resource against Table 2-2 provided in
step 2. For an UE of category 8, the theoretical throughput requires 10 HS-PDSCH codes.
If the RNC is configured with dynamic code allocation for HSDPA, the maximum
number of codes must be greater than or equal to 10. This constraint is not required if the
dynamic code function is also enabled on the Node B. In addition, the number of
licensed codes configured on the Node B must be greater than 10 because the code
resource license configured on the Node B is shared on the entire base station and the
licensed code resource may be used by other cells.
Directly run the LST CELLHSDPA command on the RNC LMT to check the
configured number of HS-PDSCH codes, as shown in Figure 2-9.

Figure 2-9 HS-PDSCH code resources configured on the RNC
Figure 2-10 shows the license on the Node B that is queried on the Node B LMT or M2000
Figure 2-10 License regarding HS-PDSCH code resource and 16QAM configured on the Node B
Both the HSDPA 16QAM function and the dynamic code function for HS-PDSCH are covered in the
license item HSDPA RRM Packe1.

For a commercial network, you cannot know whether other DCH users contend for the code
resource during the test. Therefore, you need to trace and observe the number of users in the
cell and the use of code tree in the cell simultaneously, as shown in Figure 2-11 and Figure
2-12.
Figure 2-11 Number of users in the cell traced on the RNC LMT

Figure 2-12 Use of code tree in the cell traced on the RNC LMT
In addition to the code resource, both the 16QAM modulation mode and the license
configuration must be enabled to support high throughput. For a UE of category 8, if the
reported CQI is greater than 25 and other resources are not limited but the sent CQI is only 24
in QPSK mode, the 16QAM or license is not enabled. In this case, you can check the setting
of the 16QAM enabling status on the Node B. By default, 16QAM is enabled.
SET MACHSPARA: 16QAMSW=OPEN;
2. Transmission resource
Check whether the physical bandwidth (the number of E1s) meets the test requirement
based on the actual throughput. In addition, check whether the parameter settings comply
with the transmission configuration specifications for the version. The items to be
checked are as follows:
− Whether the configured physical bandwidth is enough (AAL2 path or IP path).
− Whether the intermediate IUB transmission equipment is bottlenecked. If the
condition permits, you can directly connect the RNC to the Node B for a comparative
test.
− Whether the HSDPA path configuration complies with the specifications. Improper
configuration may cause limited throughput or loss of packets. For example, the SRC
configured on the RNC is far smaller than the RCR configured on the Node B.
In this section, you only need to check the configuration of and specification for
transmission resource. To check the transmission quality, see the subsequent steps.
3. Power resource
During the test, check whether the downlink transmit power of the TRX in the cell is
limited, as shown in Figure 2-13.

Figure 2-13 Downlink transmit power of the TRX in a cell traced on the RNC LMT
If the downlink transmit power of the TRX in a cell often exceeds 90%, you can infer that the
power is limited. Normally, the product configuration baseline can meet the test requirement
for HSPA data transmission of a single user (7.2 Mbit/s). Therefore, you need to check
whether the power-related parameters are set according to the baseline. It is recommended
that the offset of the total HSDPA power in comparison with the maximum transmit power of
the cell be 0. That is, HSDPA can use the maximum transmit power of the cell, as shown
in Figure 2-14. The power in the common pilot channel is 33 dBm, and the MPO constant is
2.5)
Figure 2-14 Available power for HSPA configured on the RNC LMT
If the items mentioned above are normal, the radio resources are not limited and limitation is
imposed in other aspects. In this case, you need to proceed with step 4 to check the RLC BO
and check whether the cause is insufficient data sources at the level above the RNC (RNC,
CN and server) or an abnormal channel (IUB, air interface, UE, or test computer) at a level
below the RNC.
Step 4 Check the RLC BO (mandatory).
If no fault occurs on any upper-level NE above the RNC, TCP continuously sends data to the
RNC through the GGSN/SGSN before the sending window on the FTP server is congested. In

this case, the RLC BO is large. Therefore, you can check whether a fault occurs at the upper
level above RNC by checking the RLC BO on the RNC.
You can directly use the tracing review tool on the RNC to open the CDT file and view the
RLC BO information in the displayed messages (with periodic reporting of L2 data), as
shown in Figure 2-15. For how to use the RNC CDT, see the document attached. The
displayed messages also indicate the information about allocated bandwidth for HSDPA flow
control. Checking this item is described later.
Figure 2-15 Information about the RLC BO and allocated bandwidth for flow control viewed
from the CDT file by using the tracing review tool
After the RLC BO curve is obtained during the HSDPA data transmission, you need to
analyze the curve. As shown in Figure 2-15, the RLC BO keeps large, which indicates that the
RNC receives sufficient data from the SGSN. This is the condition for high-speed data
transmission in the downlink direction and indicates that no fault occurs at the upper-level
above the RNC.
Two states of the RLC BO are analyzed in the subsequent two steps.
 If the RLC BO drops to zero, proceed with step 5.
 If the RLC BO does not drop to zero, proceed with step 6.
Step 5 Check the RLC BO in zero state (condition).

If the RLC BO frequently drops to zero during the HSDPA data transmission, no data in the
RLC buffer is sent to the MAC layer, which must result in fluctuation of the downlink
throughput. During the high-speed data transmission, the RLC BO in zero state is a serious
problem. This section analyzes the possible causes of the RLC BO in zero state. If the RLC
BO is not zero but the download throughput is abnormal, see the analysis in step 6.

If the RLC BO frequently drops to zero, the possible causes are as follows:
 Loss of packets occurs on an upper-level NE above the RNC or on the intermediate
transmission equipment. When a single thread is used to download data, the amount of
data in the RLC buffer may be insufficient.
 The round trip time (RTT) is large or fluctuates. In this case, the uplink
acknowledgement packet from the UE cannot reach the FTP server in time. As a result,
the TCP sending window on the server is congested and data cannot be sent to the RNC
in time.
 The uplink radio quality on the air interface is poor. In this case, the uplink
acknowledgement packet (used to acknowledge the downlink TCP packet) from the UE
cannot be received by the FTP server in time. As a result, the TCP sending window on
the server is congested and data cannot be sent to the RNC in time.
 Limitation is imposed on an upper-level NE above the RNC or on the FTP server.
Unstable performance of the FTP server or throughput limitation on the SGSN/GGSN
can also cause insufficient data in the RLC buffer.
Now, you need to check the possible causes mentioned above to identify the actual cause of
the RLC BO in zero state. Note that the possible causes may affect each other. That is, you
cannot identify the problem based on the check result of an item and need to depend on the
check results of different items.
Check item 1: great value or fluctuation of the RTT, and loss of a small number of packets
You can download data by using multiple threads for a comparative test. Multiple threads can
overcome congestion of the TCP sending window that results from the loss of a small number
of packets or from a great value or fluctuation of the RTT. An increase in the number of
threads makes it less probable that the TCP sending windows of all the threads are congested
simultaneously, except in the case of serious loss of packets. You can skip this section if
multiple threads are used to download data during the on-site test.
It is recommended that the FlashGet software (with 10 threads) be used to download two large
files.
If the RLC BO does not drop to zero, and the throughput is stable and can reach the target
value during the multi-thread download, you can infer that the cause is long RTT or loss of a
small number of packets. If the test result of the multi-thread download can meet the on-site
requirement, you can end the effort that is intended to identify the problem. You are not forced
to download data by using a single thread.
If the multi-thread download does not produce a good result and the RLC BO still drops to
zero, check the following item.
Check item 2: poor uplink quality on the air interface
The default value of uplink R99 384K BLER configured on the RNC is 1%. RLC
retransmission must occur due to bit errors on the air interface. The delay of the uplink
acknowledgement packet required by the high-speed download service possibly is not
satisfied. It is recommended that you use the following two methods to perform a comparative
test.
Method 1: Uplink data carried by the E-DCH (HSUPA) channel
HSUPA adopts the HARQ mechanism at the physical layer. This mechanism greatly reduces
RLC retransmissions caused by poor quality on the air interface. In addition, a short
transmission time interval (TTI) can further reduce the RTT and overcome the adverse impact
caused by the delay jitter.

If the download throughput is stable and normal after data is carried by E-DCH, a small
number of retransmissions occur on the air interface. In consideration that uplink bit errors on
the air interface cannot be prevented when the DCH bearer is used, it is recommended that
E-DCH be used instead of DCH in the test.
Method 2: invariable outer loop power control (OLPC) in the uplink direction
In certain cases, HSUPA cannot be used for a comparative test and it is recommended that the
invariable OLPC be used to prevent uplink bit errors. Take the 384 kbit/s interactive service
for example. Perform the following operation:
Find the typical service index of the service (see the MML command ADD TYPRABBASIC).
In this example, the service index is 48. Then run the following MML command to set the
uplink signal-to-interference ratio (SIR) in the OLPC to 10 dB:
MOD TYPRABOLPC: RabIndex=48, SubflowIndex=0, TrchType=TRCH_DCH,
DelayClass=1, InitSirtarget=182, MaxSirtarget=182, MinSirtarget=182;
If the download throughput becomes normal after the uplink OLPC is set to an invariable
value, you can infer that the RLC BO in zero state is caused by bit errors on the air interface
and this symptom is normal. It is recommended that method 1 or 2 be used in the test.
Otherwise, the on-site engineer needs to optimize the uplink wireless environment. For the
purpose of optimization, the engineer can check whether unstable connection to a device
causes poor quality of uplink signals and whether strong uplink interference occurs.
If the RLC BO still drops to zero after the two methods are used, check the next item.
MOD TYPRABOLPC is an internal MML command and the script can be executed on the LMT only.
Check item 3: limitation on an upper-level NE above the RNC or on the FTP server.
It is recommended that packets be actively sent to perform a comparative test and ensure that
sufficient data in the RLC buffer can be sent. It is recommended that the TESTPING tool be
used to actively send packets. For the operation guide to this tool, see the document annexed
to this Troubleshooting Guide. The precondition is that actively sending packets on the FTP
server is permitted in the on-site test environment.
By checking the preceding two check items, you can infer that the cause is not the loss of a
small number of packets, poor uplink quality on the air interface, or the RTT fluctuation.
Therefore, whether the RLC BO still drops to zero after packets are actively sent by using the
TESTPING tool, you need to check whether any upper-level NE above the RNC is abnormal.
If the RLC BO does not drop to zero, actively sending packets solves the problem. If the RLC
BO still drops to zero, actively sending packets does not solve the problem. It is
recommended that the FTP server be checked or replaced on the site. In this case, ask a CN
engineer to capture and analyze packets on the SGSN/GGSN and intermediate transmission
equipment and to exclude faults at the upper level.
You must prevent the RLC BO from dropping to zero before the throughput is recovered. If
the problem cannot be completely solved for any objective reason, you can use the tool of
actively sending packets provided by the CDT to meet the test requirement. In this case, you
can know whether the RAN works properly. The RAN10 C01B061 allows packets to be
actively sent to UE in the LMT CDT, as shown in Figure 2-16. Select CDT on the navigation
tree. In the dialog box that is displayed, click the “Other” tab, select the
“AUTO_PACKET_GENERATE” check box and set the parameters. Packets are actively sent
at the L2 throughput of (1472+28)*8/(0.1*10)ms = 12 Mbit/s.

Figure 2-16 Actively sending packets to a UE by using the RNC CDT
Step 6 Check the RLC BO in non-zero state (condition).

If the check result in step 4 shows that the RLC BO does not drop to zero after the data
transmission begins, you can infer that sufficient data in the RLC buffer is sent to the MAC
layer and a fault occurs on the RNC or a lower-level device.
The basic principles of HSDPA are as follows: The Node B allocates a certain flow to the
RNC and the flow is the total number of PDUs that the RNC can send in a period of time. The
RNC sends data in the RLC buffer in the form of FP packets to the Node B according to the
protocol. Note that when data is sent at the RLC layer, acknowledgement packets are required.
Therefore, the sending window may also be congested due to loss of packets or delay.
If the RLC BO does not drop to zero but the throughput still fluctuates, the possible causes are
as follows:
 Loss of packets on the intermediate IUB transmission media or device causes fluctuation
of the bandwidth that is allocated by the Node B for flow control.
 The air interface shows poor downlink quality and the CQI reported by the UE cannot
meet the requirement. This item is checked in step 2 above.
 The radio resources (codes and power) and transmission resources are limited. This item
is checked in step 3 above.
 The laptop shows poor performance and cannot process data on the user plane in time.
One symptom is that the CPU usage is high.
 An improper UE driver is installed. It is recommended that the correct UE driver be
installed for a comparative test.
According to the experience, the first four items are likely to cause a fault in HSDPA data
transmission. Especially, loss of packets is highly likely to occur on the IUB interface and is
worthy of your attention.

When the IUB transmission resources are sufficient and the air interface shows good
downlink quality, the Node B allocates a sufficient bandwidth to the RNC. Therefore, you
need to check whether the data sending throughput at the RLC layer matches the allocated
bandwidth for IUB flow control.
Check result 1: Data sending throughput at the RLC layer matches the allocated bandwidth
for IUB flow control.
You can easily obtain the RLC BO curve, curve of allocated bandwidth for HSDPA IUB flow
control, and curve of data sending throughput at the RLC layer. As shown in Figure 2-17, the
allocated bandwidth for IUB flow control matches the data sending throughput at the RLC
layer. This indicates that the IUB bandwidth limits the data sending throughput at the RLC
layer and finally affects the data throughput at the TCP layer. You can infer that the fault
occurs on the IUB interface.
Figure 2-17 Allocated bandwidth for HSDPA IUB flow control and the RLC throughput obtained
by using the UMAT tool
In steps 2 and 3 above, you have excluded the causes related to quality on the air interface and
the transmission configuration. In this step, it is suspected that the abnormal transmission
quality on the IUB interface causes bandwidth adjustment for dynamic flow control, which is
known as adaptive flow control in a version earlier than RAN10. The basic principle of
bandwidth adjustment for adaptive flow control is as follows: If the Node B finds that the
ratio of loss of FP packets on the IUB interface exceeds the threshold (the baseline is 5%) in a
flow control period, the Node B adjusts the available HSDPA bandwidth to a small value.
Otherwise, the Node B adjusts the available HSDPA bandwidth to a large value. The basic
principle is based on the assumption that loss of a large number of packets is caused by traffic
congestion and that packet loss ratio caused by a damage of the transmission network does not
exceed the threshold. Otherwise, even traffic is not congested, the available bandwidth may
be continuously adjusted to a small value and finally the throughput on the UE fluctuates or
decreases sharply. The process is similar in the case of delay jitter and is not repeated here.
You can prove or determine loss of packets or delay jitter on the IUB interface by using the
following three methods:
1. Mirroring and packet capture

2. Internal statistics on packet loss

3. Static HSDPA flow control (known as simple flow control in a version earlier than RAN
10) for a comparative test
The third method is recommended except when you need to prove loss of packets and know
the model of packet loss. Unlike the dynamic flow control algorithm, the static flow control
algorithm considers only the RLC BO and the quality on the air interface instead of packet
loss or delay jitter on the IUB interface during the bandwidth allocation for flow control.
Therefore, this algorithm can be used for a comparative tet. Table 2-3 lists the HSDPA flow
control algorithms supported by the Node B in the version RAN 10.
Table 2-3 HSDPA flow control algorithms supported by the Node B in the version RAN 10
Algorithm Description Considered Factors
STATIC_BW_SHAPING Static flow Quality on the air interface

control RLC BO
Available bandwidth on the IUB
interface
DYNAMIC_BW_SHAPING Dynamic flow Quality on the air interface
control RLC BO
Packet loss ratio and delay on
the IUB interface
Available bandwidth on the IUB
interface
NO_BW_SHAPING No flow control Quality on the air interface
Back press function on the RNC
BW_SHAPING_ONOFF_TOGGLE Adaptive flow When traffic is congested, the
control following algorithm is selected:
DYNAMIC_BW_SHAPING
When traffic is not congested,
the following algorithm is
selected:
NO_BW_SHAPING
You can select an HSDPA flow control algorithm on the Node B LMT (the M2000), as shown
in Figure 2-18.

Figure 2-18 HSDPA flow control algorithm selected on the Node B LMT
The static HSDPA flow control produces three results:

1. The bandwidth allocated by the Node B for flow control obviously increases and keeps
stable, and the HSDPA throughput returns to normal. You can infer that delay jitter,
out-of-sequence FP packets, or loss of a small number of FP packets occurs on the IUB
interface but does not affect the data transmission performance. In this case, you can end
the effort intended to identify the problem.
2. The bandwidth allocated by the Node B for flow control obviously increases but
fluctuates, and the HSDPA throughput is improved but is unstable. You can infer that the
IUB interface is affected by both bandwidth adjustment and packet loss. In this case, you
need to check the quality of the IUB transmission equipment. When necessary, ask the
customer to check the IUB transmission equipment.
3. The bandwidth allocated by the Node B for flow control keeps unchanged and the
HSDPA throughput still fluctuates. You can infer that obvious packet loss,
out-of-sequence packets, or delay jitter does not occur. If you can ensure good quality on
the air interface, and sufficient RLC BO and transmission resources (configuration) in
the steps above, the bandwidth allocated by the Node B for flow control should not be
limited. In this case, the product may have a defect or be improper in other
configurations. Information should be collected on the site and reported to the HQ for
analysis.
Check result 2: Data sending throughput at the RLC layer does not match the allocated
Obtain the curve of data sending throughput at the RLC layer and the curve of allocated

Figure 2-19 Allocated bandwidth for HSDPA IUB flow control and the data spending throughput
at the RLC layer (do not match) obtained by using the UMAT tool
This symptom indicates that the RNC cannot send data in time. Data sent by the RNC to the
Node B is affected by both the allocated bandwidth for IUB flow control and the data sending
mechanism at the RLC layer. Data is sent abnormally at the RLC layer because of the
following two factors:
1. The RLC sending window is congested and the data sending throughput at the RLC layer
is lower than the allocated bandwidth for flow control.
2. The RNC or UE is abnormal in protocol processing at the RLC layer.
Theoretical throughput at the RLC layer = Size of the RLC sending window (number of PDUs) x Size of
a PDU / RTT
Check item 1: whether the RLC sending window on the RNC is congested
Check whether the RLC sending window on the RNC is frequently full by using the UMAT
tool.

Figure 2-20 UMAT tool used to obtain the times for which the RLC sending window on the RNC
is full
Figure 2-21 Curve of changes in the times for which the RLC sending window on the RNC is full
If the value of DownLinkWindowsFullNum continuously increases, as shown in Figure 2-21,

the downlink RLC sending window is frequently full. Packets sent by the RLC are not

positively acknowledged by the UE in time through status reports. The possible cause is that
the uplink status reports are dropped or are not sent in time.
If the uplink status reports are not sent in time or if a small number of status reports are
dropped, you can use the E-DCH bearer for a comparative test. During demonstration or in a
scenario where HSUPA is not supported, you can use an invariable uplink SIR. For details,
see the description mentioned in step 5.
 If the data sending throughput at the RLC layer matches the allocated bandwidth after
HSUPA is used for a comparative test, you can infer that the poor uplink quality on the
air interface causes untimely arrival of status reports on the RNC. The on-site network
planning engineer needs to optimize the quality on the air interface.
 If the data sending throughput at the RLC layer is still lower than the allocated
bandwidth, that is, the downlink sending window is full as frequently as before, after
HSUPA is used for a comparative test, you can infer that HSUPA cannot improve the
RTT or that the RTT cannot be improved and the sending window is still limited. In this
case, check whether an improper PDU size (for example, 336 bits) is used. Information
should be collected as required and reported to the HQ for analysis.
If the value of DownLinkWindowsFullNum does not increase and the RNC does not send
data in the RLC buffer in time when the allocated bandwidth for flow control is sufficient, the
cause is that the RNC or UE is abnormal in protocol processing at the RLC layer. According
to the experience, the improper UE driver is highly likely to cause the problem. It is
recommended you replace the UE driver or directly use another UE for the test.
 If the data transmission is normal after the UE or UE driver is replaced, you can infer
that the UE or UE driver has a fault. In this case, the problem is identified.
 If the test result is not improved after the UE or UE driver is replaced, internal
processing on the RNC may have a fault. In this case, information should be collected on
the site as required and reported to the HQ for analysis.
Step 7 Collect and report information (mandatory).
If the problem persists after the operations mentioned in the previous steps are performed,
information should be collected according to the information collection list and reported to the
HQ for analysis.
2.1.3 Information Collection List
Information
Collection for Data Transmission Problems Regarding HSPA
2.2 Zero HSDPA Throughput

2.2.1 Symptom
Zero HSDPA throughput has only one symptom, that is, the UE is not successfully connected
to the FTP server and cannot download files from the FTP server. The DU meter shows that
the downlink throughput is zero or the uplink throughput occasionally shows a burr shape, as
shown in Figure 2-22.

Figure 2-22 Zero HSDPA throughput

Check whether the signaling process is normal and then check whether the user plane is
normal. In the case of signaling process, the zero throughput is generally caused by improper
configuration. The user plane involves a wide range, including the FTP server, SGSN, GGSN,
RNC, Node B, UE, laptop, transmission configuration, and intermediate switching
configuration. You can check the user plane layer by layer and interface by interface.
According to the experience, zero HSPA data transmission is often caused by improper
transmission configuration, which results in unavailable HSPA path or timeout in response to
the CC activation request (different VCI/VPI interconnection parameter settings on the Node
B and RNC, or incorrect configuration on the intermediate switching device). VCI refers to
virtual channel identifier and VPI refers to virtual path identifier. Therefore, check the RNC or
Node B for relevant alarms before the analysis. In this way, you can quickly identify the
problem.
Step 1 Check the signaling plane (mandatory).
Since RAN 6.0 that completely supports the HSDPA function, Huawei has accumulated four
years of experience in commercial use of the product. The product is mature in major HSDPA
features (scheduling, flow control, and mobility) and applies to a wide range of networking
scenarios. According to the experience, a failure on the user plane (zero download throughput)
is seldom caused by a product defect and often relates to the configuration, server, UE, laptop
or intermediate transmission equipment.
When the download throughput is zero, check whether the PDP activation process is
successful. Figure 2-23 shows a signaling process normally established for a PS service. The
RANAP message (act-PDP-CONTEXT-ACCEPT) received by the RNC from the CN
indicates that the signaling process is successfully established.

Figure 2-23 Normal signaling process for PDP activation
Note that although the signaling process for activating the PDP context is complete normally,
the radio access bearer (RAB) is released in a short time. In this case, dialup on the UE is
successful, but data transmission still fails because the RAB is released. For this symptom,
you need to check whether the subsequent signaling process is normal, that is, whether the
RAB is released.
If the signaling process is unsuccessful, the cause is often incorrect access point name (APN)
settings or improper subscription of the USIM card. You need to check whether such settings
are correct. If such settings are proper, you need to find out the cause based on the messages
displayed by the RNC CDT. The messages displayed by the CDT record each key step during
the service establishment. By viewing the messages, you can roughly know the cause of the
signaling process failure. It is recommended that the on-site engineer identify the cause based
on the messages displayed by the CDT. If the on-site engineer cannot identify the cause,
information should be collected as required and reported to the HQ for analysis.
If the signaling process is normal but data transmission fails on the user plane, proceed with
step 2.
Step 2 Check the user plane 1 — comparative test of the DCH (optional).
If the signaling process is successful, you can verify the abnormal HSDPA user plane by using
the DCH bearer in both the uplink and downlink directions for a comparative test. In this way,
you can deny the possibility of abnormal HSUPA. In most cases, a comparative test helps you
quickly isolate the problem and check whether the problem strongly relates to the HSPA
feature.

If data can be transmitted when the DCH bearer is used, you can infer that the upper-level
NEs above the RNC are normal and the problem relates to the HSPA feature of the RAN
because the upper-level NEs above the RNC process different radio bearers in the same way.
In this case, you need to skip steps 3 and 4, and analyze the RNC and the lower-level NEs
based on the HSPA feature.
If data transmission fails after the DCH bearer is used (this case seldom occurs according to
the experience), you can infer that the problem does not relate to the HSPA feature. On one
hand, you cannot exclude the possibility that a lower-level NE below the RNC is abnormal.
On the other hand, you do not know whether the upper-level NEs above the RNC are normal.
You still need to execute the steps mentioned below.
Step 3 Check the user plane 2 — packets received by the RNC (mandatory).
The user plane involves a wide range of NEs. When analyzing the problem, use the RNC
CDT to check whether an upper-level NE above the RNC or a lower-level NE below the RNC
is abnormal.
Use the UMAT tool to obtain the number of downlink and uplink service data units (SDUs)
received by the RLC layer. Figure 2-24 shows the check method, and Figure 2-25 shows the
check result.
Figure 2-24 Obtaining the number of SDUs received by the RLC layer by using the UMAT tool

Figure 2-25 Trend of changes in the number of SDUs received by the RLC layer
If the number of downlink packets received by the RNC is always zero and the number of
uplink packets is not zero, the RNC does not receive data from the upper-level NEs. In this
case, a fault may occur on the FTP server or the SGSN/GGSN. The SGSN and the GGSN do
not fail after the environment commissioning. The FTP server is highly likely to fail.
Therefore, it is recommended that you first check the FTP server by using another FTP server
or by directly browsing Web pages on the laptop. If the connection to the FTP server is
unsuccessful, the FTP client software displays the relevant messages. You can check the
connection to the FTP server by viewing the messages.
If the service is successful after you browse the Web pages or use another FTP server, you can
infer that the current FTP server fails. In this case, the on-site engineer needs to check whether
the settings on the FTP server are correct.
If the service still fails after you browse the Web pages or use another FTP server, you can
infer that the SGSN or GGSN performs abnormal processing on the user plane. In this case, a
CN engineer should be asked to analyze the cause of abnormality, and information should be
collected as required and reported to the HQ for analysis.
If the number of downlink packets received by the RNC is not zero, the FTP server can send
data from the SGSN/GGSN to the RNC. The fault occurs on a lower-level NE below the RNC.
In this case, proceed with step 4.
Step 4 Check the user plane 3 — packets sent by the RNC (mandatory).
If the RNC receives downlink packets from the FTP server (that is, the RLC BO is not zero)
but the UE cannot transmit data, you can infer that the fault occurs on the RNC or a
lower-level NE. In this case, check whether the RNC successfully sends data to the Node B
through the IUB interface (in the form of FP packets). Figure 2-26 shows that the RNC
successfully sends FP packets to the Node B.

Figure 2-26 Statistics on downlink FP packets that are sent from the RNC and are obtained from
the CDT by using the UMAT tool
If the number of downlink FP packets sent from the RNC as shown in Figure 2-26 is zero, you
know that the RNC does not send downlink data to the Node B. The RLC BO is not zero and
the bandwidth allocated by the Node B for flow control is a major mechanism that restricts
packets sent by the RNC. According to the product implementation, the Node B allocates at
least the bandwidth corresponding to credit = 1. Therefore, the symptom that the RNC cannot
send FP packets due to the zero bandwidth allocated for flow control does not occur, except
when the transmission configuration is incorrect or there is a defect in the version of the RNC
or Node B. To check whether the allocated bandwidth for HSDPA flow control is abnormal,
you can observe the messages displayed by the RNC CDT. The credit is at least 1, as shown
in Figure 2-27.

Figure 2-27 Information about allocated bandwidth for flow control in the messages displayed by
the RNC CDT
 If the allocated bandwidth for IUB flow control is not zero (as shown in Figure 2-27) and
the RNC does not send downlink FP packets, the RNC may fail. Information should be
collected on the site as required and reported to the HQ for analysis.
 If the allocated bandwidth for IUB flow control is zero (that is, the credit in the displayed
message is always zero), the Node B does not allocate an effective bandwidth. The
problem may relate to the allocated transmission bandwidth. In this case, you need to
check whether the transmission configuration complies with the specifications (see the
attachment) and modify the transmission configuration according to the specifications as
required. If the transmission configuration complies with the specifications but the
allocated bandwidth for flow control is still zero, information should be collected on the
site as required and reported to the HQ for analysis.
If the number of downlink FP packets sent from the RNC as shown in Figure 2-26 increases
continuously, you know that the RNC has sent downlink data to the Node B. Then check
whether the IUB interface (including the intermediate transmission equipment) drops all the
downlink FP packets or whether the bit error rate on the air interface is 100%. Likewise,
improper transmission configuration also causes downlink packets to be dropped. For
example, if the maximum transmission unit (MTU) is set improperly, an IP packet is
segmented into many fragments and cannot be reassembled. The symptom also occurs when
different VCI/VPI values are set on the RNC and the Node B, or when the intermediate
transmission equipment is configured incorrectly. Therefore, you need to check whether the
transmission configuration (including the configuration of intermediate devices) complies
with the specifications and modify the configuration according to the specifications.
If the transmission configuration complies with the specifications, proceed with step 5.
Step 5 Check the UE and laptop (mandatory).
If the HSDPA data transmission fails, you can infer that the problem does not occur on any
equipment other than the UE or laptop. If the check results are normal, you need to check
whether the UE and laptop work properly. Replace the laptop, UE, and driver version for a
comparative test. The Huawei E270 11.415.05.00.00.B409 is recommended.
Step 6 Collect and report information (mandatory).

information should be collected on the site as required and reported to the HQ for analysis.
Information

3 HSUPA Throughput Problems
This chapter describes how to handle two major HSUPA throughput problems. It is guidance
to on-site engineers in analyzing and checking the problems, and in collecting required
information for identifying the problems. HSUPA throughput problems are analyzed more
simply than HSDPA throughput problems. It is hard, however, to collect valid information,
that is, messages displayed by the UE Probe and Node B CDT are required. After the RAN 10
supports the Node B CDT, valid information is collected more easily.
 One problem is that the uplink throughput is low or fluctuates.
The history maintenance data shows that this problem occurs frequently and widely. The
following causes contribute to this problem:
− Unstable transmission quality. The symptom is loss of packets on the IU or IUB
interface.
− Limited radio resources. The symptom is that the uplink load, IUB transmission
resources, or uplink channel element (CE) resources are limited.
− Improper parameter settings. The parameter settings on the RAN or CN side cannot
meet the test requirement.
− Mismatch of or a performance defect in the UE driver. The symptom is that the UE
does not act according to the protocol.
− Mutual influence caused by data transmission that is performed by other users
simultaneously.
 Another problem is that the HSUPA service cannot be established.
The HSUPA service cannot be successfully established and the uplink throughput
reaches R99 384 kbit/s only. This problem is generally caused by improper parameter
settings. Especially, this chapter describes the process for analyzing the problem that the
HSUPA 5.76 Mbit/s service cannot be established. This problem often occurs during the
deployment because of special requirements for hardware specifications and parameter
settings.
This chapter describes the symptom of each problem so that the on-site engineers can
judge the problems they encounter, check the problems, and collect required information.
Then this chapter provides the idea of analyzing the problem and the detailed process for
checking and handling the problem. Finally, this chapter lists all the information required
for analyzing the problem. The document annexed to this Troubleshooting Guide
provides the general tools required for analyzing HSDPA throughput problems and the
user guide to these tools.

 This chapter focuses on the idea of analyzing HSUPA throughput problems. The throughput indexes
of HSDPA UEs of category 5/6 are provided for reference.
 The normal throughput is close to the theoretical value and keeps stable. The low throughput
mentioned in this document indicates that the throughput does not reach the maximum theoretical
throughput supported by the device capability or configured resources.
 To identify problems related to product defects, you may require additional information that is not
completely covered in the information collection guide provided in this document.
3.1 Low or Fluctuating HSUPA Throughput

3.1.1 Symptom
One symptom of the abnormal HSUPA throughput is that the HSUPA throughput is lower
than the expected value and keeps stable without sharp fluctuation. By default, when there is
only one HSUPA user in a cell, the user rate should be over 1.2 Mbit/s in phase 1 (a version
earlier than RAN 10). In phase 2 (RAN 10 or a later version), the user rate should be over 1.7
Mbit/s in the case of a UE of category 5 (the typical UE is the Huawei E270), and over 3.5
Mbit/s in the case of a UE of category 6 (the typical UE is the Huawei E180).
Symptom 1: The uplink data rate is stable but does not reach the theoretical value, as shown
in Figure 3-1.This symptom is mainly caused by limited resources or improper parameter
settings (such as the MBR).
Figure 3-1 HSUPA data transmission rate that is stable but lower than the theoretical value
Symptom 2: The uplink data rate fluctuates and does not reach the theoretical value, as
shown in Figure 3-2.Many causes contribute to this symptom, for example, poor transmission
quality on the IUB interface, throughput limitation in certain sections, limitation on the air
interface and transmission resources, and limitation on the CE resources.

Figure 3-2 Low and fluctuating HSUPA data transmission rate

Before analyzing the problem, you need to know all the NEs involved in HSDPA data
transmission and the matters worthy of attention in an overall perspective.
The HSUPA throughput depends on the amount of data to be sent (amount of data in the
buffer) and the data sending capability of the UE. On one hand, the TCP feature determines
that the amount of data in the buffer is sufficient as long as the intermediate sections are not
limited (packet loss or large RTT). On the other hand, the data sending capability of a UE
depends on the available transmit power of the UE and the serving grant (SG) obtained by the
UE. According to the MAC-E scheduling algorithm, the Node B allocates SGs to HSUPA
users based on the available resources, including the uplink load, IUB transmission, uplink
CE, and scheduling information (SI) reported by users. Therefore, the SG that a UE can
obtain is closely related to use (congestion) of the resources mentioned above.
SI covers the actual amount of data in the buffer on the UE side and available transmit power of the UE.
SI is used for reference of Node B in allocating SGs.

Figure 3-3 NEs involved in and major sections of HSUPA data transmission
The basic idea of identifying a data transmission problem regarding HSUPA is as follows:
Perform a comparative test by using the TESTPING tool to check whether the problem occurs
above or below the RLC layer. If the TESTPING test result is abnormal, you need to check
whether resources are limited by observing the SG on the UE side through the Probe. During
the analysis, you may encounter a problem related to the FTP server, UE, or laptop. You can
analyze the problem through a comparative test.
Before analyzing a problem, you need to check the RNC or Node B for relevant alarms on the site. In
this way, you can identify the problem quickly.
Step 1 Check whether the service to be established is an HSUPA service (optional).

If the uplink rate is low and can reach 364 kbit/s only, check whether the service is established
on the E-DCH bearer. In doing so, see section 3.2 "Failure to Establish the HSUPA Service."
Otherwise, proceed with step 2.
Step 2 Check whether data at the application layer on the UE is sufficient.
Data is uploaded in FTP mode during the test. Data that the UE can send (that is, the amount
of data in the buffer) may be insufficient for any cause at the TCP layer and, as a result, the
uplink data transmission rate is affected. It is recommended that you use the TESTPING tool
for a comparative test to check whether the problem occurs below or above the RLC layer.
The principle is as follows: Data can be sent from the laptop to the UE at the specified
throughput and a reverse acknowledgement packet does not need to be sent to the UE at the
TCP layer. The acknowledge packet is still required at the RLC layer. Therefore, you can
easily know whether the problem occurs above or below the RLC layer (limitation on TCP
rate at the source end, loss of packets on the IUB interface, unstable server performance, and
loss of packets on an upper-level NE above the RNC).
If the data rate keeps stable at the expected value after the TESTPING tool is used to actively
send packets, the rate may be limited due to a fault at the TCP or application layer. In this case,
you need to check whether the rate is limited on the FTP server or CN side and whether the
UE driver is in the latest version. Currently, the stable version of the Huawei E270 is
11.415.05.00.00.B409, and the stable version of the Huawei E180 is 11.105.05.00.00.B409.If
the condition permits, you can use the two UEs to perform a comparative test. If you find

nothing abnormal, use the Ethereal tool to capture packets on the UE and FTP server, and to
send information about the user plane displayed by the RNC CDT to the HQ for analysis.
If the rate remains abnormal after the TESTPING tool is used, a fault may occur on the RAN
side. Proceed with the subsequent steps.
Step 3 Check whether the transmit power of the UE is limited.
If the signal quality is poor and the path loss is high, the HSUPA throughput may fail to reach
the expected value due to the limitation on transmit power of the UE. Check whether the
transmit power of the UE is limited by observing the UE TxPower item on the RNC LMT, as
shown in Figure 3-4.
Figure 3-4 Enabling the function of tracing the transmit power of the UE on the RNC LMT
If the tracing result shows that the transmit power of the UE often reaches 20 dBm, the
transmit power of the UE already approaches the maximum value (24 dBm), which results in
a low HSUPA throughput. The on-site network planning engineer should check the
environment on the air interface and perform the test on a UE that is so close to the base
station that the received signal code power (RSCP) is larger than –90 dBm.
Step 4 Check whether the uplink power load is limited.
In a WCDMA system, the uplink load of a cell is calculated by using the received total
wideband power (RTWP) or rise over thermal (RoT). To keep stable and ensure the quality of
service, the system requires an uplink load that is controlled in a proper range. In the version
RAN 10, the default uplink load of a cell is 75%, that is, the RoT is 6 dB. The default
background noise set on the product is –106 dBm. When RTWP rises by 6 dB to reach –100
dBm, the cell reaches the uplink load threshold and the user rate cannot increase.
Observe RTWP on the RNC LMT to check whether the uplink load of the cell already reaches
the threshold, as shown in Figure 3-5.

Figure 3-5 Enabling the function of tracing RTWP of a cell on the RNC LMT
Figure 3-6 shows the RTWP information about a cell that is traced in real time. RTWP already
reaches –100 dBm, that is, RoT reaches 6 dB (the threshold).
Figure 3-6 RTWP information about a cell traced in real time
If the user rate is limited because the cell reaches the load threshold, you need to check
whether the configured background noise of the cell matches the actual background noise. To

query the configured background noise of a cell on the RNC LMT, run the LST CELLCAC
command. The query result is shown in Figure 3-7.
Figure 3-7 Parameter setting of background noise queried on the RNC LMT
To obtain the actual background noise of a cell, you can observe RTWP when no user in the
cell uses any service. As shown in Figure 3-8, the actual background noise of the cell is –104
dBm, 2 dB higher than the baseline configuration (–106 dBm).
Figure 3-8 RTWP of a zero-loaded cell observed on the RNC LMT

If the configured background noise does not match the actual background noise, perform the
following operations:
 In the test environment, run the MOD CELLCAC command on the RNC LMT to
modify the configured background noise so that the configured background noise
matches the actual background noise.
 For a commercial network, do not directly modify the configured background noise
because doing so may cause shrinkage of the uplink coverage, which means that the high
background noise is permitted to rise by 6 dB (RoT). It is recommended that the on-site
engineer find out the cause of high background noise. If the cause of high background
noise cannot be identified in a short time during a major acceptance test, the configured
background noise of the cell can be modified within a short time to verify the HSUPA
performance.
 For the relationship between the configured background noise of a cell and the actual physical
meaning, see the help information about the MOD CELLCAC command.
 If the actual background noise of a cell is continuously over –102 dBm or below –110 dBm, RTWP
is abnormal. In this case, ask the Node B engineer or network planning engineer to solve the
problem and then perform an HSUPA test.
If the configured background noise of a cell matches the actual background noise, the actual
uplink load on the air interface already reaches the load threshold. Check whether other users
in the cell use the service. If other users use the service in the cell, the users may occupy part
of the load and cause the load to be limited. If the uplink load of a cell already reaches the
threshold when only one user uses the service in the cell and the user throughput does not
reach the expected value, the possible causes are as follows:
 Strong external interference exists. As a result, RTWP exceeds the threshold. In this case,
ask the on-site engineer to eliminate the source of interference.
 The UE OLPC does not converge because the uplink path loss is too low. The symptom
is that the transmit power of the UE DPCCH is already low but still results in too high
RTWP. This problem generally occurs in the test environment possibly because no
proper signal attenuator is installed. In this case, take the UE away from the antenna of
the base station.
 A defect in the product or UE causes the abnormal uplink power control. In this case, use
another UE for a comparative test.
If you find nothing wrong with the check items above but RTWP remains abnormal, a fault
may occur on the product. You need to rectify the fault or modify the configured background
noise to be the same as the actual background noise so that the test can proceed. Based on the
test result, decide whether to proceed with step 5.Otherwise, information should be collected
on the site against the information collection list and reported to the HQ for analysis.
If the problem is solved through the check items above but the rate remains abnormal,
proceed with step 5.
Step 5 Check whether the IUB transmission resources are limited.
After data from the UE is correctly received by the Node B, the data should be sent to the
RNC in the form of FP frames through the transmission resources on the IUB interface.
If the transmission resources on the IUB interface are limited, the user rate cannot reach the
expected value.
Observe HSUPA RL Enhanced Info Report of the Node B CDT. The reported messages
cover uhwBwForPath that indicates the available bandwidth for the path where the user is
located. If the value is smaller than the expected rate but close to the current tested rate, the

low rate may be caused by limited IUB transmission resources. The transmission resources
are limited because of the transmission configuration, traffic, delay jitter and loss of packets
during the transmission.
In this case, check whether the physical bandwidth (the number of E1 lines) meets the test
requirement based on the actual required throughput. In addition, check whether the
parameter settings comply with the transmission configuration specifications for the version.
Pay attention to the following items:
 Whether the configured physical bandwidth is sufficient. One E1 line can provide a
physical bandwidth of 2 Mbit/s. When the physical bandwidth is converted to the
application layer, the transmission efficiency of 0.75 should be considered. During
transmission over fast Ethernet (FE), the physical bandwidth is not limited.
 Whether the intermediate IUB transmission equipment is bottlenecked. If the condition
permits, you can directly connect the RNC to the Node B for a comparative test.
 Whether the HSUPA path configuration complies with the specifications.
 Whether port rate limitation is configured on the Node B. You can run the LST LR
command to check this item, as shown in Figure 3-9.
Figure 3-9 Check result of the LST LR command executed on the Node B LMT
The command mentioned above displays the port rate, which includes the rates on all the IP paths that
use the port. When calculating the HSUPA bandwidth, you need to deduct the bandwidth occupied by
other services. In addition, when converting the bandwidth to the application layer, the transmission
efficiency of 0.9 should be considered.
If the transmission configuration is correct, you can observe the number of users in the cell.
To prevent limitation transmission resources caused by traffic, perform the test at a time when
a small number of users use the service in the cell.
If the transmission resources are not limited because the transmission configuration is
incorrect or other users contend for the resource, the limitation on transmission bandwidth
may be caused by loss of packets or delay jitter during the transmission. In this case, perform

a comparative test and capture packets on the IUB transmission equipment to identify the
problem.
Step 6 Check whether the uplink CE resources are limited.
If the HSUPA DCCC function is used or if both the dynamic CE function and GBR admission
are used, you may encounter the symptom that the HSUPA service can be normally
established but the rate cannot reach the expected value due to the insufficient uplink CE
resources. You can run the DSP LICENSE command on the Node B LMT to query the
number of CEs on the Node B, as shown in Figure 3-10.
Figure 3-10 Number of licensed CEs as queried on the Node B LMT
Table 3-1 lists the CEs used by different spreading factors.
Table 3-1 Rules on used uplink CEs for different rates (SF)
Min SF Supported Rate HSUPA Phase 1 HSUPA Phase 2

(Bit/s)
SF64 32K 1+1+1 1
SF32 64K 1+1+1.5 1
SF16 160K 1+1+3 2
SF8 320K 1+1+5 4
SF4 640K 1+1+10 8
2xSF4 1.44M 1+1+20 16
2xSF2 2.7M Not supported 32

2xSF2 + 2xSF4 5.76M Not supported 48
The supported rates listed in Table 3-1 are not strict and are for reference only. The actual rate is affected
by retransmission on the air interface. During the test, ensure the uplink CE resources required for the
expected rate.
During an acceptance test of a commercial network, you cannot prevent other users from
contending for the uplink CE resources. Therefore, you need to trace the use of uplink service
resources in real time. You can check the number of CEs used by each cell by querying the
service resources of cells on the Node B LMT, as shown in Figure 3-11.
Figure 3-11 Number of current CEs used by a cell as queried on the Node B LMT
Based on the CE license configuration, check whether the remaining available CE resources
on the Node B are sufficient for the UE to reach the expected rate. Likewise, you can use the
messages displayed by the Node B CDT to check whether the uplink CEs are limited. If the
configured available CEs cannot meet the uplink throughput required by the UE, you need to
expand the CE license, or to add the hardware capability when the license already reaches the
hardware capability.
Step 7 Check whether there are changes in the uplink bandwidth allocated by the RNC.
If there are changes in the uplink bandwidth allocated by the RNC, the HSUPA throughput
may change accordingly. You can observe the changes in the uplink bandwidth by tracing the
uplink bandwidth and throughput on the RNC LMT, as shown in Figure 3-12.

Figure 3-12 Enabling the function of tracing uplink throughput and bandwidth on the RNC LMT
The possible causes of changes in the bandwidth include HSUPA DCCC actions and
switchover to a cell supporting a different HSUPA capability (for example, switchover from a
cell supporting 5. 76 Mbit/s to a cell supporting 1.44 Mbit/s).
If the cause is an action of the HSUPA DCCC, you need to capture logs on the RNC CDT and
UE (Probe or QXDM) to analyze what triggers the HSUPA DCCC action.
If the cause is the switchover and the test objective does not cover the HSUPA performance
during the switchover, disable the adjacent cell or delete the adjacency relationship to prevent
frequent switchover.
To test cases related to switchover, you need to collect information and report the information
to the HQ for analysis.
Information

3.2 Failure to Establish the HSUPA Service

3.2.1 Symptom
The uplink throughput monitored by the DU meter does not exceed 384 kbit/s. The
RRC_RB_SETUP message on the air interface shows that the traffic radio bearer
(corresponding to radio bearer 5 when only a single PS service is provided) uses E-DCH as
the bearer, as shown in Figure 3-13.
Figure 3-13 Bearer type in the RRC_RB_SETUP message

Step 1 Check the UE capability.
If the UE does not support the HSUPA function, the service cannot be established over
HSUPA. Therefore, you need to check the capability reported by the UE. The
RRC_CONNECT_REQ message on the Uu interface specifies whether the UE supports the
E-DCH function. For the specific capability type, you need to analyze the
RRC_CONNECT_CMP message. If the ueCapabilityIndication cell exists in the message and
the cell value covers e-dch, the UE supports the HSUPA function, as shown in Figure 3-14.

Figure 3-14 RRC CONNECTION SETUP REQ message
Otherwise, the UE does not support the HSUPA function. In this case, use another HSUPA UE
(the Huawei E270 is recommended) for the test.
If the check result shows that the UE supports the HSUPA function, proceed with step 2.
Step 2 Check the cell capability.

If HSUPA is not configured or activated for the cell, the HSUPA service cannot be established.
Run the LST CELLHSUPA command on the RNC LMT to query the HSUPA capability and
status of the cell. The query result shows that HSUPA is configured and activated for the cell,
as shown in Figure 3-15.
Figure 3-15 HSUPA status of the cell checked on the RNC LMT

If the query result shows that the HSUPA function is not activated or that the HSUPA cell is
not configured or is configured incorrectly, run the ADD CELLHSUPA command to
configure the HSUPA cell on the site.
If the query result shows that the HSUPA function is activated, proceed with step 3.
Step 3 Check the throughput assigned by the CN.
The RNC checks whether the service uses the E-DCH bearer based on the MBR assigned by
the CN and the configured threshold. If the MBR assigned by the CN exceeds the throughput
threshold of the E-DCH bearer, the service is established over E-DCH. Otherwise, the DCH
bearer is used. Thresholds are set separately for the BE service and streaming service.
The MBR is assigned in the RANAP_RAB_ASSIGNMENT_REQUSET message, as shown
in Figure 3-16.
Figure 3-16 MBR information in the RAB ASSIGNMENT REQ message
Run the LST FRCCHLTYPEPARA (in the version RAN 10) or LST FRC (in a version
earlier than RAN 10) command on the RNC LMT to query the HSUPA traffic
thresholds. Figure 3-17 shows the query result.

Figure 3-17 Query result of the LST FRCCHLTYPEPARA command
If the uplink throughput assigned by the CN is lower than the HSUPA traffic thresholds,
directly modify the HSUPA traffic thresholds or modify the subscription information on the
home location register (HLR). Before the modifying the subscription information, confirm
that the subscription information about the IMSI matches the information assigned by the CN.
Otherwise, you may encounter the symptom that the subscription is correct on the HLR but an
AT command is used to limit the throughput during the dialup. Note that after the HSUPA
traffic thresholds are modified, the service can be established over HSUPA but the problem is
not solved because the UE throughput is still limited by the MBR. Therefore, you must
modify the subscription information on the HLR or cancel the throughput limitation imposed
by the AT command. For how to limit the throughput by using the AT command, see the
document annexed to this Troubleshooting Guide.
If the throughput assigned by the CN is higher than the HSUPA traffic thresholds, proceed
with step 4.
Step 4 Check the RAN parameter settings.
If there are no special requirements during the test, the parameter settings on the RNC and
Node B should be the same as the baseline, and the transmission configuration on the IUB
interface should comply with the configuration specifications. Otherwise, improper parameter
settings may cause a failure to establish the HSUPA service. In the version RAN 10, the
causes of a failure to establish the HSUPA service include but are not limited to the following
ones:
 Limited uplink power resource. The precondition is that the uplink admission is enabled.
 Limited uplink CE resources. For details, see the relevant description section 3.1 "Low
or Fluctuating HSUPA Throughput."
 Limited IUB transmission resources. For details, see the relevant description section 3.1
"Low or Fluctuating HSUPA Throughput."
 Limited maximum number of HSPA users. Run the LST CELLCAC command to check
whether the value of MaxHsupaUserNum meets the test requirement.
 The typical service parameter TYPRAB is incorrectly deleted. This problem occurred in
Algeria.

Figure 3-18 Admission process for the RAN 10
You can identify the limited resource by checking the RNC CDT and then adjust the resource
configuration or parameter settings. Figure 3-19 shows a problem that occurs on a commercial
network in Poland. The messages displayed by the CDT indicate that the uplink CE resources
are insufficient. The service is established after the CE license is adjusted.
Figure 3-19 Limited uplink CE resources indicated by the messages displayed by the RNC CDT

HQ for analysis.
Information
3.3 Failure to Establish an HSUPA 5.76 Mbit/s Service

The HSUPA 5.76 Mbit/s service is introduced in phase 2. This service puts forward high
requirements for resource configuration and parameter settings (UE of category 6, and 2*SF4
+ 2*SF2). The service cannot be successfully established due to improper configuration or
settings. This section describes the common causes of a failure to establish the HSUPA 5.76
Mbit/s service and the idea of analyzing the failure.
3.3.1 Symptom
The uplink rate monitored by the DU meter does not exceed 2 Mbit/s. The RB SETUP
message on the Uu interface shows that the traffic radio bearer (radio bearer 5 when only a
single PS service is provided) is established on DCH or is established on E-DCH but the
uplink SF used is not 2*SF2+S*SF4, as shown in Figure 3-20.
Figure 3-20 E-DCH bearer used without supporting the rate of 5.76 Mbit/s
Figure 3-21 shows the uplink SF capability set used when the HSUPA 5.76 Mbit/s service is
successfully established.

Figure 3-21 E-DCH bearer with support for the rate of 5.76 Mbit/s

Step 1 Check the UE capability.
To successfully establish the HSUPA 5.76 Mbit/s service, you need to use an HSUPA UE of
category 6.You can obtain the HSUPA capability level supported by a UE from the
RRC_CONNECT_REQ_CMP message on the Uu interface. If the message contains the
ueCapabilityContainer cell and the value of the cell is 5, the UE supports the HSUPA rate of
5.76 Mbit/s, as shown in Figure 3-22. The LMT does not resolve the container and value 5
indicates a UE of category 6.
Figure 3-22 HSUPA capability level of a UE indicated in the RRC_CONNECT_REQ_CMP

message
If the check result does not meet the test requirement, use a UE of category 6 for the test. The
Huawei E180 data card is recommended.
If the check result shows that the UE supports the HSUPA 5.76 Mbit/s service, proceed with
step 2.
Step 2 Check the versions of the RNC and Node B.

The Huawei RAN 10 or a later version supports the HSUPA 5.76 Mbit/s service. For the RNC,
only the RAN 10 is required. For the Node B, you need to differentiate between the baseband
processing boards.
For the V1platform, the baseband processing boards on the Node B are the NBBI, HBBI, and
EBBI. For the V2platform, the baseband processing boards on the Node B are the WBBPa
and WEEPb. Currently, only the EBBI and WEEPb boards support the HSUPA 5.76 Mbit/s
service.
If the RAN version or board on the site does not support the HSUPA 5.76 Mbit/s service,
replace the RAN version or hardware.
If both the RAN version and the board on the site support the HSUPA 5.76 Mbit/s service,
proceed with step 3.
Step 3 Check the licensed capability of the RAN.
Both the RNC and the Node B in the version RAN 10 provide a license to control the HSUPA
5.76 Mbit/s service.
Two control items in the RNC license relate to the HSUPA 5.76 Mbit/s service: HSUPA
5.74Mbps per User and SRB over HSUPA. According to the 3GPP protocol, to support
2*SF2 + 2*SF4 in the uplink direction, you must carry signaling over E-DCH. Run the DSP
LICENSE command on the RNC LMT to query the two control items, as shown in Figure
3-23.
Figure 3-23 Control items related to the HSUPA 5.76 Mbit/s service in the RNC license
The control item related to the HSUPA 5.76 Mbit/s service in the license on the Node B is
HSUPA TTI Function, as shown in Figure 3-24. The HSUPA function must also be
supported.

Figure 3-24 Control item related to the HSUPA 5.76 Mbit/s service in the license on the Node B
To use the HSUPA 5.76 Mbit/s service, you should set the license items listed above in the
supported state.
If the control items in the license are in the supported state but the HSUPA 5.76 Mbit/s service
cannot be established, proceed with step 4.
Step 4 Check the parameter settings on the RNC.
Check item 1: The uplink SRB needs to use the E-DCH bearer.
To establish the HSUPA 5.76 Mbit/s service, you need to use 2*SF2+2*SF4 in the uplink
direction and establish the signaling ratio bearer (SRB) over E-DCH. Run the LST/SET
FRCCHLTYPEPARA command on the RNC LMT to query or modify the current settings,
as shown in Figure 3-25.

Figure 3-25 Query result of the LST FRCCHLTYPEPARA command executed on the RNC LMT
If the query result shows that the SRB cannot be established on E-DCH, modify the settings.
If the query result shows that the SRB can be established on E-DCH, proceed with check item
2.
Check item 2: enabling status of the HSUPA 2 ms TTI
To establish the HSUPA 5.76 Mbit/s service, you must use the 2 mm TTI. Therefore, you must
enable the 2 ms TTI on the RNC. Run the LST/SET CORRMALGOSWITCH command on
the RNC LMT to query or modify the enabling status of the 2 ms TTI, as shown in Figure
3-26.
Figure 3-26 Query result of the LST CORRMALGOSWITCH command executed on the RNC
LMT
If the query result shows that the 2 ms TTI is not enabled, you need to modify the enabling
status by running the MML command SET CORRMALGOSWITCH:
HspaSwitch=HSUPA_TTI_2MS_SWITCH-1.

If the query result shows that the 2 ms TTI is enabled, proceed with check item 3.
Check item 3: The MBR assigned by the CN needs to be higher than the 2 ms HSUPA traffic
threshold.
If you need to establish the HSUPA 5.76 Mbit/s service, the MBR assigned by the CN must be
higher than the 2 ms HSUPA traffic thresholds. For the MBR assigned by the CN, see step 3
in section 3.2.2 "Troubleshooting Procedures." You can run the LST FRC command on the
RNC LMT to query the 2 ms HSUPA traffic thresholds, as shown in Figure 3-27.
Figure 3-27 Query result of the LST FRC command executed on the RNC LMT
If the MBR assigned by the CN is smaller than the 2 ms HSUPA service thresholds, you need
to modify the MBR assigned by the CN. For details, see step 3 in section 3.2.2
"Troubleshooting Procedures."
Step 5 Collect and report information.
HQ for analysis.
Information

Troubleshooting Guide To HSPA

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Troubleshooting Guide To HSPA

Uploaded by

Copyright:

Available Formats

RAN10 Troubleshooting Guide to HSPA Throughput Problems INTERNAL

Doc. Code Product Name WCDMA-RAN-

Usage For internal use Product Version RAN10

RAN10 Troubleshooting Guide to HSPA

Huawei Technologies Co., Ltd.

Transmission Group of UMTS

Approved By Date 2009-03-09

2016-03-24 Huawei Confidential Page 1 of 61

2009-02-05 1.1 The process for identifying problems was Zhang Xu

2016-03-24 Huawei Confidential Page ii of 61

1 Troubleshooting Process for HSPA Throughput Problems ................................................. 7

3 HSUPA Throughput Problems ................................................................................................. 39

2016-03-24 Huawei Confidential Page 3 of 61

Figure 1-1 Troubleshooting process for HSPA throughput problems .................................................................... 7

Figure 2-4 HSDPA throughput that fluctuates irregularly ................................................................................... 12

Figure 2-7 UE capability reported in the RRC_CONNECT_SETUP_CMP message ......................................... 15

Figure 2-9 HS-PDSCH code resources configured on the RNC ......................................................................... 18

Figure 2-22 Zero HSDPA throughput .................................................................................................................. 32

Figure 2-23 Normal signaling process for PDP activation .................................................................................. 33

2016-03-24 Huawei Confidential Page 4 of 61

Figure 3-13 Bearer type in the RRC_RB_SETUP message ................................................................................ 51

Figure 3-14 RRC CONNECTION SETUP REQ message .................................................................................. 52

Figure 3-17 Query result of the LST FRCCHLTYPEPARA command ............................................................... 54

2016-03-24 Huawei Confidential Page 5 of 61

Table 2-1 Capabilities of HSDPA UEs ................................................................................................................ 15

2016-03-24 Huawei Confidential Page 6 of 61

1 Troubleshooting Process for HSPA

Figure 1-1 Troubleshooting process for HSPA throughput problems

2016-03-24 Huawei Confidential Page 7 of 61

This document is intended for readers who:

2016-03-24 Huawei Confidential Page 8 of 61

2 HSDPA Throughput Problems

2016-03-24 Huawei Confidential Page 9 of 61

2.1 Low or Fluctuating HSDPA Throughput

Figure 2-1 Stable HSDPA throughput close to the theoretical value

2016-03-24 Huawei Confidential Page 10 of 61

Figure 2-2 Stable HSDPA throughput below the theoretical value

Figure 2-3 HSDPA throughput that fluctuates regularly

2016-03-24 Huawei Confidential Page 11 of 61

Figure 2-4 HSDPA throughput that fluctuates irregularly

2.1.2 Troubleshooting Procedures

The process for data transmission over FTP is as follows:

2016-03-24 Huawei Confidential Page 12 of 61

Step 1 Check the signaling process (mandatory).

2016-03-24 Huawei Confidential Page 13 of 61

2016-03-24 Huawei Confidential Page 14 of 61

Figure 2-7 UE capability reported in the RRC_CONNECT_SETUP_CMP message

Table 2-1 Capabilities of HSDPA UEs

UE Type Supported Largest TB Supported Highest Rate at the

11, 12 3630 1.8

If the sdsch-physical-layer-category reported by the UE does not meet the theoretical

2016-03-24 Huawei Confidential Page 15 of 61

Cat12 1.8 Mbit/s 5 18

2016-03-24 Huawei Confidential Page 16 of 61

Figure 2-8 CQI reported by the UE and traced by the Probe

Step 3 Check radio resources (mandatory).

2016-03-24 Huawei Confidential Page 17 of 61

Figure 2-9 HS-PDSCH code resources configured on the RNC

2016-03-24 Huawei Confidential Page 18 of 61

2016-03-24 Huawei Confidential Page 19 of 61

2016-03-24 Huawei Confidential Page 20 of 61

2016-03-24 Huawei Confidential Page 21 of 61