Ps-Service Problem Optimization

W-PS Service Problem Optimization Guide For internal use only
Product name Confidentiality level

WCDMA RNP For internal use only
Product version
Total 133 pages
3.1
W-PS Service Problem Optimization Guide

(For internal use only)
Prepared by Yu Yongxian Date 2006-03-22

Reviewed by Xie Zhibin, Chen Qi, Xu Date
Zili, Xu Dengyu, Jiao
Anqiang, Hu Wensu, Ji 2006-03-22
Yinyu, Qin Yan, Wan Liang,
and Ai Hua
Reviewed by Qin Yan and Wang Chungui Date 2006-03-30
Approved by Date
Huawei Technologies Co., Ltd.

All Rights Reserved
2006-08-28 Huawei Proprietary. No Spreading Without Permission. Page 1 of 133

Revision Records
Date Version Description Author

2004-11-26 1.00 Initial transmittal. Yu Yongxian
Removing ABCD network for optimization target; Yu Yongxian
putting analysis of traffic statistics in a single
2006-03-09 1.01 chapter; completing the operations and instructions
at core network side by CN engineers; removing
CDR part.
2006-03-16 Moving the comparison of APP and RLC Yu Yongxian
1.02 throughput to DT/CDT data analyais part;
supplementing flow charts.
2006-03-22 Changing the cover; removing BLER target and Yu Yongxian
3.00 changing power control parameters; supplementing
flow chats; adding an HSDPA case.
2006-05-23 Supplementing HSDPA KPIs; adding flow for Wang Dekai
analyzing the poor performance for HSDPA to bear
RAN side data in data transfer; adding analysis of
3.10 interruption of data transfer for HSDPA service;
supplementing HSDPA cases; revising minor errors
in V3.0 guide.

Table of Contents
1 Introduction.........................................................................................................................12
2 Evaluation of PS Throughput Problems...........................................................................14
3 Data Collection..................................................................................................................18
3.1 Traffic Statistics...................................................................................................................................19
3.2 DT/CQT...............................................................................................................................................19
3.3 Others..................................................................................................................................................21
4 Analysis of Traffic Statistics Data......................................................................................23

4.1 Analysis of Traffic Statistics for Throughput Problems......................................................................24
4.1.1 Traffic Statistics Indexes Related to Throughput.......................................................................24
4.1.2 Generic Analysis Flow...............................................................................................................27
5 Analysis of DT/CQT Data...................................................................................................38

5.1 Access Failure......................................................................................................................................39
5.1.1 Originating PS Service by UE Directly.....................................................................................40
5.1.2 UE as the Modem of PC.............................................................................................................41
5.2 Disconnection of Service Plane...........................................................................................................48
5.2.1 Analyze Problems at RNA Side.................................................................................................49
5.2.2 Analyzing Problems at CN Side.................................................................................................55
5.3 Poor Performance of Data Tranfer......................................................................................................57
5.3.1 Checking Alarms........................................................................................................................59
5.3.2 Comparing Operations and Analyzing Problem........................................................................59
5.3.3 Analyzing Poor Performance of Data Transfer by DCH............................................................60
5.3.4 Analyzing Poor Performance of Data Transfer by HSDPA at RAN Side..................................66
5.3.5 Analyzing Poor Performance of Data Transfer at CN Side........................................................90
5.4 Interruption of Data Transfer...............................................................................................................93
5.4.1 Analzying Interruption of Data Transfer....................................................................................93
5.4.2 Analyzing HSDPA Interruption of Data Transfer.......................................................................95
6 Cases..................................................................................................................................101
6.1 Cases at RAN Side............................................................................................................................102
6.1.1 Call Drop due to Subscriber Congestion (Iub Resource Restriction)......................................102
6.1.2 Uplink PS64k Service Rate Failing to Meet Acceptance Requirements in a Test (Air Interface
Problem)............................................................................................................................................102
6.1.3 Statistics and Analysis of Ping Packet Delay in Services of Different Types..........................103
6.1.4 Low Rate of HSDPA Data Transfer due to Over Low Pilot Power.........................................105
6.1.5 Unstable HSDPA Rate due to Overhigh Receiving Power of Data Card.................................106
6.1.6 Impossible Maximum HSDPA Rate due to Over large Radius of Cell....................................107
6.1.7 Decline of Total Throughput in Cell due to AAL2PATH Bandwidth larger than Actual Physical
Bandwidth.........................................................................................................................................109

6.2 Cases at CN Side................................................................................................................................111

6.2.1 Low FTP Downloading Rate due to Over Small TCP Window on Server TCP......................111
6.2.2 Simultaneous Uploading and Downloading.............................................................................113
6.2.3 Decline of Downloading Rate of Multiple UEs.......................................................................114
6.2.4 Unstable PS Rate (Loss of IP Packets).....................................................................................116
6.2.5 Unstable PS Rate of Single Thread in Commercial Deployment (Loss of IP Packets)...........118
6.2.6 Unavailable Streaming Service for a Subscriber......................................................................118
6.2.7 Unavailable PS Services due to Firewall of Laptop.................................................................119
6.2.8 Low PS Service Rate in Presentation Occasion.......................................................................119
6.2.9 Abnormal Ending after Long-time Data Transfer by FTP.......................................................119
6.2.10 Analysis of Failure in PS Hanodver Between 3G Network and 2G Network.......................124
7 Summary...........................................................................................................................129
8 Appendix..........................................................................................................................130
8.1 Transport Channel of PS Data...........................................................................................................131
8.2 Theoretical Rates at Each Layer........................................................................................................131
8.2.2 TCP/IP Layer............................................................................................................................132
8.2.3 RLC Layer................................................................................................................................132
8.2.4 Retransmission Overhead.........................................................................................................133
8.2.5 MAC-HS Layer........................................................................................................................133
8.3 Bearer Methods of PS Services.........................................................................................................133
8.3.1 DCH.........................................................................................................................................134
8.3.2 HSDPA.....................................................................................................................................134
8.3.3 CCH..........................................................................................................................................135
8.4 Description of HSDPA Algorithms and Parameters..........................................................................135
8.4.1 Code Resource Configuration..................................................................................................135
8.4.2 HS-PDSCH MPO Instant.........................................................................................................141
8.4.3 HSDPA UE Category...............................................................................................................142
8.4.4 HS-DPCCH Power Control......................................................................................................143
8.5 Method for Modifying TCP Receive Window..................................................................................148
8.5.1 Tool Modification.....................................................................................................................148
8.5.2 Regedit Modification...............................................................................................................148
8.6 Method for Modifying MTU.............................................................................................................148
8.6.1 Tool Modification.....................................................................................................................149
8.6.2 Regedit Modification...............................................................................................................150
8.7 Confirming APN and Rate in Activate PDP Context Request Message...........................................150
8.7.2 Traffic Class.............................................................................................................................151
8.7.3 Maximum Rate and Guaranteed Rate......................................................................................152
8.7.4 APN..........................................................................................................................................152
8.8 APN Effect.........................................................................................................................................153
8.8.1 Major Effect.............................................................................................................................153
8.8.2 Method for Naming APN.........................................................................................................154

8.8.3 APN Configuration...................................................................................................................154

8.9 PS Tools.............................................................................................................................................154
8.9.1 TCP Receive Window and MTU Modification Tools..............................................................154
8.9.2 Sniffer.......................................................................................................................................155
8.9.3 Common Tool to Capture Packet: Ethereal..............................................................................156
8.9.4 HSDPA Test UE.......................................................................................................................156
8.10 Analysis of PDP Activation.............................................................................................................157

List of Tables
Table 2-1 Requirements by DT/CQT on PS throughput...........................................................................15
Table 2-2 Requirements by RAN traffic statistics on PS throughput........................................................17
Table 3-1 Major parameters to be collected in DT/CQT...........................................................................19
Table 3-2 Tools for collecting data............................................................................................................21
Table 4-1 Measured items related to PS throughput in overall performance measurement of RNC........24
Table 4-2 Measured items related to PS throughput in cell performance measurement...........................25
Table 4-3 Measured items related to HSDPA throughput (cell measurement)..........................................26
Table 4-4 Other measured items related to throughput.............................................................................27
Table 4-5 Indexes to judge whether a cell has PS service request............................................................33
Table 4-6 Cell measurement/cell algorithm measurement analysis..........................................................33
Table 4-7 Analysis of cell performance/Iub interface measurement.........................................................34
Table 4-8 Cell Measurement/Cell RLC Measurement Analysis...............................................................35
Table 5-1 Comparing operations and analyzing problem..........................................................................59
Table 5-2 Relationship between CQI and TB size when the UE is at the level 11–12..............................73
Table 5-3 Relationship between CQI and TB size when the UE is at the level 1–6.................................74
Table 5-4 HS-SCCH power offset.............................................................................................................78
Table 6-1 Delay test result of ping packet...............................................................................................104
Table 8-1 CCH SFs..................................................................................................................................136
Table 8-2 Secondary CCPCH fields........................................................................................................137
Table 8-3 HSDPA SFs.............................................................................................................................139
Table 8-4 Relationship between the CQI reported by UE and pilot Ec/Io..............................................142
Table 8-5 FDD HS-DSCH physical layer categories..............................................................................142
Table 8-6 Quantized power offset...........................................................................................................144
Table 8-7 HS-DPCCH power control parameters...................................................................................146

List of Figures
Figure 4-1 Flow for analyzing RNC-level traffic statistics data...............................................................29
Figure 4-2 Flow for analyzing cell-level traffic statistics data.................................................................31
Figure 5-1 Flow for analyzing DT/CQT data...........................................................................................39
Figure 5-2 Flow for analyzing access failure problems when originating PS services by UE directly. . .40
Figure 5-3 Flow for analyzing access problem when the UE serves as the modem of PC......................42
Figure 5-4 Flow for processing problem of failure in opening port.........................................................43
Figure 5-5 Flow for analyzing access failure problems............................................................................45
Figure 5-6 Signaling flow of successful setup of a PS service in Probe..................................................46
Figure 5-7 Flow for analyzing RAN side problem about disconnection of service plane for DCH bearer
...................................................................................................................................................................49
Figure 5-8 Connection Performance Measurement-Downlink Throughput and Bandwidth window

...................................................................................................................................................................51
Figure 5-9 HSDPA parameters in Probe...................................................................................................53
Figure 5-10 Flow for analyzing problems at CN side about disconnection of service plane...................56
Figure 5-11 Flow for analyzing poor performance of data transfer..........................................................58
Figure 5-12 Flow for analyzing RAN side problem about poor performance of data transfer................61
Figure 5-13 Flow for analyzing data transfer affected by Uu interface...................................................62
Figure 5-14 Flow for analyzing data transfer affected by Iub interface...................................................65
Figure 5-15 Flow for analyzing poor performance of data transfer at RAN side.....................................69
Figure 5-16 Confirming in the RNC message that PS service is set up on HSDPA channel...................70
Figure 5-17 Confirming in Probe that service is set up on HSDPA channel............................................71
Figure 5-18 High code error of ACK->NACK/DTX in Probe.................................................................85
Figure 5-19 Uplink and downlink RL imbalance in handover areas........................................................86
Figure 5-20 Residual BLER at MAC layer in WCDMA HSDPA Decoding Statistics window............89
Figure 5-21 Flow for analyzing poor performance of data transfer at CN side.......................................90
Figure 5-22 Flow for analyzing interruption of data transfer...................................................................94
Figure 5-23 Interruption delay of data transfer in HSDPA.......................................................................97
Figure 5-24 Normal and abnormal interruption of data transfer upon update of H-H serving cell..........98
Figure 5-25 Interruption of data transfer due to H-D and D-H handover................................................99
Figure 5-26 Interruption delay of TCP displayed in Ethereal.................................................................100
Figure 6-1 UE HSDPA statistics data in QXDM....................................................................................107
Figure 6-2 Variation of total throughput of one IMA link of HSDPA codes..........................................109
Figure 6-3 Variation of total throughput of two IMA links of HSDPA codes........................................110

Figure 6-4 Unstable PS rate (1)..............................................................................................................116
Figure 6-5 Unstable PS rate (2)..............................................................................................................116
Figure 6-6 Analyzing packets captured by Ethereal upon unstable PS rate...........................................117
Figure 6-7 Interactive interface in CuteFTP...........................................................................................120
Figure 6-8 Signaling of normal downloading by FTP............................................................................121
Figure 6-9 Signaling of abnormal downloading by FTP........................................................................122
Figure 6-10 Signaling of normal handover between 3G network and 2G network................................125
Figure 6-11 Normal signaling flow between UE and 2G SGSN............................................................126
Figure 6-12 Signaling flow traced on 2G SGSN....................................................................................127
Figure 8-1 Transport channel of PS data................................................................................................131
Figure 8-2 Packet Service Data Flow.....................................................................................................132
Figure 8-3 Code tree of downlink channel code.....................................................................................136
Figure 8-4 Code resource occupation sample.........................................................................................140
Figure 8-5 ACK/NACK/CQI parameters in RB SETUP message.........................................................147
Figure 8-6 Running interface of DRTCP................................................................................................149
Figure 8-7 Detailed resolution of Activate PDP Context Request message...........................................151
Figure 8-8 Converting ASCII code to string in UltraEdit.......................................................................153
Figure 8-9 PDP context activation process originated by MS................................................................157
WCDMA PS Service Problem Optimization Guide

Key words: WCDMA, PS service, and throughput
Abstract: The document serves the optimization of PS service problems in large networks. It describes
problem evaluation, data collection, and methods for analyzing problems.
Acronyms and abbreviations:
Acronyms and abbreviations Full spelling
RNO Radio Network Optimization
RNP Radio Network Planning
APN Access Point Name
CHR Call History Record
CQI Channel Quality Indicator
CQT Call Quality Test

DT Driver Test
HSDPA High Speed Data Packet Access
HS-PDSCH High Speed Physical Downlink Shared Channel
HS-SCCH Shared Control Channel for HS-DSCH
QoS Quality of Service
SF Spreading Factor
UE User Equipment
SBLER Scheduled Block Error Rate
IBLER Initial Block Error Rate
HHO Hard Handover
SHO Soft Handover
NE Network Element

1 Introduction
About This Guide
The following table lists the contents of this document.
Title Description
Chapter 1 Introduction
Chapter 2 Evaluation of PS Throughput Problems
Chapter 3 Data Collection

Chapter 4 Analysis of Traffic Statistics Data
Chapter 5 Analysis of DT/CQT Data

Chapter 6 Cases
Chapter 7 Summary
Chapter 8 Appendix

In WCDMA networks, besides traditional conversational service, data service is

growing with features. It has a significant perspective.
The indexes to indicate the performance of WCDMA data service includes:
 Access performance
It is reflected by the following indexes of data service:
− Success rate of RRC setup
− Success rate of RAB setup
− Success rate of PDP activation
 Call drop rate of PS service
 Throughput
 Delay
There are access delay and the service interruption delay caused by HHO.
This document addresses on problems in PS service optimization, such as access
problems, data transfer failure, low rate of data transfer, unstable rate of data transfer,
and interruption of data transfer. It describes the method to analyze and solve DT/CQT
problems. In addition, it describes the flow for processing access failure and data
transfer failure problems in optimization of PS throughput.
For access problems, see W-Access Problem Optimization Guide. For call drop and
handover problems, see W-Handover and Call Drop Problem Optimization Guide.
These two guides provide analysis in terms of signaling flow and performance
statistics. This guide supplements the possible causes and solutions to PS service
access problems in terms of operations.
This guide is for deployment RNO.
The problem analysis and description of MML command and product function are
based on the following product versions:
 BSC6800V100R006C01B064
 BTS3812E V100R006C02B040
2 Evaluation of PS Throughput Problems
About This Chapter
This chapter describes the evaluation of PS throughput problems.

Optimize PS throughput in terms of DT/CQT, and traffic statistics. In actual network

optimization, the optimization objects and test methods are according to contract.
lists the requirements by DT/CQT on PS throughput.
Requirements by DT/CQT on PS throughput

Index Service Reference Reference test method
Average PS 48–56 kbps 1) Test in the areas where Ec/Io

downlink UL64k/DL is large than –11 dB and RSCP is
throughput of 64k larger than –90 dBm.
R99 2) Test when traffic is low
PS 96–106 kbps
UL64k/DL without call drop problems due
128k to congestion.
3) Put FTP servers in CN.
PS 300–350 kbps 4) Download with 5 threads.
UL64k/DL 5) Exclude non-RAN problems
384k or decline of throughput caused
by UE.
Average PS 48–56 kbps 1) Test in the areas where Ec/Io
uplink UL64k/DL is large than –11 dB and RSCP is
throughput of 64k larger than –90 dBm.
R99 2) Test when traffic is low (the
uplink and downlink load is not
larger than planned load)
without call drop problems due
to congestion.
3) Put FTP servers in CN.
4) Download with 5 threads.
5) Exclude non-RAN problems
or decline of throughput caused
by UE.
Downlink CAT12 1.52Mbps  The carrier power, number of
average (SBLER = HS-PDSCH codes, and lub
throughput 10%) bandwidth resource are not
for HSDPA restricted. The throughput is
single determined by capability of
subscriber UE.
 The average CQI of tested area
is 18.
 Single subscriber in unloaded
conditions and in the center of
cell.

760 kbps  Other resources except power

are not restricted.
is 10.
 Single subscriber in unloaded
conditions and in the edge of
cell.
Throughput CAT12 3.255 Mbps  4 Cat12 UEs, and 14 HS-
of HSDPA PDSCH codes
cell  It is restricted by HS-PDSCH
code. The carrier power and
lub bandwidth are not
restricted.
is 18.
800 kbps  4 Cat12 UEs, and 14 HS-
PDSCH codes
 It is restricted by carrier
power. The HS-PDSCH code
and lub bandwidth are not
restricted.
is 18.
lists the requirements by RAN traffic statistics on PS throughput.
Requirements by RAN traffic statistics on PS throughput

Index Service Reference value
Downlink average PS UL64k/DL 64k 48–56 kbps

throughput of R99
PS UL64k/DL 128k 96–106 kbps
PS UL64k/DL 384k 300–350 kbps
Downlink average CAT12

throughput for HSDPA
single subscriber
Downlink average CAT12

throughput for HSDPA
cell

The PS throughput in RAN traffic statistics is obtainable from cell throughput of different
services. HSDPA throughput of RAN traffic statistics is obtainable from average throughput of
MAC-D flow in HSDPA service measurement (cell).
3 Data Collection
About This Chapter
The following table lists the contents of this chapter.

 3.1Traffic Statistics
 3.2DT/CQT
 3.3Others

There are two major methods for evaluating PS throughput: traffic statistics and
DT/CQT.
3.1 Traffic Statistics

For collecting traffic statistics data, see W-Equipment Room Operation Guide.
3.2 DT/CQT
To obtain DT/CQT data, use the software Probe. UE, scanner, and GPS are involved.
Obtain the information output by UE, such as:
 Coverage
 Pilot pollution
 Signaling flow
 Downlink BLER
 Transmit power of UE
Based on the measurement tracing on RNC LMT, obtain the following information:
 Downlink BLER
 Downlink code transmit power
 Downlink carrier transmit power
 Signaling flow at RNC side
By the DT processing software Assistant, analyze comprehensively the data collected
by Probe in foreground DT and tracing record on RNC LMT.
lists the major parameters to be collected in DT/CQT.
Major parameters to be collected in DT/CQT

Parameter Tool Effect
Longitude and latitude Probe + GPS Record trace

Scramble, RSCP, Ec/Io of Probe + UE Analyze problems
active set
UE Tx Power Probe + UE Analyze problems and
output reports
Downlink BLER Probe + UE Analyze problems and
output reports
Uplink/Downlink Probe + UE Analyze problems and
application layer, RLC output reports
layer throughput
RRC and NAS signaling at Probe + UE Analyze problems
UE side

HSDPA CQI, HS-SCCH Probe + UE Analyze problems and

scheduling success rate, output reports
throughput of APP, RLC,
and MAC
Uplink BLER RNC LMT Analyze problems and
output reports
Downlink transmit code RNC LMT Analyze problems and
power output reports
Single subscriber signaling RNC LMT Analyze problems
tracing by RNC
Iub bandwidth RNC/NodeB LMT Analyze problems
Downlink carrier transmit RNC LMT Analyze problems and
power and non-HSDPA output reports
carrier transmit power
Downlink throughput and RNC LMT Analyze problems and
bandwidth output reports
Dowlink traffic RNC LMT Analyze problems
In PS service test, to reduce the impact from TCP receiver window of application
layer, using multi-thread downloading tools like FlashGet is recommended. Set the
number of threads to 5. For uplink data transfer, start several FTP processes.
For the detailed test and operation methods of DT and CQT, see W-Test Guide. For
detailed operations on LMT, see W-Equipment Room Operation Guide.
3.3 Others
After finding problems by traffic statistics, DT/CQT, and subscribers' complaints,
analyze and locate problems with DT/CQT and the following aspects:
 RNC CHR
 Connection performance measurement
 Cell performance measurement
 Alarms on NEs
 States of NEs
 FlashGet
 DU Meter
lists the tools for collecting data.

Tools for collecting data

Data Tools for Tools for Effect Remark
collecting viewing/
data analyzing
data
Traffic M2000 Nastar Check the network For detailed

statistics operation conditions operations on
data macroscopically, LMT, see W-
analyze whether Equipment
there are abnormal Room
NEs. Operation
Guide. For
usage of Nastar,
see the online
help and
operation
manual of
Nastar.
DT/CQT Probe + UE Assistant Analyze calls in See W-Test
data terms of flow and Guide.
coverage based on
Connecti RNC LMT Assistant DT/CQT data and See the online
on or RNC traced data on RNC help of RNC
performa LMT LMT
nce
measure
ment, cell
performa
nce
measure
ment,
signaling
tracing
by RNC
Alarm M2000 or M2000 or Check alarms
RNC LMT RNC LMT whether there are
abnormal NEs
CHR RNC LMT Nastar or Record historic
RNC record of abnormal
Insight calls for all
Plus subscribers, help to
locate problems. For
subscribers'
complaints,
analyzing CHR helps
to find the problem
happening to
subscribers.

None FlashGet None Downlink with Assistant tool

multiple threads to for PS service
obtain more stable test
throughput
None DU Meter None Observe throughput Assistant tool
of application layer for PS service
realtime, take test
statistics of total
throughput, average
throughput, and peak
throughput in a
period (the result is
recorded by
PrintScreen shot).
Sniff data Sniffer Sniffer Construct stable Used by CN
packet uplink and downlink engineers. For
data transmission usage, see
requirement. appendix.
Sniff data Ethereal Ethereal Sniff data packet at Used by CN

packet interfaces and parse engineers. For
data packet usage, see
appendix.
CHR is called CDL in those versions prior to RNC V1.6. CHR is used in these versions after
V1.6.
When analyzing data with previous tools, engineers need to combine several data for
analysis. For example, in network maintenance stage, if some indexes are faulty,
analyze some relative data such as performance statistic, alarm data, and CHR.
According to the level of problems, perform DT/CQT in cell coverage scope, trace the
signaling of single subscriber and conduct connection performance measurement on
RNC LMT.
If there are problems in DT/CQT, analyze them based on traffic statistics and alarms.

4 Analysis of Traffic Statistics Data
About This Chapter
This chapter analyzes traffic statistics data.

The access, call drop, SHO, HHO, inter-RAT handover problems may affect
throughput of PS services. Therefore, before analyzing and optimizing throughput of
PS services, analyze access, call drop, SHO, HHO, inter-RAT handover problems.
To analyze access problems and traffic statistics indexes, see W-Access Problem
Optimization Guide.
To analyze handover and call drop problems, and traffic statistics indexes, see W-
Handover and Call Drop Problem Optimization Guide.
4.1 Analysis of Traffic Statistics for Throughput Problems

4.1.1 Traffic Statistics Indexes Related to Throughput
The following four tables are based on RNC V1.6.
lists the measured items related to PS throughput in overall performance measurement
of RNC.
Measured items related to PS throughput in overall performance measurement of RNC

Measured item Major indexes Effect
Overall performance RLC cache size, average Check whether the RLC
measurement of utilization of cache; cache is inadequate; check
RNC/RLC statistics number of data packets the probability of
measurement sent and received by RLC dropping data packets by
in TM/AM/UM mode; RLC or whether the
number of data packets downlink retransmission
dropped by RLC, number rate is overhigh.
of retransmitted data
packets
Overall performance Number of UEs in Serve as reference for
measurement of RNC/UE CELL_DCH, knowing traffic model of
state measurement CELL_FACH, subscribers
CELL_PCH, and
URA_PCH state
Overall performance Number of conversational Analyze the number of
measurement of RNC/RB service, streaming service, subscribers using different
measurement interactive service, and services at different rate;
background service in analyze the call drop
various uplink and problems of various rate
downlink rates in PS
domain under RNC; Times
of abnormal call drops for
previous services in
various rate in PS domain
Overall performance Uplink and downlink
measurement of traffic (RLC layer excludes
RNC/RNC traffic traffic of RLC header) of
measurement all services in PS domain
under RNC

Overall performance Times of successful/failure Frequent inter-RAT and

measurement of RNC/PS PS inter-RAT handovers, the call drop due to it will
inter-RAT handover the failure causes directly affects PS service
measurement subscribers' experiences.
Guarantee high handover
success rate by analyzing
and optimizing the
measured item while
avoid ping-pong
handover. Reduce the
impact from inter-RAT
handover on PS
throughput.
lists the measured items related to PS throughput in cell performance measurement.
Measured items related to PS throughput in cell performance measurement

Cell measurement/traffic Uplink and downlink Analyze whether the

measurement traffic volume (number of CCH is to be congested;
MAC-d PDU bytes) at Iub take statistics of Iub
interface, traffic of RACH, TCH traffic
FACH, and PCH; Iub CCH
bandwidth
Cell measurement/cell DCCCC and congestion Analyze cell congestion
algorithm measurement control problems and rationality
of DCCC parameters
Cell measurement/cell Valid data rate at RLC in Take statistics of valid
RLC measurement cell, downlink service, data rate at RLC layer,
number of signaling PDUs, the transmission rate of
number of retransmitted service and signaling,
PDUs, number of dropped and the dropping rate
PDUs
Cell measurement/cell Average throughput and Obtain the average
throughput of various volume of various service throughput of various
services, throughput t services in the cell.
measurement Judge whether the
average throughput
meets the optimization
objectives
Cell measurement/BLER Uplink average BLER of
measurement of various various services in cell,
services in cell and the ratio of time of
maximum value of BLER

Cell measurement/Iub Number of requested RLs Check the resource

interface measurement at Iub interface, number of allocation condition at
successful RLs, number of Iub interface whether
failed RLs, and different Iub is congested.
causes of failures.
In cell performance measurement, HSDPA part is added, and other indexes are the
same as that of R99. Some traffic statistics indexes corresponding to HSDPA services
are not added to RNC traffic statistics.
lists the measured items related to HSDPA throughput (cell measurement).
Measured items related to HSDPA throughput (cell measurement)

Cell measurement/HSDPA Statistics of HSDPA Know the HSDPA

service measurement service setup and deletion; throughput and number of
number of HSDPA subscribers in cell
subscribers in cell, D-H,
F-H handover, serving cell
update, intra-frequency
HHO, inter-frequency
HHO; MAC-D flow
throughput.
shows other measured items related to throughput.
Other measured items related to throughput

Performance measurement Iu-PS reset times, setup Analyze whether lu-PS

at Iu interface and release times, and interface is normal
overload control times.
GTP-U measurement Determine the scope of
Number of bytes sent and problems by comparing
received by GTP-U RLC layer traffic and
GTP-U traffic. Distinguish
RAN side problems from
CN side problems
UNI LINK measurement Average receiving and
sending rate of UNI LINK
IMA LINK measurement Average receiving and
sending rate of IMA LINK
IMA GROUP link Average receiving and
measurement sending rate of IMA
GROUP

4.1.2 Generic Analysis Flow

According to 4.1.2, the indexes related to PS throughput include:
 Overall performance measurement of RNC
 Cell measurement
 Performance measurement at Iu interface
 GTP-U measurement
 UNIUNI LINK measurement
 IMA LINK measurement
 IMA GROUP link measurement
Analyzing traffic statistics data is mainly based on overall performance measurement
of RNC and cell measurement. Analyzing RNC-level data addresses on evaluating and
analyzing performance of entire network. Analyzing cell-level data addresses on
locating cell problems. Other measured items like Iu interface and transmission help
engineers to analyze problems in the whole process of performance data analysis.
In actual traffic statistics analysis, evaluate the indexes of entire network and then
locate cell-level problems.
Flow for Analyzing RNC-level Traffic Statistics Data

shows the flow for analyzing RNC-level traffic statistics data.

Flow for analyzing RNC-level traffic statistics data
The RNC traffic statistics indexes of current version do not include statistics of
throughput of various services, but include RNC traffic volume measurement. The
traffic volume measurement is relevant to subscribers' behaviors and traffic model.
The traffic volume is not the same every day, but is fluctuating periodically from
Monday to Saturday and Sunday. Therefore, upon analysis of RNC traffic volume,
observe the fluctuation of weekly traffic volume. For example, compare the curve
chart of traffic volume for a weak with that of last weak. If they are similar, the
network is running normally according to RNC-level analysis. If they are greatly
different from each other, analyze the problem in details.

When analyzing problems, check whether the RNC-level traffic statistics indexes are
normal in synchronization, such as RB, RLC, Iu interface. Then follow the flow for
analyzing cell-level traffic statistics data.
If the PS throughput of one or two cells is abnormal, this cannot be reflected by RNC-
level traffic statistics. Therefore, analyzing cell-level traffic statistics data is necessary
even if RNC-level traffic statistics is normal.

Flow for Analyzing Cell-level Traffic Statistics Data
Flow for analyzing cell-level traffic statistics data
The cell-level traffic statistics data is obtainable from cell measurement/cell

throughput of various services, and volume measurement, including the average
throughput and total volume of various services.

Select a representative service in the network, or a continuous coverage service.

Analyze the average throughput of each cell for the selected service by Nastar and sort
the cells by cell throughput. Select the top N worst cells for analysis.
The cells with 0 PS RAB setup request is excluded from sorting alignment, namely,
the total number of the four indexes listed in is 0. Such cells are considered as having
no PS service request, so they are excluded from sorting alignment the worst cells for
PS throughput.
Indexes to judge whether a cell has PS service request

Measured item Type Index
Cell measurement Number of successful VS.RAB.AttEstabPS.Conv
RABs with RAB VS.RAB.AttEstabPS.Str
assignment setup in
PS domain in cell VS.RAB.AttEstabPS.Inter
VS.RAB.AttEstabPS.Bkg
Cell measurement/HSDPA Times of HSDPA VS.HSDPA.RAB.AttEstab
service measurement service setup requests
in cell
For the worst cell, check that they are not with access, call drop, and handover
problems. Then analyze the cell performance from cell measurement/traffic
measurement, cell measurement/cell algorithm measurement, and cell
measurement/cell RLC measurement.
describes the cell measurement/cell algorithm measurement analysis.
Cell measurement/cell algorithm measurement analysis

Index Meaning Analysis Solution
VS.LCC.BasicCongNumUL Times of If one of them If the load of

VS.LCC.BasicCongNumDL uplink and is large than inter-frequency
downlink 0, the cell is cells with
basic with basic overlapped
congestion congestion coverage is low,
in cell problem optimize load
balance
parameters.
Otherwise
consider adding
carriers.

VS.LCC.OverCongNumUL Times of If one of them If the load of

VS.LCC.OverCongNumDL cell is large than inter-frequency
congestion 0, the cell cells with same
due to must be badly coverage is low,
uplink and congested optimize load
downlink balance
overload parameters.
Otherwise
consider adding
carriers.
VS.DCCC.D2D.SuccRateDown.UE Times of If the average Confirm the
VS.DCCC.D2D.SuccRateUp.UE successful service DCCC
configurati throughput is algorithm
on of DCH much lower parameter
dynamic than the
channel bandwidth,
with the DCCC
decreasing algorithm
downlink parameter
rate in cell may be
irrational.
VS.Cell.UnavailTime.OM Length of If it is large Check alarms
unavailabl than 0, the and CHR for
e time of cell must have causes of
cell been system
unavailable. abnormalities
describes the analysis of cell performance/Iub interface measurement.
Analysis of cell performance/Iub interface measurement

Index Meaning Analysis Soluti
on
VS.IUB.AttRLSetup Number of requested If SuccRLSetup <

VS.IUB.SuccRLSetup RLs set up at lub AttRLSetup, the RL
interface in cell. setup must have
Number of successful failed at lub
RLs set up at lub interface. Analyze
interface in cell. the problem for
detailed causes.
VS.IUB.FailRLSetup.Cf Number of RLs failed Analyze the setup
gUnsup at lub interface due to failure due to
VS.IUB.FailRLSetup.Co different causes in cell different causes.
ng If the
VS.IUB.FailRLSetup.H VS.IUB.FailRLSetu
W p.Cong is large than
0, the lub interface is
VS.IUB.FailRLSetup.O probably congested.
M

VS.DL.RL.Timing.Adjus Number of downlink If they are larger

t.Succ RLs of successful and than 0, timing
VS.DL.RL.Timing.Adjus failed RLs of timing adjustment is present
t.Fail adjustment in cell in cell. If timing
adjustment fails, the
normal sending and
receiving may be
affected.
Cell Measurement/Traffic Measurement Analysis

In cell measurement/traffic measurement analysis, take statistics of traffic at MAC
layer.
Take statistics of traffic flow, signaling flow, FACH/RACH/PCH transport channel
flow, and Iub CCH bandwidth.
If the total service throughput approaches available Iub bandwidth of TCH, the
throughput may declines due to inadequate Iub bandwidth. Solve this problem by
adding transmission bandwidth.
Cell Measurement/Cell RLC Measurement Analysis

Index Meaning Analysis Solution
VS.RLC.AM.TrfPDU.Trans Number of Check the

PDUs sent power
by RLC in control
AM mode parameters
like target
VS.RLC.AM.TrfPDU.Retrans Number of Service value of
service retransmission service
PDUs rate = number BLER,
retransmitted of PDUs for transmission
by RLC in retransmission error rate,
downlink in service/number and clock
AM mode of sent service abnormality.
PDUs. If the Check
retransmission coverage.
rate is high,
there may be
some problems.

VS.AM.RLC.DISCARD.TRF.PDU Number of Dropping rate =

service number of
PDUs dropped service
dropped by PDUs/number
RLC in of sent service
downlink in PDUs. If the
AM mode of PDU drop rate
cell is high, there
may be some
problems.
VS.RLC.AM.SigPDU.Trans Number of Check the
signaling power
PDUs sent control
by RLC in parameters
AM mode like target
value of
VS.RLC.AM.SigPDU.Retrans Number of Signaling service
signaling retransmission BLER,
PDUs rate = number transmission
retransmitted of retransmitted error rate,
by RLC in signaling and clock
downlink in PDUs/number abnormality.
AM mode of sent Check
signaling PDUs coverage.
VS.AM.RLC.DISCARD.SIG.PDU Number of Signaling
signaling dropping rate =
PDUs number of
dropped by dropped
RLC in signaling
downlink in PDUs/number
AM mode of of sent
cell signaling PDUs
The causes of high RLC retransmission rate and PDU packet dropping rate are:
 Bad BLER of radio link (including weak coverage)
 High transmission error rate
 Clock abnormality
To confirm weak coverage problem, perform DT/CQT and analyze CHR as below:
Perform DT/CQT to know the overall coverage conditions
Analyze CHR to know the RSCP and Ec/Io of subscribers in the environment
Sort the subscribers by RSCP in CHR analysis
Record the worst N subscribers and visit the location
Perform DT/CQT accordingly in these locations
----End

5 Analysis of DT/CQT Data
About This Chapter

 Access Failure
 5.2Disconnection of Service Plane
 5.3Poor Performance of Data Tranfer
 5.4Interruption of Data Transfer

WCDMA PS service data transfer problems include the following three types in terms
of phenomena:
 Access failure (or dial-up connection failure)
 Successful access but unavailable data transfer
 Available data transfer but low speed or great fluctuation
For the problem with different phenomena, follow different flows for processing them.
Flow for analyzing DT/CQT data
For access, call drop, signaling plane, and handover problems, see W-Access Problem
Optimization Guide and W-Handover and Call Drop Problem Analysis Guide. This
guide supplements some operations in PS service test.
Access Failure
There are two ways to use PS services:
 Originating PS services directly on UE, browsing web pages, and watching video
streaming directly on UE
 Combining personal computer (PC) and UE. Namely, UE serves as the modem of
PC, and the service is originated through PC
In optimization test, the combination of PC and UE is most widely used. In DT/CQT,
the PC is usually a laptop with the DT software Probe installed on it. This is called
Probe + UE. When the UE fails to directly originate PS services, it can obtain more
information by using Probe + UE. Therefore, the following analysis is mainly based on
Probe + UE.
5.1.1 Originating PS Service by UE Directly

shows the flow for analyzing access failure problems when originating PS services by
UE directly.

Flow for analyzing access failure problems when originating PS services by UE directly
The signaling of originating PS services by UE directly is the same as that of PC +

UE. The difference lies in the access point name (APN), and the way to set the address
for service visiting.
If the UE fails to originate PS services directly, following the step below for analyzing
causes:
Verify the problem by PC + UE
If the PS services through PC + UE is normal, the system must work normally. Then
check and modify the APN, address for serving visiting, Proxy, and password set on
UE.
Follow 5.1.2 if originating PS services by PC + UE fails.
----End
5.1.2 UE as the Modem of PC

shows the flow for analyzing access problem when the UE serves as the modem of
PC.

Flow for analyzing access problem when the UE serves as the modem of PC
Failure in Opening Port

shows the flow for processing problem of failure in opening port.

Flow for processing problem of failure in opening port
The major causes to failure in opening port include:

 Port in Hard Config of Probe is incorrectly configured
Check the configuration in Hardware Config. The port must be consistent with
the Com port and Modem port in Device Manager in Windows operating system.
 The port state is abnormal
The driver is improperly installed. Or during DT, the DT tool may abort
abnormally, so the port mapped in Windows Device Manager is marked by a
yellow exclamatory mark.
To solve this problem, reinstall the driver, pull and plug data line or data card of
UE.
 After the software aborts abnormally, the port is not deactivated
The DT software like Probe may abort abnormally, so the corresponding port is
improperly closed.
To solve the problem, quit the Probe and restart it. If the problem is still present,
restart PC.
 The software of UE is faulty
Restart UE to solve the problem.
 The driver of UE is incompletely installed

Reinstall the driver. This problem usually occurs upon the first connection of PC
and UE.
Successful Activation of Port but Access Failure

Opening port succeeds, but access fails. This is probably due to signaling flow
problem.
shows the flow for analyzing access failure problems
Flow for analyzing access failure problems
Trace the NAS and RRC signaling in Probe or trace the signaling of single subscriber
on RNC LMT. Analyze the problem by comparing it to the signaling flow for standard
data service. For the signaling flow for standard data service, see the senior training
slides of RNP: W-RNP Senior Training-Signaling Flow.
shows the signaling flow of successful setup of a PS service in Probe.

Signaling flow of successful setup of a PS service in Probe
In , Probe contains two windows: RRC Message, and NAS Messages. The signaling
point in NAS Messages window corresponds to the point of direct transfer messages
in RRC Message.
The following problem may occur due to the comparison of signaling flow:
 RRC connection setup failure
Description: in , it is abnormal from the RRC Connection Request message to the
RRC Connection Setup Complete message.
Analysis: the UE fails to send the RRC Connection Request message according to
the RRC Messages window in Probe, probably due to:
− Modem port is not selected in the Hardware Config widow in Probe.
− TestPlan is not configured in Probe or improperly configured.
− The port of UE is abnormal. See the Failure in Opening Port in 5.1.2 for
solution.

After the UE sends the RRC Connection Request message, it receives no

response or receives RRC Connection Reject message due to the admission
rejection caused by weak coverage and uplink and downlink overload. For
details, see the section Analyzing RRC Connection Setup Problems in W-Access
Problem Optimization Guide.
 UE's failure in sending Service Request
Description: There in no Service Request message in NAS Messages.
Analysis: The UE may have disabled PS functions or may have not registered in
PS domain.
− The UE may have disabled PS functions. Some UE supports CS or PS, or CS
+ PS. If the UE is set to support CS, PS services will be unavailable on it.
Check the UE configuration and Set it to support PS or CS + PS.
− The UE may have not registered in PS domain. According to signaling flow,
after the UE sends the Attach Request message, the network side responds the
Attach Reject message. The engineers at CN side need to check whether the
USIM supports PS services.
 The flow for authentication and encryption is abnormal
Description: it is abnormal from the Authentication AND Ciphering REQ in NAS
messages to the Security Mode Complete in RRC messages.
Analysis: the engineers at CN side need to check whether the authentication
switch in PS domain of CN is on, whether the CN CS domain, PS domain,
encryption algorithm of RNC, and the integrity protection algorithm is consistent.
On RNC LMT, query the encryption algorithm by executing the command LST
UEA. Query the integrity protection algorithm by executing the command LST
UIA.
For details, see the section Analyzing Authentication Problems and the section
Analyzing Security Mode Problems in W-Access Problem Optimization Guide.
 PDP activation is rejected
Description: after the UE sends the Activate PDP Context Request message, it
receives the Activate PDP Context Reject message.
Analysis: there are two types of problems, the improper configuration of APN
and rate at UE side, or CN problems.
− Improper APN at UE side
If the cause value of Activate PDP Context Reject is Missing or unknown
APN, the APN configuration is probably inconsistent with CN side. Check the
Probe and APN at UE side, and compare them with HLR APN. For the
method to set APN of UE and Probe, see the section Connecting Test Device
in Genex Probe Online Help. Ask the CN engineers to check the APN in HLR.
− Improper rate at UE side
If the cause value of Activate PDP Context Reject is Service option not
supported, the requested rate of UE is probably higher than subscribed rate in
HLR. Check the requested rate at Probe and UE side, and compare them with
the subscribed rate in HLR. Ask the CN engineers to check the subscriber rate
in HLR.
Check the APN and requested rate in the Activate PDP Context Request
message. See the appendix 8.7.
− CN problem

If the APN at UE side and restricted rate are properly configured, the problem
is probably due to CN problem. If some interfaces of CN are unavailable,
locate the problem with engineers on PS domain of CN.
If the PS service is the initial commissioning, the APN for defining a
subscriber by HLR is inconsistent with that of gateway GPRS support node
(GGSN). Confirm this with engineers on PS domain of CN.
For the analysis of causes of PDP activation rejection, see 8.10.
 RB setup failure
Description: after Activate PDP Context Request, the system fails to receive
Radio Bearer Setup message, but receives the release message.
Analysis: for details, see the section Analyzing RAB or RB Setup Problems in W-
Access Problem Optimization Guide.
 Others
See 5.3.1. Shrink the scope of the problem by changing each device.
5.2 Disconnection of Service Plane

shows the flow for analyzing disconnection of service plane, though the PS service
setup succeeds.

Flow for analyzing disconnection of service plane
5.2.1 Analyze Problems at RNA Side

The connection setup succeeds, so the signaling plane is connected but the service
plane is disconnected. This is probably due to TRB reset at RAN side. For HSDPA, the
service is carried by HS-PDSCH and the signaling is carried by DCH. When the power
of HS-PDSCH is inadequate, probably the signaling plane is connected and service
plane is disconnected. The following sections distinguish PS services carried on DCH
from PS services carried on HSDPA.
DCH bearer
shows the flow for analyzing RAN side problem about disconnection of service plane
for DCH bearer.

Flow for analyzing RAN side problem about disconnection of service plane for DCH
bearer
Check coverage conditions

Trace the pilot RSCP and Ec/Io of serving cell by Probe + UE. Judge whether a
point is in weak coverage area. For weak coverage area, such as RSCP < –100
dBm or Ec/Io < –18 dB, the data transfer for PS services is probably unavailable.
Solution: If the RSCP is bad, optimize it by improving coverage quality. If the
RSCP is qualified, but Ec/Io is bad, check:
− Pilot pollution. Then optimize the serious pilot pollution.
− Power configuration of pilot channel (LST PCPICH), usually 33 dBm.
− There is no external interference
Check call drop problem due to TRB reset
Obtain the CHR files corresponding to the occurrence point of problem. On RNC
LMT or in Nastar, check whether there is abnormal information near the point of
problem occurrence. This provides the evidence for judgment.
For the analysis tool, see W-Handover and Call Drop Problem Optimization
Guide.
Trace uplink and downlink throughput and bandwidth
On RNC LMT, select Connection Performance Measurement > Uplink

Throughput and Bandwidth, Downlink Throughput and Bandwidth. For
details, see the online help for RNC LMT. Check the uplink and downlink
throughput and bandwidth.
shows the Connection Performance Measurement-Downlink Throughput
and Bandwidth window.
Connection Performance Measurement-Downlink Throughput and Bandwidth

window
In ,
 The bandwidth shown is the bandwidth assigned for UE by system.
 The DlThroughput is the actual throughput of downlink data transfer.
Monitor the variation of access layer rate and non-access layer rate of uplink and
downlink data transfer for the current connection. This helps analyze the functions of
dynamic channel configuration and variation features of service source rate.
 If the uplink throughput is 0, the uplink may be disconnected.
 If the downlink throughput is 0, the downlink may be disconnected.
When the RNC DCCC function is valid, distinguish the variation of bandwidth caused
by DCCC.
If the problem is still unlocated after previous operations, collect the data packets
received and sent at RNC L2 and by GTPU by using the tracing tool RNC CDT. This
helps judge whether the disconnection of subscriber plane is in uplink or downlink, at
CN side or RAN side.
Others
Check problems at the CN side according to analysis of problems at CN side in
5.2.2.
Refer to Comparing Operations and Analyzing Problem. Change each part and
compare the operations. This helps reduce the scope of the problem. Feed back
the problem.

HSDPA Bearer
The HSDPA feature of cell is activated, The UE supports HSDPA. The rate requested
by UE or the subscribed rate is higher than HSDPA threshold for downlink BE service
(for BE service) or HSDPA threshold for downlink streaming service (for streaming
service). When the PS services are carried by HSDPA, follow the steps below:
Alarms in RNCs and CHR
Check the alarms and CHR for the point of problem occurrence whether there are
abnormalities. Provide diagnosis.
Deactivate HSDPA features so that PS services are set up on DCH
Deactivate HSDPA features by executing the command DEA CELLHSDPA. Connect
UE to the network by dial-up so that PS services are set up on DCH.
If the data transfer is unavailable on DCH, see the troubleshooting in previous block
DCH Bearer.
If the data transfer is available on DCH, the problem must be about HSDPA. Follow
the steps below.
Check the CQI, HS-SCCH success rate, and SBLER
Check the CQI, HS-SCCH success rate, and SBLER by Probe + UE as below:
 CQI
The UE estimates and reports CQI based on PCPICH Ec/Nt. For the calculation,
see 8.4.2.
If the CQI reported by UE is 0, the NodeB will not send UE any data.
In the current version, if the CQI calculated by NodeB based on current available
power is smaller than 2, the NodeB will not schedule the UE and send it any data.
If the common parameters like pilot Ec/Io, CellMaxPower, PcpichPower, and
MPO are normal, but the CQI is bad, change a PC. The PCs of different types
have different thermal noises, so they have different impact on reported CQI.
 HS-SCCH success rate
The HS-SCCH success rate is obtainable in the WCDMA HSDPA Decoding
Statistics window and WCDMA HSDPA Link Statistics window, as shown in .

HSDPA parameters in Probe
Wherein, the HS-SCCH Success Rate (%) is the HS-SCCH scheduling success
rate of the UE. It is relevant to the following parameters:
− Number of HS-SCCHs
− Number of HSDPA subscribers
− Scheduling algorithm parameter
If an HS-SCCH is configured to the HSDPA cell, the scheduling algorithm is the
RR algorithm, and all the connected subscribers keeps data transfer, the HS-
SCCH success rate is the reciprocal of number of subscribers. Namely, all the
subscribers share the HS-SCCH resource.
If the HS-SCCH success rate of a subscriber approaches 0, the data transfer rate
of the subscriber approaches 0, and the service plane may be disconnected.
The HS-SCCH success rate approaches 0 due to:
− The scheduling algorithm is much similar to MAX C/I algorithm, more than
one HSDPA subscribers connects to the cell, and the CQI of the subscriber is
low.
− The transmit power of HS-SCCH is over low. Now in the indoor scenario, the
transmit power of HS-SCCH is fixed to 2% of total transmit power of cell. In
outdoor scenarios, the proportion is 5%. If the transmit power of HS-SCCH is
lower than the fixed power, the UE may fail to demodulate HS-SCCH data.
− No data is transmitted at the application layer. Confirm this by the actual
transmitted data volume in the Connection Performance Measurement-
Uplink Throughput and Bandwidth, Downlink Throughput and
Bandwidth on RNC LMT.

− The CQI reported by UE is over low, so the NodeB will not schedule the
subscriber.
 SBLER being 100%
The SLBER is the slot block error rate of HS-DSCH. In , the right pane of the
WCDMA HSDPA Decoding Statistics window shows the SBLER and
retransmission conditions of transport blocks of different sizes. The WCDMA
HSDPA Link Statistics window shows the following parameters:
− HS-DSCH SBLER-Deta
− HS-DSCH SBLER-Average
Wherein, the Deta is the instantaneous value. The Average is the average value.
When the HS-PDSCH Ec/Nt is over low, the SBLER will be 100%. This is
actually caused by inadequate HSDPA power. Check the HSDPA power
configuration by executing the command LST CELLHSDPA. Wherein, the HS-
PDSCH and HS-SCCH power are the HSDPA power configuration.
There are two methods for HSDPA power configuration: static power
configuration and dynamic power configuration.
− If the power of the parameter configuration is higher than or equal to the
maximum transmit power of cell, use dynamic power configuration.
− If the power of the parameter configuration is lower than the maximum
transmit power of cell, use static power configuration.
The available power of HS-PDSCH in static power configuration = maximum
transmit power of cell – power margin – R99 downlink load (including CCH
load) – HS-SCCH power.
The available power of HS-PDSCH in dynamic power configuration = power of
HS-PDSCH and HS-SCCH – HS-SCCH power.
Note the static power configuration. Due to power control, the R99 services can
use HS-PDSCH power.
According to previous two formulas, in dynamic power configuration of HSDPA
power, if the power margin is over large, R99 downlink load is overhigh, or HS-
SCCH power is overhigh, the available power of HS-PDSCH is over low. In
static power configuration of HSDPA power, if the HS-PDSCH and HS-SCCH
power are over low, or HS-SCCH power is overhigh, the available power of HS-
PDSCH is over low.
SBLER is 100% seldom due to inadequate power, unless the CQI reported by UE
is over small. When the power of NodeB is inadequate, the CQI calculated by
NodeB is smaller, the scheduled TB blocks becomes smaller, so the rate obtained
by UE declines.
Solution: adjust parameter configuration. If the R99 load is overhigh, add
carriers.
Check the available bandwidth, occupied bandwidth, and assigned bandwidth at Iub
interface
Query lub bandwidth by executing the command DSP AAL2PATH on RNC LMT. Or
start the task Periodic Reporting of Iub Bandwidth Assignment Conditions of HSDPA
on NodeB console.
If errors occur in data transmission, the IMA group number of AAL2PATH (For
HSDPA) on NodeB fails to match that on RNC. When the available bandwidth of
HSDPA is inadequate due to product software problems, the data transfer is
unavailable.

5.2.2 Analyzing Problems at CN Side

The problems at CN side include abnormal work state of service servers and incorrect
user name and password.
shows the flow for analyzing problems at CN side about disconnection of service
plane.
Flow for analyzing problems at CN side about disconnection of service plane
Confirm by other access network or LAN that the service software servers and service
software run normally.
 LAN

Use FTP or HTTP service on a PC connected to LAN, and check whether the
service is available. In addition, verify the user name and password of the
connected user.
 Other radio access network under the same CN
If different 3G access networks under the same CN sets up PS service or sets up
PS service from the GRPS network, check whether the service is normal.
After previous checks, if the service servers work normally, focus on the problems at
RAN side for analysis. If the service servers are abnormal according to previous
checks, ask the on-site engineers of CN PS domain to solve the problem.
The IP address for visiting FTP and HTTP service servers by LAN is different from that for
visiting service servers after the UE sets up wireless connection. For details, turn to on-site
engineers of CN PS domain.
5.3 Poor Performance of Data Tranfer

The poor performance of data transfer, in terms of throughput measurement, lies in the
following problems:
 Unstable rate like great fluctuation
 Low rate
The poor performance of data transfer, in terms of QoS, lies in the following problems:
 Unclear streaming image
 Buffering
 Low rate in browsing web pages
The appendix 8.1contains the transport path of PS data. The PS data passes Internet
service servers, GGSN, SGSN, RNC, NodeB, and finally UE. Meanwhile the PS data
passes Gi, Gn, IuPS, Iub, and Uu interfaces. During the process, the PS data passes
Internet servers to GGSN using IP protocol. Between them, there may be one or more
devices like router and firewall.
The PS services use the AM mode of RLC and support retransmission function. The
FTP and HTTP services use TCP protocol which supports retransmission. The
parameters of these two protocols (RLC/TCP) have great impact on rate.
If the parameter configuration is improper, or missing and dropping data packet may
cause the data rate to decline. When checking the quality of service (QoS), engineers
make UE as the modem of a computer running applications, so the performance of
computer and servers will influence the QoS.
By and large, several factors affect the performance of data transfer of PS services, and
they include:
 RAN side
 CN equipment
 Applications and service software
The applications and service software problems are contained in the CN side
problems. shows the flow for analyzing poor performance of data transfer.

Flow for analyzing poor performance of data transfer
Checking Alarms
If there is a problem, check whether there are alarms. Query the NodeB and RNC
alarms at RAN side. Query the SGSN, GGSN, LAN switch, router, and firewall at CN
side. The alarms like abnormal clock alarms, high transmission error rate, and
abnormal equipment affect data transfer.
If problems cannot be located according NE alarms, refer to 5.3.1. By comparing
operations and analyzing problem, reduce the scope of problem.
 If the problem is at RAN side, refer to 5.3.2.
 If the problem is at CN side, refer to 5.3.4.
 If the problem concerns both the RAN and CN side, analyze it from both sides.

5.3.1 Comparing Operations and Analyzing Problem

Compare operations and analyze problem to focus on the possible faulty NE and to
determine the scope of problem: at CN side and service software, or at RAN.
Comparing operations and analyzing problem

Order Operation Result Analysis
1 Change USIM card Data transfer problem Problem maybe

has been solved related to user
information
configured in the
USIM card.
Data transfer problem is The problem cannot
still unsettled be located, so
continue checks.
2 Change UE/data card Data transfer problem Related to UE, such
has been solved as incompatibility
and poor
performance of UE
continue checks.
3 Change PC Data transfer problem Related to drivers,
has been solved APN, restricted rate,
and firewall.
continue checks.
4 Change PC under the Data transfer problem The problem at CN
same server (ensure than has been solved side, related to
the service is running service software
normally, and try to
PING the server and use Data transfer problem is The problem cannot
streaming services. still unsettled be located, so
continue checks.
5 Change a new website Data transfer problem The problem at CN
for visiting (from other has been solved side, related to
websites) performance of
server, TCP/IP
parameters, or
service software
continue checks.
6 Change other access Data transfer problem The problem at RAN
network under the same has been solved side.

server, such as GPRS Data transfer problem is The problem cannot

network still unsettled be located.
7 Test on other NodeBs Data transfer problem The NodeB problem,
has been solved or improper
configuration of
parameters related to
the NodeB and
configured by RNC
still unsettled be located.
After the approximate scope of problem cannot be located after previous checks,
analyze it as a problem of data transfer at RAN side and CN side.
5.3.2 Analyzing Poor Performance of Data Transfer by DCH

The mechanism at the air interface of HSDPA is different from that of DCH, so
different factors affect data transfer on DCH and HSDPA.
shows the flow for analyzing RAN side problem about poor performance of data
transfer on DCH.

Flow for analyzing RAN side problem about poor performance of data transfer on DCH
NE Alarms
If the performance of data transfer for PS services is poor, analyze NodeB and RNC
alarms. The clock alarms, alarms on transmission error rate, and transmission
interruption may cause fluctuation of PS data. For querying NodeB and RNC alarms,
see W-Equipment Room Operation Guide.
Data transfer affected by Uu interface
When PS services are carried by DCH, the factors affecting data transfer at Uu
interface includes:

− DCH bandwidth
− State transition
− Block error rate (BLER) at Uu interface
shows the flow for analyzing data transfer affected by Uu interface.
Flow for analyzing data transfer affected by Uu interface
1) DCH bandwidth
When PS services are carried by DCH, the RNC assigns bandwidth for each
connected UE. The bandwidth depends on spreading factor and coding
method.
On RNC LMT, in the Connection Performance Measurement-Uplink
Throughput and Bandwidth, Downlink Throughput and Bandwidth
window, check the uplink and downlink assigned bandwidth and throughput.
The bandwidth is the channel bandwidth assigned to UE by RAN. The
DlThroughput is the actual downlink rate of data transfer. Assigning
bandwidth (namely, code resource, power resource, and Iub resource are
normal) is normal if one of the following conditions is met:
− The bandwidth is the same as the request rate or subscribed rate.
− Maximum assignable rate (such as 384 kbps) is met upon DCH bearer.
If the bandwidth assigned to UE is smaller than the expectation, there are
two causes:
− Congestion or other causes. The RAN cannot assign UE with channels
of higher rate, which is abnormal.

− DCCC algorithm of RNC. If the DCCC algorithm parameter is rational,

the decline of rate is normal.
Enable the DCCC algorithm in the existing network so that the system can
save resource by reducing assigned bandwidth upon decline or pause of data
transfer. However, the DCCC algorithm configuration may be irrational.
DCCC algorithm involves rate adjustment based on traffic and coverage, and
rate adjustment in soft handover (SHO) SHO areas. According to the
parameters configured on site and based on algorithm, judge whether the
assignment and adjustment of DCH bandwidth are rational, whether there are
abnormalities, and whether the problem is solve by adjusting parameters.
If the assigned DCH bandwidth is small due to congestion and other
abnormalities, solve the problem by the following methods:
− Trace signaling of single subscriber
− Query cell downlink load, assignment of code resource, and available
bandwidth at Iub interface
− Obtain CHR from BAM and check the abnormalities on RNC INSIGHT
PLUS or Nastar.
2) BLER at Uu interface
The BLER at uplink and downlink Uu interface directly affect data transfer of
PS services. If the average of UL BLER or DL BLER measured in a period is
equal to or better than BLER Target, the code errors at Uu interface are
normal. Otherwise, analyze this problem.
DL BLER measurement: collect DT data by Probe and UE, and then import
the DT data to Assistant for analysis.
UL BLER measurement: In Connection Performance Measurement-Uplink
Transport Channel BLER window, import the measurement file to Assistant,
and analyze together with the Probe DT data files.
The power control and coverage affects the uplink and downlink BLER in the
following aspects:
− Outer loop power control switch. Check that the outer loop power
control switch of RNC is on.
− Coverage. Check whether the uplink and downlink are restricted in the
areas with bad UL BLER and DL BLER. For details, see W-RF
Optimization Guide.
− Performance of UE. Change a UE of other types and compare their
performance.
3) In Sequence Delivery
Set the sequence submission to TURE or FALSE. This affects the rate and
fluctuation of downlink. If you set the sequence submission to TURE, the
RLC keeps the transfer sequence of upper-layer PDUs. If set the sequence
submission to FALSE, the receiver RLC entity allows sending SDUs to
upper-layer in a sequence different from the sender. If you set the sequence
submission to FALSE, the uplink rate for data transfer will be low and data
transfer fluctuates much.
Setting sequence submission to TURE by executing the command MOD
GPRS on Huawei HLR is recommended.

Data Transfer Affected by Iub Interface

The transport code error at Iub interface, delay jitter, and Iub bandwidth affect the
performance of data transfer.
shows the flow for analyzing data transfer affected by Iub interface.
Flow for analyzing data transfer affected by Iub interface
Transport code error and delay jitter

According to transport alarms and clock alarms, check whether there are
problems.
Bandwidth at Iub interface
Check whether the Iub interface is congested by the following methods:
− Querying the bandwidth at Iub interface on RNC LMT and NodeB LMT.
− Referring to the section Flow for Analyzing Cell-level Traffic Statistics Data.
− Checking abnormal record in CHR

Querying bandwidth at Iub interface at RNC side proceeds as below:

1. Query adjacent node corresponding to each cell by executing the command LST
AAL2ADJNODE
2. Query the path of the NodeB by executing the command LST AAL2PATH.
3. Query the bandwidth by executing the command LST ATMTRF.
4. Query the residual bandwidth by executing the commands DSP AAL2ADJNODE and DSP
AAL2PATH at RNC side.
Querying the bandwidth at Iub interface at NodeB side proceeds as below:
AAL2PATH is necessary at NodeB. The relevant commands include LST AAL2PATH and DSP
AAL2PATH.
Comparison of Throughput at APP and RLC Layer

The throughput at APP and RLC layer is obtainable by DT/CQT. For the theoretical
relationship of rate at each layer, see the appendix 8.2.
If the rate of APP throughput and RLC throughout is lower than the normal range
according to theoretical analysis, the retransmission cost of TCP/IP is over large.
Check and modify the TCP receiver window and MTU configuration. For the method,
see the appendix 8.5 and 8.6.
5.3.3 Analyzing Poor Performance of Data Transfer by HSDPA at RAN Side

The HSDPA network schedules power and code resources by code division or time
division between multiple subscribers. When there is only one HSDPA subscriber in a
cell, the following factors affect the rate for data transfer:
 HSDPA available power
 Number of HS-PDSCH codes in cell (when there is only one subscriber, a HS-
SCCH is necessary)
 Category of UE (maximum number of codes supported by UE and whether to
support 16QAM)
 Radio signals near UE
In addition, the following factors affect the reachable maximum rate:
 Subscribed rate
 Bandwidth at Iub interface
 Maximum rate supported by RNC, NodeB, GGSN, and SGSN.
When there are multiple subscribers, besides previous factors, the scheduling
algorithm used by NodeB and number of HS-SCCH configured to cell affect the rate
of data transfer.
An HSDPA subscriber works as below:
The UE reports CQI on HS-DPCCH. The NodeB obtains the CQI of UE's location.
The scheduling module inside NodeB evaluates different subscribers by channel
conditions, the amount of data in cache for each subscriber, the last serving time. It
then determines the HS-DSCH parameters.
The NodeB sends HS-DSCH parameters on HS-SCCH, and after two slots it sends data
on HS-DSCH.

The UE monitors HS-SCCH for information sent to it. If there is any schedule
information, it starts receiving HS-DSCH data and buffers them.
According to HS-SCCH data, the UE judges whether to combine the received HS-DSCH
data and data in soft buffer.
The UE demodulates the received HS-DSCH data, and send the ACK/NACK message
on uplink HS-DPCCH according to CRC result.
If the NodeB receives the NACK message, it resends the data until it receives the ACK
message or reaches the maximum retransmission times.
In the DT tool Probe, out of consideration for multiple subscriber scheduling and
retransmission at MAC-HS layer, there are three rates at MAC-HS layer:
 Scheduled rate
Schedule rate = total bits of all TBs received in statistics period/total time with
TB scheduled in statistics period
The total time with TB scheduled in statistics period includes the time with data
received and excludes the time without data received.
 Served rate
Served Rate = Scheduled Rate * HS-SCCH Success Rate
Served rate = total bits of all TBs received in statistics period/statistics period
The total bits of all TBs received in statistics period include the bits of received
correct and wrong TBs.
The statistics period includes the time with and without data received.
 MAC layer rate
MAC Layer Rate = Served Rate * (1- SBLER)
MAC Layer Rate = total bits of correct TBs received in statistics period/statistics
period
The total bits of correct TBs received in statistics period include the bits of
corrects TBs and excludes bits of wrong TBs.
The statistics period includes the time with and without data received.
HS-SCCH success rate is the success rate for receiving HS-SCCH data by UE
SLBER = wrong TBs received at MAC-HS layer/(received correct and wrong TBs)
ACK->NACK/DTX is the ratio that NodeB judges the ACK message as NACK/DTX
message.
shows the flow for analyzing poor performance of data transfer on HSDPA at RAN
side.

Flow for analyzing poor performance of data transfer on HSDPA at RAN side
NE Alarms
When the performance of data transfer for PS services is poor, analyze the NodeB and
RNC alarms. The clock alarms, alarms on transport code error, and transmission
interruption may lead to fluctuation of PS data. For querying NodeB and RNC alarms,
see W-Equipment Room Operation Guide.
Whether the Service Is Set Up on HSDPA Channel

Check the IE serving HSDSCH RL indicator of the message RB SETUP on RNC. If
the IE is True, and the SF of downlink channel code is 256, the service must be
carried by HSDPA channel, as shown in .

Confirming in the RNC message that PS service is set up on HSDPA channel
You can also check the information like reported CQI in the WCDMA HSDPA Link
Statistics window in the DT software Probe. If no information is in the window, the
service must be carried on DCH, as shown in .
Confirming in Probe that service is set up on HSDPA channel
If the service is not set up on HSDPA channel, it will automatically be set up on DCH.
Now the service rate is the rate of R99 service, usually equal to or smaller than 384
kbps.

If it is confirmed that the service is not set up on HSDPA channel, analyze it from the
following aspects.
HSDPA cell is not set up
Check at RNC side whether the HSDPA cell is activated by executing the
command LST CELLHSDPA.
Check at NodeB side whether the local cell supports HSDPA. Check by executing
the command LST LOCELL whether the value of the local cell is TRUE or
FALSE.
If the HSDPA cell at RNC side is not activated, activate it by executing the
command MOD LOCELL: LOCELL=0, HSDPA=TRUE.
In addition, during modifying the HSDPA cell configuration on RNC, if HSDPA
codes are statically assigned, and if there are excessive R99 subscribers
connected to the cell so the code assigned to HSDPA is inadequate, the RNC still
displays that the modifying HSDPA cell configuration succeeds. However,
actually the HSDPA cell is not successfully set up. Check whether the codes
assigned to HSDPA cell are successful by selecting Realtime Performance
Monitoring > Cell Performance Monitoring > Code Tree Tracing on RNC.
Incorrect type of HSDPA AAL2PATH or No Configuration
Set the type of HSPDA AAL2PATH to HSDPA_RT or HSDPA_NRT. Otherwise
the cell can support R99 services only, but not HSDPA services. It is
recommended that one HSDPA AAL2PATH is configured to one NodeB. If
multiple HSDPA AAL2PATHs are configured, the data packets are easily dropped
in the current version. Query it at RNC or NodeB side by executing the command
LST AAL2PATH.
If the HSDPA AAL2PATH is set to RT or NRT, the downlink subscription rate of
UE is 2 Mbps. When the UE accesses the network, setting subscriber plane for
HSDPA service fails, and the RNC will automatically set up the subscriber plane
of PS 384kbps service. According to signaling of the RB Setup message, the
service is set up on R99, and SF is 8.
HSDPA subscriber's admission failure
The HSDPA subscriber's admission failure leads to that the RNC reconfigures
HSDPA service to be carried by PS384K channel of R99 service. If the service
cannot be set up, the UE continues to access the network after lowering the rate
of R99 service. If the rate of connected HSDPA subscriber is as low as 384 kbps,
128 kbps, or 64 kbps of R99 services according to test, confirm whether the
service is set up on HSDPA channel and whether the admission fails.
Check whether the following aspects are rational:
− Uplink and downlink load of R99 services
− Downlink code resource
− Iub transmission resource
− Number of HSDPA subscribers
− Threshold of HSDPA cell rate
− Guaranteed rate threshold of streaming service
− Guaranteed power threshold
Overhigh HSDPA threshold for downlink BE service
The HSDPA threshold for downlink BE service defines the rate judgment
threshold for background or interactive services carried on HS-DSCH in PS

domain. If the request rate is great than or equal to the threshold, the PS service is
carried on HS-DSCH; otherwise, the PS service is carried on DCH.
Set HSDPA threshold for downlink BE service by executing the command SET
FRC: DlBeTraffThsOnHsdpa=D384 on RNC.
Low Scheduled Rate

The TB size of NodeB scheduling depends on CQI, HSDPA codes, available power for
HSDPA, and so on. TB size/2ms is scheduled rate.
Normally, there is mapping relationship (depending on mapping table of NodeB CQI
in actual use) between the schedule rate and CQI reported by UE. The NodeB will
filter and adjust the CQI reported by UE, so the scheduled rate and CQI scheduled by
NodeB have mapping relationship, not completely having mapping relationship with
the CQI reported by UE.
lists the relationship between CQI and TB size according to the protocol 3GPP
25.306. It is only for reference, the product realization does not completely consist
with protocol.
Relationship between CQI and TB size when the UE is in category 11–12

CQI Transport Block Number of Modulation Reference power
value Size HS-PDSCH adjustment 
0 N/A Out of range
1 137 1 QPSK 0
2 173 1 QPSK 0
3 233 1 QPSK 0
4 317 1 QPSK 0
5 377 1 QPSK 0
6 461 1 QPSK 0
7 650 2 QPSK 0
8 792 2 QPSK 0
9 931 2 QPSK 0
10 1262 3 QPSK 0
11 1483 3 QPSK 0
12 1742 3 QPSK 0
13 2279 4 QPSK 0
14 2583 4 QPSK 0
15 3319 5 QPSK 0
16 3319 5 QPSK –1
17 3319 5 QPSK –2

18 3319 5 QPSK –3
19 3319 5 QPSK –4
20 3319 5 QPSK –5
21 3319 5 QPSK –6
22 3319 5 QPSK –7
23 3319 5 QPSK –8
24 3319 5 QPSK –9
25 3319 5 QPSK –10
26 3319 5 QPSK –11
27 3319 5 QPSK –12
28 3319 5 QPSK –13
29 3319 5 QPSK –14
30 3319 5 QPSK –15
Relationship between CQI and TB size when the UE is at the level 1–6
CQI Transport Number of Modulation Reference
value Block Size HS-PDSCH power
adjustment
0 N/A Out of range
1 137 1 QPSK 0
2 173 1 QPSK 0
3 233 1 QPSK 0
4 317 1 QPSK 0
5 377 1 QPSK 0
6 461 1 QPSK 0
7 650 2 QPSK 0
8 792 2 QPSK 0
9 931 2 QPSK 0
10 1262 3 QPSK 0
11 1483 3 QPSK 0
12 1742 3 QPSK 0
13 2279 4 QPSK 0
14 2583 4 QPSK 0

15 3319 5 QPSK 0
16 3565 5 16-QAM 0
17 4189 5 16-QAM 0
18 4664 5 16-QAM 0
19 5287 5 16-QAM 0
20 5887 5 16-QAM 0
21 6554 5 16-QAM 0
22 7168 5 16-QAM 0
23 7168 5 16-QAM –1
24 7168 5 16-QAM –2
25 7168 5 16-QAM –3
26 7168 5 16-QAM –4
27 7168 5 16-QAM –5
28 7168 5 16-QAM –6
29 7168 5 16-QAM –7
30 7168 5 16-QAM –8
The following factors affect scheduled rate:

 CQI
 Available power of HSDPA cell
 Available codes of HSDPA cell
CQI
If the downlink rate of UE is low, check whether the CQI reported by UE is over
low, and check the PCPICH RSCP and Ec/Io of the serving cell from the
following aspects:
− The coverage is weak, and the CQI reported by UE is low.
− The interference is strong, and there is pilot pollution, and the CQI reported
by UE is low.
− When the HSDPA serving cell is frequently updated, the HSDPA subscribers
cannot change accordingly due to punishment, so the CQI reported by UE is
low.
If the coverage is weak, improve the CQI reported by UE by RF optimization and
constructing sites.
If the interference is strong, adjust the azimuth and down tilt in RF optimization. This
forms a primary cell.
If the HSDPA serving cell is frequently updated, avoid frequent handover by adjusting
antenna azimuth and down tilt or constructing sites in RF optimization.
Available power of HSDPA cell

If the available power of HSDPA cell is over low, the TB size of NodeB
scheduling will be affected.
HSDPA power configuration includes dynamic and static configuration.
The RNC MML is MOD CELLHSDPA: HSDPAPOWER=430. The unit of
HSDPA power is 0.1 dB. The total power of all HS-PDSCHs and HS-SCCHs
must not exceed the HSDPAPOWER.
When HSDPAPOWER in previous formula is higher than or equal to total power
of cell, the HSDPA power configuration is dynamic configuration. The available
power of HSDPA cell = total power of cell * (1 – power margin) – power used by
R99 TCH and CCH.
When HSDPAPOWER in previous formula is lower than total power of cell, the
HSDPA power configuration is static configuration. Namely, the available power
of HSDPA cell is the HSDPAPOWER. However, the maximum available power =
total power of cell * (1 – power margin) – CCH power.
In static power distribution, the R99 services may occupy the power of HSDPA cell, so the
actual power used by HSDPA cell is not the configured power.
Analyze the factors affecting available power of HSDPA cell from the following
aspects:
− Query power margin by executing the command LST MACHSPARA on
NodeB. The default power margin is 10%, namely, the total downlink load of
cell can use 90% of total power of cell.
− On RNC LMT, select Realtime Performance Monitoring > Cell
Performance Monitoring > Tx Carrier Power. Observe the transmit carrier
power and power used by non-HSDPA subscribers. The available power of
HSDPA = transmit carrier power - power used by non-HSDPA subscribers. If
the power used by non-HSDPA subscribers is overhigh, the available power of
HSDPA cell becomes low, so the scheduled rate is affected.
Available codes of HSDPA cell
If inadequate codes are assigned to HSDPA subscribers, the TB size of NodeB
scheduling will be affected. For the method of assigning HSDPA channel codes,
see the appendix 8.4.1.
HSDPA UE CATEGORY
The 3GPP protocol 25.306 defines 12 types of UE category. In a TTI, the UE of a
type obtains different maximum TB size, so the maximum scheduled rate
obtained by UE is different.
The UE reports its capability in the IE hsdsch physical layer category of the
RRC Connection Setup Complete message.
For the HSDPA UE category, see 8.4.3.
Amount of data to be transmitted being smaller than the maximum TB size
The TB size scheduled by NodeB depends on the available power and codes of
the subscriber, as well as the amount of data transferred by the subscriber. If the
amount of data sent is smaller than the maximum scheduled TB size, the rate at
physical layer is lower than the expectation.
This problem occurs when there is data in NodeB buffer but the amount of data is
inadequate for a scheduled maximum TB size.

Low Served Rate

According to the previous formula Served Rate = Scheduled Rate * HS-SCCH
Success Rate, if the scheduled rate is normal, over low HS-SCCH success rate leads to
over low served rate. If there is only one subscriber in normal conditions, and the HS-
SCCH power and traffic are not restricted, the success rate of HS-SCCH is shall be
highly approach to 100%.
The success rate of HS-SCCH is relevant to HS-SCCH power, number of HS-SCCHs,
number of subscribers, scheduling algorithm, and transported traffic. The following
paragraphs describe them respectively.
HS-SCCH power distribution
The HS-SCCH is a downlink CCH, shared by all subscribers. The UE keeps
monitoring UE ID on HS-SCCH, and judge whether the UE ID is for itself. If the
UE ID is for itself, it demodulates HS-PDSCH data. Therefore, correct
demodulation of HS-SCCH goes before data transfer.
The HS-SCCH power is in static configuration or dynamic configuration.
The default configuration is static configuration. Set the HS-SCCH power to a
fixed ratio of maximum transmit power of cell as below:
− Set the ratio to 3% in indoor environment.
− Set the ratio to 5% in outdoor environment.
Set the HS-SCCH power on NodeB LMT by executing the command below:
SET MACHSPARA: PWRFLG=FIXED, PWR=5;
HS-SCCH power can be configured as dynamic power control, which is achieved
by setting a power offset to the pilot bit of DL-ADPCH. The power offset is
relevant to spreading factor of downlink DPCH and whether the UE is in SHO
state. When this method is used, the HS-SCCH power offset is listed as in .
The MML command is as below:
SET MACHSPARA: PWRFLG=DYNAMIC;
HS-SCCH power offset

Spreading factor of HS-SCCH power offset HS-SCCH power offset
downlink DPCH in non-SHO period in SHO period
4 –10.75 –6.75
8 –7.75 –3.75
16 –4.75 –0.75
32 –1.75 +2.25
64 +1.25 +5.25
128 +4.25 +8.25
256 +7.25 +11.25
Number of HSDPA subscribers and number of HS-SCCHs

The success rate of HS-SCCH is relevant to number of subscribers.

− If there is only one HSDPA subscriber in a cell, the traffic is not restricted and
HS-SCCH power is adequate, the success rate of HS-SCCH for the subscriber
approaches 100%.
− If there are multiple HSDPA subscribers in the cell, the success rate of HS-
SCCH for each subscriber is relevant to scheduling algorithm and number of
HS-SCCHs.
Usually set the HS-SCCH according to available power of HS-PDSCH, code
resource, and traffic of service source. For example, if UEs used in the cell are all
category 12 UE, set number of HS-PDSCH codes and number of HS-SCCHs as
below:
− If you set 5 codes to HS-PDSCH, it is recommended to set 2 HS-SCCHs.
Scheduling algorithm
Using different scheduling algorithm for multiple subscribers enables each
subscriber to be scheduled at different probability. For example, after MaxC/I
scheduling algorithm is used, the subscribers far from the cell center will hardly
or even never be scheduled due to low CQI.
The scheduling algorithm is one function of new function entity of HSDPA, the
MAC-hs function entity. Four factors are involved as below:
− CQI
CQI is the quality of signals received by UE at the location.
− Wait_Inter_TTI
It indicates the length of time that the UE must wait for service.
− Queue priority
− Queue length
The following scheduling algorithms are typical:
− MaxC/I (only considering CQI value)
− RR (only considering wait_Inter_TTI)
− Classic PF (proportional fair, considering previous factors)
Parameters are not configured for current scheduling algorithm. Select one of
previous three algorithms by executing the command below:
SET MACHSPARA: LOCELL=10131, SM=PF;//The previous algorithm
corresponds to the PF scheduling algorithm.
The following aspects must be considered in a typical PF scheduling algorithm:
− Allocate resources according to the weighting factor of scheduling equal to
R/r. Wherein, the R is the requested rate; the r is the actual average scheduling
rate for the subscriber, and it is the output after а filter. The average length is
equivalent to 1.6s. The retransmitted data is not involved in the calculation of
R and r. Therefore, the actual rate obtained by the subscriber at the
application layer and the rate requested by CQI are approximately
proportional.
− Upon overall scheduling, the NodeB allocates resources to the UE with
highest weighting factor of scheduling. If there are resources left, the NodeB
allocates them to the UE with the second highest weighting factor of
scheduling.

Selecting scheduling algorithm depends on the scenarios for cell coverage. In

an indoor distributed system scenario, the signals are qualified, the difference
of signals quality between one spot and another is little, so RR algorithm is
proper.
In outdoor scenarios, some areas are well covered, some are weakly covered,
so the classic PF scheduling algorithm is recommended to equalize different
subscribers.
Cell radius configured by NodeB
The NodeB downlink digital signal processing chip (DSP) does not know the
distance between UE and NodeB, so it cannot obtain the accurate transit delay,
but judge the transit delay by cell radius.
If the cell radius is short than 5 km, the NodeB takes 15.5 timeslots between
scheduling the UE on HSSCCH and receiving the response of the scheduling
according to timing relationship of HSDPA. The NodeB schedules a single
subscriber by multiple threads. While it waits for the response of a scheduling, it
can schedule other threads. This increases the efficiency. There are 6 threads used
at most, and each TTI needs 3 timeslots, so there are 18 timeslots in a cycle. A
single thread RTT needs 15.5 timeslots. The NodeB takes 2.5 timeslots of 15.5
for scheduling. During the scheduling, HS-DPCCH demodulation, HSSCCH
coding, and internal scheduling delay are involved.
If the cell radius is longer than 5 km, the NodeB uses 7 TTIs for scheduling by 6
threads. This guarantees enough time for NodeB. The NodeB can schedule the
UE for 6 times with 7 TTIs, so the total success rate of scheduling is 6/7 (85.7%)
at most.
When an RRU is used, the remote deployment distance of it is within the cell radius.
Set the cell radius and set the cell to support HSDPA by executing the command
below:
ADD LOCELL: LOCELL=1, RADIUS=5000, HSDPA=TRUE;
Traffic
After previous configuration and checks, there is no problem and CQI reported by
UE is high, but the rate of subscribers fluctuates. Check downlink traffic in
Connection Performance Monitoring window on RNC LMT, and see whether
there is enough traffic for scheduling. Or check downlink traffic in HSDPA User
Flow Control Performance Periodic Report window on NodeB LMT.
The cause of this problem is unstable source rate, single thread used upon
downloading, and small TCP window.
In the HSDPA User Flow Control Performance Periodic Report window, there
are following selections:
− Queue Priority
− Queue Buffer Used Ratio
− RLC User Buffer Size
− Input Data Size
− Output Data Size
Select Queue Buffer Used Ratio to draw picture on LMT, and check the
occupation of NodeB queue.
Select RLC User Buffer Size to check RLC cache.

Select Input Data Size and Output Data Size to check the sending and receiving
queue data. The data involved in Output Data Size is the data with ACK
indicator received.
Restricted Rate at UE side
The request service type, uplink and downlink maximum rate are sent to UE by
AT commands. The UE sends the information to CN in the following Active PDP
context request message. When the subscribed rate is higher than or equal to the
requested maximum rate, the CN sends the RAN Assignment request message at
the requested maximum rate. If the resource is not restricted at RNC side, the
final output rate is the request maximum rate. If the downlink maximum rate in
the RAB Assignment request message is much lower than scheduled rate, and the
traffic in buffer is inadequate upon NodeB's scheduling, the success rate of HS-
SCCH must be low.
Execute AT commands as below:
Right click My Computer
Select Property > Hardware > Device Manager > Modem > Property > Senior
Type AT command into the Initialization Command text box. Set APN by AT
command. If you want to set APN to cmnet, the rate is restricted to 64 kbps in uplink
and 384 kbps in downlink, execute the following command:
AT+cgdcont=1,"ip","cmnet"; +cgeqreq=1,3,64,384
When you remove the restriction on rate, execute AT command to set the rate to 0. The
value 0 means that no specified rate is requested, so the system assigns the subscribed
rate as possible. Execute the following command:
AT+cgdcont=1,"ip","cmnet"; +cgeqreq=1,3,0,0
----End
Restriction of bandwidth at Iub interface

If the physical bandwidth at Iub interface is restricted, the HSDPA service obtains
inadequate AAL2PATH bandwidth. As a result, the traffic in NodeB buffer is
inadequate, so the success rate of HS-SCCH is low.
In addition, the R99 AAL2PATH and HSDPA AAL2PATH are respectively
configured, but they share the physical bandwidth. If multiple R99 subscribers are
using the bandwidth at Iub interface in the cell, the HSDPA service obtains
inadequate AAL2PATH bandwidth. As a result, the success rate of HS-SCCH is
low.
Restriction of RNC FMR flow
On RNC, set the HSDPA flow supported by the WFMR/WFMRb board by
executing the command SET HSDPATRF. For the HSDPA UE of category 12, set
the HSDPA flow to D2 (standing for 2 Mbit) for single subscriber, and D8
(standing for 8 Mbit) for multiple subscribers.
By default, the RNC sets the HSDPA flow to D2. When the CQI is high, and the
sum of rate of multiple subscribers is equivalent to the rate of single subscriber in
test, the parameter configuration must be improper.
ACK/NACK repeat factor
The following parameters at physical layer are sent to UE and NodeB in the
messages at higher layer:
− ACK/NACK repeat factor: N_acknack_transmit
− CQI repeat factor: N_cqi_transmit

− CQI feedback cycle: CQI Feedback Cycle k

After the UE demodulates HS-PDSCH data, the UE sends an HARQ ACK or
NACK message based on cyclic redundancy check (CRC) of MAC-hs, and it
repeats sending the ACK/NACK message in the continuous N_acknack_transmit
HS-DPCCH subframes. If the N_acknack_transmit is larger than 1, the UE will
not try to receive or demodulate transport blocks between the HS-DSCH n+1 and
n + N_acknack_transmit – 1 subframes. The n is the subframe number of last HS-
DSCH in the received transport blocks. Now the rate obtained by UE is as below:
Rate of UE when the ACK/NACK is not repeatedly sent * (1/
N_acknack_transmit)
Low MAC Layer Rate

According to a previous formula MAC Layer Rate = Served Rate * (1- SBLER), low
MAC layer rate is a result of high SBLER. Normally, when the IBLER is 10%, the
SLBER will be lower than 15%. The following factors affect SBLER.
IBLER
IBLER affects MAC-HS retransmission, so it consequently affects the actual rate
of subscribers. The IBLER here is number of incorrect TBs/number of total new
data blocks when the NodeB transmits new data. The SBLER here is number of
incorrect blocks/(number of incorrect and correct blocks) when the NodeB
transmits new data or retransmits data.
IBLER directly affects SBLER. Now the default IBELR is 10%. IBLER directly
affects the power for scheduling each subscriber. This is similar with outer loop
power control of R99.
Execute the command SET MACHSPARA to set the following items:
− Scheduling algorithm
− MAC-HS retransmission times
− Power margin
− HS-SCCH power
− Initial BLER
The MML command is as below:
SET MACHSPARA: LOCELL=1, SM=PF, MXRETRAN=4, PWRMGN=10,
PWRFLG=FIXED, PWR=5, IBLER=10;
Low CQI and inadequate HSDPA power
If the CQI reported by UE is low, and the available power of HSDPA is
inadequate, SBLER will be high. The size of an MAC-d PDU is 336 bits. The
MAC PDU requires the TB size larger than 336 bits in transmission. As a result,
the CQI upon NodeB's scheduling must be larger than a value to meet that IBLER
is within 10%.
CQI reported by UE being higher than actual one
The CQI reported by UE is inaccurate, higher than the actual one. The NodeB
adjusts the CQI according to target IBLER, but it takes some time for adjustment.
During this period, the NodeB transfers data with low power according to the
CQI reported by UE. As a result, the SLBER is high, so the performance of data
transfer is affected.
Solution: by Windows HyperTerminal, connect UE to the data card. Adjust the
CQI reported by UE by executing AT commands (This solution caters for Huawei
data card only. The current version does not support this).

Assume: before the following operations, the CQI reported by connected UE is

25.
− Enable the function of adjusting CQI, set the offset to –200, and lower CQI.
Type the following command:
AT^CQI=1,-200
The UE responds OK. The CQI is 2–3 lower than before, and is 22–23.
− Enable the function of adjusting CQI, set the offset to 0, and the CQI restores
to be the actual value. Type the following command:
AT^CQI=1,0
The UE responds OK. The CQI is 25.
− Enable the function of adjusting CQI, set the offset to 200, and raise CQI.
Type the following command:
AT^CQI=1,200
The UE responds OK. The CQI is 2–3 lower than before, and is 27–28.
− Disable the function of adjusting CQI. Type the following command:
AT^CQI=0,200
The UE responds OK. The CQI remains 27–28.
− If you type wrong parameters as below:
AT^CQI=1,100,1
The UE responds TOO MANY PARAMETERS.
− If you query the state of CQI adjustment function, type the following
command:
AT^CQI?
When the UE responds +CME ERROR, the current NV time 4448
NV_CQI_ADJUST_I is not activated, and the adjustment function is disabled.
When the UE responds ^CQI:0,200, the function of adjusting CQI is disabled.
When the UE responds ^CQI:1,200, the function of adjusting CQI is enabled.
Over low pilot power
On prior version of NodeBs, according to RTT test,
− If the power of other channel is 10 dB higher than pilot channel, this leads to a
10% code error for HSDPA.
− If the power of other channel is 13 dB higher than pilot channel, this leads to a
100% code error for HSDPA.
Now the NodeB can adjust power in a certain scope according to HSDPA
SBLER. If the power of other channels is 13 dB higher than the pilot power, the
impact on throughput is little. Setting PICH over low is forbidden; otherwise, the
power is inadequate after adjustment by NodeB. This leads to overhigh SBLER,
and consequently the throughput is affected.
Low RLC Layer Rate
High ACK->NACK/DTX ratio

ACK->NACK/DTX is the ratio that the NodeB judges ACK as NACK/DTX.
Simulation requires the average probability of ACK->NACK/DTX to be lower
than 1%. If the NodeB judges ACK as NACK/DTX, the NodeB will retransmit
the data correctly received by UE. This wastes resource and lowers subscribers'
rate.

The following parameters describe an example on Probe, as shown in .
High code error of ACK->NACK/DTX in Probe
In the WCDMA HSDPA Decoding Statistics window, you can see ACK-
>NACK/DTX. In , ACK->NACK/DTX is 76.01%. The right pane displays
detailed number of blocks that are correct received and retransmitted. As a result,
ACK->NACK/DTX=7808/(7808+2465)=76.01%.
In the WCDMA HSDPA Link Statistics window, the MAC Layer Rate-Average
is 67.33 kbps. In the left pane, the RLC DL Throughput is 16.19 kbps. The ratio
of RLC rate and MAC rate is 16.19/67.33, equal to 24.05%. If the correct blocks
that are repeated received is excluded from calculating MAC layer rate, the MAC
layer rate is 67.33 * (1- 76.01) = 16.15 kbps. The MAC layer rate is
approximately equal to RLC rate.
− Over low configuration of HS-DPCCH power parameters
HS-DPCCH is an uplink dedicated physical channel, transporting the
ACK/NACK, and CQI messages at physical layer. HS-DPCCH is not under
respective power control, but has a power offset with downlink DPCCH.
When HS-DPCCH carries different information, it uses different offset values.
If the ACK/NACK power offset on HS-DPCCH is over low, the ACK-
>NACK/DTX demodulated by NodeB in uplink will be overhigh, and
consequently the subscribers' rate is affected.
For the description of HS-DPCCH power parameters, see the appendix HS-
DPCCH Power Control Parameter Configuration.
− Uplink and downlink RL imbalance in handover areas
The uplink and downlink RL imbalance in handover areas are defined as
below, and shown in:
RL2_dl > RL1_dl
RL2_ul < RL1_ul

Uplink and downlink RL imbalance in handover areas
Because RL2_dl > RL1_dl, the serving cell is updated, and the HSDPA service is set
up in the cell 2. The RNC adjusts SIRtarget according to combination result of two UL
RLs due to SHO. The two cells perform inner loop power control according to
SIRtarget. The UE combines the downlink TCP of the two cells. According to
combination principles, if the TCP of one cell is –1, lower power accordingly. When
the TCP of two cells is +1, raise power.
Because RL2_ul < RL1_ul, the RL1_ul SIR is converged to target value, and RL2_ul
SIR is lower than the target value. The power control over HS-DPCCH is based on the
associated channel of RL_ul, so the demodulation performance of HS-DPCCH
ACK/NACK/CQI cannot meet requirement. As a result, the performance of data
transfer for HSDPA subscribers is poor.
Analysis proceeds as below:
Obtain HSDPA-HSDPA handover test data, including the data at UE side and RNC side.
According to single subscribing signaling tracing, analyze to see whether there is a
serving cell updated due to UL RL failure. If yes, find the UE APP throughput at the
corresponding point.
With the data at RNC side, draw a chart involving uplink SIR, SIRtarget, UL BLER,
downlink throughput, PCPICH RSCP and Ec/No. Obtain the SIR information on
HSDPA uplink associated channel.
Based on the results from Step 2 and 3 above, obtain the information about RL
imbalance.
Analyze RL imbalance and provide solutions.
----End
Impact from power control of uplink associated DCH

The impact from power control of uplink associated DCH includes the following
two aspects:
HS-DPCCH is not under individual power control, but has a power offset with
uplink DPCCH. If the uplink DCH power control is not converged, and BLER is
overhigh, the uplink HS-DPCCH power will be over low, and the NodeB will
judge ACK as NACK/DTX in a great probability. As a result, the rate of RLC
layer for HSDPA subscribers is over low.

TCP and RLC uses AM mode, so sending the ACK message is necessary on
uplink DCH.
TCP provides reliable transport layer, the receiver responds the ACK message.
Any the data and the ACK message may be lost during transmission, so TCP sets
a timer upon sending for solving this problem. If the sender does not receive the
ACK message till expiration of the timer, it resends the data. As a result, the rate
for data transfer is affected. If the uplink DCH power control is not converged,
and BLER is overhigh, the sender TCP will fail to receive the ACK message and
resend the data. As a result, the rate of data transfer is affected.
RLC uses AM mode. If the uplink BLER is not converged, the RLC will receive a
late ACK response or no response. After expiration, the RLC resend the data, so
the rate for data transfer is affected. If the RLC fails to receive the ACK message
after multiple times, RLC reset occurs. The RLC sending window can configure
the maximum value to 2047 at most. When the rate for sending by RLC is high,
and the response to RLC is late, the RLC sending window will be full and no new
data can be sent.
Check the uplink BLER in Uplink BLER of RNC Connection Performance
Monitoring window. The baseline requires target uplink BLER as 1%. Find the
causes of non convergence of uplink power control from the following two
aspects:
− Check whether the RTWP fluctuates abnormally, and whether there is uplink
interference. Check RTWP in RNC cell performance monitoring.
− Check whether the configuration of outer loop power control parameters for
the current services is proper. Focus on SIRTarget and BLERTarget. Follow
the steps below:
Query the index value for current services by executing the command LST TYPRAB.
For example, the index value for the 384 kbps services is 22.
Query SIRTarget and BLERTarget by executing the command LST TYPRAB:
RABINDEX=22, TRCHTYPE=TRCH_HSDSCH,
IUBTRANSBEARTYPE=IUB_GROUND_TRANS;
Modify SIRTarget and BLERTarget for current service by executing the command MOD
TYPRABOLPC: RABINDEX=22, SUBFLOWINDEX=0,
TRCHTYPE=TRCH_HSDSCH, IUBTRANSBEARTYPE=IUB_GROUND_TRANS,
BLERQUALITY=-20;
----End
In addition, in remote deployment test of single HSDPA subscriber in a single

HSDPA cell, at the cell edge, the CQI reported by UE is good, but subscriber's
rate is low, even as low as 0. The major cause is that the uplink power of UE is
restricted, that uplink power control is not converged, and that uplink BLER is
high, even as high as 100%.
Wrong configuration of AAL2 PATH (NodeB RCR > RNC PCR, or configured
bandwidth > physical bandwidth)
The RCR parameter is added to AAL2 PATH at NodeB side to fulfill flow
control. It is the receiving rate of NodeB. For ATM driver, the receiving rate
cannot be restricted, so the RCR parameter is logical only. The receiving rate is
not necessarily equal to the configured RCR parameter, but depends on the
sending rate of RNC, namely, the PCR and SCR upon configuration of
AAL2PATH by RNC.

The NodeB deducts the bandwidth corresponding to R99 call from the total
bandwidth of PATH according to receiving rate, and then obtains the residual
bandwidth of all PATH. The RCR is reported to DSP, and the DSP construct
frame informs RNC of residual bandwidth. The residual bandwidth is for HSDPA
subscribers, so the flow is controlled.
If the receiving bandwidth RCR of NodeB AAL2 PATH is larger than PCR of
RNC AAL2 PATH, the data packets at Iub interface will be dropped.
In addition, if the configured bandwidth of AAL2PATH is larger than the physical
actual bandwidth, the data packets at Iub interface will be dropped. As a result,
the total throughput of cell declines.
Overhigh RLC retransmission rate due to overhigh residual BLER at MAC layer
If the retransfer at MAC layer reaches the maximum times, the TBs incorrectly
received will be dropped. If the receiver detects dropping data packets, it requires
the sender to resend data packets by state report. Retransfer lowers the sending
efficiency of RLC, so it affects the valid throughput of RLC. When residual
BLER at MAC layer is overhigh, the SBLER at MAC layer is probably overhigh.
For detailed analysis, see the analysis of overhigh SLBER in previous sections.
Normal the residual BLER at MAC layer is smaller than 1%.
shows the residual BLER at MAC layer in WCDMA HSDPA Decoding
Statistics window.
Residual BLER at MAC layer in WCDMA HSDPA Decoding Statistics window
Downlink rate affected by restriction over uplink rate

TCP and RLC uses AM mode, and transferring the ACK message is necessary on
uplink DCH. According to test data, the transmission rate for feeding back
information on uplink channel takes 2%–3% of transmission rate of downlink
channel.
For example, the downlink rate is 1.6 Mbps, and the corresponding uplink rate is
32–48 kbps. When the downlink rate is 3.6 Mbps, the corresponding uplink rate
is 72–108 kbps. If the uplink subscribed rate is 64 kbps, the requirement on
uplink rate corresponding to downlink data transfer cannot be met.
In addition, if there is data to be transferred in uplink for HSDPA subscribers, the
uplink channels must transport the confirmation data of TCP and RLC, as well as
uplink data of subscribers. If the uplink subscribed rate is low, the downlink data
transfer is affected.
Check the uplink rate for service setup in RAB Assignment Request message. If
the uplink rate is low, check the HLR subscribed rate.
Check the actual uplink bandwidth in RB SETUP message.

Comparison of Throughput at APP and RLC Layer

Obtain the throughput at APP and RLC layer in DT/CQT. For the theoretical
relationship between them, see the appendix 8.2.
If the ratio of throughput at APP layer to that of RLC layer is lower than the range of
theoretical analysis, the TCP/IP retransmission cost may be over large. Check and
modify the TCP receiver window and MTU configuration. For the modification
method, see the appendixes 8.5and 8.6.
5.3.4 Analyzing Poor Performance of Data Transfer at CN Side

shows the flow for analyzing poor performance of data transfer at CN side.
Flow for analyzing poor performance of data transfer at CN side
NE Alarms
At CN side, analyze the alarms on SGSN, GGSN, LAN switch, router, and firewall
(collecting SGSN and GGSN alarms as key task). Clock alarms and transport code
error alarms may lead to fluctuation of PS data.

Environment Problems
The rate is relevant to PC, OS, and applications. The internal algorithm of software at
different application layer and TCP parameters of OS have great impact on
performance. If other conditions are the same, the rate of data transfer on Windows
2000 computer is superior to that on Windows 98 computer. Therefore, it is
recommended to use Windows 2000 Professional and Windows 2000 server as the OS
of PCs and servers.
Now the laptops are installed with Windows XP, so there is no problem concerning
perform due to OS. Anyhow, the servers must be installed with Windows 2000 server,
because Windows XP will affect the performance of data transfer.
The PC (laptop) for being daemon of UE must be of good performance. Tests prove
that IBM laptops have good performance in playing VODs. Now Huawei RNP
engineers use the new laptops of D Corporation, which have worst performance in data
transfer of HSDPA test than the new ones of H Corporation.
If the utilization CPU being daemon of UE is 100%, the TCP/IP receiver window is
full. As a result, the performance of data transfer is affected.
The performance of servers may affect service effect, which must be considered.
TCP Receiving and Sending Window

For the services (such as VOD and FTP) using TCP protocol, the TCP window size of
test laptop (client) and server have great impact on performance of services. Set the
window as large as possible to guarantee good performance. Set the window of client
and server in the same size, such as 64K.
For modification method, see the appendix.
Maximum Transmission Unit

If a data packet at IP layer is to be sent, and the data packet is larger than the maximum
transmission unit (MTU), the IP layer will divide the data packet to pieces. Each piece
is smaller than MTU. Using larger MTU and avoiding IP segment and reassembly
helps to raise efficiency. MTU is usually smaller than or equal to 1450.
Changing MTU includes changing the MTU of server and changing the MTU of test
laptop. After PS service connection setup, the service negotiates with the client. The
MTU in use takes the smaller of the two MTUs.
For modification, see the appendix.
Service-related Problems
FTP
Use the commercial FTP software, because the FTP software embedded in
Windows OS is of average performance. Download data with FTP in binary. The
multi-thread downloading software like FlashGet is recommended.
VOD
The software RealPlayer sets the maximum play rate to larger than 384 kbps. The
buffer time must not be over long, and 3s is proper. Some computers are installed
with qualified video adapter, so the monitor jumps some frames. Change the
resolution to 800x600. If the problem is still present, change the video adapter.

Net TV
When the rate of down-layer declines, the Net TV is difficult to restore. Note this.
Video conference
Set the output rate of convergence TV smaller than the rate of down-layer;
otherwise, data packets will be dropped. Huawei conference video sets 64 kbps as
step from 128 kbps. The recommended configuration is 320 kbps. If the rate is
over low, utilization rate of down-layer rate will be over low. Otherwise, using
the rate higher than 320 kbps, such as equal to or larger than 384 kbps, leads to
dropping data packets because the rate of down-layer cannot meet the
requirements by application layer. As a result, the performance of video
conference declines. If a lightning sign appears on the right upper corner of
conference TV, there must be code error or packet dropping during transmission.
HSDPA Subscribed Rate

In test, if the downlink throughput of HSDPA subscriber is only 384 kbps, 128 kbps, or
64kbps. By check the HSDPA cell is set up exactly. After confirmation that the
problem is not at RAN side, check the HLR subscribed rate and subscribers' QoS
parameters of SGSN and GGSN.
HLR
The APN and subscribed rate is changed in MOD GRPS of HLR. You can set
multiple APNs to a SIM card. Each APN matches a highest rate.
When the maximum rate is not restricted at UE side, the RAB assignment request
message sent by CN brings the subscribed rate.
If no resource, such as power resource and code resource, is restricted at RNC
side, the Activate PDP content Accept message of NAS signaling brings the
assigned rate to UE. Obtain the rate contained in the Activate PDP content Accept
message in Probe or other DT tools.
GGSN
Modify subscribers'' QoS parameters on GGSN. Set downlink bit rate and
downlink guaranteed rate as required. The default configuration is 384 kbps. The
commands are as below:
SET QOS: MBRDNLK=2048, GBRDNLK=2048;
The previous command sets the downlink maximum rate to 2048 kbps. As a
result, the CN allows the downlink maximum rate of HSDPA to be 2 Mbps.
SGSN
Modify downlink maximum rate and downlink guaranteed rate of subscriber by
executing the command below:
SET 3GSM: MBRDNLK=151, GBRDNLK=151;
Set the maximum bandwidth to 151 (standing for 2 Mbps) by executing the
command SET 3GSM.
5.4 Interruption of Data Transfer

5.4.1 Analzying Interruption of Data Transfer
Description: data transfer is interrupted for a period.
The possible causes include:

 Call drop during data transfer

 After the UE hands over 3G networks to 2G networks, it cannot perform data
transfer.
 State transitions occurs. After the UE transits from CELL_DCH to CELL_FACH
and CELL_PCH, when restoring data transfer is necessary and the resource for
restoring data transfer is inadequate, the UE cannot restore to CELL_DCH state.
Therefore data transfer is affected.
 Other causes, like interruption of data transfer.
Analyze the problem from alarms, signaling flow, and CHR.
Flow for analyzing interruption of data transfer
Alarms
Query the alarms on CN and RAN. Know the abnormalities in the operation of
current system. Guide to analyze and exclude problems. Some problem, such as
interruption of data transfer, clock asynchronization in some cells, and NE
congestion, can be known from alarms.
Signaling Flow
Analyze signaling in details to locate interruption of data transfer. Check whether
call drops, whether the UE hands over from 3G networks to 2G networks, and
whether state transits.
Collect signaling in several ways. Collect the signaling at UE side by using Probe
and UE. Collect the signaling at RNC side on RNC LMT. By comparison of two

signaling flow, check whether messages are lost at air interface. Based on
analysis and CHR, engineers can locate the problem or obtain the rough direction.
Call Drop
For call drop problems, see W-Handover and Call Drop Problem Optimization Guide.
Channel State Transit

When the cell state transits to CCH, it cannot restore to CELL_DCH. Check the
abnormal information in CHR. If the downlink load is over large by confirmation, or
the bandwidth at Iub interface is congested, add carriers or transport resources.
If the data transfer is problematic after handover from a 3G network to a 2G network,
the problem involves the cooperation of the two networks. If the 2G network was
constructed by partners, locating the problem will be more difficult.
Try to set up PS services in the 2G network, and see whether it runs normally. If the
data transfer upon access to the 2G network is normal, but the data transfer after
handover from the 3G network to the 2G network is abnormal, check the UE and the
signaling flow at 3G and 2G NE side.
In terms of causes, defining a subscriber or inconsistent configuration of authentication
and encryption algorithm may lead to failed update of routing area.
Take the case 6.2.10 Analysis of 3G-2G PS Handover Failure in a Deployment. The
3G SGSN encryption algorithm is UEA1, but the partner does not use encryption
algorithm. When the UE hands over from the encrypted 3G network to unencrypted
2G network, the 2G network does not send a message to indicate UE to disable
encryption algorithm, and the encryption state of UE's message does not synchronize.
As a result, when the UE sends the RAU (routing area update) Complete message, the
network side fails to receive the message because the UE encrypts the message but the
network side does not.
5.4.2 Analyzing HSDPA Interruption of Data Transfer

An RAB can be mapped on the HS-DSCH of only one cell, so SHO is unavailable on
HS-DSCH. As a result, data transfer is interrupted inevitably upon update of serving
cell.
The SHO associated HSDPA serving cell update includes two aspects:
 Intra-NodeB. In the same DSP of a NodeB, interruption of data transfer does not
occur because no data needs transiting from one MAC-hs buffer to another MAC-
hs buffer.
 Inter-NodeB. When MAC-HS is reset, the NodeB drops original data in buffer
and restores the dropped data by RNC RLC retransmission. The interruption of
data transfer lasts for about 300ms.
During the inter-frequency and intra-frequency HHO associated HSDPA serving cell
update, the MAC-HS is reset, the NodeB drops original data in buffer and restores the
dropped data by RNC RLC retransmission. The interruption of data transfer also
occurs.
During H2D SHO, intra-frequency HHO, inter-frequency HHO, D2H SHO, intra-
frequency HHO, and inter-frequency HHO, the interruption of data transfer also will
occur.

During the handover between HSDPA and GPRS, data transfer will also be
interrupted.
The interruption of data transfer includes two aspects:
 The interruption of data transfer without update of serving cell or handover
 Over long interruption of data transfer with update of serving cell or handover
Interruption of data transfer without update of serving cell or handover
The causes of interruption of data transfer without update of serving cell or
handover includes:
− Call drop or TRB reset occurs during data transfer
− Other abnormalities, such as interruption of transport resource like Iub or
completing downloading data files.
Locate the problem by checking alarms, whether downloading is complete, and
signaling flow.
− Alarms
Query the alarms on CN and RAN. Know the abnormalities in the operation
of current system. Guide analyzing and identifying problems. Some problem,
such as interruption of data transfer, clock asynchronization in some cells, and
NE congestion, can be known from alarms.
− Whether downloading is complete
Data transfer is interrupted for a long time, so restoring it is impossible. Check
whether downloading the file by FTP is complete.
− Signaling Flow
According to detailed analysis of RNC and UE signaling, judge whether call
drops upon interruption of data transfer, whether the H-H serving cell is
updated, and whether H2D or D2H handover occurs. If the interruption of data
transfer is caused by call drop, analyze the cause of call drop. For details, see
W-Handover and Call Drop Problem Optimization Guide.
Over long interruption of data transfer with update of serving cell or handover
lists the interruption delay of data transfer in HSDPA.
Interruption delay of data transfer in HSDPA

Index Service Statistic method Reference
Interruption delay at subscriber HSDPA DT 300ms
plane upon intra-frequency H-
Serving cell update
plane upon inter-frequency H-
Serving cell update
plane upon H-R99 intra-frequency
handover
plane upon H-R99 inter-frequency
handover


plane upon R99-H inter-frequency
handover
Interruption delay at subscriber HSDPA DT NULL
plane upon H-GPRS inter-RAT
handover
The previous table provides value only for reference. The actual KPI depends on the issue of
WCDMA&GSM Network Performance Research Department. Different product algorithms
lead to different references.
The causes to over long interruption of data transfer upon update of serving cell
or handover include:
− The serving cell is frequently updated in ping-pong handover areas, and the
CQI reported by UE is low.
− Impact from product processing algorithm
− Bugs of UEs and other products
shows the normal and abnormal interruption of data transfer upon update of H-H
serving cell.
Normal and abnormal interruption of data transfer upon update of H-H serving cell
In ,
The point A indicates over long interruption of data transfer due to ping-pong
handover
− The point B indicates over long interruption of data transfer duo to H-H intra-
NodeB serving cell update
− The point C over long interruption of data transfer duo to H-H inter-NodeB
serving cell update.
− The point D indicates over long interruption of data transfer due to faulty UE
− The point E indicates over long interruption of data transfer due to improper
RNC product processing algorithm.
shows the interruption of data transfer due to H-D and D-H handover.
Interruption of data transfer due to H-D and D-H handover
In ,
− The point A indicates the interruption of data transfer upon H-D handover
− The point B indicates the interruption of data transfer upon D-H handover
In the ping-pong handover areas, perform RF optimization by:

− Adjusting antenna azimuth and down tilt

− Constructing sites
− Providing primary cell
For the impact from product algorithm or faulty UEs, analyze the problem based
on the data of UE, NodeB, and RNC. Focus on analyzing data sending and
receiving at MAC-HS and RLC layer. Now the UE collects data by using
Qualcomm QXDM, and analyze data by using Qualcomm QCAT. The RNC
collects the processing information and flow control information of subscribers
by CDR.
The common tools Probe and Assistant cannot analyze the interruption of data
transfer because their sampling period is 200ms.
Analysis of interruption time of data transfer
The following two methods help to take statistics of interruption time of data
transfer:
− Use Qualcomm QXDM and QCAT tool. The interval between dropping
packet at receiver and receiving current data is the interruption time of data
transfer.
− Capture TCP/IP packets directly by using the software Ethereal. Analyze the
interval between TCP/IP.
The first method is simple. It directly obtains the interruption interval of data
transfer. The time is inaccurate. The method takes statistics of handover signaling
one by one.
The second method directly obtains the interruption delay of data transfer from
TCP rate figure. This method applies for limited interruption times, as shown in .
Interruption delay of TCP displayed in Ethereal
In , the data transfer is interrupted for two times, and the interruption delays are
respectively 300ms and 300ms. Compare the TCP rate in Ethereal and the rate at
application layer in Assistant, and they must match. Therefore, obtain the update
point of serving cell in Assistant.

文档名称文档密级
6 Cases
About This Chapter
Title Description
6.1Cases at RAN Side

6.2Cases at CN Side
2019-1-19 华为机密，未经许可不得扩散第 82 页, 共 133 页

6.1 Cases at RAN Side

6.1.1 Call Drop due to Subscriber Congestion (Iub Resource Restriction)
Description
In a project, there are abundant 3G UEs or data cards. The subscribers are test
subscribers, so they need not to pay. As a result, the traffic model in the area is
special. The busy hour of traffic is around 23:00, when PS call drops.
Analysis
According to traffic statistics, the traffic in the cell is heavy. The bandwidth at
Iub interface is 1 Mbps, always fully used. If a UE keeps transferring data on
line, the transferring is stable. If the subscriber browses web pages without
data transfer, the UE transits to idle mode to save resource according to
DCCC algorithm. When the UE needs to transfer data again, it must apply for
resource again. However, the resource may be used by other UEs, so no
resource is assigned to it. As a result, the connection fails. The subscriber feels
that he/she is off line. It is difficult to reconnect to the network. When other
subscribers use less resource, the subscriber can succeed in dial to connect to
the network.
The essence of the problem lies in that excessive subscribers use the
resources, so the resource is congested.
To solve this problem, use the methods below:
 Reduce test subscribers
 Add E1 bandwidth
6.1.2 Uplink PS64k Service Rate Failing to Meet Acceptance Requirements in a

Test (Air Interface Problem)
Description
For PS64k service, the acceptance contract prescribes that the actual average
rate must be larger than 51 kbps, but the uplink rate is about 50 kbps in test.
Analysis
According to statistics of rate at RNC RLC layer, the maximum rate exceeds
64 kbps, and it fluctuates sharply. As a result, the average rate at application
layer displayed by the software FTP is low. According to signaling tracing and
statistics of uplink BLER, the uplink BLER is about 10%. As a result, the rate
at application layer fluctuates and the throughput declines.
Solution
Change the target uplink BLER to 6% or 1%. Change related power control
parameter.

Setting different target BLER helps balance the performance of single UE and
more UEs. According to the information from other networks, different target
BLER are set for different networks, but they are small.
Note that setting target BLER is according to index of service type. The
uplink and downlink bandwidth are usually different, namely, the index of
service type is different. Set target BLER after confirming the index of service
type.
6.1.3 Statistics and Analysis of Ping Time Delay in Different Service Types
Description
On SNSN, test the transfer delay of streaming and conversational service. CN
test engineers feed back that the transfer delay of conversational service
cannot meet the protocol requirement. The test result is that: the ping delay of
conversational service is 230ms and that of streaming service is 109ms.
According to R5 TS23.107 requirement, the delay of conversational must be
smaller than 100ms. The delay in the test is 115ms (230ms/2), so it does not
meet the requirement.
Analysis
In formal tests, the ping delay of conversational service is 230ms and that of
streaming service is 109ms. The conversational service uses 8k/8k, and the
streaming service uses 64k/128k. Their bandwidth is different, so their delay
is different.
According to R5 TS23.107 requirement, the delay of conversational must be
smaller than 100ms. The unidirectional delay from UE to Gi interface (UMTS
bearer) is 100ms. The delay at RAN is 80ms. The 80ms shall contain the
delay at access layer of UE and exclude that of USB and PC. According to
test, the end-to-end delay is 115ms (230ms/2), so it does not meet the
requirement.
It is almost certain that engineers cannot test with 8k/8k bandwidth whether
the delay meets the requirement, because the bandwidth is too small. The
RNC of current version support PS conversational service of 8k only. Now
which service uses the type of PS conversational service is unknown.
Test twice with Sony-Ericsson Z1010, because other UEs fail to support
conversational service. After the UE is activated, execute the command ping
over firewall on GGSN through a laptop.
 Activate the four 8k/8k services: background, interactive, streaming, and
conversational. Test the delay, and trace SGSN and RNC CDR.
 Activate the three 64k/128k services: background, interactive, and
streaming. Test the delay, and trace SNSN and RNC CDR.
lists the delay test result of ping packet.
Delay test result of ping packet

Conversational Streaming Interactive Background
8k/8k 275ms 258ms 293ms 307ms

64k/128k - 121ms 134ms 131ms
In 8k/8k, the delay of each service is larger than 220ms. In 64k/128k, the
delay is smaller. Therefore the delay and bandwidth are relevant.
Execute the command ping by 32 bytes, and analyze as below:
In 8k/8k, execute the command ping by 32 bytes. It is 60 bytes including the
IP head. The TTI of 8k is 40ms. Each TTI has a block. The TB size is 336
bits. As a result, executing the command ping by 32 bytes occurs on two
TTIs, namely, 80ms. The downlink is similar.
The uplink and downlink must stagger a TTI. Assume that the processing at
nodes and interface goes infinitely fast. To the air interface and from the air
interface take 200ms (5*40 ms).
In addition, a PC always sends data about MSN, HTTP protocols. If the PC
sends other packet during sending ping data, the ping command has to wait.
Therefore, 8k bandwidth is over small.
In 64k/128k, execute the command ping by 32 bytes. It is 60 bytes including
the IP head. The TTI of 128k is 20ms. Each TTI has 8 blocks. The TB size is
336 bits. As a result, executing the command ping by 32 bytes occurs on a
TTI, namely, 20ms. The downlink is similar.
The uplink and downlink must stagger a TTI. Assume that the processing at
nodes and interface goes infinitely fast. To the air interface and from the air
interface take 60ms (3*20 ms). Adding this to CN cost and laptop cost makes
more than 100ms.
Execute the command ping by 8 bytes on conversational service. After on-site
verification, the test is consistent with prediction.
Analyze the parts of total delay from laptop, to UE, to NodeB, to RNC, to CN,
and to server. Analyze the factors that affect delay in each part. This helps
locate delay problems.
Compared with 8k/8k streaming service, the typical parameters of 8k/8k
conversational service must be optimized.
6.1.4 Low Rate of HSDPA Data Transfer due to Over Low Pilot Power
Description
In an HSDPA live demonstration, when the commissioning is complete, the
rate of HSDPA service is as low as half of standard rate, and the
retransmission rate is high.
Analysis
On-site NodeB engineers have demonstrated the service in laboratory, and the
rate is normal, 1400 kbps. They use big antenna and lower the power on site
to cover the sites of the operator. After this, the Ec is –50 dBm, and Ec/Io is –
3 dB. Namely, the coverage is qualified. In the on-site test, after starting
downloading data, the Ec/Io deteriorates sharply. According to QXDM
tracing, the transmission rate is 100% (engineers doubt that the problem is
caused by interference and improper installation of antenna, but the cause is
not them according to frequency sweep and SITEMASTER test). As a result,
engineers doubt that the transmission on the interface board of NodeB and
trunk are faulty. After changing the interface board and trunk, the problem is
still present.
Test with PS384k service, the result is normal. According to causes of
problem, the HSDPA feature leads to weak Ec/Io, as a result, the BLER and
retransmission rate are high. At the beginning of test, to reduce radiation,
engineers lower the pilot power. However, the HSDPA network distribute
power according to amount of data as its feature, so the network distributes
high power (near 35 dBm) to TCH upon downloading. As a result, the Ec/Io
declines, which consequently causes decline of demodulation performance
and increment of retransmission rate. Raise the pilot power, and then the
transmission rate is normal. The problem is solved.
Solution
Raise the pilot power from 23 dBm to 33 dBm, and the transmission rate will
be normal.
Suggestions and Summary

As a habit of test, engineers will lower pilot power and then perform test.
However, due to new features of HSDPA, lowering pilot power leads to
new problems.
Lower the pilot power and HSDPA power in the following tests, such as by
using attenuator.
6.1.5 Unstable HSDPA Rate due to Overhigh Receiving Power of Data Card
Description
On HBBU, activate HSDPA service, and the retransmission rate is high. The
BLER of data sent at the first time is about 60%, the residual BLER is 5%.
The downloading rate is low, and the rate fluctuates sharply.
Analysis
Once the on-site engineers download data, the CQI fluctuates sharply and
frequently between 15 and 26. The rate fluctuates between 100 kbps and 600
kbps.
The load of HSDPA fluctuates sharply between 3% and 24%. This must be
relevant to downloading rate.
No FP packet is missing. No packet is missing because the queue is full. In the
scheduling period, abundant DTXs exist according to NodeB, with few
NACK messages.
According to check, the receiving power of data card is as high as –45 dBm,
exceeding the normal range (–55 dBm to –85 dBm). The signals are strong,
and the attenuation is inadequate, so the measured CQI is inaccurate.

Solution
Add an attenuator at the antenna port, and keep the receiving power at about –
70 dBm. After this, the problem of frequently fluctuation, as well as the
BLER problem, is solved.
6.1.6 Impossible Maximum HSDPA Rate due to Over large Radius of Cell
Description
A subscriber uses Huawei E620 data card. The HSDPA rate fails to reach
above 1.5 Mbps, but remains at about 1.2 Mbps. Check through QXDM, there
is no code error in downlink DSCH. Anyhow, the HSSCCH scheduling cannot
reach 100%, but remains at 80%.
shows the UE HSDPA statistics data in QXDM.
UE HSDPA statistics data in QXDM
Analysis
To locate the problem, proceed as below:
Check the transmit power of cell carriers. It is lower than 60%, so the power is
not restricted.
Check the UE HSDPA statistics in QXDM. There is no code error on HS-
DSCH, but its scheduling is only 80%.
Check the AAL2 Path bandwidth. The HSDPA AAL2 Path bandwidth is 2
Mbps, so there is no bottleneck.

Disable downlink DSP flow control, so the impact from flow control is avoided.
Still, the HSDPA rate is 1.25 Mbps.
Check the downlink throughput and traffic of single subscriber on the
corresponding RNC. The rate at RLC layer on RNC fails to reach the required
flow rate. According to CDR, the HS-DSCH flow control information sent by
NodeB is consistent. The decline of RLC rate is irrelevant to RNC, but
relevant to the bottleneck of overall process.
Query the scheduling information of downlink DSP on NodeB LMT. According
to the scheduling information, the scheduling times in 1s is 428 at most, so it
is impossible to reach 100% scheduling of 500 times.
The coding DSP experts calculate the scheduling times, 500*6/7 = 428. They
check the cell radius. The cell radius is 10 km. After engineers change the
radius to 2 km, the rate increases to about 1.5 Mbps.
According to timing relationship of HSDPA, it takes 15.5 timeslots from
HSSCCH's scheduling the subscriber to receiving the response to the
scheduling. HSSCCH schedules single subscriber with multiple threads, so it
can schedule other threads while waiting for the response of a scheduling. As
a result, scheduling is more efficient. Now at most 6 threads are used, and
each TTI needs 3 timeslots, so a cycle contains 18 timeslots. Compared with
the single thread RTT of 15.5 timeslots, the NodeB can schedule subscribers
in 2.5 timeslots with the following aspects:
 Demodulating HS-DPCCH data
 Coding HSSCCH data
 Internal processing delay
In NodeB design, the single thread RTT is relevant to the distance between
NodeB and the subscriber. When the distance is long, the RTT will be large.
As a result, the processing time for NodeB is short, so the NodeB has
inadequate time to process HS-DPCCH feedback, coding HS-SCCH and
scheduling subscribers.
Actually, the downlink DSP does not know the distance of UE, so it uses the
cell radius. If the cell radius is larger than 5 km, the downlink DSP uses 7
TTIs to schedule 6 threads to guarantee enough processing time. The
downlink DSP can schedule 6 threads in 7 TTIs, so the total scheduling time
at most is 6/7, namely, 85.7%. In 1s, the downlink DSP can schedule 500 *
6/7 times, namely, 428 times.
Solution
After engineers adjust the cell radius less than 5 km, the rate exceeds 1.4
Mbps, and the scheduling time reach about 95%.
6.1.7 Decline of Total Throughput in Cell due to AAL2PATH Bandwidth larger than
Actual Physical Bandwidth
The WCDMA network runs normally. The admission of the cell to be
measured is disabled. The cell is unloaded. The neighbor cells are disabled.
The HSDPA cell is successfully set up. The power is dynamically distributed.
HSDPA uses 5 codes. The MAC-HS scheduling algorithm uses PF. There is
one HS-SCCH. The cell uses 8 E1's. One of them uses UNI method, and the
rest 7 E1's use the IMA group method. The IMA group bears HSDPAAAL2

PATH. The UNI bears the NCP/CCP/ALCAP/R99 AAL2 PATH at other Iub
interfaces.
Select a good test point (CPICH RSCP is about –70 dB, Ec/Io is above –6 dB,
and the fluctuation is stable). Connect 6 HSDPA UEs one by one to the
network. The PS service is activated on UE. The RAN bears PS service on
HS-DSCH. Download with FTP, and record the peak throughput of cell.
Disconnect the E1 link of IMA group one by one manually while connect 6
subscribers one by one to the network. Record the total peak throughput of
cell after one subscriber accesses the network.
Draw a curve chart with the recorded peak throughput of cell at every point,
as shown in and .
Variation of total throughput of one IMA link of HSDPA codes
Variation of total throughput of two IMA links of HSDPA codes
In and , the throughput of one E1 is lower than the throughput of two E1's.

Analysis
The cell uses 5 HSDPA codes, and class-12 UE. The maximum throughput at
MAC layer of cell is 1.72 Mbps. The SBLER is 10%, so the throughput at
MAC layer of cell is about 1.55 Mbps. In , the measured throughput of cell is
consistent with the theoretical rate, but in , the throughput of cell declines.
Check the Iub bandwidth. The AAL2PATH bandwidth is 10 Mbps, but the
physical bandwidth is about 1.9 Mbps with one E1, and 2.8 Mbps with 2 E1's.
Obviously, the NodeB flow control does not consider the variation of physical
bandwidth, but allocates bandwidth according to configured AAL2PATH
bandwidth.
The throughput of cell with 2 E1's is not affected by physical bandwidth. This
must be analyzed in terms of flow control at NodeB Iub interface. The Node
flow control allocates bandwidth for each subscriber according to the data
amount in NodeB buffer, the data amount of RNC RLC buffer, and the rate at
the air interface.
The Iub flow control allocates bandwidth for subscribers that the maximum
allocated bandwidth is twice of the rate at the air interface. According to
previous analysis, the twice of the rate at the air interface is 3.4 Mbps at most,
not exceeding the physical bandwidth of 2 E1's. As a result, the rate of air
interface is not affected when there are 2 E1's. When there is 1 E1, the twice
of the rate at the air interface exceeds the physical bandwidth of 1 E1. As a
result, data packets are missing at Iub interface, and the rate of subscribers is
affected.
Solution
Change the AAL2PATH of HSDPA to 1.9 Mbps when there is one E1. Test
again, and the rate of subscribers is about 1.5 Mbps.
In actual networks, guarantee that the AAL2PATH allocated bandwidth to
HSDPA is smaller than the physical bandwidth at Iub interface. This will
affect throughput of cell. Meanwhile, check NodeB alarms whether there are
E1 fault alarms.
6.2 Cases at CN Side

6.2.1 Low FTP Downloading Rate due to Over Small TCP Window on Server TCP
Description
Activate uplink 64 kbps and downlink 384 kbps services on UE and laptop.
Download data from the servers of operator with CUTEFTP. The average
downloading rate of UE is 33 kbps, much lower than 384 kbps. The average
rate at FTP application layer is about 28 kbps.
Analysis
Activate uplink 64 kbps and downlink 128 kbps services, and download data.
Engineers obtain the required rate. However, after activating 384 kbps, the
maximum rate cannot be reached. Try to connect the UE to Huawei web
server (the GGSN Gi interface <-> Lanswitch <-> NE08 <-> Internet <->
Server of operator. The <-> used here means connection between two network
elements (NEs). Huawei web servers connect to Lanswitch by Gi interface.
The address of web server and the address of GGSN Gi interface share the
same network segment).
The downloading rate reaches 47 kbps. After engineers connect UE to the
server of operator, the downloading rate is 30 kbps, far from the required rate.
After engineers activate PS service from Huawei SGSN to the GGSN of other
vendors (such as N), the rate is about 30 kbps after visiting the server of
operator by N's GGSN. Therefore, the problem must not be due to system.
Probably the operator restricts the rate on the server, so the downlink 384 kbps
is unavailable.
Capture packets on Gn and Gi interface, and UE by Sniffer. According to
analysis of packet capture, the TCP at the FTP server of operator restricts the
sending window (the TCP window of the operator's host server is 63136, but
probably the software at application layer restricts the sending window.
According to the analysis below, the sending window size of FTP on
operator's server is about 8 kbps, much smaller than 64 kbps).
According to the basic regulations of data packet at Gi interface,
FTP server to client: After sending 6 TCP packets (4 * 1500 + 2 *1190), the
server stops sending, and 6 packets must be confirmed.
The FTP server receives an ACK message. After the FTP server and client
confirm two TCP packets, the server stops sending. There are 4 packets
to be confirmed.
The FTP server receives an ACK message again. After the FTP server and
client confirm two TCP packets, the server sends three continuous TCP
packets (2 * 1500 + 1190). There are 5 packets to be confirmed.
The FTP server receives an ACK message again. After the FTP server and
client confirm two TCP packets. The server sends 3 continuous TCP
packets (2 * 1500 + 1190). There are 6 packets to be confirmed.
It goes back to the first step. A cycle forms.
The FTP server sends at most 8.4 kbyte (4 *1500 + 2 * 1190) packets to be
confirmed. According to the second step above, the sender needs to send 4
kbyte data continuously. Therefore, the FTP server sets the TCP sending
window to be smaller than 10 kbyte, and the TCP is optimized to send large
block data (over 4 kbytes). The actual TCP window is 7 kbytes on average for
FTP server. Assume that the round-trip delay is t mm, so the maximum
available rate is (7 kbytes/t) * 8 kbps.
According to previous analysis, after activating PS service, do not transfer
data. Execute ping to server on UE, and check the delay at the air interface. In
Huawei system, the average delay for ping packets is 250ms. According to
analysis, 7 kbps/0.25 = 28 kbps. Namely, the theoretical average rate at
application layer is 28 kbps. This theoretical value is the same as the actual
value. Therefore, the operator must have restricted the TCP window at
application layer on the server, so the rate keeps low.
Solution
 To increase rate, engineers must reduce the round-trip delay. When the
delay is smaller than 150ms, the rate can reach 384 kbps (7 kbps/0.15 =
46.7 kbps). Actually reducing the delay at air interface is difficult. The

Huawei delay at air interface is about 250ms. Therefore, the rate cannot
reach 284 kbps.
 Download data with multiple threads tool, such as FlashGet and NetAnt.
Multiple TCP connects to the server, so the rate can increase. According
to test result, download data with more than two threads by using
FlashGet or NetAnt, the rate can reach 47 kbps.
 Remove the restriction on sending window size of server, and set the
sending window size of server to 65535.
6.2.2 Simultaneous Uploading and Downloading
Description
Activate uplink 64 kbps and downlink 384 kbps services on UE and laptop.
Connect UE to the server of operator, and upload and download data with FTP
simultaneous. Wherein, the downloading rate is greatly affected, and
fluctuates sharply. The average downloading rate declines from 47 kbyte to 20
kbyte. However, downloading and uploading respectively are available.
Analysis
Uploading and downloading simultaneously affect the ACK delay of TCP.
This leads to prolonged delay upon confirmation, and the TCP window size is
inadequate. Execute the ping command upon for confirming delay upon
simultaneous uploading and downloading. Obtain the maximum supported
rate with the TCP window size/delay.
According to the analysis of the second problem, the TCP window size of
operator's server is about 8.4 kbyte (the operator may use the FTP software
Serv-U. Its default sending and receiving buffer is 8293 bytes). Upon
simultaneous uploading and downloading, check the ping packet delay by
executing the command ping to the server. The ping packet delay is about
1500ms, 8.4/1.4 = 6 kbyte.
The previous two paragraphs describe the case of single thread. Start 3 threads
and the theoretical rate should be 18 KB/s (6 * 3 = 18). According to actual
test, download data with 3 threads by using FlashGet from the operator's
server, and upload data with CuteFTP simultaneously. The average sending
and receiving rate of UE is 17.9 KB/s in downlink and 7.2 KB/s in uplink.
The downlink rate is approximately equal to theoretical value.
Namely, when the UE sends data in uplink, the delay increases sharply, so is
the uplink response delay to the ACK message. As a result, the TCP judges it
as congestion, so the rate declines. This explains that uploading and
downloading respectively are available but simultaneous uploading and
downloading lead to decline of downlink rate.
Solution
According to previous analysis, increasing TCP window size of server leads to
increasing downlink theoretical rate. Actually, when using Huawei
servers for test, set the TCP window size to 65535, download with three
threads by using FlashGet. Simultaneously upload data with CuteFTP.
The average sending and receiving rate is 46.5 KB/s in downlink and 6
KB/s in uplink.

Download data with multiple threads. According to test, download data with
10 threads from operator's server when the TCP window size is 8192.
The average sending and receiving rate is 42 KB/s in downlink and 6
KB/s in uplink. The data transfer is unstable with jitters.
Send the ACK message in downlink data packets, and sends uplink data
packets at a fixed rate. Restrict the uplink rate so that the uplink data
packets will not be blocked at the air interface and the delay at the air
interface will not increase, and there is no jitter. Obviously, the decline of
downlink rate upon uplink and downlink data transfer is not due to
Huawei system, and this problem cannot be mitigated by this solution.
This is a defect of TCP/IP protocol used in radio transmission. It is good
to combine the UE and the driver of wireless Modem to carry out the
solution.
6.2.3 Decline of Downloading Rate of Multiple UEs
Description
Activate 6 UEs with downlink 384k service, and connect them to the
operator's server simultaneously. Download data with FTP, and the rate
declines to 30 KB/s.
Analysis
Download data on one UE by FTP from operator's server, and the rate is as
normal as above 47 KB/s. Download data on two UEs, and then on three. The
downloading rate keeps at about 47 KB/s with 4 UEs connected at most.
When the fifth UE connects to the server, the rate declines. Try on site as
below:
Download data with four UEs from the operator's server, and with two UEs
from Huawei servers. Check whether the rate is faulty.
As a result, the downloading rate of 6 UEs reaches 47 KB/s.
Probably, the operator's server does not well cooperate with Huawei
networks.
Download data with six UEs from Huawei servers. Check whether the rate is
faulty.
Huawei servers cooperate well with Huawei networks. Probably the
operator's server does not well cooperate with Huawei networks.
The difference between the operator's server and Huawei server lies in the
router and firewall over the operator's server. Try to avoid the impact
from firewall and router, and check whether the rate increases.
Connect the Gi interface of GGSN to NE08 directly, and download data
with UE from the operator's server. Check whether the rate increases.
The result proves that the rate remains the same.
Therefore, the firewall has no impact on the rate.
Download data with six UEs from Huawei servers, and there is no problem.
Connect Huawei server to NE08 port to replace the operator's server for
test, and check whether the rate is faulty.
As a result, the downloading rate of six UEs reaches above 47 KB/s.
Therefore, the router is normal.
Connect a laptop to Gi interface. Download data with 4 UEs and with a laptop
simultaneously, and check whether their downloadings affect each other.
Tests prove that they seldom affect each other. The rate of some UEs
declines a little, and that of some UEs are seldom affected. The rate of
downloading data directly by laptop is 388 KB/s (single thread) or 1000
KB/s (three threads).
The export bandwidth to the operator's server is enough, so decline of
rate must not be due to bandwidth used for downloading data by multiple
UEs simultaneously.
After previous verifications, the peripheral equipment problems are excluded,
so probably the problem lies in the cooperation between the operator's
server and Huawei network. The major differences between Huawei
server and the operator server lie in two aspects: MTU and
TcpWindowSize. Still on Huawei Server, modify the two parameters for
verification:
The configuration in the regedit on server is MTU 1450, and
TcpWindowSize is 65535. Activate six UEs simultaneously, and the rate
is as stable as above 47 KB/s.
Keep the MTU of web server at 1450. Modify the TcpWindowSize in
regedit to 10 KB (10240). After restart, the rate of simultaneous rate by
six UEs keeps above 47 KB/s.
Delete the MTU from the regedit of web server (use the default value
1500). Keep TcpWindowSize at 65535. After restart, the rate of six UEs
declines sharply (20–30 KB/s). The downloading rate of three UEs keeps
at 47 KB/s until the fourth UE joins.
Therefore, when the MTU is the default value 1500, the rate of
simultaneous downloading by multiple UEs declines. According to the
packets captured by Sniffer, the MTU on the operator's server is the
default value 1500.
According to analysis, when the MTU is 1500, due to the TCP header
encapsulated along the path, the data packet is over long when the
downlink data packet reaches SGSN. Before sending data packet to
RNC, the SGSN must fragment and reassemble the packet. The current
SGSN transfers data by using software, so it starts flow control to protect
main controller. As a result, the downlink rate declines upon fragment
and reassembly.
Solution:
− Set the MTU of the operator's server to 1450 (if fragment is
unnecessary, MTU should be as large as possible. According to test,
1450 is improper).
− Set the MTU of laptops connected to UE to 1450 (you must change
the MTU at USB port of laptops) so that the SGSN will not start
fragment and reassembly.
Since it is impossible to modify MTU of the operator's server, solve the
problem by using the second method. For how to TCP parameters in
Windows, see the appendix.
6.2.4 Unstable PS Rate (Loss of IP Packets)
Description
On-site engineers feed back that the data transfer fluctuates at the beginning
every morning. Facts prove this right upon downloading. and show unstable
PS rate.

Unstable PS rate (1)
Unstable PS rate (2)
Analysis
shows analyzing packets captured by Ethereal upon unstable PS rate.

Analyzing packets captured by Ethereal upon unstable PS rate
The messages at IP layer mean as below;

 499 SN: 436540---next seq = 438000
 500: ACK
 501 SN: 439460---next seq = 440920
 515: ACK. It needs a SN of 438000. This means that the frame 499 is
missing, so the TCP layer keeps resending it.
Check the cable at Gi interface. After engineers pulling the cable out and
plugging it in, the problem is solved. The problem does not occur in the
following tracing period.
6.2.5 Unstable PS Rate of Single Thread in Commercial Deployment (Loss of IP

Packets)
Description
After the commercial network is launched, the rate of 384 kbps service is
unstable. It cannot reach the required rate, and even keeps at several dozen
kbps.

Analysis
Probably the problem is caused by loss of data packets and delay. After
capturing packets by segment, the cause proves on the firewall.
After repeated tests, the Up/Down and CRC Error occur frequently at the
firewall 2 interface 2/2. After another 3 hours' test, the cable between the
firewall 2 interface 2/2 and LS12 must not be physically broken, and CRC
error must be due to improper installation of fiber.
A faulty firewall leads to loss of packets at the application layer, which has
great impact on rate.
When the firewall is normal, the PS rate increases greatly. However, the rate is
still unstable. According to further analysis, the BLER at the air interface is
10%, so it is normal for PS rate to fluctuate at the air interface. After
engineers modify the BLER to 1%, the problem is solved. However, the cost
is more consumption of power at the air interface and impact on capacity.
6.2.6 Unavailable Streaming Service for a Subscriber
Description
A subscriber cannot use streaming service in a deployment.
Analysis
The subscriber can browse the portal websites, but cannot use streaming
service. Meanwhile other subscribers can use streaming service. Therefore,
the PS service bearer is normal, and the cause cannot be on RAN, SGSN, and
GGSN. Probably the UE, USIM card, and server are faulty. According to
further analysis, the problem must be on the USIM card, and the subscriber
did not pay for using streaming service. The subscriber can browse the free
portal websites.
6.2.7 Unavailable PS Services due to Firewall of Laptop
Description
A subscriber cannot use PS services with Nokia 7600 connected to his laptop.
Analysis
The subscriber feed back that other subscribers can use PS services with his
card. He could use PS service until one day recently. Therefore, the problem is
about the laptop. The problem does not occur after he changes the laptop.
According to check, the subscriber has installed a firewall on his laptop
recently. After uninstalling the firewall, he can use PS services again.
6.2.8 Low PS Service Rate in Presentation Occasion
Description
The rate of PS downlink 384k service is low in presentation.

Analysis
After numerous tests and analysis, the problem must be at RAN. After
engineers analyze to detailed subscriber signaling, data statistics at subscriber
plane, the quality of signals at the air interface, and loss of packets at Iub
interface, the problem is still present. It is difficult. RNP engineers check the
signals on site, and the signals are qualified. After using the laptop of an RNP
engineer, the data transfer of PS service is normal. According to further
analysis, the problem lies in the driver of public laptop used in presentation.
After engineers change the laptop, the problem is solved.
6.2.9 Abnormal Ending after Long-time Data Transfer by FTP
Description
An operator's engineer feed back that the downloading cannot be ended
normally when it lasts for over 10 minutes with Huawei 3G network. The
downloading is normal with other operators' networks or 2G networks.
Analysis
According to analysis of FTP messages captured by Ethereal, the data session
of FTP is over, but it misses the last interactive completion process, and no
messages like 221-Goodbye is found. The downloaded files can be opened.
After the files are downloaded, they can be opened according to check.
shows the interactive interface in CuteFTP.

Interactive interface in CuteFTP
To describe the problem, compare the messages as below:

shows the signaling of normal downloading by FTP.

Signaling of normal downloading by FTP
shows the signaling of abnormal downloading by FTP.

Signaling of abnormal downloading by FTP
According to comparison of previous two figures, there are differences.

Activate UL64k/DL 32k service, and download data with Qualcomm 6250,
and capture packets on RNC and SGSN.
Download a 3.5 Mb file with the operator's FTP, and it takes 12 minutes. The
problem is still present.
Download a 3.5 Mb file with the Windows FTP command, and it takes 30
minutes. After downloading is complete, quit the FTP by typing bye. The
problem is still present. Maybe the Outlook is transferring data in daemon
during data transfer, so there may be impact. After the transfer is complete, the
transfer is abnormally disconnected after a long time.
Download a 0.4 Mb file with the Windows FTP command, and it takes 2
minutes. Quit the FTP by typing bye. The problem is not present.
Download a 0.4 Mb file with the operator's FTP, and it takes 2 minutes. The
problem is not present.
Perform the same operations as the second step. Disconnect the downloading by
Outlook in daemon. The result is the same as the second step. See the
following print.
----End
According to previous operations, the downloading is relevant to time, not the

file size. Based on analysis of massive data, the data transfer by FTP is

normal, the downloaded content is correct and available, but the signaling is
abnormally closed.
Without other better method, the method of exchanging NEs and segment is
used.
Check whether the problem is about UE and server.
The problem is still present with verification by three UEs: Nokia 6630,
Qualcomm 6250, and Moto 835. The problem is still present with verification
by two servers: Eurotel FTP server and Huawei FTP server. The problem is
still present with verification by Huawei FTP server in UNIX operating
system and in Windows 2000 Professional FTP server.
Search for the configuration of FTP server, and no relevant configuration is
found.
Conclusion: the problem is present with multiple UEs, operators, and Huawei
FTP server, so the problem is irrelevant to UEs and FTP server, but relevant to
Huawei network.
Compare the tests in the 3G network, the 2G network, and the tests of handover
to the 2G network after access in the 3G network.
According to tests, the problem must be between GGSN and FTP server. This
reduces the scope of problem.
According to other tests, the problem does not occur when no firewall is over
Huawei server. This shows the cause. The problem does not reoccur due to no
firewall.
According to data analysis, the data transfer at the FTP port is normal, but the
signaling port is disconnected after 10 minutes. This must be due to firewall.
It is the firewall that can disconnect a port without data transfer after 10
minutes, so the problem is due to firewall.
Processing the problem goes smoothly after focusing on the firewall. The
expert on firewall explains as below:
The FTP session includes two session tables on firewall. One is for FTP
control channel, and the default aging time is 10 minutes. The other is FTP
data channel, and the default aging time is 4 minutes. The no detect ftp
command is configured between domains, the data channel will not update the
aging time of control channel upon data transfer. As a result, the control
channel is aging and deleted after 10 minutes with the following phenomenon.
If the detect ftp command is configured, the data channel will update the
aging time of control channel. As a result, the problem does not occur.
The problem, in whole process, is irrelevant to RAN. However, the process
and result of locating problem is considerable.
Changing NEs in test is significantly useful.
The difficulty of problem may exceed engineers' consideration. It needs wide-
range knowledge. However, after the problem is solved, it seams easy.

6.2.10 Analysis of Failure in PS Hanodver Between 3G Network and 2G Network
Description
A test of handover between Huawei 3G network of trial deployment and the
2G network of a partner is going in a deployment. The test UE is Huawei
U626. When the UE hands over from the 3G network to the 2G network in
connection mode, it keeps being in PS connection, but it cannot transfer data
normally. When the UE hands over from the 2G network to the 3G network, it
can transfer data normally.
Analysis
The UE hands over between the 3G network and 2G network. The UE camps
on 3G network, and has activated PDP, in PMM Connected state. When the
UE moves at the edge of 3G network coverage areas, it starts handing over to
2G network. When the handover is complete, the PS user plane is restores and
can perform data transfer. However, the problem lies in that the UE cannot
continue data transfer.
Analyze traced signaling.
shows the signaling of normal handover between 3G network and 2G
network.
Signaling of normal handover between 3G network and 2G network
Check the 3G signaling LMT. During the handover from the 3G network to the
2G network, the handover signaling is normal at 3G network side. After the
UE sends the routing area update request message to the 2G SGSN, the SGSN
context and response flow between the 2G SGSN and 3G SGSN is normal.

Till now, the handover of 3G SGSN is complete. The next step is the signaling
interaction between the UE and the 2G SGSN, as shown in :
Normal signaling flow between UE and 2G SGSN.
Trace the signaling on the partner's 2G SGSN. It is found that the signaling
interaction flow from 2G SGSN to GGSN and that of HLR are complete.
After the 2G SGSN sends UE the routing area update request message, the UE
must sends 2G SGSN the routing area update complete message according
to standard flow, which is not found in traced signaling. As a result, the 2G
SGSN judges that the UE has not completed the routing area update, so the
UE cannot transfer data after handover to the 2G network. However, the UE
keeps being in connected mode after handover to 2G network, so the UE
judges that it has completed routing area update. This indicates that the
problem lie between the UE and SGSN.
shows the signaling flow traced on 2G SGSN.

Signaling flow traced on 2G SGSN
Check the encryption state of 3G SGSN. The SGSN uses UEA1 as the
encryption method, but the serving 2G network uses no encryption method.
When the UE hands over from the encryption in 3G network to the non-
encryption in 2G network, the 2G network fails to send the encryption and
authentication message, indicating UE to disable encryption state, and the
encryption state of UE has not synchronized with network side. As a result,
the UE encrypted its messages upon sending RAU, but the RAN side does not
encrypt messages. Therefore, the RAN side fails to receive RAU result.
Solution
This problem concerns the partner's equipment at RAN side. It cannot be
solved at UE side due to restriction from protocols. Therefore, the solution is
to set the encryption item to non-encryption so that the messages sent by UE
are not encrypted. As a result, the problem is mitigated.

Suggestion and Summary

The problem concerns the partner's equipment at RAN side. Not every type of
UE meets the problem, because the problem is just incidental. Therefore
locate the problem based on signaling and analyze the problem to obtain the
correct result.

7 Summary
This document describe the access, disconnection of data transfer, low rate of
data transfer, unstable rate of data transfer, and interruption of data transfer. It
provides the methods for analyzing and processing these problems in terms of
traffic statistics and DT/CQT. The experience from analyzing problems in
terms of traffic statistics is little, and will be supplemented.
In addition, the document details the flow for optimizing DCH bearer of data
service and the flow for optimizing HSDPA bearer of data service.
The used cases include abundant cases at CN side. Actually, analyzing
problems or modifying parameters at CN side must be processed by engineers
at CN side. These CN cases just serve as reference for analyzing problems.

8 Appendix
About This Chapter
Title Description
8.1Transport Channel of PS
Data
8.2Theoretical Rates at Each
Layer
8.3Bearer Methods of PS
Services
8.4Description of HSDPA
Algorithms and Parameters
8.5Method for Modifying TCP
Receive Window
8.6Method for Modifying
MTU
8.7Confirming APN and Rate
in Activate PDP Context
Request Message
8.8APN Effect
8.9PS Tools
8.10Analysis of PDP
Activation
8.1 Transport Channel of PS Data

shows the transport channel of PS data.

Transport channel of PS data
Wherein, the Gi interface connects to the application server, on which the FTP
Server software is running. Download data from the application server to UE
(MS) through five interfaces: Gi, Gn, IuPS, Iub, and Uu. The PS services use
the AM mode of RLC, which supports retransmission. The services like FTP
and HTTP use TCP protocol, which also supports retransmission.
The parameters of these two protocols (RLC/TCP) have great impact on rate.
If the parameters are improper, or packet error or loss of packets occurs during
transmission, the rate will decline. Evaluate QoS based on that a computer
with UE as its modem runs applications. This concerns the performance of
computers and servers.
8.2 Theoretical Rates at Each Layer

shows the packet service data flow.

Packet Service Data Flow
Observe different protocol layers, and there are different definitions of

throughput, such as the application layer throughput, RLC layer throughput,
and MAC layer throughput.
Due to data packet header at each protocol layer, there is overhead. Except the
physical layer, the TCP/IP and RLC layer have high overhead. The typical
PDU size and overhead at each layer are listed as below.
8.2.1 TCP/IP Layer

Assume that the MTU is 1500 Bytes.
The TCP/UDP header overhead is 20 Bytes. The IP header overhead is 20
Bytes.
The TCP/UDP PDU size, namely, the payload at application layer, is 1460
Bytes, but the whole IP packet size is 1500 Bytes.
8.2.2 RLC Layer

The RLC header overhead is 16 Bits.
The RLC PDU size is 336 Bits.
Assume that the rate at the application layer is 1 Bytes/s. if retransmission at
each layer is not considered, the corresponding rate at RLC layer is
1500/1460, namely, 1.027. The rate at MAC-d layer is 1500/1460 * 336/320,
namely, 1.079.

8.2.3 Retransmission Overhead

If the TCP layer retransmission (assume that the retransmission rate is r1) and
RLC layer retransmission are considered, the corresponding rate at RLC layer
is 1500 * (1 + r1)/1460. The rate at MAC-d layer is 1500 * (1 + r1)/1460 * (1
+ r2) * 336/320.
8.2.4 MAC-HS Layer

If there is only one subscriber, without retransmission at MAC-HS layer, the
rate at MAC-HS is (scheduling transport block size TBs)/2ms, and the rate at
MAC-d layer is 336 * (TBs/336s)/2ms.
In the DT tool Probe, with consideration of multiple subscriber scheduling
and retransmission at MAC-HS, there are three rate involved at MAC-HS
layer: scheduled rate, served rate, and MAC layer rate.
Served Rate = Scheduled Rate * HS-SCCH Success Rate
MAC Layer Rate = Served Rate * (1- SBLER)
Wherein, the HS-SCCH Success Rate is the success rate for receiving HS-
SCCH data by a subscriber, and SLBER is incorrect TB received at MAC-HS
layer/total TBs received.
8.3 Bearer Methods of PS Services

In Rel 4 and R99 protocol versions, data service is carried on DCH. If the data
services are low in traffic, it can also be carried on FACH.
When HSDPA is used in Rel 5, the data service can be carried on DCH or
HSDPA. If the traffic is low, the data service can be carried by FACH through
state transition.
The following three paragraphs describe the method for RNC to judge
whether a PS service is carried by DCH or HSDPA in a cell supporting
HSDPA.
Two parameters are relevant to the SET FRC command on RNC LMT:
downlink streaming service HSDPA threshold and downlink BE service
HSDPA threshold.
Downlink streaming service HSDPA threshold indicates the rate judgment
threshold of PS streaming service carried on HS-DSCH. When the downlink
maximum rate of PS streaming service is equal to or larger than the threshold,
the service can be carried on HS-DSCH. Otherwise, it is carried on DCH.
Downlink BE service HSDPA threshold indicates the rate judgment threshold
of PS background/interactive service carried on HS-DSCH. When the
downlink maximum rate of PS background/interactive service is larger than or
equal to the threshold, the service can be carried on HS-DSCH. Otherwise, it
is carried on DCH.
The service is carried by from DCH or HSDPA to FACH through state
transition.

8.3.1 DCH
The DCH bandwidth depends on the current power resource, code resource,
and Iub bandwidth resource. Typical rates include 8 kbps, 32 kbps, 64 kbps,
128 kbps, 144 kbps, and 384 kbps. The DCH bandwidth is adjustable by
algorithms like DCCC according to the current traffic and coverage
conditions, but the adjustment is limited to previous rates. In addition, the
interval to trigger adjustment is long. As a result, the adjustment is not
frequent.
8.3.2 HSDPA
The network does not allocate fixed bandwidth or resources for the PS
services carried by HSDPA, but perform fast schedule every 2ms. Therefore,
the throughput that a subscriber can reach depends on abundant factors, such
as:
 UE category (capacity level)
 Available code resource of HSDPA
 Available power resource of HSDPA
 Number of HSDPA subscribers
 Scheduling algorithm
 Radio environment
Therefore, the throughput of single PS service carried by HSDPA fluctuates
more sharply than that carried by DCH. However, HSDPA uses new
technologies, such as fast schedule, HARQ, and 16QAM, so the utilization
rate of resources is higher, and throughput of whole cell is higher.
8.3.3 CCH
FACH can carried PS services of low traffic, it can also bear broadcasting
services like CMB.
FACH uses code resource of different SFs, so it support variable channel rate.
This depends on the need by broadcasting services like CMB.
8.4 Description of HSDPA Algorithms and Parameters
8.4.1 Code Resource Configuration
CCH Code Resource

shows the code tree of downlink channel code.

Code tree of downlink channel code
In , the pink massy dot is assigned to CCH. Each channel code is indicated by
C (m, n). Wherein, the m is SF (spreading factor), and n is channel code
number, 0 ≤ n ≤ m – 1. The m is 2 to the power x. The x is an integer.
The HSDPA cells, like R99 cells, must be configured with CCH. Codes must
be assigned to CCH. The codes of PCPICH and PCCPCH are fixed to C (256,
0), C (256, 1). Number of SCCPCHs and SF change. The SF ranges from 256
to 4. It is set on RNC LMT.
lists the CCH SFs.
CCH SFs
Channel SF
PCPICH 256
PSCH None
SSCH None
BCH Carried by P-CCPCH. SF: 256
PCH Carried by S-CCPCH. SF is variable. The
default SF is 64.
FACH
AICH 256

PICH 256
On RNC LTM, allocate SCCPCH by executing the command ADD

SCCPCHBASIC. The command changes the slot format of the channel.
According to the 3GPP protocol 25.211, the SF and rate of each slot format
are prescribed as in . Therefore, changing slot format leads to different
allocation of SCCPCH codes. For example, changing slot format from 8 to 6
equals to changing SF from 64 to 128.
Secondary CCPCH fields

Slot Channel Channel SF Bits/ Bits/ Ndata1 Npilot NTFCI
Format Bit Rate Symbol Rate Frame Slot
#i (kbps) (kbps)
0 30 15 256 300 20 20 0 0
1 30 15 256 300 20 12 8 0
2 30 15 256 300 20 18 0 2
3 30 15 256 300 20 10 8 2
4 60 30 128 600 40 40 0 0
5 60 30 128 600 40 32 8 0
6 60 30 128 600 40 38 0 2
7 60 30 128 600 40 30 8 2
8 120 60 64 1200 80 72 0 8*
9 120 60 64 1200 80 64 8 8*
10 240 120 32 2400 160 152 0 8*
11 240 120 32 2400 160 144 8 8*
12 480 240 16 4800 320 312 0 8*
13 480 240 16 4800 320 296 16 8*
14 960 480 8 9600 640 632 0 8*
15 960 480 8 9600 640 616 16 8*
16 1920 960 4 19200 1280 1272 0 8*
17 1920 960 4 19200 1280 1256 16 8*

The number of SCCPCHs and SF depends on the capacity of PCH and FACH bearer.
Engineers must be cautious on actual modification. Only when engineers perform cell
throughput test or maximum subscriber number of single cell, can them change SF
larger, such as from 64 to 128.
Assigning HSDPA Channel Codes

HSDPA code resource management includes HS-SCCH code resource
allocation and HS-PDSCH code resource management. Wherein, HS-SCCH
code resource uses manual allocation, namely, manually set the number of
HS-SCCHs by executing the command RNC LMT.
The HS-SCCH success rate of subscribers depends on HS-SCCH power,
number of HS-SCCHs, number of subscribers, scheduling algorithm,
available power and code resource for HS-PDSCH, and transmissible traffic.
Configure the HS-SCCH according to available power and code resource for
HS-PDSCH and traffic of service source.
Configure HS-PDSCH for level 12 UE as below:
Configure 5 codes to HS-PDSCH. It is recommended to configure 2 HS-
SCCHs.
SCCHs.
SCCHs.
In V1.6 RNC, the allocation of HS-PDSCH code resource supports manual
code allocation and automatic code allocation.
Manual code allocation means that the code resource for HS-PDSCH is
statically allocated by RNC LMT, unless engineers modify it on RNC LMT.
Otherwise, the code resource for HS-PDSCH is fixed in the network.
Automatic code allocation means the RNC LMT only allocates the available
code range for HS-PDSCH. In system running, the NodeB automatically
adjusts number of actual HS-PDSCH used.
RNC manual code allocation algorithm
Configure HSDPA cells with the CCH which is the same as R99 cells. In
addition, configure code resource (in manual code allocation) for HS-
SCCH and HS-PDSCH. HS-SCCH SF is fixed to 128. HS-PDSCH SF is
fixed to 16. Number of HS-SCCHs and HS-PDSCHs configured in cell
depends on factors like actual throughput of data services.
lists HSDPA SFs.
HSDPA SFs
Channel SF
HS-SCCH 128
HS-PDSCH 16

Only when the HSDPA feature is deactivated, can engineers modify code
resource. After modification, activate HSDPA feature. Modify HSDPA
by executing the command below:
DEA CELLHSDPA; //Deactivate HSDPA feature of cell
MOD CELLHSDPA: CELLID=10201, AllocCodeMode=Manual,
HSPDSCHCODENUM=10, HSSCCHCODENUM=2;
ACT CELLHSDPA; // Activate HSDPA feature of cell
RNC automatic code allocation algorithm
In automatic code allocation, the RNC LMT sets the maximum and
minimum number of available codes for HS-PDSCH.
Minimum number of HSDPA codes: assume that the value is N1, and
then the codes with the number from 16 to 16 – N1 + 1 are allocated to
HS-DSCH.
Maximum number of HSDPA codes: assume that the value is N2, and
then the codes with 16 as SF and with the number from 16 – N1 + 1 to
16 – N2 + 1 are totally allocated to HS-DSCH if R99 DPCH does not
need the codes.
The codes with 16 as SF and with code number from 16 – N1 + 1 to 16 –
N2 + 1 are shared codes. Namely, they can be used by R99 DPCH and
HSDPA. Most of the services carried on R99 DPCH are CS services,
with high priority. As a result, when the R99 DPCH code resource is
inadequate, the R99 DPCH will use shared code by priority.
DEA CELLHSDPA; // Deactivate HSDPA feature of cell
MOD CELLHSDPA: CELLID=10201, AllocCodeMode=Automatic,
HsPdschMaxCodeNum=10, HsPdschMinCodeNum=5,
RevSFThd=SF32;
ACT CELLHSDPA; // Activate HSDPA feature of cell
Code Resource Allocation of Associated DCH of HSDPA

When a subscriber applies for using high speed PS service, the network
carries it on HSDPA. The subscriber uses HS-SCCH and HS-PDSCH, and
meanwhile the network allocates a downlink associated DCH for transmitting
signaling upon service setup. According to current product implement, upon
RRC connection setup, DCH carries the service at a rate of 13.6 kbps. Each
HSDPA subscriber needs allocating a DCH with 128 as SF. During RB setup
state, reconfigure the 12.6 kbps signaling to 3.4 kbps signaling.
If engineers want to have associated DCH to use fewer codes so that more
codes can be allocated to HSDPA or more subscribers can connect to the
network, change the signaling channel to be carried by 3.4 kbps channel. The
MML command is SET RRCESTCAUSE.
Code Resource Occupation Sample

shows a sample of code resource occupation.

Code resource occupation sample
In ,
 CCH: PCIPCH uses C(256,0), PCCPCH uses C(256,1), AICH uses
C(256,2), PICH uses C(256,3), and SCCPCH(64,1).
 HS-SCCH: C(128,4)–C(128,7). Four HS-SCCHs are configured.
 HS-PDSCH: C(162,2)–C(16,15). 14 HS-PDSCHs are configured.
 Associated DCH: C(256,16)–C(256,19). There are four HSDPA
subscribers. After each subscriber sets up HSDPA services, the network
allocates a DCH with 256 as SF.
8.4.2 HS-PDSCH MPO Instant

Modify HS-PDSCH MPO constant by executing the command ADD
CELLHSDPA on RNC LMT.
Modifying HS-PDSCH MPO will not effect data transfer, but affect the CQI
reported by UE. When the NodeB schedules UEs, it modifies the CQI
reported by UE according to available power for HS-PDSCH. After
modification, the CQI equals to available power for HS-PDSCH – PCPICH
power – MPO + the CQI reported by UE.
In HSDPA network, the UE reports CQI. The NodeB judges the quality of
current radio link according to modified CQI, and adjusts the data block size

and the power. In current version, when the CQI modified by NodeB is
smaller than 2, the NodeB will not transfer data to the UE.
Calculate the CQI reported by UE according to Ec/Nt as below:
CQI reported by UE = (Ec/Nt)CPICH + 10 * lg(16) + MPO + 4.5
Wherein,
 10 * lg(16) is the spreading factor (SF = 16) for calculating HS-PDSCH.
 MPO is the acronym of Measure Power Offset. Calculate MPO with the
MPO constant as below:
MPO = Min(13,CellMaxPower - PcpichPower – MPO constant)
 4.5 is a fixed constant, obtained from simulation result.
The CellMaxPower is 43 dBm. The PcpichPower is 33 dBm. The default
MPO constant is 2.5 dB. The orthogonal factor is 0.6. The average
interference factor of neighbor cell is 0.65. Therefore, the relationship
between pilot Ec/Io and pilot Ec/Nt is N t  (1    f ) * I oc  N 0 and
I o  (1  f ) * I oc  N 0 . Wherein, Ioc is the signals of the cell. Neglecting the
impact from thermal noise, the relationship between the CQI reported by UE
and pilot Ec/Io is as listed in .
Relationship between the CQI reported by UE and pilot Ec/Io

Pilot Ec/Io (dB) CQI reported by UE
–14 12
–13 13
–12 14
–11 15
–10 16
–9 17
–8 18
–7 19
–6 20
–5 21
Reducing MPO constant leads to increment of the CQI reported by UE.
The CQI reported by UE is relevant to factors like multipath conditions, and thermal
noise of laptops.
Sometime the impact from thermal noise No cannot be neglected, especially with
laptop and data card.
8.4.3 HSDPA UE Category

3GPP protocol 25.306 prescribes UE category (12 categories) as listed in .

FDD HS-DSCH physical layer categories

HS-DSCH Maximum Minimum Maximum number of bits Total
category number of inter-TTI of an HS-DSCH transport number of
HS-DSCH interval block received within soft channel
codes an HS-DSCH TTI bits
received
Category 1 5 3 7298 19200

Category 2 5 3 7298 28800
Category 3 5 2 7298 28800
Category 4 5 2 7298 38400
Category 5 5 1 7298 57600
Category 6 5 1 7298 67200
Category 7 10 1 14411 115200
Category 8 10 1 14411 134400
Category 9 15 1 20251 172800
Category 10 15 1 27952 172800
Category 11 5 2 3630 14400
Category 12 5 1 3630 28800
Wherein, the categories 11 and 12 support QPSK only. Other categories

support both QPSK and 16QAM.
In current HSDPA tests, the Huawei E620 data card is category 12.
In , the 3GPP protocol TS25.306 prescribes that the maximum transport block
received by category 12 UE is 3630 bits. This is the receiving capacity of UE.
According to sender, the maximum transport block size (TBS) for category 12
UE is 3440 bits in NodeB of current version. The reachable peak rate of
MAC-hs layer for category 12 UE of single subscriber according to TBS is
3440 bit/2ms, 1.72 Mbps.
According to MAC-d PDU, assume the MAC-d PDU is 336 bits, so the
reachable peak rate for single subscriber is:
336bits *  3440 / 336 / 2ms  1.68Mbps
  means rounding down to the nearest integer.

The UEs like category 5 and 6 which support 16QAM, can obtain higher rate.
The category 10 UE has the highest rate, as high as 27952/2ms/1024/1024,
namely, 13.3 Mbps.
8.4.4 HS-DPCCH Power Control

HS-DPCCH is uplink dedicate physical channel, transmitting signals at
physical layer: ACK/NACK and CQI. HS-DPCCH does not use respective

power control, but keeps a power offset with uplink DPCCH. When HS-
DPCCH carries different information, it uses different power offsets.
Basic Process
Upon modulation, the information 0, 1, and DTX of HS-DPCCH are
respectively mapped as +1, –1, and 0. After spreading, they are multiplied
with a gain factor  hs . The  hs depends on the power offsets  ACK ,
 NACK , and  CQI . lists the quantized amplitude ratio of power offsets
 ACK ,  NACK , and  CQI .
Quantized power offset
Signaling values for  ACK, ACK Quantized amplitude ratios for

and CQI   HS  DPCCH 
 
 20 
10
8 30/15
7 24/15
6 19/15
5 15/15
4 12/15
3 9/15
2 8/15
1 6/15
0 5/15
For the timeslot to bear HARQ-ACK, if the HARQ-ACK is 1,

 HS  DPCCH   ACK . If the HARQ-ACK is 0,  HS  DPCCH   NACK .
 HS  DPCCH   CQI
For the timeslot to bear CQI, , so for uncompressed
 HS  DPCCH
frames,
 HS   c  10 20
.
At the header and tail of compressed frames, the ratio of DPCCH power and
HS-DPCCH power keeps fixed. Between the frame header and tail,
 HS  DPCCH
N pilot ,C
 HS   c  10 20

N pilot , N
Initial Target SIR

  
The power offsets ACK , and NACK , and CQI are based on the initial
target SIR of uplink DPCH. Outer loop power control sets different initial
  
target SIRs to different services. The values of ACK , NACK , and CQI

vary with the difference between initial target SIR of the service and the
reference target SIR.
Repeat Factor and Feedback Cycle

The following parameters are sent to UE and NodeB through signaling at high
layer.
 ACK/NACK repeat factor: N_acknack_transmit
 CQI repeat factor: N_cqi_transmit
 CQI feedback cycle:: CQI Feedback Cycle k
On the one hand, after decoding HS-PDSCH data, based on MAC-hs cyclic
redundancy check (CRC), the UE sends an HARQ ACK or NACK message,
and keeps resending ACK/NACK message in the N_acknack_transmit
continuous HS-DPCCH subframes. If N_acknack_transmit is larger than 1, in
the HS-DSCH n + 1 frame to n + N_acknack_transmit – 1 frame, the UE will
not try to receive or decode transport blocks on HS-PDSCH. The n is the
number of last HS-DSCH subframe that receives transport blocks.
On the other hand, no matter whether the UE receives the data sent to it, it
resends N_cqi_transmit CQI every CQI Feedback cycle (k ms). Obviously,
the CQI Feedback Cycle is larger than N_cqi_transmit * 2ms.
Configuration of HS-DPCCH Power Control Parameters

HS-DPCCH cannot perform multiple link combination, without SHO gain, so
it sets two sets of parameters (whether there is FORSHO at the end of the
parameter) for whether the UE is in SHO state. The initial target SIR of
DPCCH, namely, SIRTARGET, does not distinguish UE in SHO state from
UE in non-SHO state.
The parameters related to ACK and NACK include three types: 1, 2, and 3.
This distinguishes UEs of different capacities. Namely, the UE can support 1,
2, or 3 TTI(s) to send an ACK or NACK message.
lists HS-DPCCH power control parameters.
HS-DPCCH power control parameters

Parameter name Parameter description Default Value
SIRTARGET Initial target SIR of DPCCH 112(3dB)

ACKPO1 ACK power offset 1 PO_24/15
ACKPO1FORSHO Multiple RLS state ACK power PO_24/15
offset 1
offset 2


offset 3
NACKPO1 NACK power offset 1 PO_24/15
NACKPO1FORSHO Multiple RLS state NACK PO_24/15
power offset 1
power offset 2
power offset 3
ACKNACKREF1 ACK/NAK repeat factor 1 1
ACKNACKREFFORSHO Multiple RLS state 1
ACK/NACK repeat factor
CQIPO CQI power offset PO_24/15
CQIPOFORSHO Multiple RLS state CQI power PO_24/15
offset
CQIREF CQI repeat factor 1
CQIREFFORSHO Multiple RLS state CQI repeat 1
factor
CQIFBCK CQI feedback cycle k D2
CQIFBCKFORSHO Multiple RLS state CQI D2
feedback cycle k
In softer handover, multiple HS-DPCCH connects to at the same NodeB, so engineers

can perform multiple link combination. As a result, the parameters configured in
softer handover are consistent with the parameters of single link.
The parameters related to HS-DPCCH can be observed in the messages like

RB SETUP, PHYSICAL CHANNEL RECONFIGURATION, and RB
RECONFIGURATION.
shows ACK/NACK/CQI parameters in RB SETUP message.

ACK/NACK/CQI parameters in RB SETUP message
Check whether the HS-DPCCH ACK PO is proper by the ACK ->

NACK/DTX misjudgment probability in the HSDPA Decoding Statistics
window in Probe. The probability is usually smaller than 1%.
8.5 Method for Modifying TCP Receive Window

For the services (such as VOD and FTP) using TCP protocol, the TCP
window size of test laptop (client) and server have great impact on
performance of service. To obtain better performance, set the window size as
large as possible, and set the window size of client and server to the same,
such as 64K (65535).
8.5.1 Tool Modification

Run the DRTCP.exe attached in the appendix 8.9.1. For the running interface,
see the method for modifying MTU.
Change the TCP Receive Window, such as 65535.
8.5.2 Regedit Modification

Detailed operations are as below:
In Windows 2000,
 In
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpi
p, add string: "TcpWindowSize"="65535"

 In
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpi
p\Parameters, add double type value TcpWindowSize. Set it to 65535 or
ffff (hex).
8.6 Method for Modifying MTU

The MTU here is IP packet size. As shown in , GGSN has two layer IP. The
maximum IP packet size is 1500 bytes. If a data packet at IP layer is to be
transmitted, and the packet is larger than MTU at IP layer after encapsulation,
IP packet fragment is necessary. After fragment, each fragment is smaller than
the MTU at IP layer.
In terms of PS CN efficiency, avoid IP fragment and reassembly, and
meanwhile use the MTU as large as possible. The MTU is usually smaller
than or equal to 1450 bytes. The data transmission rate of PS CN is usually
higher than the rate at air interface, so the MTU has little impact on the rate at
air interface. The default MTU in computers is 1500 bytes.
Modifying MTU includes modifying the MTU of server and modifying the
MTU of test laptop. The server and client will negotiate, so the actual MTU is
the smaller one.
Modify MTU by using DRTCP tool or modifying regedit. The following
sections detail the operations.
8.6.1 Tool Modification

Run the DRTCP.exe attached in the appendix 8.9.1, with the running interface
as shown in .
Running interface of DRTCP
Server
Modify the MTU in Adapter Settings shown in , namely, the MTU at the
network port.

Test Laptop
For test laptops, the UE is connected to it by data line and dial-up connection
is set up. Data packets are sent through USB port. As a result, modifying
MTU of USB port is necessary, namely, the Dial Up(RAS) MTU as shown in .
After modification, restart the Windows operating system.
8.6.2 Regedit Modification
Modifying MTU of server

Modify the MTU of network port on server.
In Windows 2000, in
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Pa
rameters\Interfaces\{.........}\, add a double byte value, named mtu, with the
value of 1450.
Modifying MTU of client

For activating UE and laptop, dial-up connection is used with data line. Data
packets are sent through USB port. Modify the MTU of USB on laptop as
below:
In Windows 2000, in
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NdisWan
\Parameters\Protocols\0\, modify the ProtocolMTU to 1450.
After modification, restart the Windows operating system.
8.7 Confirming APN and Rate in Activate PDP Context Request Message
When the UE originates data services, the QoS is sent to the system in
Activate PDP Context Request message. The message result is as shown in .

Detailed resolution of Activate PDP Context Request message
8.7.1 Traffic Class

In PDP activation request, the traffic class includes the following classes:
000 Subscribed traffic class
001 Conversational class
010 Streaming class
011 Interactive class
100 Background class
111 Reserved
Wherein, the subscribed traffic class above indicates that the traffic class is
not determined by UE, but by CN according to the subscribed information of
the subscriber.
8.7.2 Maximum Rate and Guaranteed Rate

 max bit rate up: uplink maximum rate, 64 in , namely, 64 kbps.
 max bit rate down: downlink maximum rate, 104 in the following figure,
namely, 384 kbps.

 guar bit rate up: uplink guaranteed rate, 0 in the following figure,
namely, no requirement is on uplink guaranteed rate.
 guar bit rate down: downlink guaranteed rate, 0 in the following figure,
namely, no requirement is on downlink guaranteed rate.
3GPP protocol 24.008 prescribes the method for calculating rate as below:
Assume x is the initial value required by a rate.
If 0 < x < 64, the actual rate is x kbps.
If 64 ≤ x < 128, the actual rate is 64 + (x – 64) * 8 kbps. In the following
figure, the downlink maximum rate is 104 kbps. The calculation formula: 64 +
(104 – 64) * 8 = 384 kbps.
If 128 ≤ x < 255, the actual rate is 576 + (x – 128) * 64 kbps.
If x = 255, the actual rate is 0 kbps.
8.7.3 APN
The APN in messages are ASCII code of characters, so engineers cannot see
the string directly.
shows converting ASCII code to string in UltraEdit.
Converting ASCII code to string in UltraEdit
Converting ASCII code to string in UltraEdit proceeds as below:

Run UltraEdit
Create a File
Select Edit > Hex Edit
Type the ASCII code of APN in the messages

You can see the APN string in , it start at the fourth byte.
8.8 APN Effect

8.8.1 Major Effect
In GPRS/WCDMA networks, APN has the following effects:
 In GRPS/WCDMA backbone networks, APN identifies GGSN.
 APN defines the external PDN that GGSN can connect to, such as ISP
networks, private networks, and enterprise intranets.
8.8.2 Method for Naming APN

APN consists the following two parts:
 APN network identity
It defines the external networks that subscribers can connect to by the
GGSN. This part is compulsory. It is assigned to ISP or Huawei by
network operators, the same identity as the fixed Internet domain name.
For example, to define subscribers to connect to Huawei enterprise
intranet by the GGSN, the APN network identity must be huawei.com.
 APN operator identity
It defines the GPRS/WCDMA backbone network. This part is optional.
For example, in a GPRS network, it could be xxx.yyy.gprs (such as
MNC.MCC.gprs), which identifies the PLMN network of GGSN.
APN network identity is saved in HLR as a subscribed data. When a UE
originate packet services, it provides APN for SGSN. APN is used by SGSN
to select the GGSN to be connected and by GGSN to judge the external
networks to be connected. In addition, HLR can save a wildcard. In this way,
the MS or SGSN can select an APN that is not saved in HLR.
Subscribers select GGSN by different APNs. Namely, subscribers can activate
multiple PDP context, and each PDP context is related to an APN. Subscribers
select different APNs to connect to different external networks through
different GGSNs.
8.8.3 APN Configuration

Before configuring APN on GGSN9811, the PDN that can be visited by
subscribers must be clearly known. Set different APNs to different PDNs. For
example, the GGSN9811 allows a subscriber to visit Internet through an ISP
and an enterprise intranet simultaneously, and two APNs must be set up on
GGSN9811: one for visiting Internet, and the other for visiting the enterprise
intranet.
8.9 PS Tools
8.9.1 TCP Receive Window and MTU Modification Tools
Modify TCP receive window and MTU with the following tool:

Drtcp.rar
For the detailed method, see the appendix 8.5 and 8.6.
8.9.2 Sniffer
Sniffer can capture, construct, and send packets. It constructs transfer data at a
fixed rate, and then obtains the rate at other NEs. This eliminates the external
impact. Sniffer can send packets at UE side or on server. It can construct data
transfer at fixed rate in uplink and downlink simultaneously, or just construct
data transfer in uplink or downlink.
Verifying Bearer Capacity of System by IP Data Packet of Fixed Rate

Constructed by Sniffer
In service demonstration, if the rate declines, it is difficult to judge whether
the system is faulty or the source rate declines. By IP data packet of fixed rate
constructed by sniffer, engineers can focus on system problems without being
disturbed by source rate.
How to construct IP data packet of uplink and downlink fixed rate
Execute the ping command on a computer of UE daemon to the
application server. Capture the ping packet by using capture function of
Sniffer. Send the ping packet automatically and continuously by using
the packet generator function of Sniffer, and then obtain the data flow of
uplink and downlink fixed rate (if the system is normal). Calculate the
rate according to sending interval and ping packet size. Monitor by the
monitoring software at UE daemon whether the uplink and downlink rate
are normal.
Execute the ping command on the application service to UE. Capture the
ping packet by using capture function of Sniffer. Send the ping packet
automatically and continuously by using the packet generator function of
Sniffer, and then obtain the data flow of uplink and downlink fixed rate
(if the system is normal).
How to construct IP data packet of unidirectional uplink fixed rate
Capture the ping packet by using capture function of Sniffer. Destroy the
IP packet and data related to ping by using the packet generator function
of Sniffer. The IP header remains the same. Send the IP packet
automatically and continuously. When the IP packet reaches the
application server, it will be dropped by the server because the server
cannot identify the content of IP packet. As a result, the data flow of
unidirectional uplink fixed rate is obtained (if the system is normal).
How to construct IP data packet of unidirectional downlink fixed rate
Use the same method as mentioned in how to construct IP data packet of
unidirectional uplink fixed rate. The data flow of unidirectional uplink
fixed rate is obtained (if the system is normal).
Judge by Sniffer Whether Packets are lost in Uplink and Downlink

Use the previous method for capturing packets. Set the Sniffer to send ping
packets of fixed number. Monitor at the destination by Sniffer whether the

ping packets of the same number are received. This checks whether packets
are lost during transmission.
8.9.3 Common Tool to Capture Packet: Ethereal

Ethereal captures packets. It can parse protocols like HTTP, RTP, and FTP,
even WAP, and GSM-MAP protocols. It can also analyze the throughput of
TCP flow, delay distribution, and RTP flow. It features to resolute IP packet
and time label of high precision (ms level). The latest version of Ethereal can
record the content of PPP protocol on laptop. It helps to analyze end-to-end
problems and delay conveniently.
8.9.4 HSDPA Test UE

In terms of test methods, the PS service test carried by HSDPA is the same as
that carried by DCH. Select the test UEs that support HSDPA.
Now the UEs available in HSDPA PS service test include Huawei E620 data
card, Qualcomm TM6275, and UB TM500.
Huawei E620 data card is a category 12 UE. It supports 5 HS-PDSCH codes
at most. It supports QPSK, but not 16QAM. The maximum throughput at
physical layer is 1.8 Mbps. The actual throughput at application rate is 1.4
Mbps. Huawei E620 data card supports combination of PS and AMR services,
but not VP service.
Qualcomm TM6275 is a category 11 or 12 UE. It supports 5 HS-PDSCH
codes at most. It supports QPSK, but not 16QAM. It supports streaming and
VP services.
UB TM500 is an emulation test UE. It can emulate the UEs of multiple
categories. It supports 15 HS-PDSCH codes at most. It supports QPSK and
16QAM. It supports the combination of PS and CS services, namely, after a
subscriber starts PS service, it then start CS service.
Huawei E620 data card and Qualcomm TM6275 are for DT. TM500 is large,
unfit for DT, but it can emulate multiple UE categories. In laboratory, HSDPA
performance test requires UE to support 10 or 15 codes, but no UE or data
card support 10 or 15 codes. As a result, using TM500 for test is necessary.
8.10 Analysis of PDP Activation

The GRPS subscribed data can include the subscribed information of multiple
packet data protocol (PDP) address. In MS, SGSN, and GGSN, one or more
PDP contexts describe each PDP address. Each PDP context is in the
following two states: inactive or active state.
In active state, PDP context is activated in MS, SGSN, and GGSN. It contains
the routing and mapping information to process PDP PDU between MS and
GGSN. The PDP context activation process contains the activation process
originated by MS, the activation process originated by network, and the
second activation process. The activation process originated by MS is used
upon PS service connection.
shows the PDP context activation process originated by MS.

PDP context activation process originated by MS
MS UTRAN 3G-SGSN 3G-GGSN
1. Activate PDP Context Request
C1
3. Radio Access Bearer Setup
4. Invoke Trace
5. Create PDP Context Request
5. Create PDP Context Response
C2
7. Activate PDP Context Accept
The MS sends SGSN the Activate PDP Context Request (NSAPI, TI, PDP
Type, PDP Address, Access Point Name, QoS Requested). The PDP Address
indicates the dynamic address or the static address. If the PDP Address is
dynamic address, set it to null.
The following aspects lead to unsuccessful PDP activation process:
 Activation rejected, unspecified (#31): Huawei SGSN defines GTPU
interaction failure, expiration, operation SDB failure, activation failure
due to other abnormalities to this kind of failure.
 Activation rejected by GGSN (#30): GGSN rejects or fails to decode the
corresponding activation request.
 Missing or unknown APN (#27): APN is not contained in the activation
request message or cannot be extracted. Huawei SGSN takes DNS
resolution failure, DHCP or MIP GGSN address acquisition failure, APN
error specified by activation at network side, other APN error as
activation failure. These are internal causes.
 Unknown PDP address or PDP type (#28): the PDP address or PDP type
cannot be identified by SGSN.
 User Authentication failed (#29): user authentication fails.
 Service option not supported (#32): the requested serving PLMN does
not support this. Huawei SGSN takes wildcard (*) activation rejection,
service non-supportive, IPV6 non-supportive as this type.
 Requested service option not subscribed (#33): requested service is not
subscribed. Huawei SGSN takes mismatch subscribed information,
VPLMN access inhibit, and charging restricted callingVPLMN as this
type.
 Insufficient resources (#26): activation fails due to inadequate resource.
Huawei SGSN takes the following causes as inadequate resource.
− UGBI PDP resource congestion
− UGBI board congestion
− RPU failure
− Inadequate SDB or SM CB resource
− Activation failure due to internal charging restricted calling
 Operator Determined Barring (#8): operators bar PDP activation process.

 Service option temporarily out of order (#34): this is a cause value which
MSC use to indicate that function are inadequate to support
corresponding requests. Huawei SGSN is seldom used, so neglect it.
 NSAPI already used (#35): the requested NSAPI is already used by PDP
activated by the subscriber, but the cause value will not be sent.
 Protocol error, unspecified (#111): Huawei SGSN in abnormal SDB or
SM state may confront this type of activation rejection.

Reference
[1] W-Equipment Room Operation Guide
[2] W-Test Guide
[3] W-Access Problem Optimization Guide
[4] W-Handover and Call Drop Problem Optimization Guide

Ps-Service Problem Optimization

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Ps-Service Problem Optimization

Hochgeladen von

Copyright:

Verfügbare Formate

W-PS Service Problem Optimization Guide For internal use only

Product name Confidentiality level

W-PS Service Problem Optimization Guide

Prepared by Yu Yongxian Date 2006-03-22

Huawei Technologies Co., Ltd.

2006-08-28 Huawei Proprietary. No Spreading Without Permission. Page 1 of 133

Date Version Description Author

2006-08-28 Huawei Proprietary. No Spreading Without Permission. Page 2 of 133

4 Analysis of Traffic Statistics Data......................................................................................23

5 Analysis of DT/CQT Data...................................................................................................38

2006-08-28 Huawei Proprietary. No Spreading Without Permission. Page 3 of 133

6.2 Cases at CN Side................................................................................................................................111

2006-08-28 Huawei Proprietary. No Spreading Without Permission. Page 4 of 133

8.8.3 APN Configuration...................................................................................................................154

2006-08-28 Huawei Proprietary. No Spreading Without Permission. Page 5 of 133

Table 2-2 Requirements by RAN traffic statistics on PS throughput........................................................17

Table 3-1 Major parameters to be collected in DT/CQT...........................................................................19

Table 3-2 Tools for collecting data............................................................................................................21

Table 4-2 Measured items related to PS throughput in cell performance measurement...........................25

Table 4-3 Measured items related to HSDPA throughput (cell measurement)..........................................26

Table 4-4 Other measured items related to throughput.............................................................................27

Table 4-5 Indexes to judge whether a cell has PS service request............................................................33

Table 4-6 Cell measurement/cell algorithm measurement analysis..........................................................33

Table 4-7 Analysis of cell performance/Iub interface measurement.........................................................34

Table 4-8 Cell Measurement/Cell RLC Measurement Analysis...............................................................35

Table 5-1 Comparing operations and analyzing problem..........................................................................59

Table 5-4 HS-SCCH power offset.............................................................................................................78

Table 6-1 Delay test result of ping packet...............................................................................................104

Table 8-1 CCH SFs..................................................................................................................................136

Table 8-2 Secondary CCPCH fields........................................................................................................137

Table 8-3 HSDPA SFs.............................................................................................................................139

Table 8-5 FDD HS-DSCH physical layer categories..............................................................................142

Table 8-6 Quantized power offset...........................................................................................................144

Table 8-7 HS-DPCCH power control parameters...................................................................................146

2006-08-28 Huawei Proprietary. No Spreading Without Permission. Page 6 of 133

Figure 4-2 Flow for analyzing cell-level traffic statistics data.................................................................31

Figure 5-1 Flow for analyzing DT/CQT data...........................................................................................39

Figure 5-4 Flow for processing problem of failure in opening port.........................................................43

Figure 5-5 Flow for analyzing access failure problems............................................................................45

Figure 5-6 Signaling flow of successful setup of a PS service in Probe..................................................46

Figure 5-8 Connection Performance Measurement-Downlink Throughput and Bandwidth window

Figure 5-9 HSDPA parameters in Probe...................................................................................................53

Figure 5-11 Flow for analyzing poor performance of data transfer..........................................................58

Figure 5-13 Flow for analyzing data transfer affected by Uu interface...................................................62

Figure 5-17 Confirming in Probe that service is set up on HSDPA channel............................................71

Figure 5-18 High code error of ACK->NACK/DTX in Probe.................................................................85

Figure 5-19 Uplink and downlink RL imbalance in handover areas........................................................86

Figure 5-22 Flow for analyzing interruption of data transfer...................................................................94

Figure 5-23 Interruption delay of data transfer in HSDPA.......................................................................97

Figure 5-26 Interruption delay of TCP displayed in Ethereal.................................................................100

Figure 6-1 UE HSDPA statistics data in QXDM....................................................................................107

2006-08-28 Huawei Proprietary. No Spreading Without Permission. Page 7 of 133

Figure 6-4 Unstable PS rate (1)..............................................................................................................116

Figure 6-5 Unstable PS rate (2)..............................................................................................................116

Figure 6-6 Analyzing packets captured by Ethereal upon unstable PS rate...........................................117

Figure 6-7 Interactive interface in CuteFTP...........................................................................................120

Figure 6-8 Signaling of normal downloading by FTP............................................................................121

Figure 6-9 Signaling of abnormal downloading by FTP........................................................................122

Figure 6-10 Signaling of normal handover between 3G network and 2G network................................125

Figure 6-11 Normal signaling flow between UE and 2G SGSN............................................................126

Figure 6-12 Signaling flow traced on 2G SGSN....................................................................................127

Figure 8-1 Transport channel of PS data................................................................................................131

Figure 8-2 Packet Service Data Flow.....................................................................................................132