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.
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.
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
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.
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
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
following operations:
In the test environment, run the MOD CELLCAC command on the RNC LMT to modify the configured background noise so that the configured background noise matches the actual background noise.
For a commercial network, do not directly modify the configured background noise because doing so may cause shrinkage of the uplink coverage, which means that the high background noise is permitted to rise by 6 dB (RoT). It is recommended that the on-site engineer find out the cause of high background noise. If the cause of high background noise cannot be identified in a short time during a major acceptance test, the configured background noise of the cell can be modified within a short time to verify the HSUPA performance.
For the relationship between the configured background noise of a cell and the actual physical
meaning, see the help information about the MOD CELLCAC command.
If the actual background noise of a cell is continuously over –102 dBm or below –110 dBm, RTWP
is abnormal. In this case, ask the Node B engineer or network planning engineer to solve the problem and then perform an HSUPA test.
If the configured background noise of a cell matches the actual background noise, the actual uplink load on the air interface already reaches the load threshold. Check whether other users in the cell use the service. If other users use the service in the cell, the users may occupy part of the load and cause the load to be limited. If the uplink load of a cell already reaches the threshold when only one user uses the service in the cell and the user throughput does not reach the expected value, the possible causes are as follows:
Strong external interference exists. As a result, RTWP exceeds the threshold. In this case, ask the on-site engineer to eliminate the source of interference.
The UE OLPC does not converge because the uplink path loss is too low. The symptom is that the transmit power of the UE DPCCH is already low but still results in too high RTWP. This problem generally occurs in the test environment possibly because no proper signal attenuator is installed. In this case, take the UE away from the antenna of the base station.
A defect in the product or UE causes the abnormal uplink power control. In this case, use another UE for a comparative test.
If you find nothing wrong with the check items above but RTWP remains abnormal, a fault may occur on the product. You need to rectify the fault or modify the configured background noise to be the same as the actual background noise so that the test can proceed. Based on the test result, decide whether to proceed with step 5.Otherwise, information should be collected on the site against the information collection list and reported to the HQ for analysis.
If the problem is solved through the check items above but the rate remains abnormal, proceed with step 5.
Step 5 Check whether the IUB transmission resources are limited.
After data from the UE is correctly received by the Node B, the data should be sent to the RNC in the form of FP frames through the transmission resources on the IUB interface. If the transmission resources on the IUB interface are limited, the user rate cannot reach the expected value.
Observe HSUPA RL Enhanced Info Report of the Node B CDT. The reported messages cover uhwBwForPath that indicates the available bandwidth for the path where the user is located. If the value is smaller than the expected rate but close to the current tested rate, the low rate may be caused by limited IUB transmission resources. The transmission resources
are limited because of the transmission configuration, traffic, delay jitter and loss of packets during the transmission.
In this case, check whether the physical bandwidth (the number of E1 lines) meets the test requirement based on the actual required throughput. In addition, check whether the
parameter settings comply with the transmission configuration specifications for the version. Pay attention to the following items:
Whether the configured physical bandwidth is sufficient. One E1 line can provide a physical bandwidth of 2 Mbit/s. When the physical bandwidth is converted to the application layer, the transmission efficiency of 0.75 should be considered. During transmission over fast Ethernet (FE), the physical bandwidth is not limited.
Whether the intermediate IUB transmission equipment is bottlenecked. If the condition permits, you can directly connect the RNC to the Node B for a comparative test. Whether the HSUPA path configuration complies with the specifications.
Whether port rate limitation is configured on the Node B. You can run the LST LR command to check this item, as shown in 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
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)
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
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.
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 ormati on