gsm-to-umts training series 23_hspa data transmission troubleshooting_v1.0

8/12/2019 GSM-To-UMTS Training Series 23_HSPA Data Transmission Troubleshooting_V1.0

1/92

HUAWEI TECHNOLOGIES CO., LTD.

www.huawei.com

HUAWEI Confidential

Internal

HSPA Data Transmission

Troubleshooting

GSM-to-UMTS Training Series_V1.0


2/92

HUAWEI TECHNOLOGIES CO., LTD. HUAWEI Confidential Page 2

Date Revision

Version

Description Author

2008-01-20 1.0 Draft completed Gao Bo


3/92


Preface

With the evolution from the WCDMA to the HSPA, the HSPA service becomes a basic service of wireless networks,

just like the voice service. The HSPA rate is a basic test item in the competition tests and admission tests of a pilot

office. The HSPA rate also becomes a basic test item in the presentation, version upgrade, and service verification

of a commercial office.

The equipment of the end-to-end voice service such as the calling UE, BTS, BSC, and called UE is standard

telecom network equipment; therefore, the QoS of the voice service is guaranteed. In addition, the rate of the voice

service is relatively low and requires less resources. Hence, the probability of a service failure is low.

The end-to-end HSPA service involves more equipment, that is, equipment from the data card to the laptop on the

terminal side, equipment from the GGSN to the server on the network side, and equipment involved in public

networks. Laptops and servers are usually used by individual users; therefore, the QoS (especially the QoS of a

laptop) is not guaranteed. The performance of a laptop can be hardly controlled after more software is installed on

the laptop; therefore, the HSPA rate problem may occur.


4/92


Preface

Rate is an end-to-end issue, involving NEs such as laptop, UE, air interface, NodeB, Iub

interface, RNC, Iu interface, SGSN, Gn interface, GGSN, Gi interface, transport network, and

server. If any of them is faulty or the performance is poor, the PS rate decreases or is unstable.

Because so many NEs are involved, a problem is located difficultly in the earlier stage. If the

range of a problem is as specific as a NE and corresponding adjustments and test measures are

found, we can try more tests to locate the cause of the fault.

Key to Locate a rate fault: Find the faulty NE


5/92


Objective

Master the definitions of various rates of PS service layers and their

conversion relationships

Master common factors affecting the data transmission of the HSPA

service

Master the methods of analyzing various HSPA problems through drive

test data by using the Probe

Master the methods of tracing and analyzing various HSPA problems by

using the CDT tool

Master the self-test methods of HSPA problems

After this course, you are able to:


6/92


Contents

Chapter 1 HSPA Concepts

Chapter 2 HSPA Data Transmission ProblemChecklist

Chapter 3 Analysis for Poor Performance of theBearer Data Transmission of HSPA(Based on Probe Data)

Chapter 4 HSDPA Troubleshooting from the RAN(Based on CDT Tracing)


7/92



1.1 Protocol Layers of User Plane

1.2 Definitions of Common Rates

1.3 HSPA Rates Tested by Using the

Probe Tool


8/92


Data transmission Channel of the PS Service

NE: Ftp ServerCNRNCNodeBUE

User planeThe MAC-hs/e entity is added to

the R5.


9/92


New Protocol Structure of HSPA

UuUE Node B

DTCH DCCH DTCH DCCH

MAC-d

MAC-hs

PHY

MAC-

hs

PHY

HS-

DSCH FP

AAL2 or

UDP/ IP

ATM or

IP

ATM or IP

AAL2 or UDP/IP

HS-DSCH FP

MAC-d

CRNC/SRNCIub

New protocol structure of HSDPA PS (MAC-hs)

New protocol structure of HSDPA PS (MAC-e)

PHY PHY

EDCH FP EDCH FP

IubUE NodeBUu

DCCHDTCH

TNL TNL

DTCHDCCH

MAC-e

SRNC

MAC-d

MAC-e

MAC-d

MAC-es /MAC-eMAC-es

Iur

TNL TNL

DRNC


10/92


Data Frame Structure of User Plane Protocols of the HSDPA Service

The MAC-hs/e entity is

added to the R5 protocol.

Structure of the R99 MAC

layer


11/92


Data Frame Structure of User Plane Protocols of the HSUPA Service

MAC-d Flows

MAC-es PDUMAC-e header

DCCH DTCH DTCH

HARQprocesses

Multiplexing

DATA

MAC-d DATA

DATA

DDI N Padding(Opt)

RLC PDU:

MAC-e PDU:

L1

RLC

DDI N

Mapping info signaled over RRC

PDU size, logical channel id, MAC-d flowid => DDI

DATA DATA

MAC-d PDU:

DDI

Header

MAC-es/e

NumberingMAC-es PDU: TSN DATA DATA

Numbering Numbering


12/92


Data Frame Structure of User Plane Protocols of the HSUPA Service

MAC-d PDU MAC-d PDU MAC-d PDU

MAC-es SDUMAC-es SDUTSN1N1DDI1 MAC-es SDU

MAC-d PDUs coming from one Logical Channel

N1 MAC-es SDUs of size and LCh indicated by DDI1

MAC-es PDU1

DDI1 N1 DDI2 N2

DDI1 N1 DDI2 N2 DDIn Nn DDI0(Opt)

MAC-es PDU1 MAC-es PDU2 MAC-es PDUn

MAC-es PDU2MAC-es PDU1 DDIn Nn MAC-es PDUn

MAC-e PDU

SI

(Opt)

Padding

(Opt)

MAC-es PDU

MAC-e PDU


13/92





1.3 HSPA Rates Tested by Using the

Probe Tool


14/92


Rates of the R99 PS Service (PS64k, PS128k, PS384k)

RLC Payloadrate (input rate of the RLC layer, excluding the RLC header overhead)

The maximum RLC Payload rates of different services can be calculated according to

their transmission formats.

For example:

For 384K PS service:

TB Size = 336bits, TB Number = {12,8,4, 2,1,0}, TTI = 10ms

Because TB Size equals the MAC PDU size:

RLC Payload = MAC PDU-MAC header RLC header.

For a dedicated channel: MAC header = 0 bit, RLC header = 2 bytes = 16bits

Hence, RLC Payload = 336 0 16 = 320 bits.

RLC Payload rate = (RLC Payload Size * TB Number)/TTI = 320*12/10=384 kbps


15/92


HSDPA PS Service Rate (Theoretical CAT6 Rate)

RLC Payloadrate (input rate of the RLC layer, excluding the RLC header overhead)

Step 1: Search the CAT6 CQI schedule extended table to get the maximum TB size and

TTI that can be used by UE CAT12:

TB Size = 7298 bit, TTI = 2ms.

Step 2: Calculate the MAC-d PDU Number that can be carried according to the maximum

TB Size.

If: MAC-d PDU Size = 336;

Then: MAC-d PDU Number = int(7298/336) = 21

Step 3: Subtract the MAC-d header and RLC header to get the RLC Payload rate

The length of the MAC-d header and RLC header is 16 bitin total.

If MAC-d PDU Size = 336 and the maximum TB Size that can be used by UE CAT6 is 7298,

the theoretical rate of UE CAT6 (RLC Payload rate) is calculated as follows:int(7298/336)*320/2 = 3.36Mbps.

If MAC-d PDU Size = 656 and the maximum TB Size that can be used by UE CAT6 is 7298,

the theoretical rate of CAT6 (RLC Payload rate) is calculated as follows:

=int(7298/656)*640/2 = 3.52Mbps.


16/92


HSUPA Capability Categories of UEs

E-DCH

category

Maximum number of

E-DCH codes

transmitted

Minimum

spreading

factor

Support

for

10 and 2 ms

TTI EDCH

Maximum number of

bits of

an E-DCH transport

block

transmitted within a 10 msE-DCH TTI

Maximum number of bits of an

E-DCH transport block transmitted

within a 2 ms E-DCH TTI

Category 1 1 SF4 10 ms TTI only 7110 -

Category 2 2 SF4 10 ms and 14484 2798

2 ms TTI



2 ms TTI



2 ms TTI

NOTE: When 4 codes are transmitted in parallel, two codes shall be transmitted with SF2 and two with SF4


17/92


HSDPA PS Service Rate (Theoretical Rate of UE CAT3)

RLC Payloadrate (input rate of the RLC layer, excluding the RLC header overhead)Step 1: Search the HSUPA capability categories table of UEs to get the maximum E-DCH

TB Size and the supported TTI of UE CAT3:

E-DCH TB Size = 14484 bit; TTI=10ms;

Step 2: Calculate the MAC-d PDU Number that can be carried according to the maximum

TB Size.

If: MAC-d PDU Size=336

Then: MAC-d PDU Number = int(14484/336) = 43;

Step3: Subtract the MAC-d header (0bit) and RLC header (16bit) and get the RLCPayload rate.

The total length of the MAC-d header and RLC header is 16bit. Hence, RLC Payload Size

33616320bit.

Theoretical rate of UE CAT3 (RLC Payload rate) = 43*320/10 = 1.376 Mbps.


18/92


Uplink and Downlink Throughput of RNC Radio Performance Monitoring

The MAC SDU rate (input rate of the MAC layer), or the RLC PDU rate (output rate of the

RLC layer), includes the retransmitted data of the RLC layer.

MAC-d SDU Rate = (TB Size*TB Number)/TTI

R99 PS384K service: MAC layer throughput(33612)/10 = 403.2 kbpsHSDPA CAT6MAC SDU Size=336

MAC-d SDU Rate=int(7298/336)*336/2 = 3.528 Mbps.

HSDPA CAT6MAC SDU Size=656

MAC-d SDU Rate=int(7298/656)*656/2 = 3.608 Mbps.

HSUPA CAT3, MAC SDU Size=336

MAC-d SDU Rate=int(14484/336)*336/10 = 1.444 8Mbps.


19/92


Application Layer Throughput Statistics by DU Meter

The rate obtained based on DU Meter is the rate of the IP layer (including the IP protocol header). See

the data transmission rate on B interface in the figure below:

PDCP

PHY

MAC

RLC

UE

B

Computer

Receive data

When the PDCP header overhead is 0 (no PDCP header compression and the lossless relocation is not

supported), the rate measured by the DU Meter equals the RLC Payload rate.


20/92





1.3 HSPA Rates Tested by Using the Probe Tool

HSDPA R t T t d b U i th P b T l


21/92


HSDPA Rates Tested by Using the Probe Tool

Scheduled Rate-Delta: Transient rate scheduled by the

MAC layer (the transient rate is the average rate within

200ms, same below)

Scheduled RateAverage: Average rate scheduled by

the MAC layer (average of all the data mentioned above,same below)

Served RateDelta: Transient transmission rate of the

MAC layer, including transmission failure andretransmission

Served RateAverage: Average transmission rate of the

MAC layer, including transmission failure and

retransmission MAC Layer RateDelta: Transient transmission rate of

the MAC layer, not including transmission failure and

retransmission

MAC Layer RateAverage: Average transmission rate of

the MAC layer, not including transmission failure and

retransmission HS-SCCH Success RateDelta: Scheduling success

ratio of HS-SCCH-Transient (scheduling success ratio)

HS-SCCH Success Rate

Average: Scheduling successratio of HS-SCCH- Average (scheduling success ratio)

HS-DSCH SBLER - Delta: Block error rate of HS-DSCH -

Transient (Number of error blocks/Total number of blocks)

HS-DSCH SBLER - Average: Error block rate of HS-DSCH -

Average

HS-DSCH Res. SBLER - Delta: Residual SBLER of HS-

DSCH - Transient (transient error block rate of the RLC

layer. That is, if the transmission still fails after multiple

retransmission attempts by the MAC layer, the RLC

originates the retransmission) HS-DSCH Res. SBLER - Average: Residual SBLER of HS-

DSCH - Average

CQI: Average channel quality indicator (average of all

CQIs within 200 ms)

Number of HS-PDSCH Codes: Average number of

occupied HS-PDSCH codes (Average of all codes within

200 ms)

Relations between HSPDA Rates


22/92


Relations between HSPDA Rates

Sum of the bits of all TB blocks received by the MAC-HS layer in the measurement period: A1+A2

Sum of the bits of all TB blocks received by the MAC-HS layer in the measurement period: A1

Sum of the bits of all TB blocks receivedby the MAC-HS layerin the measurement period: A2

Duration of the measurement period: T1 + T2

Sum of time with TB block receiving in the measurement period: T1Sum of time without TB block receiving in the measurement period: T2

Then, the HSDPA-related rates provided by the Probe tool are as follows:

Rate Definition Relation

Scheduled Rate = (A1+A2)/T1 None

HS-SCCH Success Rate = T1/(T1+T2) None

Served Rate = (A1+A2)/ (T1+T2) Served Rate = Scheduled Rate * HS-SCCH Success Rate

SBLER = Sum of incorrectly received TB

blocks/(Sum of correctly received

TB blocks + Number of incorrectly

received TB blocks)

None

MAC Layer Rate = A1/(T1+T2) MAC Layer Rate = Served Rate*(1 - SBLER)

RLC Throughout None RLC Throughput = MAC Layer Rate * (1 - MAC-HS PDU

header overhead ratio)

Note: To get the exact relation, both the header

overhead and the Padding bits added when the TB Size

does not match N RLC PDU bits must be subtracted.


23/92


24/92


Relations between HSUPA Rates

Rate Definition Relation

MAC-e PDU Non-DTX Rate = (A1+A2)/T1 None

Non-DTX Probability = T1/(T1+T2) None

MAC-e PDU Served Rate = (A1+A2)/ (T1+T2) MAC-e PDU Served Rate = MAC-e PDU

Non-DTX Rate * Non-DTX Probability

SBLER = (Number of non-DTXsNumber of ACK

or ACK_NS)/Number of non-DTXs * 100%

None

MAC-e PDU Available Rate = A1/(T1+T2) MAC-e PDU Available Rate = MAC-e PDUServed Rate *(1SBLER)

RLC PDU Throughput UL =Sum of the bits of all the RLC PDU

transmitted by the RLC layer in the

measurement period/Duration of the

measurement period

RLC PDU Throughput UL = MAC-e PDU * Available Rate

(1header overhead ratio of MAC-e PDU)

Note: To get the exact relation, both the header overhead

and the Padding bits added when the TB Size does not

match N RLC PDU bits must be subtracted.

Sum of the bits of all TB blocks transmitted by the MAC-e layer in the measurement period: A1+A2Sum of the bits of TB blocks primarily transmitted by the MAC-e layer in the measurement period: A1

Sum of the bits of all TB blocks retransmitted by the MAC-e layer in the measurement period: A2Duration of the measurement period: T1+T2

Sum of time with TB block transmission in the measurement period: T1

Sum of time without TB block transmission in the measurement period: T2

Then, the HSDPA rates provided by the Probe tool are as follows:


25/92


Contents






26/92


Chapter 2 HSPA Data Transmission Problem Checklist

2.1 Factors Affecting HSPA Data Transmission

2.2 HSPA Data Transmission Problem Checklist

2.3 Common Tools and Usages


27/92


Factors Affecting HSDPA Data Transmission

MBR limitations Subscription rate

Limited AT command

TCP receive window

size of PC

Limited server rate

Transmission configuration

Iub Iu-PS

Air interface quality

Poor CQI or high

SBLER

Delay

Large Ping delay

Packet loss Iub

Iu-PS

TCP

RLC layer parameters RLC Window Size

Status report barring

timer

Parameter configuration

Power configuration

Code configuration

Equipment

RNC

Board processing

capability

NodeB

Board processing

capabilityUE

Drive exception

Capability limitation


28/92


Factors Affecting HSUPA Data Transmission

MBR limitations

Subscription rate Limited AT command

TCP receive window size

of PC

Transmission configuration

Iub

Iu-PS

Air interface quality

Channel type

Limited RSCP-UE

transmit power

Delay

Large Ping delay

Packet loss

Iub

Iu-PS

TCP

RLC layer parameters RLC Window Size

TSP

Parameter setting

Target RoT load Reference RTWP

Target retransmission times

Equipment:

RNC

Board processing capability

NodeB

Board processing capability

UE Drive exception

Limited UE capability

No response from AG

RG false alarm

No response from the

power controller;

Too high a transmit

power

Occupancy of RoT

resources


29/92





2.3 Common Tools and Usage

HSDPA Rate Problem Checklist


30/92


Category Items

1. UE and laptop

1.1 Check the UE version and drive version and ensure that the drive is installed correctly.

1.2 Check whether the TCP Window Sizeof the laptop is configured correctly. The parameter can be optimized by DRTCP. The TCP

Window Sizeshould be set to 65535and the MTUshould be set to 1500.

1.3 Check the memory of the laptop. The memory should be at least 512 M.

1.4 Check the CPU occupancy in downloading. The CPU occupancy cannot be too high to affect the downloading rate.

1.5 Disable the firewall of the laptop.

2. RAN

2.1 Check whether HSDPA is activated by run the command DSP CELLon the RNC LMT.

2.2 Check the number of HSPDSCH codes allocated to the HSDPA. If the HSDPA rate is 7.2 Mbit/s, 10 codes must be available

(dynamical or static allocation).

2.3 Check the maximum available power allocated to H. The dynamic power control, namely the maximum transmit power of the cell, is

often configured.

2.4 Check the versions of the RNC and NodeB.

2.5 Check the bandwidth configuration of Iub. In ATM mode, at least 5 E1s must be available for the 7.2 Mbit/s HSDPA and the

recommended available bandwidth for H is 9 Mbit/s or above. The NodeB should be configured with the RCR


31/92


3. CN

3.1 Check the subscription rate of SIM cards. The downlink subscription rate should be 7.2 Mbit/s and the recommended uplink

subscription rate is 384K.

3.2 Check the setting of the rate limit switch on the SGSN. Both the maximum uplink rate and the maximum downlink rate should be

configured on the SGSN by using the command SET 3GSM. In the case of the 7.2M HSDPA, the rate limit switch should be set to254, namely 8M.

3.3 Check the setting of the rate limit switch on the GGSN. Both the maximum uplink rate and the maximum downlink rate should be

configured on the GGSN by using the command SET QOS. The rate limit switch should be set to 8M .

3.4 Make sure that all exchanges and network ports work in 100M full-duplex mode.

4. Iu interface4.1 Check the bandwidth configuration of the RNC Iu interface. The configuration must meet the requirements of the PS service.

4.2 Check the bandwidth configuration of the SGSN Iu interface. The configuration must meet the requirements of the PS service.

5.Server

5.1 If ServU is used as the server, check whether the transmit and receive buffers of ServU are set to 65535.

5.2 Check whether the TCP Window Sizeof the server is configured correctly. The parameter can be optimized by using DRTCP.

The TCP Window Sizeshould be set to 65535 and the MTUshould be set to 1500.

5.3 Service 2003 is recommended as the server, because it can monitor the CPU occupancy in downloading and avoid the effect on

the downloading rate caused by server performance.

6.Others

6.1 Use multithreaded downloading, especially when the RTT delay is large. In this case, multiple files can be downloaded at the

same time through multiple threads. When the delay is less than 1 s, it is recommended to download two files at the same time by

using 10 threads.

6.2 Check the signal quality of the test site. For example, in the presentation of the 7.2M HSDPA service, the CQI must be greate r

than 23

6.3 If the rate is very low and cannot meet the requirement, check whether the rate can be improved to the required value by

transmitting packets to the server.


32/92

HSUPA Rate Problem Checklist


33/92


2.9 Check whether the pilot configuration of the cell is correct. The pilot should be 10 dB lower than the maximum transmit power.

2.10 Check whether the RNC data between the BAM and SAM is consistent by using the command ACT CRC.

2.11 Check whether the pilot configuration of the cell is correct. The pilot should be 10 dB lower than the maximum transmit power.

3. CN

3.1 Check the subscription rate of SIM cards. The uplink subscription rate should be 1536 kbps and the recommended uplink

subscription rate is 384K.

3.2 Check the setting of the rate limit switch on the SGSN. Both the maximum uplink rate and the maximum downlink rate should be

configured on the SGSN by using the command SET 3GSM. The recommended uplink and downlink rate is 254, namely 8M.

3.3 Check the setting of the rate limit switch on the GGSN. Both the maximum uplink rate and the maximum downlink rate should be

configured on the GGSN by using the command SET QOS. The rate limit switch should be set to 8M .

3.4 Make sure all exchanges and network ports work in mandatory 100M full-duplex mode.

4. Iu interface

4.1 Check the bandwidth configuration of the RNC Iu interface. The configuration must meet the requirements of service

presentation.

4.2 Check the bandwidth configuration of the SGSN Iu interface. The configuration must meet the requirements of service

presentation.

5. Others

5.1 The built-in IIS FTP of Windows Server 2003 is recommended as the server. It can monitor the CPU occupancy in uploading

and avoid the effect on the uploading rate caused by server performance.

5.2 Check the signal quality of the test site based on the downlink signal quality. The signal quality can be deduced based on thedownlink signal quality. The recommended values are: RSCP > -80 dBm and Ec/N0 > -6 dB. If the values are too low, the path loss

will be too high and the transmit power of the UE will be limited.

5.3 If the rate is very low and cannot meet the requirement, check whether the rate can be improved to the required value by

transmitting packets to the server.


34/92





2.3 Common Tools and Usage

U f C T l


35/92


Usage of Common Tools

DRTCP: A TCP/IP registry entries adjustment utility for Windows. It is mainly used to increase the TCP window size and improve the

service throughput.

packet input tools:Objective of packet input: Avoid the effects of reverse ACK of the TCP service on the unidirectional data transmission and facilitate

the rapid location of transmission and air interface faults.

Observation method: Perform statistics on the rates of the receive and transmit ends by using DUmeter. When the receive rate does

not exceed the physical capability and is low, it indicates that packet loss occurs in an intermediate device of the transmission.Hence, the problem is possibly caused by air interface. Transmit packets at the transmit end in a rate exceeding the physical

capability. Then, check whether the receive end can receive the packets with the capability of the air interface. When the transmission

is not subject to bottleneck, the fault of the air interface can be located effectively according to the statistics of RNC CDT.

Testping

Iperf

Usage of Common Tools


36/92


L2 Data Transfer: You must make sure that the user plane data is selected in CDT tracing. Then, IP packets can be

resolved from the CDT by using the L2_Tool.exe tool. .

SGSN Data Transfer: It is used to analyze IP packets in the single subscriber tracing data of the SGSN.

DU Meter: It is used to make statistic of the transient rate and average rate of the IP layer of a subscriber.

Ethereal: It is the interface packet capture and analysis tool.

For details, see:


37/92


Contents






38/92


Chapter 3 Analysis for Poor Performance of theBearer Data Transmission of HSPA

3.1 Analysis for Poor Performance of the Bearer DataTransmission of HSDPA

3.2 Analysis for Poor Performance of the Bearer Data

Transmission of HSUPA

Analyze the problem of the poor

data transmission performance on


39/92


Pro

cess

of

Ana

lysis

for

Po

or

Per

formanceoftheBearerDa

ta

Transmissionof

HSDPA

End

data transmission performance on

the RAN side

Is the Scheduled Rate low?

N

N

N

Does the NE report an alarm? Y Clear the alarm

Y P er fo rm th e tr ou bl es ho ot in g

Is the MAC Layer Rate low?

N

YSolve the problem of the high

SBLER

Is the APP/RLC throughput ratio low? YCheck the TCP receive

window and MTU setting

N

Is the service established on the

HSDPA?Y P er fo rm t he t ro ub le sh oo ti ng

Is the Served Rate low?

N

YSolve the problem of the low

HS-SCCH success ratio

Is the RLC Layer R ate low? Y Perform the troubleshooting

N

Whether the Service is Established on HSDPA


40/92


Method 1:

Check whether the cell serving HSDSCH RL indicatorin the signaling message

RB SETUP of RNC is True. If the value is True and the SF of the downlink

channel code is 256, it can be concluded that the service is carried on HSDPA.

Whether the Service is Established on HSDPA


41/92


Method 2:

Check whether the CQI and other information is reported in the WCDMA HSDPA

Link Statisticswindow of the Probe. If no information is displayed in the window, it

can be concluded that the service is carried on DCH.

Analysis of the Service Not Carried on HSDPA


42/92


y

The HSDPA cell is not establishedCheck whether the HSDPA cell on the RNC side is activated by running the command LST CELLHSDPA.

Check whether the local cell at the NodeB side is configured to support HSDPA. Run the command LST LOCELL to see

whether TRUEor FALSEis returned.

The type of HSDPA AAL2PATH is configured incorrectly or is not configuredThe type of the HSPDA AAL2PATH should be set to HSDPA_RTor HSDPA_NRT. Otherwise, only the R99 service can be

transferred. The type can be queried on both the RNC and NodeB sides by using the command LST AAL2PATH.

HSDPA user admission fails

If the admission of HSDPA service fails, the RNC reconfigures the HSDPA service to the384kbps of the R99 service. If the service establishment still fails, the RNC reduces the rate

of the R99 service and attempts the establishment again. If the HSDPA user accessing rate

of is low and is close to 384 kbps, 128 kbps, or 64 kbps, it can be concluded whether the

service is carried on the HSDPA and whether the admission fails.

The HSDPA threshold of the downlink BE service is too highThe HSDPA threshold of the downlink BE service defines the rate decision threshold for

carrying the PS domain Background/Interactive service on HS-DSCH. The service can be

carried on HS-DSCH only when the maximum downlink rate of the PS domain

Background/Interactive service is equal to or greater than the threshold; otherwise, the

service must be carried on DCH.

In RNC, the parameter can be configured by running the command:

SET FRC: DlBeTraffThsOnHsdpa=D384

Low Scheduled Rate


43/92


Low Scheduled Rate

The factors that affect the Scheduled Rate include CQI, available power of the HSPDA cell, and the

available code of the HSDPA cell.

CQI

When the downlink rate of the UE is low, check whether the CQI reported by the UE is low first. Then, check

the Ec/Io and RSCP of the PCPICH of the current cell. Reasons for low CQI include:

The coverage is poor.

The interference is serious and the pilot is polluted.

The serving cell of the HSDPA subscriber changes too frequently and the H subscriber is not allowed to

change the serving cell as a punishment. As a result, the UE reports the low CQI.

In the case of poor coverage, improve the CQI by optimizing or adding new sites through RF.

In the case of serious interference, improve the CQI by adjusting the downtilt and azimuth of the antenna

and providing the dominant serving cell through RF.

In the case of frequent changes of the H serving cell, optimize and adjust the azimuth and downtilt through

RF or add new sites to avoid frequent serving cell changes.

Available code of the HSDPA cell

If the number of codes allocated to the HSDPA user is too small, the TB block size in NodeB scheduling will

also be affected. For the code allocation of HSDPA, see appendix 8.4.1 in PS Service Problem Optimization

Guide.

Low Scheduled Rate


44/92


Available power of the HSDPA cellAnalyze the factors that affect the available power of the HSDPA as follows:

In NodeB, run the command LST MACHSPARA to query the configured power margin. The default power margin is 10%.

That is, the total downlink load of the cell is allowed to reach 90% of the total power of the cell. In RNC, choose Real-time Performance Monitoring-> Cell Performance Monitoring -> Cell Downlink Carrier Transmit

Power and check the downlink carrier transmit power of the current cell and the power used by non-HSDPA users. The

available power of HSDPA equals the downlink carrier transmit power of the cell subtracted by the power used by non-HSDPA

users. If the power used by non-HSDPA users is too high, the available power of HSDPA is inevitably reduced, thus affecting

the Scheduled Rate.

HSDPA UE CATEGORY The 3GPP TS 25.306 specifies 12 UE Categories. The maximum TB size of the UEs of different categories in the same TTI

are different. Hence, the maximum Scheduled Rate available for the UEs are also different.

The UE reports the UE capability in the RRC Connection Setup Completemessageand the cell hsdsch physical layercategoryprovides the terminal capability.

The amount of data that can be scheduled by a user is smaller than the maximum TB Size The TB Size actually scheduled by the NodeB depends on not only the available power and codes of the user, but also on the

data volume that can be transmitted by the user. If the data volume that can be transmitted is smaller than the TB Size that

can be scheduled, the rate of the physical layer is smaller than the expected value.

This problem occurs only when data still exists in the NodeB buffer and its size is less than one schedulable maximum TB

Size.

Low Served Rate


45/92


According to the formula mentioned above:

Served Rate = Scheduled Rate * HS-SCCH Success Rate

When the Scheduled Rate is normal, the low Served Rate is caused by low scheduling success ratio of HS-

SCCH. In the normal single user condition, if the power and traffic volume of HS-SCCH are not limited, the

HS-SCCH scheduling success ratio should be 100%. The HS-SCCH success ratio of the user depends on the HS-SCCH power, HS-SCCH quantity, user

quantity, schedule algorithm, and transferrable traffic volume.

HS-SCCH power distribution ratioHS-SCCH is a downlink public channel and is shared by all users. The UE of a user keeps

on detecting the UE ID on the HS-SCCH and determines whether the TTI is directed to the

UE. After the UE confirms that the TTI is directed to it, the UE demodulates the data on the

HS-PDSCH. Hence, the data on the HS-SCCH must be demodulated correctly before datatransmission.

Number of HSDPA users and HS-SCCHsThe HS-SCCH success ratio is also affected by the number of users. If the cell contains only

one H user, the traffic volume is not limited, and the HS-SCCH power is enough, the HS-

SCCH success ratio of the user is close to 100%. If a cell contains multiple H users, the HS-

SCCH success ratio of each user is decided by the scheduling algorithm and HS-SCCH

quantity.

Generally, the HS-SCCH is configured according to the available power and the coderesources of HS-PDSCH and the traffic volume of the traffic source. In the case of a UE

CAT12, the HS-SCCH can be configured as follows:

When the HS-PDSCH is configured with 5 codes, 2 HS-SCCHs are recommended.



Low Served Rate


46/92


Scheduling algorithm

When multiple users are present and the users use different scheduling algorithms, the scheduling probabilities of the users

are different. For example, if the MaxC/ algorithm is used, users at the far end of the cell have a very low scheduling

probability or even 0, because the CQI of the users is low.

Scheduling algorithm is the function of the new functional entity MAC-hs of HSDPA. The algorithm takes four factors into

consideration, including the CQI, waiting duration, queue priority, and queue length. Of the four factors, the CQI corresponds

to the signal quality of the location that the UE is in and the waiting duration (Wait_Inter_TTI) correspond to the time that theUE waits for the service. Classical scheduling algorithms are:

MaxC/I (considering only the CQI value)

RR (considering only the waiting duration)

Classical PF (Proportional Fair, considering all the four factors)

EPFEnhanced Proportional Fair

The selection of the scheduling algorithm depends on the coverage of the cell. In the case of an indoor scene with the indoor

distribution system, the signal quality of the entire coverage area is good and the signal quality of locations in the room

differs slightly. Hence, the RR algorithm is preferred for such a scene. In the case of a outdoor scene, the coverage of

different locations differs greatly. To ensure the equity of different users, the classic PF algorithm is recommended. For V17

or later versions, the EPF algorithm is recommended.

The algorithm can be configured on the MML by running the command:SET MACHSPARA: LOCELL=10131, SM=EPF

Cell radius configured for the NodeB

Because the downlink DSP does not know the distance from the UE, it cannot get the accurate transfer delay and can only

estimate approximately based on the cell radius.

If the cell radius is less than 5 km, according to HSDPA timing relations, 15.5 timeslots are required for the HSSCCH to

schedule the user and receive the response of the scheduling. HSSCCH can schedule a user by using multiple threads.

When HSSCCH waits for the response of a scheduling, the HSSCCH can schedule other threads, which greatly increases

the efficiency. At present, at most 6 threads can be used. Because each TTI requires 3 timeslots, a cycle provides 18

timeslots. Because the RTT of the single-threaded scheduling is 15.5 timeslots, the extra 2.5 timeslots can be used by theNodeB for scheduling processing, including HS-DPCCH demodulation, HSSCCH coding, and internal delay processing.

If the cell radius is greater than 5 km, the 6 threads can be scheduled in 7 TTIs to ensure that the NodeB has enough time

for processing the scheduling. Because the scheduling can be implemented only for 6 times in the 7 TTIs, the maximum

general scheduling success ratio is 85.7% (6/7).

It should be noted that when the RRU is deployed, the extended distance of the RRU is also included in the cell radius.

Run the command ADD LOCELLto set the cell radius and set whether to support HSDPA:

ADD LOCELL: LOCELL=1, RADIUS=5000, HSDPA=TRUE;

Low Served Rate


47/92


Traffic volume

If the parameter configurations mentioned above are correct and the CQI reported by the UE is high, but the user rate is still

unstable, check the downlink traffic volume by using the connection performance monitoringof the RNC maintenance

console and confirm whether the traffic volume is enough for scheduling.

You can also obtain the downlink traffic volume through the HSDPA user flow control performance periodical reportof

the NodeB debugging console. The low served rate is caused by the unstable source rate or the single-threaded

downloading. Besides, it is also possible that the configured TCP window size is small. The HSDPA user flow control performance periodical report includes the Queue Priority, Queue Buffer Used Ratio, RLC

User Buffer Size, Input Data Size, and Output Data Size, of which, the f requently used parameters are:

A) Draw a figure on the debugging console based on the Queue Buffer Used Ratio and observe the queue occupancy of the

NodeB.

B) Observe the RLC buffer based on the RLC User Buffer Size.

C) Check the receive and transmit of queue data based on the Input Data Size and Output Data Size, of which, OutPut Data

Size is the statistics of data with received ACK.

Limited rate on the UE side

The service type required and the maximum downlink and uplink rates are sent to the UE through the command AT. The UE

then sends the information to the core network in the Active PDP context request signaling. When the subscription rate is

greater than or equal to the maximum rate requested, the core network sends the RAB Assignment request message

according to the maximum rate requested by the ATcommand. If the resources on the RNC side are not limited, the service

rate provided is the actual rate. I f the maximum downlink rate in the RAB assignment requestmessage is far lower than the

Scheduled rate and the traffic volume in the Buffer is insufficient in NodeB scheduling, the HS-SCCH success ratio will be

very low.

Methods of using the ATcommand: Select My Computer -> Properties(or Management -> Hardware -> Device Manager

-> Modem-> Properties -> Advancedand enter the command ATin the initialization command column. Except the limited

rate, the APN should also be configured in the AT command. For example, to set the APN to cmnet, maximum uplink rate to64 kbps, and maximum downlink rate to 384 kbps, run the ATcommand as follows:

AT+cgdcont=1,"ip","cmnet"; +cgeqreq=1,3,64,384

To cancel the rate limitation, run the ATcommand and set the rates to 0. The rate 0 means that the command does not apply

for a specific rate. In this case, the system automatically assigns the subscription rate:

AT+cgdcont=1,"ip","cmnet"; +cgeqreq=1,3,0,0

Low Served Rate


48/92


HUAWEI Confidential Page 48

Repetition factor of ACK/NACK

The following physical layer parameters are notified to the UE and NodeB through the upper layer signaling: Repetition factor of ACK/NACK: N_acknack_transmit

Repetition factor of CQI: N_cqi_transmit

CQI feedback cycle: CQI Feedback Cycle k

After the UE decodes HS-PDSCH data, the UE sends the HARQ ACK or NACK based on the CRC of the MAC-hs and

repeats transmitting the ACK/NACK message in N_acknack_transmit consecutive HS-DPCCH subframes. If

N_acknack_transmit is greater than 1, the UE does not attempt to receive or decode transport blocks from HS-PDSCH in

the subframes from HS-DSCH n + 1 to n + N_acknack_transmit - 1, in which, n is the SN of the last HS-DSCH subframe

of the received transport block.

Because the UE does not attempt to receive or decode transport blocks from the HS-PDSCH in the subframes from HS-DSCH n + 1 to n + N_acknack_transmit - 1, the rate of the UE becomes the following:

UE rate when the ACK/NACK is not transmitted repeatly * 1/N_acknack_transmit )

Limited Iub bandwidth If the physical bandwidth of the Iub interface is limited, the AAL2PATH bandwidth available for HSDPA is very low and the

traffic volume in the NodeB Buffer is insufficient. In this case, the HS-SCCH success ratio will be very low. In addition, the R99 AAL2PATH and HSDPA AAL2PATH are configured separately, but they share the same physical

bandwidth. If multiple R99 users are present in the same cell and occupy the Iub bandwidth, the available AAL2PATH

bandwidth available for the HSDPA will be low and the HS-SCCH success ratio will be affected.

Low MAC Layer Rate


49/92


HUAWEI Confidential Page 49

IBLER The setting of IBLER directly affects the retransmission of MAC-HS and thus affects the user rate. The IBLER refers to ratio

of the number of error TB blocks to the total number of blocks when the NodeB transmits new data. SBLER is calculated in

the following formula:

SBLER = Number of error blocks generated when the NodeB transmits new data and retransmit data/(Number of error

blocks + Number of correct blocks)

The IBLER has direct impact on the SBLER. The configuration of IBLER affects the power for scheduling each user. Its

function is similar to the function of the outer loop power control of R99. Run the command SET MACHSPARAto set the scheduling algorithm, MAC-HS retransmission times, power margin, HS-

SCCH power, and IBLER.

SET MACHSPARA: LOCELL=1, SM=PF, MXRETRAN=4, PWRMGN=10, PWRFLG=FIXED, PWR=5, IBLER=10

Low CQI and insufficient HSDPA powerWhen the CQI reported by the UE is low and the available power of HSDPA is small, the SBLER is often very high. The

reason is as follows: The MAC-d PDU size is 336 bits and the TB size required in transmission is more than 336 bits. Hence,The CQI in NodeB scheduling must be greater than a certain value. Otherwise, the requirement on IBLER convergence to

10% cannot be met.

According to the formula: MAC Layer Rate = Served Rate * (1- SBLER), the low MAC Layer Rate is

caused by high SBLER. In normal conditions, when the IBLER is set to 10%, the value of SBLER is

often lower than 15%.

Low MAC Layer Rate


50/92

HUAWEI TECHNOLOGIES CO., LTD.HUAWEI Confidential Page 50

The CQI reported by the UE is higher than the actual value

The CQI reported by the UE is inaccurate and is higher than the actual value. Though the NodeB cancorrect the value according to the configured target IBLER, the correction takes time. During the period,

the NodeB uses a lower power for data transmission according to the CQI reported by the UE. As a result,

the SBLER is increased and the data transmission performance of the user is affected.

The configured pilot power is too lowIn early NodeB versions, if the power of other channels is 10 dB higher than the pilot power in the test, the

effect on the error block rate of H is 10%.

When the power of other channels is 13 dB higher than the pilot power, the effect on the error block rate of

H will reach 100%.

At present, the NodeB can adjust the power according to the HSDPA SBLER. Hence, if the power of other

channels is 13 dB higher than the pilot power, the throughput is only slightly affected. However, the pilot

power configured cannot be too lower; otherwise, the power still cannot meet the requirements even after

the adjustment by the NodeB. In this case, the SBLER becomes high and the throughput is affected.

Low RLC Layer Rate

Th RLC AM th "A k l d t/ ti k l d t t t " f li bl d t t i i d


51/92

HUAWEI TECHNOLOGIES CO., LTD.HUAWEI Confidential

Page 51

The RLC AM uses the "Acknowledgement/negative acknowledgement strategy" for reliable data transmission and

adopts the "Gliding Window Protocol" for flow control.

Before the RLC receives the acknowledgement packet, the maximum number of PDUs that can be transmitted by the

RLC equals the RLC transmit window size. The more timely the transmit end receives the acknowledgement, the

more quickly the window slides, and the larger the allowed transmission rate of the RLC. If the acknowledgement

cannot be received timely, the transmit power of the RLC will be very low. In certain cases, the RLC reset and eventhe call drop may occur.

If the Scheduled Rate, Served Rate, and MAC Layer Rate are normal, it is necessary to determine whether the RLC

Throughput is abnormal.

The relationship between RLC Throughput and MAC Layer Rate is:

RLC Throughput=MAC Layer Rate * (1-MAC-HS PDU head overhead ratio)

Because the header overhead ratio is very small, the MAC Layer Rate curve nearly coincides with the RLC

Throughput curve in Probe.

Cell1 Cell2

RL1_dl

RL1_ul

RL2_dl

RL2_ul

Move

Definition of unbalanced downlink and

downlink RL of the softswitch area:

RL2_dl > RL1_dl

RL2_ul < RL1_ul

Low RLC Layer Rate


52/92


Page 52

The ACK->NACK/DTX ratio is too highThe ACK->NACK/DTX ratio indicates the ratio ACKs that are incorrectly resolved as NACK/DTX by the NodeB. According to the

emulation, the average probability of ACK->NACK/DTX should be less than 1%. After the NodeB incorrectly resolves the ACK as the

NACK/DTX, the NodeB retransmits the data that has been correctly received by the UE. As a result, the resources are wasted and the

user rate is reduced.

(1) The HS-DPCCH power configured is too low

The HS-DPCCH is an uplink dedicated physical channel and is used for the transmission of physical layer signals, including

ACK/NACK and CQI. The HS-DPCCH power cannot be controlled independently. Instead, the HS-DPCCH power is controlled through

an offset to the uplink DPCCH power. When the HS-DPCCH is used to carry different information contents, different offsets can be

used.

If the configured ACK/NACK power of the HS-DPCCH is too low, the probability of ACK->NACK/DTX by the NodeB uplink will beincreased, which in turn affects the user rate.

(2) The uplink and downlink RLs of the switching area are not balanced

Step1: Get the test data of the HH switching of the entire network, including the data at the UE side and RNC side.

Step2: Analyze whether the serving cell update caused by UL RL Failure occurs based on the single-user signaling tracing. If yes, check

the UE APP Throughput in the corresponding time.

Step3: Plot the uplink SIR, SIRtarget, UL BLER, downlink throughput, PCPICH RSCP, and EcNo in the same figure according to the data

on the RNC side to get the SIR of the uplink associated channel of H.

Step 4: Get the unbalanced links in the current network according to the results obtained in step 2 and step 3.

Step 5: Analyze the reason of the link unbalance and find the solution.

Low RLC Layer Rate


53/92


Page 53

The power control of the uplink associated DCH is incorrect

The uplink BLER can be obtained in the "Uplink BLER" window of the RNC connection performance

monitoring. The current baseline configuration requires a target BLER of 1%. The reason for uplink power

control convergence failure can be located from the following two aspects:

Check whether the RTWP fluctuates abnormally and determine whether uplink interference exists throughthe RTWP of the RNC cell performance monitoring.

Check whether the outer loop power control parameters of the current service are configured reasonably,

especially the parameters SIRTarget and BLERTarget.

In addition, when the HSDPA single-user draw length test is carried in a single HSDPA cell, the UE at the cell

edge sometimes reports a high CQI, but the actual rate of the user is quite low, and sometimes can even

reduce to 0. This is because that the uplink power of the UE is limited and the uplink power control does not

converge. As a result, the uplink BLER becomes high and may reach up to 100%.

The AAL2 PATH is configured incorrectly (the NodeB RCR is greater than RNC PCR or the

configured bandwidth is larger than the physical bandwidth)

Enable the RLC retransmission ratiobasedIub overbooking flow control switch. If the RLC retransmission

ratio of the HSDPA or R99 service exceeds the specified threshold, the TF limited rapid rate reduction or the

HSDPA service rate

rate reduction coefficient to reduce or eliminate congestion. After the RLCretransmission ratio becomes lower than the threshold, the TF limitation is gradually relieved until the R99

servicetransmission rate is restored, or increase the rate in in HSDPA data service rate rate increasing

coefficient mode until the HSDPA service transmission rate is restored.

Low RLC Layer Rate

The residual BLER of the MAC layer is too high and leads to a high RLC retransmission ratio


54/92


The residual BLER of the MAC layer is too high and leads to a high RLC retransmission ratioIf the number of retransmission times of the MAC layer exceed the maximum value but the data still cannot be correctly received, the TB blocks will be

discarded and packet loss occurs in the RLC layer. If the receive end detects the packet loss, the receive end requests the transmit end to retransmit

the data through the status report. Data retransmission reduces the transmission efficiency of the RLC and thus affects the effective throughput of the

RLC. High residual BLER of the MAC layer is often accompanied by high SBLER of the SBLER layer. In normal conditions, the residual BLER of the

MAC layer, that is, Res.BLER, is smaller than 1%. The BLER Res. BLER of the MAC layer can be see on the Probe.

The limited uplink rate affects the downlink rate Because both the TCP and RLC adopt the AM mode, the ACK packet must be transmitted on the DCH. Tremendous measurement data shows that the

transmission rate of the feedback information of the uplink channel is 2~3% of the transmission rate of the downlink channel. For example, when thedownlink rate is 1.6 Mbps, the corresponding uplink rate required is 32~48 kpbs. When the downlink rate is 3.6 Mbps, the corresponding uplink rateshould range from 72~108 kbps. If the uplink subscription rate of the user is 64 kbps, the rate obviously cannot meet the requirements of downlink datatransmission on the corresponding uplink rate.

If the HSDPA user needs to transmit data on the uplink, the uplink needs to transmit both the acknowledgement data of the TCP and RLC and the

uplink data of the user. In this case, if the uplink subscription rate is too low, the downlink data transmission will also be affected. The request message can be assigned through the RAB to check the uplink rate of the service. If the uplink rate is low, it is necessary to check the

subscription rate of the HLR.

Check the actually available uplink bandwidth through the RB SETUPmessage.

The abnormal RTT delay of the RLC layer (the RLC status report barring timer is unreasonable/the

uplink BLER does not converge) leads to full RLC transmit window At present, the maximum RLC transmit window size that can be configured is 2047 (the capability of the RLC receive/transmit window of the current

terminal is 2047). When the transmit rate of RLC is very high and the status report cannot be returned in time, the RLC transmit window will be full andcannot continue data transmission.

For example, if the air interface rate is 3 Mbps and the MAC-D PDU Size is 336 bit. the transmit window can transmit data for at most (2047336

/(31024) = 224 ms. If the RNC cannot receive the status report within 224 ms, the transmit window is full.

The time when the status report is returned is related to the status report barring timer and the transmit quality of the uplink air interface. If the time of

the status report barring time is configured too long or the uplink BLER does not converge, the problem will occur.

Throughput Comparison Between APP (Application

Layer) and RLC Layer


55/92


Layer) and RLC Layer

The factors that affect the TCP/IP data transmission rate include:

1. TCP receive/transmit window size configured

Though the actual receive window size changes dynamically (if the out-of-order packet is received or the

packet received cannot be delivered to the upper layer in time, the actually available window size will be

reduced), the configuration determines the maximum available receive window size.

According to the bandwidth-delay-product formula:Capacity (bit) = bandwidth (b/s) * round-trip time (s)

If the receive /transmit window size is too small, the transmission rate will be affected.

2. RTT fluctuation triggers the congestion

The DT/CQT test can get the throughputs of the APP and RLC layers. If the throughput of the APP layer/RLC

layer is lower than the range obtained by theoretical analysis, it is possible that the TCP/IP retransmission

overhead is too large. In this case, check and modify the configurations of the TCP receive window size and

MTU.

The TCP/IP uses the "inclusive acknowledgement strategy" for reliable data transmission and uses

the "sliding window protocol" for flow control. When the network congestion is detected, the

congestion control will be implemented.

THE END


56/92

Analyze the problems on the RAN

that cause the poor data

transmission performance

Po


57/92


Is the MAC-e PDU Non-DTX

Rate abnormal?

Is the service carried on

E-DCH?

Is the MAC-e PDU Served

Rate abnormal?

Is the MAC-e PDU AvailableRate abnormal?

Is the RLC Throughput

abnormal?

Is the TCP/IP Throughputabnormal?

End

Handle the problem

Handle the limited SG

Handle DTX

Handle SBLER

Retransmit on the RLC

Handle the TCP/IP problem

N

Y (unhappy)

Y

Y

Y

Y

N

N

N

N

YThe terminal capabilityis limited

The transmit power ofthe terminal is limitedThe traffic volume ofthe terminal is limited

N(happy)

Process

ofAnalysisforPoorPerforma

nce

oftheBearerDataTrans

missionofHSUPA

Whether the Service is Carried on E-DCH


58/92


Check the value of the cell serving E-DCH RL indicatorin the signaling message RB

SETUPof the RNC. If the indicator is True, the service is carried on the HSUPA.

Method 1:

Whether the Service is Carried on E-DCH

Method 2:


59/92


Check whether SG and other information are reported in the HSUPA Link Statisticswindow of

the drive test tool PROBE. If no information is displayed in the window, the service is carried on

DCH.

Method 2:

Analysis of Service Not Carried on HSDPA


60/92


If the service fails to be carried on HSUPA, locate the reason as follows:

Check whether the capability reported by the UE supports HSUPA. The UE reports whether the HSUPA

and HSDPA functions are supported in the RRC_CONN_REQUEST message, and the specific E-DCH

capability level is reported in the RRC_CONN_SETUP_CMPmessage.

Check whether the MBR in the uplink subscription information is normal and whether the rate threshold of

the E-DCH bearer is too high. If the MBR assigned by the CN does not exceed the rate threshold for

using the E-DCH bearer, the service will be carried on the DCH.

Check whether the HSUPA cell is available and whether it is activated.

Check whether the HSDPA user admission fails.

Check whether the HSUPA AAL2PATH type is configured correctly or not configured.

Similar to HSDPA

Abnormality of MAC-e PDU Non-DTX Rate


61/92


If the user reports the HAPPY message and the user rate cannot reach the MBR, the possible reasons are:

The terminal capability or the RAN capability is limited.

The transmit power of the terminal is limited.

The traffic volume of the terminal is limited.

If the user reports the UNHAPPY message and the user rate cannot reach the MBR, the possible reasons are:

Resources at the RAN side are limited.

Reason 1: The load of the air interface is limited.

Reason 2: The Iub bandwidth is limited.

Reason 3: The NodeB CE is limited.

The MBR (limited NodeB MBR) of the service is limited.

The UE demodulation is incorrect (CRC error of the AG value leads to SG update failure and incorrect UE

RG demodulation)Reason 1: CRC error of the AG value causes the SG updat failure.

Reason 2: The UE RG demodulation is incorrect.

If the MAC-e PDU Non-DTX Rate is abnormal, check whether the HAPPY or UNHAPPY message is reported by

the user by using the drive test tool PROBE.

Abnormality of the MAC-e PDU Served Rate


62/92


When a single HSUPA user uploads a large file, the normal Non-DTX Probability should be 100%. If the Non-

DTX Probability is less than 100%, the value is regarded abnormal.

Factors affecting the Non-DTX Probability: 1) The abnormality of the RLC layer leads to untimely data delivery of the RLC.

For details, see the procedure of locating RLC SDU Throughput UL abnormalities.

2) The abnormality of the TCP/IP layer leads to untimely data delivery of the TCP.

For details, see the procedure of locating TCP/IP layer rate abnormalities.

If the MAC-e PDU Non-DTX Rate is abnormal, further determine whether the MAC-e PDU Served Rate is

abnormal.

Relationship between the Served Rate and the MAC-e PDU Non-DTX Rate:Served Rate = MAC-e PDU Non-DTX Rate * Non-DTX Probability

Hence, the procedure of locating the Served Rate abnormality is to locate the Non-DTX Probability

abnormality.

Abnormality of the MAC-e PDU Served Rate


63/92


When a single HSUPA user uploads a large file, the normal Non-DTX Probability should be 100%. If the Non-

DTX Probability is less than 100%, the value is regarded abnormal.Factors affecting the Non-DTX Probability:

1)The abnormality of the RLC layer leads to untimely data delivery of the RLC.For details, see the procedure of locating RLC SDU Throughput UL abnormalities.

2)The abnormality of the TCP/IP layer leads to untimely data delivery of the TCP.For details, see the procedure of locating TCP/IP layer rate fault.

If the MAC-e PDU Non-DTX Rate is abnormal, determine whether the MAC-e PDU Served Rate is abnormal.

Relationship between the Served Rate and the MAC-e PDU Non-DTX Rate:

Served Rate = MAC-e PDU Non-DTX Rate * Non-DTX Probability Hence, the procedure of locating the Served Rate abnormality is to locate the Non-DTX Probability

abnormality.


64/92

Abnormality of the RLC SDU Throughput UL Relation between RLC PDU Throughput UL and MAC-e PDU Available Rate:

RLC PDU Throughput UL = MAC-e PDU Available Rate * (1 MAC-e PDU header overhead ratio)

B th h d h d ti i ll th f RLC Th h t l t i id ith th MAC L R t i


65/92


Packet loss on the air interface (residual SBLER of the MAC-e layer > 1%) results in the high RLC

retransmission ratio1) If the number of retransmission times of the MAC-e layer exceeds the maximum value but the data still cannot be correctly

received, the TB blocks are discarded. The packet loss occurs in the RLC layer.2) If the receive end of the RLC layer detects the packet loss, it requests the transmit end to retransmit the data through the status

report.

3) Data retransmission reduces the transmission efficiency of the RLC and thus affects the effective throughput of the RLC.

4) The uplink transmission quality of the air interface is controlled by the outer loop power control. If packet loss occurs in the air

interface uplink, it is quite possible that the outer loop power control is abnormal.

Because the header overhead ratio is very small, the curve of RLC Throughput almost coincides with the MAC Layer Rate curve in

Probe.

Relation between RLC SDU Throughput UL and RLC PDU Throughput UL:

RLC SDU Throughput UL RLC PDU Throughput UL * (1 RLC PDU Retransmission Rate UL) * RLC PDU header overhead ratio

In normal conditions, for the BE service, the uplink outer loop power control ensures the retransmission of only MAC-e PDUs and

RLC PDU Retransmission Rate UL is 0. Hence: RLC SDU Throughput UL RLC PDU Throughput UL* RLC PDU header overhead

ratio

Otherwise, it can be concluded that the RLC retransmission ratio is too high.

In the case of VoIP and other real-time services carried on HSUPA, to ensure the real-time feature of the services, the outer loop

power control guarantees a certain residual BLER for MAC-es PDU. In this case, the RLC PDU Retransmission Rate UL

approximately equals the target residual BLER. Otherwise, the RLC SDU Throughput UL is abnormal, that is, the RLCretransmission ratio fails to converge to the target value.

Abnormality of the RLC SDU Throughput UL Packet loss in the downlink of the air interface (high NACK->ACK probability) leads to high RLC

retransmission ratio


66/92


If the UE incorrectly resolves the NACK delivered by the NodeB as ACK, the corresponding TB block is not retransmitted. As a result,

the error block is transmitted to the RLC layer and RLC retransmission occurs. As a result, the throughput is affected.

Reasons for incorrect E-HICH demodulation of the UE: The E-HICH power in the location that the UE is in is too low.

Huawei provides two power control modes for HSUPA downlink control channels (including E-RGCH, E-AGCH, and E-HICH).

Method 1: Fixed PCPICH transmit power: Each channel uses a fixed power and all users have the same power. Hence, no power control isimplemented.

Method 2: User-oriented and DPCH transmit power-based power control: Each user is assigned with the E-RGCH and E-HICH. The E-

AGCH can transmit the signaling aiming at only one user at a moment. Hence, the uplink control channel of HSUPA can perform

power control for each user independently.

Packet loss in the uplink of the Iub interface (lower-layer transmission is abnormal) leads to high RLC retransmission ratio

Abnormalities in the lower-layer transmission (such as E1 intermitting) can lead to packet loss in the uplink.

Packet loss in the uplink of the Iub interface (the configuration of Iub uplink transmission is incorrect) leads to high RLCretransmission ratio

Incorrect uplink transmission configuration of the Iub can lead to packet loss in the uplink.

Packet loss in the uplink of the Iub interface (transmission buffer overflows) leads to high RLC retransmission ratio

The flow control on the Iub interface is not implemented timely and the Buffer overflows.

Delayed return of ACK from the RLC layer (the RLC status report barring timer is unreasonable/the downlink BLER does not

converge) leads to full RLC transmit window

At present, the maximum RLC transmit window size that can be configured is 2047 (the capability of the RLC receive/transmit window

of the current terminal is 2047). When the transmission rate of the RLC is very high and the status report cannot be returned in time,

the RLC transmit window will be full and cannot continue data transmission.

For example, if the air interface rate is 1.4 Mbps and the MAC-D PDU Size is 336 bit. the transmit window can transmit data for at

most (2047336 /(1.41000) = 491.28ms. If the RNC cannot receive the status report within 491.28 ms, the transmit window is full.

The time when the status report is returned is related to the status report barring timer and the transmit quality of the uplink air

interface. If the time of the status report barring time is configured too long or the uplink BLER does not converge, the problem occurs.

Abnormality of TCP/IP Layer Rate

If the MAC-e PDU Non-DTX Rate, MAC-e PDU Served Rate, and MAC-e PDU Served Rate are normal and the

data for transmission is sufficient but the UE still reports limited traffic volume it can be concluded that the rate


67/92


data for transmission is sufficient, but the UE still reports limited traffic volume, it can be concluded that the rate

of the TCP/IP layer is abnormal.

Factors affecting the data transmission rate of the TCP/IP layer:

1) TCP receive/transmit window configuredThough the receive window size changes dynamically during the implementation (if out-of-order packets are

received or the packets cannot be delivered to the upper layer in time, the actual available window size is

reduced), the window size configured determines the maximum available window size.

According to the bandwidth-delay-product formula:

Capacity (bit) = bandwidth (b/s) * round-trip time (s)

If the receive /transmit window size is too small, the transmission rate will be affected.

2) Actual used receive window size used

3) RTT fluctuation: The RTT fluctuation can trigger the congestion avoidance (packet loss occurs on the CN side,the downlink BLER does not converge, and the reverse bandwidth of TCP/IP is too small)

The TCP receive window size configured at the receive end is too small and the transmit window

becomes full readilyTCP uses the sliding window protocol. The protocol allows the transmit end to transmit multiple packet data continuously before

stopping data transmission and waiting for the acknowledgement. In this protocol, the transmit end need not to wait for the

acknowledgement of each packet before the transmission of the next packet. Hence, the protocol can speed up the data

transmission.

Theoretically, the TCP receive window size should be larger than the delay-bandwidth-product:

Capacity (bit) = bandwidth (b/s) * round-trip time (s)

The window size of 66535 is sufficient for the rate 1.6 Mbit/s, but may be insufficient for the rate 3.6 Mbit/s, especially when the

delay exceeds 200 ms, the TCP window will be filled readily. In this case, the buffer of the RLC and NodeB observed is 0.

Abnormality of the RLC SDU Throughput UL


68/92


The CPU occupancy of the receive end reaches 100% and the TCP receive window is full as a result

When the CPU occupancy of the receive end reaches 100%, data in the TCP receive window cannot be

delivered to the upper layer in time. As a result, the TCP receive window is full. When the TCP receive window is full, the receive end notifies the TCP transmit end and the TCP transmit end

then stops data transmission. As a result, the RLC BO is 0 and the UE cannot transmit data.

Packet loss on the CN side leads to RTT timeout at the TCP/IP layer and triggers congestion

avoidance

TCP provides a reliable transport layer. A method to ensure the reliable transmission is to acknowledge the

data received from another end. However, both the transmission and acknowledgement may get lost. To solve

this problem, TCPsets a timer in data transmission. If the acknowledgement is still not received after the timer

times out, the data is retransmitted.

The TCP transmit end measures the (namely the RTT between the time that a byte with special SN is

transmitted and its acknowledgement is received) RTT of a connection and maintains a RTT timer.

If the RTT timeout is measured, the TCP concludes that network congestion occurs and starts the congestionavoidance. Hence, the data transmission is affected.

IP packet loss on the CN side can also lead to RTT timeout.

Abnormality of the RLC SDU Throughput UL The downlink BLER does not converge. As a result, the RTT in the TCP/IP layer times out and the

congestion avoidance is triggered


69/92


congestion avoidance is triggered.

TCP provides a reliable transport layer. A method to ensure the reliable transmission is to acknowledge the

data received from another end. However, both the data and acknowledgement may get lost. To solve this

problem, TCP sets a timer in data transmission. If the acknowledgement is still not received after the timer

times out, the data is retransmitted.

The TCP transmit end measures the RTT (namely the RTT between the time that a byte with special SN is

transmitted and the acknowledgement is received) of a connection and maintains a RTT timer.

If the RTT timeout is measured, the TCP concludes that network congestion occurs and starts the congestion

avoidance. Hence, the data transmission is affected.


The reverse bandwidth of the downlink TCP/IP is too small. As a result, the RTT delay is very high. TCP provides a reliable transport layer. A method to ensure the reliable transmission is to acknowledge the

data received from another end. However, both the transmission and acknowledgement may get lost. To solve

this problem, TCP sets a timer in data transmission. If the acknowledgement is still not received after the timer

overflows, the data is retransmitted.

The TCP transmit end measures the RTT (namely the RTT between the time that a byte with special SN is

transmitted and the acknowledgement is received) of a connection and maintains a RTT timer.

If the RTT timeout is measured, the TCP concludes that network congestion occurs and starts the congestionavoidance. Hence, the data transmission is affected.


THE END

Contents


70/92






Overview


71/92


This chapter summarizes the common measures for isolating HSDPA rate problems.

When only LMT is available for log catching, you can minimize the location range by

using the UMAT tool for data analysis and tests, so that you can locate faults rapidly and

take effective measures to clear the faults. As a result, the troubleshooting efficiency

increases.

The UMAT tool and studying materials are archived in:

\\szxfs02-pub\Umts_rnp\WX_URNP_KB_F\12 Window of study\05 Performance Delivery\UMTS10.0\Data Transmission

Problem Location

Procedure of Locating HSDPA Rate Faults

The main HSDPA rate problems can be divided into two types: low rate and rate fluctuation. The analysis

procedure of the two types are problems are the same.


72/92


Confirm the symptom

Confirm the symptom and regularity of the problem based on

the rate screenshot of the application layer (screenshot ofDuMeter), description of testing personnel, and the L2

statistics in CDT.

Determine the location of

the problem through RNC

CDT

From a point of RAN view, the first step of problem location

is to determine the factors that may affect the rate. That is, is

the problem caused by the UE, air interface, NodeB, Iub, or

RNC?

The CDT of RNC can trace abundant L2 information. The

information can be used to approximately locate the reason

of the rate problem.

Perform specific tests according

to the results obtained and

determine the approximate

reason of the problem

After the faulty NE is located, you need to modify related

parameters or carry out tests to verify whether the conclusion is

correct.

Coming up are the 10 steps of collecting and analyzing the CDT data for troubleshooting.

Step 1 - HSDPA Data Transmission Model

Water tankWater is discharged from the water

t k t th l


73/92


SGSN

RNC

NodeB

Water tank tank to the pool

Water is poured to the belt conveyer

through a valve-controlled water pipe

The valve size is determined by the

belt conveyer.

The belt conveyer fills water to the

bottle in a certain rate.


74/92

Step 3 - Capture Log


75/92


Make sure that the rate abnormality has occurred and the abnormality has

lasted for 1 min before stopping the CDT tracing.

Run the CDT of the RNC in RNC LMT. The suggested parameter configurations are as follows:

Step4 - Confirm the Symptom


76/92


Check the rate status through the Dumeter or UMat and confirm the symptom.

Step 5 - Determine Whether the Problem Occurs Before the Iu interface

When the transmission before the Iu interface is abnormal, or an application layer (such as the TCP layer)

is faulty, similar problems may occur in the RNC, that is, the data volume transmitted from the Iu interface to

the RNC is insufficient. For the RNC, the data delivered from the Iu interface is the source of throughput.


77/92


, g p

When the data source is insufficient, the rate cannot be guaranteed.

Analyze the the RLC BO change recorded in the CDT and determine whether the data delivered from the Iu

interface is enough. Here is an example of testing the throughput:

The green curve in the figure represents the RLC BO. It indicates the accumulation of uplink data in the

RNC Buffer. From the rate source assurance point of view, we should care whether the RLC BO is zero or

non-zero instead of its specific value. If the RLC BO value is not zero during the entire period, it means that

data is available for the transmission by the RNC. In this case, the specific value of the RLC BO is not

important, because the relative relationship between the RLC BO curve and other curves is meaningless.

Step 5 - Determine Whether the Problem Occurs Before the Iuinterface


78/92


This figure indicates the symptom when the RLC BO is abnormal. In the first 4/5 of the figure, the RLC

BO value (green) is 0. It indicates that the low rate during this period is caused by insufficient downlink

rate of the Iu interface. In the last 1/5 of the figure, the RLC BO value increases obviously. The abnormal

rate during this period is caused by other reasons.

Step 6 - Determine whether the Problem is Triggered by RNC

If the rate abnormality is triggered by RNC, the following symptoms can be observed: 1) The RLC BO value is not 0; 2) The

delivery rate of the RB is lower than the HSDPA bandwidth assigned by the NodeB and no relationship between the them can


79/92


y g y p

be observed.

The following is an example of rate abnormality caused by insufficient UE drive performance. Because the UE drive

performance is insufficient, the UE L2 actively notifies the RNC to reduce the receive window. As a result, the delivery rate ofRNC is affected and the rate becomes abnormal.

The green curve in the figure represents RLC BO, the red curve represents the status of data delivery by RNC, and the blue

curve is the assigned HSDPA bandwidth. It can be seen that the RLC BO (green) is very high during the entire period

gsm-to-umts training series 23_hspa data transmission troubleshooting_v1.0

Documents