Actix-HSDPA-Optimization

1.1. Throughput Analysis 1.1.1.

HSDPA Low Throughput Analysis

HSDPA offers users enhanced data rates and improved latency over traditional R99 bearers, with throughputs as high as 14.4Mbps achievable. With HSDPA, users make use of the DSCH (comprising several sf16 codes) rather than the DCH for data transfer in the downlink, the scheduling of user data is performed by the a new MAC entity (MAC-hs) in the NodeB rather than the RNC and fast HARQ is used to minimize RLC retransmissions caused by errors introduced over the air interface. The table below summarizes the Ericsson HSDPA baseline configuration: Parameter

Baseline Settings

hsPowerMargin

2 (0.2 dB)

maxNumHsPdschCodes

5

supportOf16qam

TRUE 2 (PROPORTIONAL_FAIR_HIGH)

queueSelectAlgorithm

 Assuming a UE class that that allows allows sequential sequential TTI scheduling, scheduling, this this configuration configuration allows for a maximum throughput for a single user of 3.6 Mbps. The definition of a low HSDPA throughput event in Actix is: Raw Throughput: (Physical Layer throughput) – Raw HSDPA throughput lower than 400kbps occurs for longer than 3 seconds. Net Throughput: (MAC-hs layer throughput) – MAC-hs layer HSDPA throughput lower than 300kbps occurs for longer than 3 seconds.  As the individual individual low throughput throughput events will will be too numerous numerous to investigate, investigate, it it is necessary necessary to identify and analyze throughput related to a common thread, eg. An area of limited coverage causing low throughput or low throughput unique to a specific cell or site. The following section describes how to locate low throughput events and analyze these events using  Actix Spotlight. Spotlight.

1.1.2.

HSDPA Low Throughput Analysis

HSDPA offers users enhanced data rates and improved latency over traditional R99 bearers, with throughputs as high as 14.4Mbps achievable. With HSDPA, users make use of the DSCH (comprising several sf16 codes) rather than the DCH for data transfer in the downlink, the scheduling of user data is performed by the a new MAC entity (MAC-hs) in the NodeB rather than the RNC and fast HARQ is used to minimize RLC retransmissions caused by errors introduced over the air interface.  Assuming a UE class that that allows allows sequential sequential TTI scheduling, scheduling, this this configuration configuration (5 codes/UE) allows for a maximum throughput for a single user of 3.6 Mbps. The definition of a low HSDPA throughput event in Actix is:

Raw Throughput: (Physical Layer throughput) – Raw HSDPA throughput lower than 400kbps occurs for longer than 3 seconds. Net Throughput: (MAC-hs layer throughput) – MAC-hs layer HSDPA throughput lower than 300kbps occurs for longer than 3 seconds.  As the individual low throughput events will be too numerous to investigate, it is necessary to identify and analyze throughput related to a common thread, eg. An area of limited coverage causing low throughput or low throughput unique to a specific cell or site. The following section describes how to locate low throughput events and analyze these events using  Actix Spotlight.

1.1.3.

Using Actix to Identify Low HSDPA Throughput

HSPDA throughput is summarized by spotlight into a category with an associated workspace. The following sections detail how to access this workspace and associated attributes that can be used to assist in analysis. 1.1.3.1.

Event Explorer

Using spotlight it is possible to identify specific instances of low throughput for an HSDPA service. This is done by selecting the HSDPA Throughput option from the category drop down in the event explorer as shown in Figure 1.

Figure 1: Selecting HSDPA Throughput Event Category

The individual low throughput events are listed in the lower left hand pane (Figure 2) along with some preliminary Actix interpreted cause and explanation (shown in Figure 3) of how the cause was determined. It is important that the Actix cause information be used as a reference only as not all causes of low throughput fit within the defined thresholds and cause types available.

Figure 2: Low Throughput Event Selection

Figure 3: Low Throughput Event Cause Information

When selecting low throughput events for drill down, look for events clustered in specific areas as the cause is likely to be the same or similar for many events in a given area. 1.1.3.2.

Drill Down

Once selected for drilldown, a newly configured workspace is loaded specifically for low throughput investigation; a capture of the drill down layout is shown in figure xxx.

a) c)

b) d)

Figure 4: Low Throughput Drill-down

The four forms shown in the analysis window cover the basic requirements for throughput analysis. a) HSDPA Radio Charts The information presented in the five charts within this form is the most useful for determining the cause of low throughput. i. CQI – UE reported CQI. ii. Throughput (RAW and MAC) – plot of raw physical layer throughput with MAC layer throughput. iii.  ACK/NACK – percentage of Acknowledgments and Negative Acknowledgements sent, including DTX samples in the total sample space. iv. DTX – discontinuous transmission, DTX rate is equal to the total Number of DTX received divided by the total number ACK, NACK and DTX reported, as a percentage. v. MAC FER – MAC frame erasure rate is the number of HS-DSCH blocks received in error over the total number of valid HS-SCCH decodes. b) HSDPA Radio Table The information presented in this table provides an instantaneous reference for: a) CQI – UE reported CQI b) Max CQI expected – maximum CQI achievable based on UE class c) NACK Rate (without DTX) – NACK % when considering only received transport blocks. d) HS-MAC BLER – block error rate as seen at the MAC-hs entity in the UE. e) 16 QAM Modulation usage – percentage of TTI’s over a 200ms interval that use 16QAM.

f) UE State – indication of the current UE state, useful to check if UE is in HS-DSCH state at the time of a low throughput event. g) Time – timestamp of the selected event or point in the file. h) HS Serving Cell i. SC – scrambling code of the active set cell transmitting the HS-PDSCH ii. Ec/No – current Ec/No of the serving scrambling code c) Protocol Stack Browser The protocol stack browser contains all the layer 3 messaging for a session. This data is used during the analysis to observe UE interaction with the network. For HSDPA the primary use is to observe call establishment, mobility, state transitions (HSDPA -> DCH for example) and session teardown. The messages that are most useful for HSDPA analysis are: a) Radio Bearer Setup – indicates whether or not HSDPA is allocated b) Radio Bearer Reconfiguration – required for state transition and ISHO procedures. c) Physical Channel Reconfiguration – used for HS-PDSCH switching (best server change) d) Measurement Reports – particularly e1d triggers d) Map When first opened the map displays graphically the application throughput, and low throughput events can be observed spatially this way. It is possible to display any map based attribute on this map using the attribute explorer to support analysis as required. (eg. Ec/No, RSCP, average CQI etc.) 1.1.3.3.

Additional Attributes

While the forms and charts presented in the basic workspace give a useful insight into the session performance there are several other attributes that can be displayed or referenced to assist in analysis.  An indication of throughput at various layers in the protocol stack provides useful information on the cause of low throughput. Actix is able to extract a measure of throughput at several points in the protocol stack, the main lower layer throughput attributes that should be referenced during the analysis are listed below: 1. Uu_HSDPA_PayloadRate_L1 – total L1 throughput, includes retransmissions and erroneous packets 2. Uu_HSDPA_Throughput_L1 – HARQ level throughput, excluding transport blocks received in error 3. Uu_HSDPA_Throughput_MAC – HARQ level throughput, excluding transport blocks received in error and multiple reception of the error free transport blocks. The HSDPA Radio Charts – Throughput plots. To view the additional throughput metric it is necessary to use the attribute explorer as shown in Figure 5 and Figure 6.

Figure 5: Locating Attribute Explorer

Figure 6: Location of Specific HSDPA Throughput Attributes

The throughout attributes mentioned above are measured at L1 and MAC-hs layers and relate to the throughput between the Ue and the NodeB, these attributes are not necessarily indicative of the throughput experienced by the user. To view the resulting user or application layer throughput and session progress the following attributes should be referenced: a)  Application Throughput DL – user realized throughput at the application layer.

b) Cumulative Rx Bytes – shows the cumulative application layer bytes downloaded over the duration of a session. These can be found using the attribute explorer as shown in Figure 7.

Figure 7: Location of Specific Application Throughput Attributes

When these attributes are plotted together on the same chart it is possible to quickly reference areas of low throughput, and session issues for the loaded log file. Figure 8 shows an example.

Figure 8: Physical Application Layer Throughput & Received Cumulative Bytes

The sessions shown in this example are a good reference; the first session shows a download within a variable RF environment, throughput declines throughout the session which takes a long time to complete; the second session suffers low throughput and drops prior to completion (cumulative Rx bytes does not reach 5MB); the third and fourth show near ideal FTP download sessions with largely stable throughput and fast completion; the final session shown is another failure example where very little data is transferred prior to drop. In addition to the summarized attributes available via the attribute explorer it is also possible to review every message in the UE logs, including proprietary messages relating to physical layer and MAC layer measurements using the message browser. The message browser is accessed via the  View menu as shown in Figure 9. While not traditionally used for analysis the following messages are useful when investigating HSDPA  throughput: a) HS-DSCH HARQ Statistics Log Packet - contains information pertaining to the 6 individual HARQ queues providing the number of new transmissions vs. retransmissions (up to four). b) HS Decode Status Log Packet – contains HS-SCCH decode information and TFRC configurations for 100 TTI’s. The structure of these logs is shown in Figure 9 Figure 10.

Figure 9: HS-DSCH HARQ Statistics Log Packet

Figure 10: HS Decode Status Log Packet Example

1.1.4.

Using Actix To Identify Low HSDPA Throughput

The following workflow describes a process for investigating low throughput in HSDPA 

Start Analyzing Low HSDPA Throughput

TCP slow start

Y

1 Beginning of session?

N 2 Check UL/DL Load, parameter configuration.

N

HS-DPSCH assigned?

Y Y

3 Low CQI? 20%

5 High NACK %? >20

Possible NodeB/ATS issue

N Y Mobility Issue

6

UE in slow or ping pong BS switching?

N

Possible e2e issue

Figure 11: Low HSDPA Throughput Analysis Flowchart

Each stage of analysis shown in the flowchart above is discussed below with recommended solutions: 1. Beginning of the Session - TCP Slow Start Immediately following PDP Activation Accepted the application throughput begins to ramp up slowly towards the achievable rate. This is due to TCP congestion control algorithms and is called TCP slow start. This will result in lower than expected throughput over the first few seconds of a

HSDPA session, this is normal application behavior and should not be considered as a low throughput problem. Figure 12 shows an example of TCP slow start, the beginning of the session is indicated by a red dashed oval.

Figure 12: TCP Slow Start Example

Recommendation: None 2. No HS-DSCH Assignment HS-PDSCH Assignment – if the HS-PSDSCH is not available the UE will be assigned (resource dependent) a R99 DCH bearer. This will result in lower than expected throughput as R99 DCH bearers have a maximum bearer rate of 384kbps. A HS-PDSCH is assigned to UE provided: a. HSDPA is configured and is operational in the cell. b. UE supports HSDPA  c. The number of users allocated in a cell does not exceed 16. d. Sufficient code resources are available. e. Downlink Load is below the admission threshold for HSDPA. f. Uplink Load is below the admission threshold for the creation of the associated DCH.

Recommendation: confirm parameter set is aligned to CIQ and HSDPA is enabled in the cell. Check for abnormally high load (UL and DL) using RNC counters over a low traffic period. Fault related loading may result in the allocation of a non-HSDPA bearer, if high load is present with low traffic, this indicates a problem with the Node B or antenna system, escalate to field operations to investigate further. 3. Low CQI

CQI – Channel Quality Indicator – is a measure of channel quality, estimated and reported by the UE and possibly adjusted by the NodeB before being used with lookup tables to determine the appropriate TFRC to use in the next scheduled TTI. As the NodeB does may not directly use the reported CQI values, discrepancy between the allocated TFRC and expected TFRC is possible, however commonly low CQI results in a TFRC with low user data throughput and a high CQI results in high throughput within the capability of the UE and network. Figure 13 shows an example of how CQI affects throughput. In this example CQI increases from approximately 15 to 21 as a result of a HS-DSCH switch, resulting in a significant increase in throughput.

Figure 13: Impact of CQI on Throughput

Recommendation: low CQI indicates poor channel quality, resulting from low RSCP and or Ec/No. Optimize the downlink coverage in the area of concern to improve coverage and or dominance. The same steps as presented for the coverage analysis in the R99 DCH may be followed. 4. High DTX % DTX – The DTX percentage is a measure of the percentage of available TTI’s a given UE has not been scheduled for, that is, a high value near to 100% indicates that the UE is rarely being scheduled, a value close to 0% indicates that the UE is nearly always being scheduled. The following are possible causes of high DTX: a. UE is incapable of receiving subsequent TTI’s as defined by UE class. b. UE is being starved (under-scheduled) by an unfair scheduler (eg. MAX CQI or Proportional Fair with low fairness) c. Lack of data to transmit, ie. The Node B’s buffer for the given UE is empty at or for a number scheduling intervals. i. Congestion on the Iub preventing the NodeB buffer from being replenished. ii. Slow or congested application server.

d. UE does not receive scheduling indications on the HS-SCCH due to poor downlink  coverage/interference. e. Level of sharing on the HS-PDSCH – ie. Number of users. If there are two active HSDPA users in a cells coverage area, DTX will approximate 50% per user (assuming round robin scheduling) and throughput will be halved. Figure 14 shows an example of low scheduling rate in good RF.

Figure 14: High DTX in Good RF causing Low Throughput

Recommendation: Where a consistently high DTX rate is observed in good RF across a wide area of a cells footprint it is probable that there is a hardware issue at the NodeB, this should be escalated to field operations to investigate further on site. It may be necessary to re-commission HSDPA on the site. Where high DTX is observed sporadically throughout a session it is probable that there is insufficient data in the buffers for the UE to be continuously scheduled, this can be due to congestion in the Iub or an under-performing FTP server. Verify the performance of the FTP server with static testing and check RNC counters for Iub congestion events. 5. High NACK %  ACK vs. NACK – For every TTI in which a UE is scheduled to receive data, the UE will respond by sending an ACK or NACK depending on whether or not the transmission was correctly received or not. (Note that if the UE does not receive the scheduling information on the HSSCCH, no HARQ response is sent (DTX)).  As each NACK requires a physical layer retransmission of the transport block a high percentage of NACK’s can cause low throughput. This is only true where Uu_ HSDPA_Throughput_MAC decreases as a result. It is feasible that the retransmissions can be absorbed with a higher Uu_HSDPA_Payload_L1 rate.

 A consistently high NACK % indicates that the link adaptation algorithm is not able to adequately track the radio environment, this can result from: a. NodeB or ATS problem – when a site or cell is consistently showing high NACK % for all sessions on the site / cell, this can indicate a problem with the NodeB configuration or antenna system. b. UE is over reporting CQI – less likely scenario as CQI reporting accuracy is standardized. There is still a possibility that a UE under performs in this area however and this will cause a reduction in system throughput when more than one user is active in a cell.

Figure 15 shows an example of consistently high NACK % in good RF.

Figure 15: High NACK Impacting User Throughput

Recommendation: If present consistently from a given time to the end of the drive test verify the UE performance in a static test to rule this out as a cause. If the problem is observed on all HSDPA connections in a particular cell escalate to a field technician to verify the antenna system and antenna system settings in the NodeB for the affected cell/cells, and to confirm the HSDPA  commissioning parameters, these should align to the CIQ data. To overcome UE CQI overreporting it is possible to use the E\\\ RBS cqiAdjustmentOn parameter. This activates the NodeB CQI adjustment algorithm which targets a NACK% of 10%. Warning – this can result is reduced user throughput in good RF. This parameter should not be changed without prior approval.

6. Mobility Mobility – while mobility should no longer severely impact user throughput (with the use of ADCH SHO and HS-PDSCH switching), it is possible that incorrectly set mobility parameters for HSDPA may cause delayed HS-PDSCH switching, as a result the HS-PDSCH may not always be on the best server and experience lower than achievable throughput. In addition constant

switching or ping pong switching can cause reduced application throughput as data in the source NodeB buffer is discarded and recovered in the target cell through higher layer retransmissions (RLC). Recommendation: verify e1d trigger parameter alignment, optimize SHO area by creating single cell dominance in the affected area.