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.
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.
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.
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.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 lower- level NE. In this case, check whether the RNC successfully sends data to the Node B through the IUB interface (in the form of FP packets). 1.1 shows that the RNC successfully sends FP packets to the Node B.
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.
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.
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 ormat i on
3
HSUPA Throughput Problems
This chapter describes how to handle two major HSUPA throughput problems. It is guidance to on-site engineers in analyzing and checking the problems, and in collecting required information for identifying the problems. HSUPA throughput problems are analyzed more simply than HSDPA throughput problems. It is hard, however, to collect valid information, that is, messages displayed by the UE Probe and Node B CDT are required. After the RAN 10 supports the Node B CDT, valid information is collected more easily.
One problem is that the uplink throughput is low or fluctuates.
The history maintenance data shows that this problem occurs frequently and widely. The following causes contribute to this problem:
− Unstable transmission quality. The symptom is loss of packets on the IU or IUB interface.
− Limited radio resources. The symptom is that the uplink load, IUB transmission resources, or uplink channel element (CE) resources are limited.
− Improper parameter settings. The parameter settings on the RAN or CN side cannot meet the test requirement.
− Mismatch of or a performance defect in the UE driver. The symptom is that the UE does not act according to the protocol.
− Mutual influence caused by data transmission that is performed by other users simultaneously.
Another problem is that the HSUPA service cannot be established.
The HSUPA service cannot be successfully established and the uplink throughput reaches R99 384 kbit/s only. This problem is generally caused by improper parameter settings. Especially, this chapter describes the process for analyzing the problem that the HSUPA 5.76 Mbit/s service cannot be established. This problem often occurs during the deployment because of special requirements for hardware specifications and parameter settings.
This chapter describes the symptom of each problem so that the on-site engineers can judge the problems they encounter, check the problems, and collect required information. Then this chapter provides the idea of analyzing the problem and the detailed process for checking and handling the problem. Finally, this chapter lists all the information required for analyzing the problem. The document annexed to this Troubleshooting Guide
provides the general tools required for analyzing HSDPA throughput problems and the user guide to these tools.
This chapter focuses on the idea of analyzing HSUPA throughput problems. The throughput indexes
of HSDPA UEs of category 5/6 are provided for reference.
The normal throughput is close to the theoretical value and keeps stable. The low throughput
mentioned in this document indicates that the throughput does not reach the maximum theoretical throughput supported by the device capability or configured resources.
To identify problems related to product defects, you may require additional information that is not
completely covered in the information collection guide provided in this document.