Troubleshooting Guide to HSPA Throughput Problems-V1.3 .doc

RAN10 Troubleshooting Guide to HSPA Throughput Problems

Doc. Code

INTERNAL

Product Name

WCDMA-RAN-

Usage

For internal use

Product Version

RAN10

Prepared By

WCDMA UMTS Maintenance Department

Document Version

RAN10

RAN10 Troubleshooting Guide to HSPA Throughput Problems

Huawei Technologies Co., Ltd.

2009-08-11

Huawei Confidential

Page 1 of 63

RAN10 Troubleshooting Guide to HSPA Throughput Problems

Prepared By

Transmission Group of UMTS Maintenance Department

Date

Reviewed By

Date

Reviewed By

Date

Approved By

Date

2009-08-11

Huawei Confidential

INTERNAL

2009-03-09

2009-03-09

Page 2 of 63

RAN10 Troubleshooting Guide to HSPA Throughput Problems

INTERNAL

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 optimized according to the review comments.

Zhang Xu

2009-02-26

1.2

The idea of identifying problems was optimized based on case study.

Xia Cuichun

2009-03-09

1.3

Description errors were corrected based on the document test and review comments

Xia Cuichun

2009-08-11

Huawei Confidential

Page iii of 63

RAN10 Troubleshooting Guide to HSPA Throughput Problems

INTERNAL

Contents 2.1 Low or Fluctuating HSDPA Throughput................................................................................................................12 2.1.1 Symptom...........................................................................................................................................................12 2.1.2 Troubleshooting Procedures.............................................................................................................................14 2.1.3 Information Collection List..............................................................................................................................33 2.2 Zero HSDPA Throughput.......................................................................................................................................33 2.2.1 Symptom...........................................................................................................................................................33 2.2.2 Troubleshooting Procedures.............................................................................................................................34 2.2.3 Information Collection List..............................................................................................................................40 3.1 Low or Fluctuating HSUPA Throughput................................................................................................................42 3.1.1 Symptom...........................................................................................................................................................42 3.1.2 Troubleshooting Procedures.............................................................................................................................43 3.1.3 Information Collection List..............................................................................................................................52 3.2 Failure to Establish the HSUPA Service.................................................................................................................53 3.2.1 Symptom...........................................................................................................................................................53 3.2.2 Troubleshooting Procedures.............................................................................................................................53 3.2.3 Information Collection List..............................................................................................................................58 3.3 Failure to Establish an HSUPA 5.76 Mbit/s Service..............................................................................................58 3.3.1 Symptom...........................................................................................................................................................58 3.3.2 Troubleshooting Procedures.............................................................................................................................59 3.3.3 Information Collection List..............................................................................................................................63

2009-08-11

Huawei Confidential

Page 4 of 63

RAN10 Troubleshooting Guide to HSPA Throughput Problems

INTERNAL

Figures Troubleshooting process for HSPA throughput problems....................9 Stable HSDPA throughput close to the theoretical value...................12 Stable HSDPA throughput below the theoretical value.....................13 HSDPA throughput that fluctuates regularly....................................13 HSDPA throughput that fluctuates irregularly..................................14 NEs involved in and major sections of HSDPA data transmission.......14 Service type and maximum uplink/downlink bit rate in the RAB assignment message......................................................................16 UE capability reported in the RRC_CONNECT_SETUP_CMP message....17 CQI reported by the UE and traced by the Probe..............................19 HS-PDSCH code resources configured on the RNC............................20 License regarding HS-PDSCH code resource and 16QAM configured on the Node B....................................................................................20 Number of users in the cell traced on the RNC LMT..........................21 Use of code tree in the cell traced on the RNC LMT..........................22 Downlink transmit power of the TRX in a cell traced on the RNC LMT 23 Available power for HSPA configured on the RNC LMT......................23 Information about the RLC BO and allocated bandwidth for flow control viewed from the CDT file by using the tracing review tool.....24 Actively sending packets to a UE by using the RNC CDT....................27 Allocated bandwidth for HSDPA IUB flow control and the RLC throughput obtained by using the UMAT tool...................................28 HSDPA flow control algorithm selected on the Node B LMT...............30 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.......................................................................31

2009-08-11

Huawei Confidential

Page 5 of 63

RAN10 Troubleshooting Guide to HSPA Throughput Problems

INTERNAL

UMAT tool used to obtain the times for which the RLC sending window on the RNC is full...........................................................................32 Curve of changes in the times for which the RLC sending window on the RNC is full................................................................................32 Zero HSDPA throughput.................................................................34 Normal signaling process for PDP activation....................................35 Obtaining the number of SDUs received by the RLC layer by using the UMAT tool......................................................................................36 Trend of changes in the number of SDUs received by the RLC layer...37 Statistics on downlink FP packets that are sent from the RNC and are obtained from the CDT by using the UMAT tool................................38 Information about allocated bandwidth for flow control in the messages displayed by the RNC CDT...............................................39 HSUPA data transmission rate that is stable but lower than the theoretical value............................................................................42 Low and fluctuating HSUPA data transmission rate..........................43 NEs involved in and major sections of HSUPA data transmission.......44 Enabling the function of tracing the transmit power of the UE on the RNC LMT........................................................................................45 Enabling the function of tracing RTWP of a cell on the RNC LMT........46 RTWP information about a cell traced in real time............................46 Parameter setting of background noise queried on the RNC LMT......47 RTWP of a zero-loaded cell observed on the RNC LMT.......................47 Check result of the LST LR command executed on the Node B LMT....49 Number of licensed CEs as queried on the Node B LMT.....................50 Number of current CEs used by a cell as queried on the Node B LMT. 51 Enabling the function of tracing uplink throughput and bandwidth on the RNC LMT..................................................................................52 Bearer type in the RRC_RB_SETUP message.....................................53 RRC CONNECTION SETUP REQ message...........................................54 HSUPA status of the cell checked on the RNC LMT............................54 MBR information in the RAB ASSIGNMENT REQ message...................55 Query result of the LST FRCCHLTYPEPARA command........................56

2009-08-11

Huawei Confidential

Page 6 of 63

RAN10 Troubleshooting Guide to HSPA Throughput Problems

INTERNAL

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

2009-08-11

Huawei Confidential

Page 7 of 63

RAN10 Troubleshooting Guide to HSPA Throughput Problems

INTERNAL

Tables Capabilities of HSDPA UEs..............................................................17 Minimum CQI values corresponding to the theoretical throughputs of various HSDPA UEs.........................................................................18 HSDPA flow control algorithms supported by the Node B in the version RAN 10..........................................................................................29 Rules on used uplink CEs for different rates (SF).............................50

2009-08-11

Huawei Confidential

Page 8 of 63

Troubleshooting Guide to Data Transmission Problems Regarding HSPA

1

INTERNAL

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

2009-08-11

Huawei Confidential

Page 9 of 63

Troubleshooting Guide to Data Transmission Problems Regarding HSPA

INTERNAL

This document is intended for readers who:

2009-08-11

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.

Huawei Confidential

Page 10 of 63

Troubleshooting Guide to Data Transmission Problems Regarding HSPA

2

INTERNAL

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

2009-08-11

Huawei Confidential

Page 11 of 63

Troubleshooting Guide to Data Transmission Problems Regarding HSPA

INTERNAL

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 1.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 1.1 Stable HSDPA throughput close to the theoretical value

Symptom 2: The HSDPA throughput is low and relatively stable, as shown in 1.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).

2009-08-11

Huawei Confidential

Page 12 of 63

Troubleshooting Guide to Data Transmission Problems Regarding HSPA

INTERNAL

Figure 1.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 1.3.The cause is that the parameter settings or algorithm characteristics do not match in certain environments. Figure 1.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 1.4.This problem has many causes, and you need to check the FTP server and the UE in the end-to-end manner.

2009-08-11

Huawei Confidential

Page 13 of 63

Troubleshooting Guide to Data Transmission Problems Regarding HSPA

INTERNAL

Figure 1.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 1.1 NEs involved in and major sections of HSDPA data transmission

The process for data transmission over FTP is as follows:

2009-08-11

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

Huawei Confidential

Page 14 of 63

Troubleshooting Guide to Data Transmission Problems Regarding HSPA

INTERNAL

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.

2009-08-11

Huawei Confidential

Page 15 of 63

Troubleshooting Guide to Data Transmission Problems Regarding HSPA

INTERNAL

Figure 1.1 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.

2009-08-11

Huawei Confidential

Page 16 of 63

Troubleshooting Guide to Data Transmission Problems Regarding HSPA

INTERNAL

Figure 1.2 UE capability reported in the RRC_CONNECT_SETUP_CMP message

The information in 1.2 indicates that the UE is of HSDPA category 7 and supports a throughput of 7.2 Mbit/s. 1.2 lists other UE types and the relevant capabilities at the physical layer. Figure 1.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).

2009-08-11

Huawei Confidential

Page 17 of 63

Troubleshooting Guide to Data Transmission Problems Regarding HSPA

INTERNAL

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. 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. Figure 1.2 Minimum CQI values corresponding to the theoretical throughputs of various HSDPA UEs HSDPA UE Category

Supported Throughput at the Physical Layer

Number of Required HSPDSCH Codes

Required Minimum CQI for the Peak Throughput

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. 1.1 shows that the CQI reported by the current UE is 27 and meets the requirement mentioned above.

2009-08-11

Huawei Confidential

Page 18 of 63

Troubleshooting Guide to Data Transmission Problems Regarding HSPA

INTERNAL

Figure 1.1 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 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 1.1.

2009-08-11

Huawei Confidential

Page 19 of 63

Troubleshooting Guide to Data Transmission Problems Regarding HSPA

INTERNAL

Figure 1.1 HS-PDSCH code resources configured on the RNC

1.2 shows the license on the Node B that is queried on the Node B LMT or M2000 Figure 1.2 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

2009-08-11

Huawei Confidential

Page 20 of 63

Troubleshooting Guide to Data Transmission Problems Regarding HSPA

INTERNAL

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 1.3 and 1.4. Figure 1.3 Number of users in the cell traced on the RNC LMT

2009-08-11

Huawei Confidential

Page 21 of 63

Troubleshooting Guide to Data Transmission Problems Regarding HSPA

INTERNAL

Figure 1.4 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 3.1.

2009-08-11

Huawei Confidential

Page 22 of 63

Troubleshooting Guide to Data Transmission Problems Regarding HSPA

INTERNAL

Figure 3.1 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 3.2. The power in the common pilot channel is 33 dBm, and the MPO constant is 2.5) Figure 3.2 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

2009-08-11

Huawei Confidential

Page 23 of 63

Troubleshooting Guide to Data Transmission Problems Regarding HSPA

INTERNAL

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 1.1. 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 1.1 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 1.1, 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: 

2009-08-11

Loss of packets occurs on an upper-level NE above the RNC or on the intermediate

Huawei Confidential

Page 24 of 63

Troubleshooting Guide to Data Transmission Problems Regarding HSPA

INTERNAL

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-

2009-08-11

Huawei Confidential

Page 25 of 63

Troubleshooting Guide to Data Transmission Problems Regarding HSPA

INTERNAL

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 1.1. 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.

2009-08-11

Huawei Confidential

Page 26 of 63

Troubleshooting Guide to Data Transmission Problems Regarding HSPA

INTERNAL

Figure 1.1 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.

2009-08-11

Huawei Confidential

Page 27 of 63

Troubleshooting Guide to Data Transmission Problems Regarding HSPA

INTERNAL

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 1.1, 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 1.1 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.

2009-08-11

Mirroring and packet capture

Huawei Confidential

Page 28 of 63

Troubleshooting Guide to Data Transmission Problems Regarding HSPA

INTERNAL

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. 3 lists the HSDPA flow control algorithms supported by the Node B in the version RAN 10. Figure 1.3 HSDPA flow control algorithms supported by the Node B in the version RAN 10 Algorithm

Description

Considered Factors

STATIC_BW_SHAPING

Static flow control

Quality on the air interface RLC BO Available bandwidth on the IUB interface

DYNAMIC_BW_SHAPING

Dynamic flow control

Quality on the air interface 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 control

When traffic is congested, the 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 3.1.

2009-08-11

Huawei Confidential

Page 29 of 63

Troubleshooting Guide to Data Transmission Problems Regarding HSPA

INTERNAL

Figure 3.1 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, outof-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-ofsequence 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 bandwidth for IUB flow control. Obtain the curve of data sending throughput at the RLC layer and the curve of allocated bandwidth for IUB flow control.

2009-08-11

Huawei Confidential

Page 30 of 63

Troubleshooting Guide to Data Transmission Problems Regarding HSPA

INTERNAL

Figure 3.1 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.

2009-08-11

Huawei Confidential

Page 31 of 63

Troubleshooting Guide to Data Transmission Problems Regarding HSPA

INTERNAL

Figure 2.1 UMAT tool used to obtain the times for which the RLC sending window on the RNC is full

Figure 2.2 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 2.2, 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

2009-08-11

Huawei Confidential

Page 32 of 63

Troubleshooting Guide to Data Transmission Problems Regarding HSPA

INTERNAL

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 I nf or mat i on Col l ect i on f or Dat a Transmi ssi on Pr obl ems Regardi ng 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 1.1.

2009-08-11

Huawei Confidential

Page 33 of 63

Troubleshooting Guide to Data Transmission Problems Regarding HSPA

INTERNAL

Figure 1.1 Zero HSDPA throughput

2.2.2 Troubleshooting Procedures 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. 1.1 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.

2009-08-11

Huawei Confidential

Page 34 of 63

Troubleshooting Guide to Data Transmission Problems Regarding HSPA

INTERNAL

Figure 1.1 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

2009-08-11

Huawei Confidential

Page 35 of 63

Troubleshooting Guide to Data Transmission Problems Regarding HSPA

INTERNAL

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. 1.1 shows the check method, and 1.2 shows the check result. Figure 1.1 Obtaining the number of SDUs received by the RLC layer by using the UMAT tool

2009-08-11

Huawei Confidential

Page 36 of 63

Troubleshooting Guide to Data Transmission Problems Regarding HSPA

INTERNAL

Figure 1.2 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 lowerlevel 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). 1.1 shows that the RNC successfully sends FP packets to the Node B.

2009-08-11

Huawei Confidential

Page 37 of 63

Troubleshooting Guide to Data Transmission Problems Regarding HSPA

INTERNAL

Figure 1.1 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 1.1 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 1.2.

2009-08-11

Huawei Confidential

Page 38 of 63

Troubleshooting Guide to Data Transmission Problems Regarding HSPA

INTERNAL

Figure 1.2 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 1.2) 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 1.1 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).

2009-08-11

Huawei Confidential

Page 39 of 63

Troubleshooting Guide to Data Transmission Problems Regarding HSPA

INTERNAL

If the problem persists after the operations mentioned in the previous steps are performed, information should be collected on the site as required and reported to the HQ for analysis.

2.2.3 Information Collection List I nf or mat i on Col l ect i on f or Dat a Transmi ssi on Pr obl ems Regardi ng HSPA

2009-08-11

Huawei Confidential

Page 40 of 63

Troubleshooting Guide to Data Transmission Problems Regarding HSPA

3

INTERNAL

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.

2009-08-11

Huawei Confidential

Page 41 of 63

Troubleshooting Guide to Data Transmission Problems Regarding HSPA

INTERNAL



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 1.1.This symptom is mainly caused by limited resources or improper parameter settings (such as the MBR). Figure 1.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 1.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.

2009-08-11

Huawei Confidential

Page 42 of 63

Troubleshooting Guide to Data Transmission Problems Regarding HSPA

INTERNAL

Figure 1.2 Low and fluctuating HSUPA data transmission rate

3.1.2 Troubleshooting Procedures 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.

2009-08-11

Huawei Confidential

Page 43 of 63

Troubleshooting Guide to Data Transmission Problems Regarding HSPA

INTERNAL

Figure 1.1 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

2009-08-11

Huawei Confidential

Page 44 of 63

Troubleshooting Guide to Data Transmission Problems Regarding HSPA

INTERNAL

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 1.1. Figure 1.1 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 1.1.

2009-08-11

Huawei Confidential

Page 45 of 63

Troubleshooting Guide to Data Transmission Problems Regarding HSPA

INTERNAL

Figure 1.1 Enabling the function of tracing RTWP of a cell on the RNC LMT

1.2 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 1.2 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

2009-08-11

Huawei Confidential

Page 46 of 63

Troubleshooting Guide to Data Transmission Problems Regarding HSPA

INTERNAL

command. The query result is shown in 1.3. Figure 1.3 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 1.4, the actual background noise of the cell is –104 dBm, 2 dB higher than the baseline configuration (–106 dBm). Figure 1.4 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

2009-08-11

Huawei Confidential

Page 47 of 63

Troubleshooting Guide to Data Transmission Problems Regarding HSPA

INTERNAL

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

2009-08-11

Huawei Confidential

Page 48 of 63

Troubleshooting Guide to Data Transmission Problems Regarding HSPA

INTERNAL

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 1.1.

Figure 1.1 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.

2009-08-11

Huawei Confidential

Page 49 of 63

Troubleshooting Guide to Data Transmission Problems Regarding HSPA

INTERNAL

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 1.1. Figure 1.1 Number of licensed CEs as queried on the Node B LMT

1.1 lists the CEs used by different spreading factors. Figure 1.4 Rules on used uplink CEs for different rates (SF)

2009-08-11

Min SF

Supported Rate (Bit/s)

HSUPA Phase 1

HSUPA Phase 2

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

Huawei Confidential

Page 50 of 63

Troubleshooting Guide to Data Transmission Problems Regarding HSPA

INTERNAL

The supported rates listed in 1.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 1.2. Figure 1.2 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 1.1.

2009-08-11

Huawei Confidential

Page 51 of 63

Troubleshooting Guide to Data Transmission Problems Regarding HSPA

INTERNAL

Figure 1.1 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.

3.1.3 Information Collection List I nf ormat i on Col l ect i on f or Dat a Transmi ssi on Pr obl ems Regardi ng HSPA

2009-08-11

Huawei Confidential

Page 52 of 63

Troubleshooting Guide to Data Transmission Problems Regarding HSPA

INTERNAL

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 1.1. Figure 1.1 Bearer type in the RRC_RB_SETUP message

3.2.2 Troubleshooting Procedures 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 1.1.

2009-08-11

Huawei Confidential

Page 53 of 63

Troubleshooting Guide to Data Transmission Problems Regarding HSPA

INTERNAL

Figure 1.1 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 1.1. Figure 1.1 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

2009-08-11

Huawei Confidential

Page 54 of 63

Troubleshooting Guide to Data Transmission Problems Regarding HSPA

INTERNAL

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 1.1. Figure 1.1 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. 1.2 shows the query result.

2009-08-11

Huawei Confidential

Page 55 of 63

Troubleshooting Guide to Data Transmission Problems Regarding HSPA

INTERNAL

Figure 1.2 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:

2009-08-11



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.

Huawei Confidential

Page 56 of 63

Troubleshooting Guide to Data Transmission Problems Regarding HSPA

INTERNAL

Figure 1.1 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. 1.2 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 1.2 Limited uplink CE resources indicated by the messages displayed by the RNC CDT

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

2009-08-11

Huawei Confidential

Page 57 of 63

Troubleshooting Guide to Data Transmission Problems Regarding HSPA

INTERNAL

HQ for analysis.

3.2.3 Information Collection List I nf or mat i on Col l ect i on f or Dat a Transmi ssi on Pr obl ems Regardi ng HSPA

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 1.1. Figure 1.1 E-DCH bearer used without supporting the rate of 5.76 Mbit/s

1.2 shows the uplink SF capability set used when the HSUPA 5.76 Mbit/s service is successfully established.

2009-08-11

Huawei Confidential

Page 58 of 63

Troubleshooting Guide to Data Transmission Problems Regarding HSPA

INTERNAL

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

3.3.2 Troubleshooting Procedures 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 1.1. The LMT does not resolve the container and value 5 indicates a UE of category 6. Figure 1.1 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.

2009-08-11

Huawei Confidential

Page 59 of 63

Troubleshooting Guide to Data Transmission Problems Regarding HSPA

INTERNAL

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 1.1. Figure 1.1 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 1.2. The HSUPA function must also be supported.

2009-08-11

Huawei Confidential

Page 60 of 63

Troubleshooting Guide to Data Transmission Problems Regarding HSPA

INTERNAL

Figure 1.2 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 1.1.

2009-08-11

Huawei Confidential

Page 61 of 63

Troubleshooting Guide to Data Transmission Problems Regarding HSPA

INTERNAL

Figure 1.1 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 1.2. Figure 1.2 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.

2009-08-11

Huawei Confidential

Page 62 of 63

Troubleshooting Guide to Data Transmission Problems Regarding HSPA

INTERNAL

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 1.3. Figure 1.3 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. 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.

3.3.3 Information Collection List I nf or mat i on Col l ect i on f or Dat a Transmi ssi on Pr obl ems Regardi ng HSPA

2009-08-11

Huawei Confidential

Page 63 of 63