5.3 Poor Performance of Data Transfer
5.3.5 Analysis of the Problem about Poor Data Transmission Performance of the HSUPA on the RAN Side
Transmission Performance of the HSUPA on the RAN Side
The PS data transmission performance is end-to-end (UE <->data service server) system performance. Each component in the system may affect data transmission. When we test and
optimize the HSUPA data transmission performance, we usually focus on the effects of the RAN side (RNC-NodeB-UE) on the data transmission performance. We hope that the effects of the other parts (SGSN, GGSN, data service server, and external networks) of the system can be removed before the test so that we can concentrate on the radio network.
From the angle of throughput measurement, poor data transmission performance reflects a low unsteady rate with a wide fluctuation range. From the angle of the QoS, poor data transmission performance reflects unclear streaming images, buffering, and slow response to web browsing.
The working process of an HSUPA UE is as follows:
The UE originates a data transmission request according to the Scheduling Information (determined by the UE power headroom [UPH] and the quantity [Q] of data to be transmitted) carried on the E-DPDCH.
The NodeB determines the granted level (the E-AGCH sends T/P and the E-RGCH sends an adjust command to tune (+1, 0 -1)) according to the UE request (SI), monitored RoT, and the satisfaction (Happy bit indication carried on the E-DPCCH) from the UE.
The UE sends corresponding data according to the granted level. Meanwhile, the UE attaches the next frame request (SI) on the E-DPDCH and feeds back the satisfaction (Happy bit) at the allocated granted level on the E-DPCCH.
After receiving and demodulating the data, the NodeB returns an AcK/Nack on the E-HICH.
Figure 1.1 Working process of an HSUPA UE
During the optimization of the HSUPA throughput, you should combine the drive test data of the Probe tool for analysis. The following describes HSUPA-related rates in the Probe tool:
MAC-e PDU Non-DTX Rate = Sum of all TB sizes in the case of non-DTX/(number of non-DTXs * TTI)
This rate is the actual rate of the MAC-e (excluding DTX, but including the rate of retransmission blocks)
Sum of all TB sizes in the case of non-DTX: Not only the block transmitted first but also the retransmitted blocks are included.
Number of non-DTXs * TTI: Only the time when data is transmitted is counted and the time when no data is transmitted is excluded. For example, if only 50 sub-frames send data within the measurement period of 100 sub-frames (200 ms), the denominator is 100 ms.
MAC-e PDU Served Rate = Sum of all TB sizes in the case of non-DTX/
(NUM_SAMPLES * TTI)
This rate is the served rate of the MAC-e (including DTX and the rate of retransmission blocks)
Sum of all TB sizes in the case of non-DTX: Not only the block transmitted first but also the retransmitted blocks are included.
NUM_SAMPLES * TTI: The time when data is transmitted and the time when no data is transmitted are both included. For example, if only 50 sub-frames send data within the measurement period of 100 sub-frames (200 ms), the denominator is 200 ms.
MAC-e PDU Available Rate = Sum of TB sizes when COMB_HICH is ACK or ACK_NS in the case of non-DTX/(NUM_SAMPLES*TTI)
Sum of TB sizes when COMB_HICH is ACK or ACK_NS in the case of non-DTX: Only the TBs transmitted correctly are counted.
NUM_SAMPLES * TTI: The time when data is transmitted and the time when no data is transmitted are both included.
Relationship between these three throughputs:
− MAC-e PDU Served Rate = MAC-e PDU Non-DTX Rate * Non-DTX Probability
− MAC-e PDU Available Rate ≈ MAC-e PDU Served Rate *(1-SBLER) Where,
Non-DTX Probability = Number of non-DTXs/NUM_SAMPLES * 100%
SBLER = (Number of DTXs – Number of ACK or ACK_NS)/Number of non-DTXs * 100%
UL RLC PDU Throughput = Sum of bits of all RLC PDUs sent by the RLC layer within the measurement period/Measurement period duration
Sum of bits of all RLC PDUs sent by the RLC layer within the measurement period: The first transmitted data and the retransmitted data are included. In addition, the data is transferred by MAC-d anMAC-d contains the heaMAC-der overheaMAC-d (16 bits) of the RLC PDU.
Measurement period duration: The time when data is transmitted and the time when no data is transmitted are both included.
Relationship with MAC-e PDU Available Rate:
− RLC PDU Throughput UL = MAC-e PDU Available Rate * (1-header overhead ratio of MAC-e PDU)
A precise relationship should exclude the header overhead and the padding bits when the TB size does not match N RLC PDU bits
UL RLC SDU Throughput = Sum of bits of all RLC SDUs sent by the RLC layer within the measurement period/Measurement period duration
Sum of bits of all RLC SDUs sent by the RLC layer within the measurement period: Compared with the sum of RLC PDU bits, the retransmitted data and header overhead (16 bits) of the RLC PDU are excluded.
Measurement period duration: The time when data is transmitted and the time when no data is transmitted are both included.
Relationship between RLC SDU Throughput UL and RLC PDU Throughput UL:
− RLC SDU Throughput UL ≈ RLC PDU Throughput UL*(1-RLC PDU Retransmission Rate UL)*header overhead ratio of the RLC PDU The figure below shows the optimization flow of a low throughput of the HSUPA UE.
Figure 1.2 Optimization flow of a low throughput of the HSUPA UE
Service Setup on an E-DCH
Check whether the serving E-DCH RL indicator in the RB SETUP message of the RNC is True, as shown in the figure below. If yes, the service is borne on the HSUPA.
Figure 1.3 Confirming the service is set up on the HSUPA according to a signaling message of the RNC
You can also observe whether an SG is reported in the HSUPA Link Statistics window provided by a drive test tool, for example, Probe. If no information is displayed in the window, the service is borne on a DCH, as shown in the figure below.
Figure 1.4 How to confirm the service is set up on the HSUPA through the drive test tool Probe
If the service is not borne on the HSUPA, the service is automatically set up on a DCH. In this case, the service rate is the rate of the R99 service, usually 384 Kpbs or below.
If the service is not set up on the HSUPA, you can make analysis in terms of the following aspects:
Check whether the capabilities reported by the UE include the HSUPA. The
RRC_CONN_REQUEST message reported by the UE indicates whether the HSDPA and HSUPA are supported. The specific E-DCH capability level is reported in an
RRC_CONN_SETUP_CMP message.
Check whether the MBR in the subscription information in the previous line is normal and whether the rate threshold over an E-DCH is set too high. If the MBR assigned by the CN does not exceed the rate threshold over an E-DCH, the service is set up on a DCH.
Check whether the HSUPA cell is available and activated.
The access of the HSUPA UE fails.
Check whether the type of the HSUPA AAL2PATH is configured correctly and whether a type of HSUPA AAL2PATH is configured.
Abnormal MAC-e PDU Non-DTX Rate
The UE compares its current MAC-e PDU Non-DTX Rate with the maximum allowable ETFC according to the corresponding ETFC of the SG that the UE currently maintains. Make analysis in combination with the Happy/Unhappy information reported by the UE.
If the UE reports HAPPY, the user may not feel happy. Make specific analysis according to the happy reasons.
If the MAC-e PDU Non-DTX Rate is abnormal, use the drive test tool Probe to determine whether the UE reports HAPPY or UNHAPPY.
If the UE reports HAPPY and the UE rate cannot reach the MBR, the possible causes are as follows:
The terminal capability or the RAN capability is limited.
The transmit power of the terminal limited.
The traffic of the terminal is limited.
If the UE reports UNHAPPY and the UE rate cannot reach the MBR, the possible causes are as follows:
The SG (UE grant) is limited.
The resources (air interface load, IUB bandwidth, and CE) on the RAN side are limited.
Cause 1: The air interface load is limited.
Cause 2: The IUB bandwidth is limited.
Cause 3: The NodeB CEs are limited.
The service MBR (NodeB MBR) is limited.
The UE demodulates incorrectly.
Cause 1: The SG is not updated because the CRC of the AG value fails Cause 2: The UE demodulates the RG incorrectly.
The protocol gives the conditions when the UE report HAPPY and UNHAPPY.
The UE indicates that it is ‘unhappy’ if the following criteria are met:
UE is transmitting as much scheduled data as allowed by the current Serving Grant.
UE has enough power available to transmit at higher data rate.
Total buffer status would require more than Happy_Bit_Delay_Condition ms to be transmitted with the current Serving_Grant × the ratio of active processes to the total number of processes.
The first criteria are always true for a deactivated process and the ratio of the third criteria is always 1 for 10ms TTI.
Otherwise, the UE indicates that it is ‘happy’.
The terminal capability or the RAN capability is limited.
Principle description
Currently, the capability of Qualcomm HSUPA and Huawei E270 HSUPA is CAT5 (the corresponding MAC-e rate is 2 Mbit/s). The maximum capability supported by Huawei RAN6.0 (RNCV1.8 and NodeBV1.8) is 2 x SF4 (the corresponding MAC-e rate is 1.4484 Mbit/s). Currently, the maximum rate that a single UE can obtain is limited to the capability of the RAN6.0.
The RAN6.0 supports 2 x SF4, the maximum TB size is 14484), and the MAC-e PDU Non-DTX Rate is 14484/10 = 1.4484 Mbit/s
The CAT5 terminal supports 2 x SF2, the maximum TB size is 20000, and the MAC-e PDU Non-DTX Rate is 20000/10 = 2 Mbit/s.
Table 4.1 Categories of UE HSUPA capability levels
NOTE: When 4 codes are transmitted in parallel, two codes shall be transmitted with SF2 and two with SF4
Observation method:
− Observe the UE capability
Generally, the terminals supporting the HSUPA function all support the HSDPA function. That is, the HSPA bears the services of users as a whole. The following describes how to observe the HSPA function that the UE supports and the specific HS-DSCH/E-DCH capability level in combination with actual RRC messages.
First, the RRC_CONN_REQUEST message reported by the UE indicates whether the HSDPA and the HSUPA functions are supported. In the figure below, the capability reported by the UE indicates that the UE supports HS-DSCH and E-DCH.
Figure 1.5 RRC CONNECTION REQUEST message
The specific E-DCH capability level is reported in an RRC_CONN_SETUP_CMP message. As shown in the figure below, the HS-DSCH physical layer level of the UE is category 6 and the E-DCH physical layer capability level is category 5.
Figure 1.6 RRC CONNECT SETUP CMP message
− Observe the maximum capability configured on the RAN side
When the service is set up, the RL RECFG PREP message sent by the RNC to the NodeB gives the maximum spreading factor that the UE can use and the
corresponding information element (CE) is maxSet-E-DPDCHs. In the figure below, two spreading factors (SF=4) are supported.
Figure 1.7 RL RECFG PREPARE message
When the DCCC algorithm of the HSUPA is disabled, the RNC configures the maximum capability according to the MBR of the UE. When the DCCC algorithm of the HSUPA is enabled, the maximum capability is affected by the initial access rate of the DCCC.
Solution:
Improve the capability of the RAN side or use a terminal with a higher capability level.
The transmit power of the terminal is limited.
Principle description
The UE calculates the transmit TB size according to the currently available transmit power. Then, the UE selects the smaller between the TB size supported by the transmit power and the TB size supported by the SG as the actual transmit TB size.
The available transmit power of the UE is the same, but the transmit TB size may be not the same. The factors that influence the TB size are as follows:
− The UE is at the edge of a cell and the uplink path loss is large.
− The uplink load of the cell is high (the UE is not at the edge of a cell).
− The UE performs combined services. The DCH service consumes much power and insufficient power is available to the E-DCH service.
Observation method:
Method of observing whether the transmit power of the UE limited:
− Observe the power limited rate reported by the UE through the Assistant. If the power limited rate is greater than 0%, the transmit power of the UE within the
corresponding measurement period of the measurement value is limited.
Figure 1.8 Display of the Assistant HSUPA related information (limited transmit power of the UE)
When the UE uses the maximum block (14480), Qualcomm chips of early versions also display the limited transmit power, but in fact, the transmit power is not limited. This problem can be ruled out by combining the current MAC-e PDU Non-DTX Rate with the actual transmit power of the UE.
− After confirming that the transmit power of the UE is limited, analyze the limitation causes.
a.View the PCPICH RSCP of the cell where the UE is located and check whether the UE is at the edge of the cell.
b.View the RTWP of the cell where the UE is located before the access and check whether the uplink load of the cell is high.
c.View the uplink SIR of the UE to check whether the SIR is exceptionally high.
d.View the service that the UE sets up and check whether the service is a combined service.
Solution:
− If the UE is at the edge of the cell, move the UE to the center of the cell.
− If the uplink load of the cell is high and the cell load is adjustable, reduce the cell load.
− If the service that the UE sets up is a combined service, deactivate the R99 service and observe the rate of the HSUPA service.
The traffic of the terminal is limited.
Principle description:
If the data in the UE RLC Buffer is insufficient, the actual MAC-e PDU Non-DTX Rate
is low.
Observation method:
− Method of observing whether the traffic of the UE is limited
Observe the buffer limited rate reported by the UE through the Assistant. If the buffer limited rate greater than 0%, the traffic of the UE within the corresponding
measurement period of the measurement value is limited.
Figure 1.9 Display of the Assistant HSUPA related information (limited traffic)
− After confirming that the traffic of the UE is limited, probable reasons:
a. The TCP/IP layer is exceptional so that the TCP sends no data.
b. The RLC layer is exceptional so that the RLC sends no data.
Solution:
You can consider sending packets in the uplink to eliminate the effect of the TCP mechanism. If this method does not work, check whether the problem about packet loss exists on the RAN side.
In addition, some applications in the portable PC also affect the data transmission. In this case, replace the portable PC. If the problem still exists, use a tool to capture packets and locate the exceptions between the portal PC and the UE.
The SG (UE grant) is limited.
Two basic functions of the HSUPA scheduling
− [Basic function 1]: Control the cell load
When the actual cell load is greater than the target value, the cell throughput can be reduced by lowering the SG of the UE. When the actual cell load is less than the target value, the cell throughput can be improved by increasing the SG of the unhappy UE.
− [Basic function 2]: Limit the MBR of a single UE
When the actual value of the MAC-e rate (including retransmitted blocks) is greater than the MBR, an RG Down is sent to the UE to reduce the SG of the UE. As a result, the transmission rate of the UE is reduced and is kept approximate to the MBR.
The UE maintains the SG according to the AG (AG is used only to increase the rate in the RAN6.0) and the RG (Up, Hold, and Down) sent by the NodeB. The UE determines the actual transmission rate by reference to the SG. The actual transmission rate is less than or equal to the corresponding transmission rate of the SG.
The resources (air interface load, IUB bandwidth, and CEs) on the RAN side are limited.
If the resources on the RAN side are limited, the SG that the NodeB actually allocates to the UE is small. As a result, the UE reports that the SG is limited.
Cause 1: The air interface load is limited.
− Principle description:
1) According to basic function 1 of the HSUPA scheduling, when the air interface load on the RAN side is limited, the target load value is the target value configured on the RNC (this value is usually determined at the time of network planning). If the actual value of the cell load exceeds the target value, the uplink coverage of the cell may shrink (the shrinkage depends on the uplink budget margin) and the service at the edge of the cell is affected. Therefore, the cell load needs to be controlled.
2) RNC-related parameter configuration
The RNC-related parameters include MaxTargetUlLoadFactor and BackgroundNoise.
MaxTargetUlLoadFactor is the target ROT. Related command: MOD CELLHSUPA MaxTargetUlLoadFactor=75 (75 represents 75%, namely, 6 dB)
BackgroundNoise is the background noise. Related command: MOD CELLCAC:
BackgroundNoise=71 (71 represents –112 + 7.1 = –104.9 dBm) The target RTWP is calculated according to the following formula:
Target RTWP = Target ROT + Background Noise.
Hence, the target RTWP = –104.9 + 6 = –98.9 dBm 3) The RNC sends a message to the NodeB.
The RNC carries the target RTWP and the background noise to the NodeB by sending a PHYSICAL SHARED CHANNEL RECONFIGURATION REQUEST message on the Iub interface.
The relationship between the protocol value and the physical value is: physical value
= –112 + protocol value/10 (unit: dBm)
As shown in the figure below, the protocol value of the target RTWP is 114, the corresponding physical value is –112 + 11.4 = –100.6 dBm. The background noise of the RTWP is 54 and the corresponding physical value of the background noise is – 112 + 5.4 = –106.6 dBm.
Figure 1.10 PHYSICAL SHARED CHANNEL RECONFIGURATION REQUEST message (containing the target RTWP and the background)
The disagreement of the background set on the RNC LMT with the cell background affects the throughput of the cell. If the setting value of the background noise is much larger than the actual background noise value, the system stability may be reduced.
When the setting value of the background noise is greater than the actual background noise value, the actual cell throughput is greater than the throughput that the target ROT corresponds to.
When the setting value of the background noise is less than the actual background noise value, the actual cell throughput is less than the throughput that the target ROT corresponds to.
− Observation method:
Observe the cell uplink RTWP measurement recorded and displayed on the RNC LMT to check whether it is close to the configured target RTWP. If the measured value is close to the target RTWP, the air interface load is limited and reaches the
Observe the cell uplink RTWP measurement recorded and displayed on the RNC LMT to check whether it is close to the configured target RTWP. If the measured value is close to the target RTWP, the air interface load is limited and reaches the