Académique Documents
Professionnel Documents
Culture Documents
Product name
Confidentiality level
WCDMA RNP
Product version
Total 166 pages
3.2
Prepared by
Yu Yongxian
Date
Reviewed by
Date
Date
Reviewed by
Approved by
2006-03-22
2006-03-22
Date
2006-03-30
Revision Records
Date
Version Description
2004-1126
1.00
Reviewer
Author
Initial transmittal.
Yu Yongxian
1.01
Yu Yongxian
2006-0316
1.02
Yu Yongxian
2006-0322
3.00
Yu Yongxian
2006-0523
3.10
Wang Dekai
2006-1024
3.11
Wang Dekai
2006-0309
Date
Version Description
Reviewer
Author
3.2
2008-0417
3.21
Hua Yunlong
2008-1024
3.22
Zheng Kaisi
He fengming
2008-1218
3.23
Gao Bo
Contents
3.1 Traffic Statistics 19
3.2 DT/CQT 20
3.3 Others 22
4.1 Traffic Statistics Indexes Related to Throughput 25
4.2 Generic Analysis Flow 29
4.2.1 Flow for Analyzing RNC-level Traffic Statistics Data 29
4.2.2 Flow for Analyzing Cell-level Traffic Statistics Data 32
5.1 Access Failure 39
5.1.1 Originating PS Service by UE Directly 39
5.1.2 UE as the Modem of PC 40
5.2 Disconnection of Service Plane 46
5.2.1 Analyze Problems at RAN Side 46
5.2.2 Analyzing Problems at CN Side 51
5.3 Poor Performance of Data Transfer 54
5.3.1 Checking Alarms 55
5.3.2 Comparing Operations and Analyzing Problem 56
5.3.3 Analyzing Poor Performance of Data Transfer by DCH 57
5.3.4 Analyzing Poor Performance of Data Transfer by HSDPA at RAN Side 62
5.3.5 Analysis of the Problem about Poor Data Transmission Performance of the HSUPA on the RAN Side 81
5.3.6 Analyzing Poor Performance of Data Transfer at CN Side 115
5.4 Interruption of Data Transfer 119
5.4.1 Analzying DCH Interruption of Data Transfer 119
5.4.2 Analyzing HSDPA Interruption of Data Transfer 121
6.1 Cases at RAN Side 124
6.1.1 Call Drop due to Subscriber Congestion (Iub Resource Restriction) 124
6.1.2 Uplink PS64k Service Rate Failing to Meet Acceptance Requirements in a Test (Air Interface Problem)
124
6.1.3 Statistics and Analysis of Ping Time Delay in Different Service Types 125
6.1.4 Low Rate of HSDPA Data Transfer due to Over Low Pilot Power 126
6.1.5 Unstable HSDPA Rate due to Overhigh Receiving Power of Data Card 127
6.1.6 Decline of Total Throughput in Cell due to AAL2PATH Bandwidth larger than Actual Physical
Bandwidth 128
6.1.7 Causes for an Exceptional UE Throughput and Location Method in a Field Test 130
6.2 Cases at CN Side 133
6.2.1 Low FTP Downloading Rate due to Over Small TCP Window on Server TCP 133
6.2.2 Simultaneous Uploading and Downloading 134
6.2.3 Decline of Downloading Rate of Multiple UEs 135
6.2.4 Unstable PS Rate (Loss of IP Packets) 136
6.2.5 Unstable PS Rate of Single Thread in Commercial Deployment (Loss of IP Packets) 138
6.2.6 Unavailable Streaming Service for a Subscriber 139
6.2.7 Unavailable PS Services due to Firewall of Laptop 139
6.2.8 Low PS Service Rate in Presentation Occasion 139
6.2.9 Abnormal Ending after Long-time Data Transfer by FTP 140
6.2.10 Analysis of Failure in PS Hanodver Between 3G Network and 2G Network 144
8.1 Transport Channel of PS Data 151
8.2 Theoretical Rates at Each Layer 152
8.2.1 TCP/IP Layer 152
8.2.2 RLC Layer 152
8.2.3 Retransmission Overhead 153
8.2.4 MAC-HS Layer 153
8.3 Bearer Methods of PS Services 154
8.3.1 DCH 154
8.3.2 HSDPA 154
8.3.3 CCH 155
8.4 Method for Modifying TCP Receive Window 156
8.4.1 Tool Modification 156
8.4.2 Regedit Modification 156
8.5 Method for Modifying MTU 157
8.5.1 Tool Modification 157
8.5.2 Regedit Modification 158
8.6 Confirming APN and Rate in Activate PDP Context Request Message 159
8.6.1 Traffic Classes: 159
8.6.2 Maximum Bit Rates and Guaranteed Bit Rates 160
8.6.3 APN 160
8.7 APN Effect 162
8.7.1 Major Effect 162
8.7.2 Method for Naming APN 162
8.7.3 APN Configuration 162
8.8 PS Tools 163
Figures
Flow for analyzing RNC-level traffic statistics data 30
Flow for analyzing cell-level traffic statistics data 32
Flow for analyzing DT/CQT data 38
Flow for analyzing access failure problems when originating PS services by UE
directly 39
Flow for analyzing access problem when the UE serves as the modem of PC 40
Flow for processing problem of failure in opening port 41
Flow for analyzing access failure problems 42
Signaling flow of successful setup of a PS service in Probe 43
Flow for analyzing disconnection of service plane 46
Flow for analyzing RAN side problem about disconnection of service plane for DCH
bearer 47
Connection Performance Measurement-Downlink Throughput and Bandwidth
window 48
HSDPA parameters in Probe 50
Flow for analyzing problems at CN side about disconnection of service plane 52
Flow for analyzing poor performance of data transfer 55
Flow for analyzing RAN side problem about poor performance of data transfer on
DCH 58
Flow for analyzing data transfer affected by Uu interface 59
Flow for analyzing data transfer affected by Iub interface 61
Flow for analyzing poor performance of data transfer on HSDPA at RAN side 64
Confirming in the RNC message that PS service is set up on HSDPA channel 65
Confirming in Probe that service is set up on HSDPA channel 65
Tables
Requirements by DT/CQT on PS throughput 15
Major parameters to be collected in DT/CQT 20
Tools for collecting data 22
Measured items related to PS throughput in overall performance measurement of
RNC 25
Measured items related to PS throughput in cell performance measurement 26
Measured items related to HSDPA throughput (cell measurement) 27
related to HSUPA throughput (cell measurement) 27
Other measured items related to throughput 28
Indexes to judge whether a cell has PS service request 33
Cell measurement/cell algorithm measurement analysis 33
Analysis of cell performance/Iub interface measurement 34
Cell Measurement/Cell RLC Measurement Analysis 35
Comparing operations and analyzing problem 56
Relationship between CQI and TB size when the UE is in category 1112 67
Relationship between CQI and TB size when the UE is at the level 16 68
HS-SCCH power offset 71
Categories of UE HSUPA capability levels 89
PO for the E-AGCH when the Ec/Io at the edge of cells is 12 dB 103
PO for the E-RGCH when the Ec/Io at the edge of cells is 12 dB 104
PO for the E-HICH when the Ec/Io at the edge of cells is 12 dB 107
Delay test result of ping packet 126
WCDMA PS Service 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.
Full spelling
RNO
RNP
APN
CHR
CQI
CQT
DT
Driver Test
HSDPA
HS-PDSCH
HS-SCCH
QoS
Quality of Service
SF
Spreading Factor
UE
User Equipment
SBLER
IBLER
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
Chapter 3
Data Collection
Chapter 4
Chapter 5
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
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 throughput 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, call drop and handover problems, see W-KPI Monitoring and Improvement
Guide, which provides 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 RNO in commercial network, not in benchmark trial network.
The HSDPA problem analysis and description of MML command and product function are based on
the following product versions:
BSC6800V100R006C01B064
BTS3812E V100R006C02B040
When refer RRC arithmetic and product realization default is RNC V16, refer V17 it will be labeled.
The HSUPA problem analyses, description of MML command and product function are based on the
following product versions:
BSC6800V100R008C01B082
DBS3800-BBU3806V100R008C01B062
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. In actual network optimization, the optimization objects
and test methods are according to contract.
2 lists the requirements by DT/CQT on PS throughput.
1.
Ind
ex
Average
downlink
throughput of
R99
Servi
ce
Referen
ce
PS UL64k/DL
64k
4856 kbps
PS UL64k/DL
128k
96106 kbps
PS UL64k/DL
384k
300350 kbps
Average uplink
throughput of
R99
PS UL64k/DL
64k
4856 kbps
Requirements by
DT/CQT on PS
throughput
Download with
5 threads.
Ind
ex
Servi
ce
Referen
ce
planned load)
without call drop
problems due to
congestion.
Downlink
average
throughput for
HSDPA single
subscriber
CAT12
1.52Mbps
Download with
5 threads.
The carrier
power, number
of HS-PDSCH
codes and Iub
bandwidth
resource are not
restricted. The
throughput is
determined by
capability of
UE.
The average
CQI of tested
area is 18.
Single
subscriber in
unloaded
conditions and
in the center of
cell.
Other resources
except power are
not restricted.
The average
(SBLER = 10%)
760 kbps
Ind
ex
Servi
ce
Referen
ce
CQI of tested
area is 10.
Throughput of
HSDPA cell
CAT12
3.25 Mbps
Single
subscriber in
unloaded
conditions and
in the edge of
cell.
4 CAT12 UEs,
and 14 HSPDSCH codes
It is restricted by
HS-PDSCH
code. The carrier
power and Iub
bandwidth are
not restricted.
800 kbps
HSUPA Single
subscriber
throughput
CAT3
800kbps~1.1Mbps
(cell center)
The average
CQI of tested
area is 18.
4 CAT12 UEs,
and 14 HSPDSCH codes
It is restricted by
carrier power.
The HS-PDSCH
code and Iub
bandwidth are
not restricted.
The average
CQI of tested
area is 18.
Uplink RTWP,
IUB bandwidth
resource and UE
TX power are
Ind
ex
Servi
ce
Referen
ce
not restricted.
Set MTU
size 1500
bytes , set PDU
size= 336 bits.
In UE QoS
profile in HLR,
MBR=2Mbps,
service type is
Background/Inte
ractive
The data
resource of FTP
must make sure
that upload can
get the faster
rate in the wire
connection
conditions.
200kbps~400kbps
(cell edge)
Pilot power
33dBmRSCP
>=-70dBm;
Single
subscriber in
unloaded
conditions
Uplink
RTWP,IUB
bandwidth
Ind
ex
Servi
ce
Referen
ce
resource and UE
TX power are
not restricted.
Pilot power
33dBmRSCP
>=-100dBm;
Single
subscriber in
unloaded
conditions
set
MTU 1500
bytes , set PDU
= 336 bits
In UE QoS
profile in HLR,
MBR=2Mbps,
service type is
Background/Inte
ractive
The data
resource of FTP
must make sure
that upload can
get the fast rate
in the wire
connection
conditions.
3. Data Collection
About This Chapter
The following table lists the contents of this chapter.
Title
Description
3.1
Traffic Statistics
3.2
DT/CQT
3.3
Others
There are two major methods for evaluating PS throughput: traffic statistics and DT/CQT.
1. Traffic Statistics
For collecting traffic statistics data, see W-Equipment Room Operations Guide.
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
TX power of UE
Based on the measurement tracing on RNC LMT, obtain the following information:
Uplink BLER
By the DT processing software Assistant, analyze comprehensively the data collected by Probe in
foreground DT and tracing record on RNC LMT.
3.2 lists the major parameters to be collected in DT/CQT.
1.
Parameter
Tool
Major
parameters to be
collected in
DT/CQT
Effect
Probe + GPS
Record trace
Probe + UE
Analyze problems
UE TX Power
Probe + UE
Downlink BLER
Probe + UE
Uplink/Downlink
Probe + UE
Parameter
Tool
Effect
output reports
Probe + UE
Analyze problems
Probe + UE
Uplink BLER
RNC LMT
Downlink transmission
code power
RNC LMT
Single subscriber
signaling tracing by
RNC
RNC LMT
Analyze problems
Iub bandwidth
RNC/NodeB LMT
Analyze problems
Downlink carrier
transmission power
and non-HSDPA
carrier transmission
power
RNC LMT
Downlink throughput
and bandwidth
RNC LMT
Dowlink traffic
RNC LMT
Analyze problems
In PS service test, to reduce the impact from TCP receiver window of application layer, using multithread 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 Operations Guide.
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
States of NEs
FlashGet
DU Meter
1.
Da
ta
Tools
for
collecti
ng data
Tools
for
viewin
g/
analyzi
ng data
Tools for
collecting data
Effe
ct
Rema
rk
Traffic
statistics data
M2000
Nastar
Check the
network
operation
conditions
macroscopicall
y, analyze
whether there
are abnormal
NEs.
For detailed
operations on
LMT, see WEquipment Room
Operations
Guide. For usage
of Nastar, see the
online help and
operation manual
of Nastar.
DT/CQT data
Probe + UE
Assistant
See W-Test
Guide.
Connection
performance
measurement,
RNC LMT
Assistant or RNC
LMT
Analyze calls
in terms of
flow and
coverage based
on DT/CQT
data and traced
Da
ta
Tools
for
collecti
ng data
Tools
for
viewin
g/
analyzi
ng data
cell
performance
measurement,
signaling
tracing by
RNC
Effe
ct
Rema
rk
data on RNC
Alarm
M2000 or RNC
LMT
M2000 or RNC
LMT
Check alarms
whether there
are abnormal
NEs
CHR
RNC LMT
Nastar or RNC
Insight Plus
Record historic
record of
abnormal calls
for all
subscribers,
help to locate
problems. For
subscribers'
complaints,
analyzing CHR
helps to find
the problem
happening to
subscribers.
None
FlashGet
None
Downlink with
multiple
threads to
obtain more
stable
throughput
None
DU Meter
None
Observe
throughput of
Da
ta
Tools
for
collecti
ng data
Tools
for
viewin
g/
analyzi
ng data
Effe
ct
Rema
rk
application
layer real-time,
take statistics
of total
throughput,
average
throughput, and
peak
throughput in a
period (the
result is
recorded by
PrintScreen
shot).
PS data packet
Sniffer
Sniffer
Construct
stable uplink
and downlink
data
transmission
requirement.
Used by CN
engineers. For
usage, see
appendix.
PS data packet
Ethereal
Ethereal
Sniff data
packet at
interfaces and
parse data
packet
Used by CN
engineers. For
usage, see
appendix.
Note: 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.
Description
4.1
4.2
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.
1.
Measured
item
Overall performance
measurement of
RNC/RLC statistics
measurement
Major indexes
Overall performance
measurement of
RNC/UE state
RLC buffer
size
Average
utilization of
buffer
Number of
data packets
sent and
received by
RLC in
TM/AM/UM
mode
Number of
data packets
dropped by
RLC
Number of
retransmitted
data packets
Measured items
related to PS
throughput in
overall
performance
measurement of
RNC
Effect
Check
whether the
RLC buffer
is
inadequate
Check the
probability
of dropping
data
packets by
RLC
Or whether
the
downlink
retransmissi
on rate is
over high
Measured
item
Major indexes
Effect
measurement
Overall performance
measurement of
RNC/RB
measurement
Overall performance
measurement of
RNC/RNC traffic
measurement
Overall performance
measurement of
RNC/PS inter-RAT
handover
measurement
Number of
conversation
al service,
streaming
service,
interactive
service, and
background
service in
various
uplink and
downlink
rates in PS
domain
under RNC
Analyze the
number of
subscribers
using
different
services at
different
rate;
Analyze the
call drop
problems of
various rate
Times of
abnormal call
drops for
previous
services in
various rate
in PS domain
Times of
successful/fai
lure PS interRAT
handovers
The failure
causes
4.1 lists the measured items related to PS throughput in cell performance measurement.
2.
Measured
item
Major indexes
Measured items
related to PS
throughput in cell
performance
measurement
Effect
Cell
measurement/traffic
measurement
Cell
measurement/cell
algorithm
measurement
Cell
measurement/cell
RLC measurement
Cell
measurement/cell
throughput of
Number of
signaling
PDUs
Number of
retransmitte
d PDUs
Number of
discarded
PDUs
Take
statistics
of valid
data rate
at RLC
layer
The
transmissi
on rate of
service
and
signaling
The
dropping
rate
Obtain the
average
throughpu
various services,
throughput t
measurement
t of
various
services
in the cell.
Cell
measurement/BLER
measurement of
various services in
cell
Cell
measurement/Iub
interface
measurement
Judge
whether
the
average
throughpu
t meets
the
optimizati
on
objectives
Uplink
average
BLER of
various
services in
cell
The ratio of
time of
maximum
value of
BLER
Number of
requested
RLs at Iub
interface
Number of
successful
RLs
Number of
failed RLs,
Different
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.
Table 4-3 lists the measured items related to HSDPA throughput (cell measurement).
3.
Measured
item
Cell
measurement/HSDPA
service measurement
Major indexes
Statistics of
HSDPA
service
setup and
deletion
Number of
HSDPA
subscribers
in cell
D-H, F-H
transition
Serving cell
update
Intrafrequency
HHO
Interfrequency
HHO
MAC-D
flow
throughput
Measured items
related to
HSDPA
throughput (cell
measurement)
Effect
Know the
HSDPA
throughput and
number of
subscribers in
cell
Table 4-4 lists the measured items related to HSDPA throughput (cell measurement).Measured items
4. related to
HSUPA
throughput (cell
measurement)
Measured
item
Cell
measurement/HSDPA
service measurement
Major indexes
Measured item
HSUPA.CELL include
the PI of service setup ,
release and the number of
EDCH handover
Effect
5.
Measured
item
Performance
measurement at Iu
interface
Major
indexes
GTP-U measurement
Effect
Determine the
scope of
problems by
comparing
RLC layer
traffic and
GTP-U traffic
Distinguish
RAN side
problems from
CN side
problems
Number of bytes
sent and received
by GTP-U
UNI LINK
Average receiving
and sending rate of
Other measured
items related to
throughput
measurement
UNI LINK
IMA LINK
measurement
Average receiving
and sending rate of
IMA LINK
Average receiving
and sending rate of
IMA GROUP
GTP-U 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.
1.
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.
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 4.2.2 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.
1.
Measured
item
Cell measurement
Cell
measurement/HSDPA
service measurement
Type
Indexes to judge
whether a cell has
PS service
request
Index
Number of
successful
RABs with
RAB
assignment
setup in PS
domain in cell
VS.RAB.AttEstabPS.Conv
Times of
HSDPA service
setup requests in
cell
VS.HSDPA.RAB.AttEstab
VS.RAB.AttEstabPS.Str
VS.RAB.AttEstabPS.Inter
VS.RAB.AttEstabPS.Bkg
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.
14.2.2 describes the cell measurement/cell algorithm measurement analysis.
2.
Index
VS.LCC.BasicCongNumUL
Meani
ng
Analys
is
Cell
measurement/cell
algorithm
measurement
analysis
Soluti
on
Times of uplink
and downlink
basic congestion
in cell
If one of them is
large than 0, the
cell is with basic
congestion
problem
If the load of
inter-frequency
cells with
overlapped
coverage is low,
optimize load
balance
parameters.
Otherwise
consider adding
carriers.
VS.LCC.OverCongNumUL
VS.LCC.OverCongNumDL
Times of cell
congestion due to
uplink and
downlink overload
If one of them is
large than 0, the
cell must be badly
congested
If the load of
inter-frequency
cells with same
coverage is low,
optimize load
balance
parameters.
Otherwise
consider adding
carriers.
VS.DCCC.D2D.SuccRateDown.
UE
Times of
successful
configuration of
DCH dynamic
channel with
decreasing
downlink rate in
cell
If the average
service throughput
is much lower
than the
bandwidth, the
DCCC algorithm
parameter may be
irrational.
Confirm the
DCCC algorithm
parameter
Length of
unavailable time
If it is large than
0, the cell must
have been
VS.LCC.BasicCongNumDL
VS.DCCC.D2D.SuccRateUp.UE
VS.Cell.UnavailTime.OM
of cell
unavailable.
abnormalities
3.
Index
VS.IUB.AttRLSetup
VS.IUB.SuccRLSetup
Meani
ng
Number of
requested RLs set
up at lub interface
in cell.
Number of
successful RLs
set up at lub
interface in cell.
VS.IUB.FailRLSetup.CfgUn
sup
VS.IUB.FailRLSetup.Cong
VS.IUB.FailRLSetup.HW
VS.DL.RL.Timing.Adjust.F
ail
If SuccRLSetup <
AttRLSetup, the RL
setup must have failed
at lub interface. Analyze
the problem for detailed
causes.
Number of RLs
failed at lub
interface due to
different causes
in cell
Number of
downlink RLs of
successful and
failed RLs of
timing adjustment
in cell
VS.IUB.FailRLSetup.OM
VS.DL.RL.Timing.Adjust.S
ucc
Analysis
If the
VS.IUB.FailRLSetup.C
ong is large than 0, the
lub interface is probably
congested.
Analysis of cell
performance/Iub
interface
measurement
Soluti
on
4.
Index
Meani
ng
Analys
is
VS.RLC.AM.TrfPDU.Trans
Number of PDUs
sent by RLC in
AM mode
VS.RLC.AM.TrfPDU.Retrans
Number of service
PDUs
retransmitted by
RLC in downlink
in AM mode
Service
retransmission
rate = number of
PDUs for
retransmission
service/number of
sent service
PDUs. If the
retransmission
rate is high, there
may be some
problems.
VS.AM.RLC.DISCARD.TRF.P
DU
Number of service
PDUs dropped by
RLC in downlink
in AM mode of
cell
Dropping rate =
number of
dropped service
PDUs/number of
sent service
PDUs. If the PDU
drop rate is high,
there may be some
problems.
Cell
Measurement/Cel
l RLC
Measurement
Analysis
Soluti
on
VS.RLC.AM.SigPDU.Trans
Number of
signaling PDUs
sent by RLC in
AM mode
VS.RLC.AM.SigPDU.Retrans
Number of
signaling PDUs
retransmitted by
RLC in downlink
in AM mode
Signaling
retransmission
rate = number of
retransmitted
signaling
PDUs/number of
sent signaling
PDUs
VS.AM.RLC.DISCARD.SIG.P
DU
Number of
signaling PDUs
dropped by RLC
in downlink in
AM mode of cell
Signaling
dropping rate =
number of
dropped signaling
PDUs/number of
sent signaling
PDUs
The causes of high RLC retransmission rate and PDU packet dropping rate are:
Clock abnormality
To confirm weak coverage problem, perform DT/CQT and analyze CHR as below:
Analyze CHR to know the RSCP and Ec/Io of subscribers in the environment
Description
5.1
Access Failure
5.2
5.3
5.4
WCDMA PS service data transfer problems include the following three types in terms of phenomena:
For the problem with different phenomena, follow different flows for processing them.
1. 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.
1. Access Failure
There are two ways to use PS services:
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.
2.
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:
2. UE as the Modem of PC
5.1.2 shows the flow for analyzing access problem when the UE serves as the modem of PC.
1.
2.
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.
3.
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 TrainingSignaling Flow.
5.1.2 shows the signaling flow of successful setup of a PS service in Probe.
4.
Signaling flow of
successful setup of a PS
service in Probe
In 5.1.2, 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:
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.6.
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.9.
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-KPI Monitoring and Improvement Guide.
Others
See 5.3.2. Shrink the scope of the problem by changing each device.
1.
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
5.2.1 shows the flow for analyzing RAN side problem about disconnection of service plane for DCH
bearer.
2.
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:
Connection Performance
Measurement-Downlink
Throughput and
Bandwidth window
In 5.2.1,
Further
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:
CQI
The UE estimates and reports CQI based on PCPICH Ec/Nt.
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.
HSDPA parameters in
Probe
Number of HS-SCCHs
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.
The CQI reported by UE is over low, so the NodeB will not schedule the
subscriber.
HS-DSCH SBLER-Deta
HS-DSCH SBLER-Average
Wherein, the Delta 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.
1.
Confirm by other access network or LAN that the service software servers and service software run
normally.
LAN
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.
Low rate
The poor performance of data transfer, in terms of QoS, lies in the following problems:
Buffering
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
The applications and service software problems are contained in the CN side problems. 5.3 shows the
flow for analyzing poor performance of data transfer.
1.
1. 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.2. By comparing operations and
analyzing problem, reduce the scope of problem.
If the problem concerns both the RAN and CN side, analyze it from both
sides.
1. Comparing
operations and
analyzing
problem
Order
Operation
Change PC
Result
Analysis
Data transfer
problem has been
solved
Problem maybe
related to user
information
configured in the
USIM card.
Data transfer
problem is still
unsettled
Data transfer
problem has been
solved
Data transfer
problem is still
unsettled
Data transfer
problem has been
solved
Related to drivers,
APN, restricted
rate, and firewall.
Data transfer
problem is still
Order
Operation
Result
Analysis
unsettled
continue checks.
Data transfer
problem has been
solved
The problem at CN
side, related to
service software
Data transfer
problem is still
unsettled
Change a new
website for visiting
(from other
websites)
Data transfer
problem has been
solved
The problem at CN
side, related to
performance of
server, TCP/IP
parameters, or
service software
Data transfer
problem is still
unsettled
Data transfer
problem has been
solved
The problem at
RAN side.
Data transfer
problem is still
unsettled
Data transfer
problem has been
solved
The NodeB
problem, or
improper
configuration of
parameters related
to the NodeB and
configured by RNC
Data transfer
Test on other
NodeBs
Order
Operation
Result
problem is still
unsettled
Analysis
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.
1.
NE Alarms
Alarm check
When PS services are carried by DCH, the factors affecting data transfer at
Uu interface includes:
DCH bandwidth
State transition
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.
Obtain CHR from BAM and check the abnormalities on RNC INSIGHT
PLUS or Nastar.
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 MeasurementUplink 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.
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.
3.
Querying the bandwidth at Iub interface on RNC LMT and NodeB LMT.
Referring to the section Flow for Analyzing Cell-level Traffic Statistics Data.
Query adjacent node corresponding to each cell by executing the command LST AAL2ADJNODE
Query the path of the NodeB by executing the command LST AAL2PATH.
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.
Subscribed rate
When there are multiple subscribers, besides previous factors, the scheduling algorithm used by
NodeB and number of HS-SCCH configured to cell affects 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 NodeB sends HS-DSCH parameters on HS-SCCH, and after two slots it
sends data on HS-DSCH.
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 RateServed RateMAC Layer
Rate.
Served 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.
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
5.3.4 shows the flow for analyzing poor performance of data transfer on HSDPA at RAN side.
1.
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 Operations
Guide.
2.
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 5.3.4.
3.
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.
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.
1.
C
Q
I
va
lu
e
Trans
port
Block
Size
Nu
mbe
r of
HSPDS
CH
Relationship
between CQI and
TB size when the
UE is in category
1112
Modul
ation
Referen
ce
power
adjustm
ent
N/A
Out of range
137
QPSK
173
QPSK
233
QPSK
317
QPSK
377
QPSK
461
QPSK
650
QPSK
792
QPSK
C
Q
I
va
lu
e
Trans
port
Block
Size
Nu
mbe
r of
HSPDS
CH
Modul
ation
Referen
ce
power
adjustm
ent
931
QPSK
10
1262
QPSK
11
1483
QPSK
12
1742
QPSK
13
2279
QPSK
14
2583
QPSK
15
3319
QPSK
16
3319
QPSK
17
3319
QPSK
18
3319
QPSK
19
3319
QPSK
20
3319
QPSK
21
3319
QPSK
22
3319
QPSK
23
3319
QPSK
C
Q
I
va
lu
e
Trans
port
Block
Size
Nu
mbe
r of
HSPDS
CH
Modul
ation
Referen
ce
power
adjustm
ent
24
3319
QPSK
25
3319
QPSK
10
26
3319
QPSK
11
27
3319
QPSK
12
28
3319
QPSK
13
29
3319
QPSK
14
30
3319
QPSK
15
2. Relationship
between CQI and
TB size when the
UE is at the level
16
C
Q
I
va
lu
e
Trans
port
Block
Size
Nu
mbe
r of
HSPDS
CH
N/A
Out of range
137
Modula
tion
QPSK
Refere
nce
power
adjust
ment
C
Q
I
va
lu
e
Trans
port
Block
Size
Nu
mbe
r of
HSPDS
CH
Modula
tion
Refere
nce
power
adjust
ment
173
QPSK
233
QPSK
317
QPSK
377
QPSK
461
QPSK
650
QPSK
792
QPSK
931
QPSK
10
1262
QPSK
11
1483
QPSK
12
1742
QPSK
13
2279
QPSK
14
2583
QPSK
15
3319
QPSK
16
3565
16-QAM
C
Q
I
va
lu
e
Trans
port
Block
Size
Nu
mbe
r of
HSPDS
CH
Modula
tion
Refere
nce
power
adjust
ment
17
4189
16-QAM
18
4664
16-QAM
19
5287
16-QAM
20
5887
16-QAM
21
6554
16-QAM
22
7168
16-QAM
23
7168
16-QAM
24
7168
16-QAM
25
7168
16-QAM
26
7168
16-QAM
27
7168
16-QAM
28
7168
16-QAM
29
7168
16-QAM
30
7168
16-QAM
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:
Analyze the factors affecting available power of HSDPA cell from the
following aspects:
HSSCCH
power
offset
in nonSHO
period
HS-SCCH power
offset
HSSCCH
power
offset in
SHO
period
10.75
6.75
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
0 shows that HS-SCCH power control is based on CQI , which works like
this:
First set HS-SCCH initialization TX power
Then according to CQI change , adjust HS-SCCH power, like DCH innerloop power control.
At last , according to the ACK/NACK/DTX information from HSDPCCHs feedback ,adjust HS-SCCH power , like DCH outer-loop power
control.
The parameter of the power control which base on CQIs HS-SCCH : HSSCCHs initial power , Default is 28(-3 dBm), relative to pilot power ; HSSCCH power controls aim FER , Default is 10%(1%)
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 HSSCCH 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:
Scheduling algorithm
Using different scheduling algorithm for multiple subscribers enables each
subscriber to be scheduled at different probability. For example, after Max
C/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:
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
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 HSSCCH must be low.
Execute AT commands as below:
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
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;
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 23 lower than before, and is 2223.
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 23 lower than before, and is 2728.
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.
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 over high SBLER, and consequently the throughput is
affected.
Before RLC dont receive affirm package , the most number PDU which can be send is RLC send
window . the more betimes send point receive affirm information , the faster the window slip. The
faster RLC can send. Whereas , the slower RLC can send . even appear RLC replacement result in
drop call.
If Scheduled RateServed Rate and MAC Layer Rate is normal , it need more adjust whether RLC
Throughput is normal.
The relationship between RLC Throughput andMAC Layer Rate:
RLC Throughput=MAC Layer Rate * (1-MAC-HS PDUs caput spending rate)
Because PDUs caput spending rate is small , watch RLC Throughput and MAC Layer Rate from
Probe, the curve superposition
If RLC Throughput obvious less than MAC Layer Rate, it is abnormal.
In the WCDMA HSDPA Decoding Statistics window, you can see ACK>NACK/DTX. In , ACK->NACK/DTX is 76.01%. The right pane displays
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
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.
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 over high, 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%.
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.
In V17 edition, when R99 new operation connect, Max-rate multiply
activation gene as operation rate to admittance. So if you want to adjust
activation gene, you can adjust connection number . if configure activation
gene is small , it can connect more connection , but multi-connection whit
high rate will bring lub congestion, result in R99 PS or HSDPA PS lose
package , touch off a lot of RLC send again , consequently, R99 PS or
HSDPA PS RLC layer rate astaticism.
Solution: open lub overbooking flow control switch which base on RLC
retransmission rate. If discover R99 or HSDPA PS retransmission rate
exceed the gateway which set before , initiate R99 PS TF limit fall quickly
or HSDPA PS PS rate * fall coefficient , lighten or eliminate congestion.
In RLC retransmission rate under gateway , cancel TF limit , renew R99
PS transmit rate , or HSDPA PS rate * rise coefficient , renew HSDPA PS
transmit rate.
Over high RLC retransmission rate due to over high 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 over high, the
SBLER at MAC layer is probably over high. For detailed analysis, see the
analysis of over high 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.
6.
HSDPA Decoding
Statistics window
The RTT delay at the RLC layer is exceptional (the RLC state report disable
timer is not set properly/the uplink BLER is not converged) so that the RLC
send window is full.
Currently, the maximum size of the RLC send window can be set to 2047
(the RLC receive/send window size of the terminal is 2047). When the
RLC transmission rate is very high, the RLC send window is easily full
and cannot send other data if the state report is not returned in time.
For example, the rate on the air interface is 3 Mbit/s and the MAC-D PDU
size is 336 bits, the RLC send window can send data for (2047 x 336)/(3 x
1024) = 224 ms. If the RNC fails to receive a state report within 224 ms,
the RLC send window is full.
The return time of the state report is related to the state report disable timer
and the uplink air interface quality. If the state report disable time is set too
long, or the uplink BLER is not converged, the RLC send window may be
full.
Solution:
Check whether the state report disable timer is set properly and whether it
is set to the default of the baseline. Currently, the default timer length is
120 ms (service-oriented configuration) in the RNC V16 and 80 ms for the
3.6 Mbit/s services (service-oriented configuration) in the RNC V17.
Check the convergence of the uplink BLER to ensure the BLER is
converged.
Compare the throughputs at the application layer (APP) and the RLC layer.
TCP/IP adopts the inclusive acknowledgment strategy for reliable data
transmission and the sliding window protocol for flow control, and
performs congestion control when detecting a network congestion.
Therefore, the factors affecting the TCP/IP data transmission rate include:
Configured TCP receive/send window
Although the receive window size is dynamic (if packets out of
sequence are received or packets cannot be submitted to the upper layer
in time, the available window size becomes small), the configured
The NodeB determines the granted level (the E-AGCH sends T/P and the ERGCH sends an adjust command to tune (+1, 0 -1)) according to the UE
request (SI), monitored RoT, and the satisfaction (Happy bit indication
carried on the E-DPCCH) from the UE.
After receiving and demodulating the data, the NodeB returns an AcK/Nack
on the E-HICH.
1. Working process of an
HSUPA UE
During the optimization of the HSUPA throughput, you should combine the drive test data of the
Probe tool for analysis. The following describes HSUPA-related rates in the Probe tool:
MAC-e PDU Non-DTX Rate = Sum of all TB sizes in the case of nonDTX/(number of non-DTXs * TTI)
This rate is the actual rate of the MAC-e (excluding DTX, but including
the rate of retransmission blocks)
Sum of all TB sizes in the case of non-DTX: Not only the block transmitted first but also the
retransmitted blocks are included.
Number of non-DTXs * TTI: Only the time when data is transmitted is counted and the time when no
data is transmitted is excluded. For example, if only 50 sub-frames send data within the measurement
period of 100 sub-frames (200 ms), the denominator is 100 ms.
MAC-e PDU Served Rate = Sum of all TB sizes in the case of nonDTX/(NUM_SAMPLES * TTI)
This rate is the served rate of the MAC-e (including DTX and the rate of
retransmission blocks)
Sum of all TB sizes in the case of non-DTX: Not only the block transmitted first but also the
retransmitted blocks are included.
NUM_SAMPLES * TTI: The time when data is transmitted and the time when no data is transmitted
are both included. For example, if only 50 sub-frames send data within the measurement period of 100
sub-frames (200 ms), the denominator is 200 ms.
Sum of TB sizes when COMB_HICH is ACK or ACK_NS in the case of non-DTX: Only the TBs
transmitted correctly are counted.
NUM_SAMPLES * TTI: The time when data is transmitted and the time when no data is transmitted
are both included.
UL RLC PDU Throughput = Sum of bits of all RLC PDUs sent by the RLC
layer within the measurement period/Measurement period duration
Sum of bits of all RLC PDUs sent by the RLC layer within the measurement period: The first
transmitted data and the retransmitted data are included. In addition, the data is transferred by MAC-d
and contains the header overhead (16 bits) of the RLC PDU.
Measurement period duration: The time when data is transmitted and the time when no data is
transmitted are both included.
A precise relationship should exclude the header overhead and the padding bits when the TB size does
not match N RLC PDU bits
UL RLC SDU Throughput = Sum of bits of all RLC SDUs sent by the RLC
layer within the measurement period/Measurement period duration
Sum of bits of all RLC SDUs sent by the RLC layer within the measurement period: Compared with the
sum of RLC PDU bits, the retransmitted data and header overhead (16 bits) of the RLC PDU are
excluded.
Measurement period duration: The time when data is transmitted and the time when no data is
transmitted are both included.
The figure below shows the optimization flow of a low throughput of the HSUPA UE.
2. Optimization flow of a
low throughput of the
HSUPA UE
You can also observe whether an SG is reported in the HSUPA Link Statistics window provided by a
drive test tool, for example, Probe. If no information is displayed in the window, the service is borne
on a DCH, as shown in the figure below.
If the service is not borne on the HSUPA, the service is automatically set up on a DCH. In this case,
the service rate is the rate of the R99 service, usually 384 Kpbs or below.
If the service is not set up on the HSUPA, you can make analysis in terms of the following aspects:
Check whether the capabilities reported by the UE include the HSUPA. The
RRC_CONN_REQUEST message reported by the UE indicates whether the
HSDPA and HSUPA are supported. The specific E-DCH capability level is
reported in an RRC_CONN_SETUP_CMP message.
Check whether the MBR in the subscription information in the previous line
is normal and whether the rate threshold over an E-DCH is set too high. If the
MBR assigned by the CN does not exceed the rate threshold over an E-DCH,
the service is set up on a DCH.
If the MAC-e PDU Non-DTX Rate is abnormal, use the drive test tool Probe to determine whether the
UE reports HAPPY or UNHAPPY.
If the UE reports HAPPY and the UE rate cannot reach the MBR, the possible causes are as follows:
If the UE reports UNHAPPY and the UE rate cannot reach the MBR, the possible causes are as
follows:
The resources (air interface load, IUB bandwidth, and CE) on the RAN side
are limited.
Cause 1: The air interface load is limited.
Cause 2: The IUB bandwidth is limited.
The protocol gives the conditions when the UE report HAPPY and UNHAPPY.
The UE indicates that it is unhappy if the following criteria are met:
The first criteria are always true for a deactivated process and the ratio of the third criteria is always 1
for 10ms TTI.
Otherwise, the UE indicates that it is happy.
Principle description
Currently, the capability of Qualcomm HSUPA and Huawei E270 HSUPA
is CAT5 (the corresponding MAC-e rate is 2 Mbit/s). The maximum
capability supported by Huawei RAN6.0 (RNCV1.8 and NodeBV1.8) is 2
x SF4 (the corresponding MAC-e rate is 1.4484 Mbit/s). Currently, the
maximum rate that a single UE can obtain is limited to the capability of the
RAN6.0.
The RAN6.0 supports 2 x SF4, the maximum TB size is 14484), and the
MAC-e PDU Non-DTX Rate is 14484/10 = 1.4484 Mbit/s
The CAT5 terminal supports 2 x SF2, the maximum TB size is 20000, and
the MAC-e PDU Non-DTX Rate is 20000/10 = 2 Mbit/s.
1. Categories of UE
HSUPA
capability levels
E-DCH
Category
Maximum
Number of
E-DCH
Codes
Transmitted
Minimum
Spreading
Factor
Support
for 10
and 2
ms TTI
EDCH
Maximum
Number of
Bits of an EDCH
Transport
Block
Transmitted
Within a 10
ms E-DCH
TTI
Ma
Num
Bits
DC
Tra
Blo
Tra
Wit
ms
TTI
y1
SF4
10 ms TTI only
7110
y2
SF4
10 ms and
14484
2798
2 ms TTI
y3
SF4
10 ms TTI only
14484
y4
SF2
10 ms and
20000
5772
20000
y5
2 ms TTI
2
SF2
10 ms TTI only
y6
SF2
10 ms and
20000
2 ms TTI
When 4 codes are transmitted in parallel, two codes shall be transmitted with SF2 and two with SF4
Observation method:
Observe the UE capability
Generally, the terminals supporting the HSUPA function all support the
HSDPA function. That is, the HSPA bears the services of users as a
whole. The following describes how to observe the HSPA function that
the UE supports and the specific HS-DSCH/E-DCH capability level in
combination with actual RRC messages.
First, the RRC_CONN_REQUEST message reported by the UE
indicates whether the HSDPA and the HSUPA functions are supported.
In the figure below, the capability reported by the UE indicates that the
UE supports HS-DSCH and E-DCH.
11484
5. RRC CONNECTION
REQUEST message
6. RRC CONNECT
SETUP CMP message
7. RL RECFG PREPARE
message
When the DCCC algorithm of the HSUPA is disabled, the RNC configures the maximum capability
according to the MBR of the UE. When the DCCC algorithm of the HSUPA is enabled, the
maximum capability is affected by the initial access rate of the DCCC.
Solution:
Improve the capability of the RAN side or use a terminal with a higher
capability level.
Principle description
The UE calculates the transmit TB size according to the currently available
transmit power. Then, the UE selects the smaller between the TB size
supported by the transmit power and the TB size supported by the SG as
the actual transmit TB size.
The available transmit power of the UE is the same, but the transmit TB
size may be not the same. The factors that influence the TB size are as
follows:
The UE is at the edge of a cell and the uplink path loss is large.
The uplink load of the cell is high (the UE is not at the edge of a cell).
The UE performs combined services. The DCH service consumes much
power and insufficient power is available to the E-DCH service.
Observation method:
Method of observing whether the transmit power of the UE limited:
Observe the power limited rate reported by the UE through the Assistant. If
the power limited rate is greater than 0%, the transmit power of the UE within
the corresponding measurement period of the measurement value is limited.
8. Display of the Assistant
HSUPA related
information (limited
transmit power of the
UE)
When the UE uses the maximum block (14480), Qualcomm chips of early versions also display the
limited transmit power, but in fact, the transmit power is not limited. This problem can be ruled out
by combining the current MAC-e PDU Non-DTX Rate with the actual transmit power of the UE.
After confirming that the transmit power of the UE is limited, analyze the
limitation causes.
a.View the PCPICH RSCP of the cell where the UE is located and
check whether the UE is at the edge of the cell.
b.View the RTWP of the cell where the UE is located before the access
and check whether the uplink load of the cell is high.
c.View the uplink SIR of the UE to check whether the SIR is
exceptionally high.
d.View the service that the UE sets up and check whether the service is
a combined service.
Solution:
If the UE is at the edge of the cell, move the UE to the center of the cell.
If the uplink load of the cell is high and the cell load is adjustable, reduce the
cell load.
If the service that the UE sets up is a combined service, deactivate the R99
service and observe the rate of the HSUPA service.
Principle description:
If the data in the UE RLC Buffer is insufficient, the actual MAC-e PDU
Non-DTX Rate is low.
Observation method:
Solution:
You can consider sending packets in the uplink to eliminate the effect of
the TCP mechanism. If this method does not work, check whether the
problem about packet loss exists on the RAN side.
In addition, some applications in the portable PC also affect the data
transmission. In this case, replace the portable PC. If the problem still
exists, use a tool to capture packets and locate the exceptions between the
portal PC and the UE.
When the actual cell load is greater than the target value, the cell
throughput can be reduced by lowering the SG of the UE. When the
actual cell load is less than the target value, the cell throughput can be
improved by increasing the SG of the unhappy UE.
[Basic function 2]: Limit the MBR of a single UE
When the actual value of the MAC-e rate (including retransmitted
blocks) is greater than the MBR, an RG Down is sent to the UE to
Principle description:
1) According to basic function 1 of the HSUPA scheduling, when the
air interface load on the RAN side is limited, the target load value is the
target value configured on the RNC (this value is usually determined at
the time of network planning). If the actual value of the cell load
exceeds the target value, the uplink coverage of the cell may shrink (the
shrinkage depends on the uplink budget margin) and the service at the
edge of the cell is affected. Therefore, the cell load needs to be
controlled.
2) RNC-related parameter configuration
The RNC-related parameters include MaxTargetUlLoadFactor and
BackgroundNoise.
MaxTargetUlLoadFactor is the target ROT. Related command: MOD
CELLHSUPA MaxTargetUlLoadFactor=75 (75 represents 75%,
namely, 6 dB)
BackgroundNoise is the background noise. Related command: MOD
CELLCAC: BackgroundNoise=71 (71 represents 112 + 7.1 = 104.9
dBm)
The target RTWP is calculated according to the following formula:
Target RTWP = Target ROT + Background Noise.
Hence, the target RTWP = 104.9 + 6 = 98.9 dBm
3) The RNC sends a message to the NodeB.
The RNC carries the target RTWP and the background noise to the
NodeB by sending a PHYSICAL SHARED CHANNEL
RECONFIGURATION REQUEST message on the Iub interface.
The relationship between the protocol value and the physical value is:
physical value = 112 + protocol value/10 (unit: dBm)
As shown in the figure below, the protocol value of the target RTWP is
114, the corresponding physical value is 112 + 11.4 = 100.6 dBm.
The background noise of the RTWP is 54 and the corresponding
physical value of the background noise is 112 + 5.4 = 106.6 dBm.
10. PHYSICAL SHARED
CHANNEL
RECONFIGURATION
REQUEST message
(containing the target
RTWP and the
background)
The disagreement of the background set on the RNC LMT with the cell
background affects the throughput of the cell. If the setting value of the
background noise is much larger than the actual background noise
value, the system stability may be reduced.
When the setting value of the background noise is greater than the
actual background noise value, the actual cell throughput is greater than
the throughput that the target ROT corresponds to.
When the setting value of the background noise is less than the actual
background noise value, the actual cell throughput is less than the
throughput that the target ROT corresponds to.
Observation method:
Solution:
1) Set the target ROT reasonably.
2) Keep the setting value of the background noise equal to the actual
background noise value.
The background noise update algorithm has not been commercially
verified. It will be subsequently supplemented.
3) Eliminate external interference.
Principle description:
1) According to basic function 1 of the HSUPA scheduling, when the
available bandwidth of the Iub HSUPA is limited on the RAN side, the
target load is the adjusted target value after flow control (principle of
the Iub flow control: adjust the target load according to the buffer
change trend on the transmission path). If the actual cell load exceeds
the target load value, the data transmission delay is prolonged or even
packet loss occurs on the Iub interface so that the data transmission
performance is affected. Therefore, the actual cell load needs to be
controlled.
2) When the ATM is adopted on the Iub interface, the HSUPA Iub
bandwidth utilization = TCP layer rate/ATM bandwidth
When the TCP layer rate is less than 320 kbit/s, the utilization is less
than 73%.
When the TCP layer rate ranges from 320 kbit/s to 736 kbit/s, the
utilization is 74% or so.
When the TCP layer rate ranges from 768 kbit/s to 1376 kbit/s, the
utilization is 75% or so.
3) When the IP is adopted on the Iub interface, the HSUPA Iub
bandwidth utilization = TCP layer rate/IP bandwidth
When the TCP layer rate is less than 224 kbit/s, the utilization is less
than 80%.
When the TCP layer rate ranges from 224 kbit/s to 448 kbit/s, the
utilization is 80% to 85%.
When the TCP layer rate ranges from 480 kbit/s to 1376 kbit/s, the
utilization is 85% to 90%.
Observation method:
Since the Iub bandwidth is shared by all cells of a NodeB, you need to
obtain the rate information of all HSUPA UEs of the NodeB when
determining whether the Iub bandwidth is limited.
Principle description:
When the NodeB CE resources on the RAN side are limited, the
dynamic CE adjustment algorithm (not implemented in NodeB V18 but
implemented in later versions) reduces the MBR of the UEs or the
minimum available SF.
Observation method:
Solution:
Add CEs.
Principle description:
The RNC combines the MBR in the RAB Assignment Request message
with the UE capability and the resources on the RAN side to obtain an
MBR for the final service setup. This MBR is called RNC MBR.
NodeB MBR: MAC-e PDU rate (including retransmitted blocks)
The RNC notifies the NodeB of the NodeB MBR in an RL RECFG
PREPARE message.
14. RL RECFG PREPARE
message (containing
NodeB MBR)
UE MBR:
HsupaMaxRateUpScale
Requested
rate up
scale for
the
HSUPA
service
step of 0.1
Physical unit: None
Content: The value of this parameter
times the uplink maximum rate in an
RAM Assignment Request message is
the peak rate when the service is borne
on an E-DCH. The RNC configures the
bottom-layer bandwidth for the UU
interface and IUB interface according to
the peak rate. The configuration of this
parameter is related to the target number
of service retransmissions on the EDCH.
Recommended value: 11
Observation method:
Step1: Obtain the uplink rate (IP layer rate) of the UE from a DU meter and
UE MAC-e PDU Served rate from the Assistant.
Step 2: Obtain the CN MBR from the RAM Assignment Request message,
the RNC MBR from the typical rate configuration in the RNC MML
command, and the NodeB MBR from the RL RECFG PREP message.
Solution:
To improve the throughput of a UE, modify the subscription information
and configure a higher MBR.
Cause 1: The SG is not updated because the CRC of the AG value fails
Principle description:
According to the AG, the UE updates the SG that it maintains. If an AG
reception error (CRC failure) occurs, the SG maintained by the UE is
incorrect.
There are two possible causes for the AG reception error:
1) The E-AGCH power in the position where the UE is located is low.
Huawei RNC provides two power control modes for the HSUPA
downlink control channels (including E-RGCH, E-AGCH, and EHICH).
Power control mode 1: Fixed transmit power relative to the PCPICH. In
this mode, each channel adopts a fixed power and all UEs use the same
power. This is equivalent to "no power control".
Power control mode 2: Power control for UE based on the DPCH
transmit power. Since each UE is assigned with its own E-RGCH and
E-HICH and signaling can be sent to only one UE on the E-AGCH at a
specific time, the downlink control channel of the HSUPA can
separately perform power control for each UE.
2) The quality of the E-AGCH signals at the receiving end is high but
the UE has bugs so that demodulation errors occur.
Observation method:
For cause 1:
Step 1: Confirm the current power control mode by using an MML
query command.
COMMAND: LST MACEPARA (NodeB LMT)
Step 2: If the power control mode is fixed transmit power relative to the
PCPICH (default algorithm in V18), check whether the parameters used
by the system are baseline parameters.
If not, change the parameters to the baseline parameters and observe
whether the problem is solved. If the problem is not solved, confirm the
pilot signal quality (PCPICH RSCP and Ec/Io) in the position where the
UE is located. The baseline parameters are set on the assumption that a
signal Ec/Io is given at the edge of the cell. If the actual signal Ec/Io at
the edge of the cell is less than the assumed value, increase the power
offset (PO) on the basis of the baseline parameters.
1. PO for the EAGCH when the
Ec/Io at the edge
of cells is 12 dB
Control
channel
E-AGCH
Scenario
Power Offset
(dB)
None
11.2 dB
If the actual signals at the edge of the cell in a scenario are worse, the
Ec/Io decreases by 1 dB and the PO of each channel increases by 1 dB.
Compare the AG received by the UE with the one sent by the NodeB
(the latter can be obtained from the NodeB scheduling debugging
information file).
It is forbidden to use the NodeB debugging management system in a commercial network.
Solution:
For cause 1, increase the PO of the E-AGCH on the basis of the
baseline parameters according to the actual signal coverage quality at
the edge of the cell.
Principle description:
The UE updates the SG that it maintains based on the RG information.
If an RG reception error occurs, infer that the maintained SG is
incorrect.
The possible causes for a UE RG demodulation error are as follows:
1) The E-RGCH power in the position where the UE is located is low.
2) The E-RGCH power is sufficient, but the E-HICH ACK is
demodulated into RG UP owing to the E-HICH interference when RG
Hold is sent.
Observation method:
Make observations on the NodeB maintenance/debugging console.
For cause 1:
Step 1: Confirm the current power control mode by using an MML
query command.
COMMAND:LST MACEPARA (NodeB LMT)
Step 2: If the power control mode is fixed transmit power relative to the
PCPICH (default algorithm in V18), check whether the parameters used
by the system are baseline parameters.
Check whether the parameters used by the system are baseline
parameters. If not, change the parameters to the baseline parameters and
observe whether the problem is solved. If the problem is not solved,
confirm the pilot signal quality (PCPICH RSCP and Ec/Io) in the
position where the UE is located. The baseline parameters are set on the
assumption that a signal Ec/Io is given at the edge of the cell. If the
actual signal Ec/Io at the edge of the cell is less than the assumed value,
increase the PO on the basis of the baseline parameters.
2. PO for the ERGCH when the
E-RGCH
Scenario
Power Offset
(dB)
22
Non-serving E_DCH
RLS
17.3
If the actual signals at the edge of the cell in a scenario are worse, the
Ec/Io decreases by 1 dB and the PO of each channel increases by 1 dB.
Make comparison tests between NodeB and UE and ensure that the ERGCH power is properly set.
Step 3: If the power control mode is power control for UE based on the
DPCH transmit power (default algorithm in V22), no test experience is
available in V18 and test experience will be supplemented in later
versions.
For cause 2:
Cause 2 is caused by the signature used by the E-HICH and the ERGCH. A signature error exists in a NodeB test version. When the pilot
power is 33 dBm and HICH power is set to 33 21 = 12 dBm, AG
Hold is normally demodulated. When the HICH power is set to 13
dBm, AG Hold is occasionally demodulated into AG UP. When the
HICH power is set to 14 dBm, AG Hold is most demodulated into AG
UP. When the HICH power is set to 16 to 18 dBm, AG Hold is
basically all demodulated into AG UP.
Solution:
For cause 1, increase the PO of the E-RGCH on the basis of the baseline
parameters according to the actual signal coverage quality at the edge of
the cell.
For cause 2, rectify the product.
The RLC layer is exceptional so that RLC data is not sent in time.
The maximum uplink SIRtarget is set so low that the SBLER is high.
Principle description:
When the actual SBLER is greater than the target value, the uplink
outer power control of the HSUPA increases the value of the SIRtarget
so that the actual SBLER can be converged to the target value.
A maximum SIRtarget value is set on the RNC for the purpose of
exception prevention. When the SIRtarget required for power control is
greater than the maximum SIRtarget value, the maximum SIRtarget
value is used. That is, the SIRtarget value is truncated.
If the SIRtarget is set too small, the actual SBLER will be greater than
the target value.
Observation method:
Query the maximum SIRtarget that the system currently uses.
MML command: LST TYPRAB
Solution:
Step 1: Check whether the maximum SIRtarget is the default. If not,
change it to the default value and observe whether the problem is
solved.
Step 2: If the problem is not solved after the maximum SIRtarget is
changed to the default, check whether the outer loop power control
parameters (mainly including reference ETFCI, reference PO, and
target number of retransmissions) are set to the defaults. If not, change
the values of these parameters to the defaults and observe whether the
problem is solved.
Packet loss on the Iub interface causes a high SIRtarget but a low SBLER.
Principle description:
The statistics of the number of MAC-es PDU retransmissions for the
uplink outer loop power control in the version earlier than V18 involves
bit errors on the air interface and packet loss on the Iub interface. When
packet loss occurs on the Iub interface, the number of MAC-es PDU
retransmissions is larger than the target value. As a result, the SIRtarget
is high. In this case, the air interface quality is high, that is, the SBLER
observed from the UE is low.
The statistics of the number of MAC-es PDU retransmissions for the
uplink outer loop power control in the version later than V18 involves
only bit errors on the air interface, regardless of packet loss on the Iub
interface. Therefore, packet loss on the Iub interface does not affect the
performance of power control.
The possible causes for packet loss on the Iub interface are as follows:
1) The bottom-layer transmission is exceptional.
2) The Iub uplink transmission is configured incorrectly.
3) Transmission buffer overflows occur.
Observation method:
See "RLC SDU Throughput UL Exception Location".
Solution:
See "RLC SDU Throughput UL Exception Location".
Principle description:
The UE obtains ACK/NACK/DTX information by demodulating the EHICH. If ACK is taken for NACK or DTX, the UE performs a
retransmission. In this case, the SBLER measured on the UE side is greater
than the actual one and the effective rate is reduced.
If the E-HICH transmit power is low, the probability of demodulating
ACK into NACK or DTX is high.
There are two power control algorithms for the E-HICH: 1) Fixed transmit
power relative to the PCPICH. 2) Power control for UE based on the
DPCH transmit power.
Currently, the first algorithm (NodeB V1) is adopted. When the E-HICH
power offset is set low, the E-HICH demodulation performance of the UE
at the edge of a cell is affected.
When the UE is located in a soft handover cell, a soft combination is
performed for the E-HICHs in the same RLS, and the E-HICHs in the nonserving RLS can send ACK and DTX coming from the E-HICHs in
different RLSs.
Observation method:
Confirm the current power control mode by using an MML query
command.
LST MACEPARA
Solution:
Step 1: If the power control mode is fixed transmit power relative to the
PCPICH (default algorithm in V18), check whether the parameters used by
the system are baseline parameters.
If not, change the parameters to the baseline parameters and observe
whether the problem is solved. If the problem is not solved, confirm the
pilot signal quality (PCPICH RSCP and Ec/Io) in the position where the
UE is located. The baseline parameters are set on the assumption that a
signal Ec/Io is given at the edge of the cell. If the actual signal Ec/Io at
the edge of the cell is less than the assumed value, increase the Ec/Io on
the basis of the baseline parameters.
3. PO for the EHICH when the
Ec/Io at the edge
of cells is 12 dB
Control
Channel
E-HICH
Scenario
Power Offset
(dB)
Single link
21.2
21.2
12
If the actual signals at the edge of the cell in a scenario are worse, the
Ec/Io decreases by 1 dB and the PO of each channel increases by 1 dB.
Since the R&D personnel do not distinguish between two cases (single
link and RLS including serving_DCH cell) in the implementation of the
power control, the PO for a single link is the same as that for RLS
including serving E_DCH.
Make comparison tests between NodeB and UE and ensure that the EHICH power is properly set.
When performing a test, ensure that the uplink channel is in good
condition, disable the outer loop power control, and set the SIR to 11
dB. Construct a scenario without HARQ retransmissions so that the
NodeB sends HARQ_ACK all the time. Test the probability of
demodulating ACK into NACK from the UE side.
Step 2: If the power control mode is power control for UE based on the
DPCH transmit power (default algorithm in V22), no test experience is
available in V18 and test experience will be supplemented in later versions.
RLC transmission includes transparent transmission (TM), unacknowledgment mode (UM), and acknowledgment mode (AM). PS services
(FTP and HTTP) usually adopt the AM and the sequence in which the RLC
submits SDUs can be configured (sequential submission and non-sequential
submission) on the RNC LMT.
The sequential submission ensures that no packet loss occurs to the data
submitted to the upper-layer and the data is submitted in sequence. PS
services usually use TCP/IP. If packet loss happens at the upper layer, it may
lead to congestion and slow starting of TCP.. This affects the transmission
rate.
If MAC-e PDU Non-DTX Rate and MAC-e PDU Served Rate are both
normal, further determine whether the RLC PDU throughput UL and RLC
SDU throughput UL are exceptional.
Relationship between the RLC PDU throughput UL and the MAC-e PDU avaivable rate:
As the header overhead ratio is small, seen from the Probe, the RLC throughput curve and the MAC
layer rate curve are basically overlapped.
This relationship should be kept between RLC PDU throughput UL and MAC-e PDU available rate
all the time and no exception should occur.
Relationship between RLC SDU throughput UL and RLC PDU throughput UL:
For BE services, the uplink outer loop power control usually ensures that the RLC PDU
retransmission rate UL is 0% when only MAC-e PDU retransmission happens. Therefore, RLC SDU
throughput UL is approximate to the RLC PDU throughput UL * header overhead ratio of the RLC
PDU. Otherwise, an exception is considered, that is, the RLC retransmission high.
For time sensitive services such as VoIP over the HSUPA, to ensure the real-time of services, the
uplink outer loop power control ensures that the MAC-es PDU has a residual BLER. In this case, the
RLC PDU retransmission rate UL is approximate to the target residual BLER. Otherwise, an
exception is considered, that is, the RLC retransmission rate is not converged within the target value.
The version V18 supports only the BE services over the HSUPA. Therefore, the RLC retransmission
rate is usually required to approach 0.
Factors affecting the RLC SDU throughput UL:
The uplink packet loss on the air interface (MAC-e layer residual SBLER
>1%) causes a high RLC retransmission rate.
Principle description:
1) TBs are discarded if they are not received when the number of MACe layer retransmissions reaches the maximum. This is packet loss for the
RLC layer.
2) If the receiver at the RLC layer detects packet loss, it requires the
sender to retransmit the packet through a state report.
3) Data retransmission reduces the transmission efficiency of the RLC,
and further affects its efficient throughput.
Solution:
Principle description:
If the UE takes the NACK sent by the NodeB for ACK, the
corresponding TB is not retransmitted. As a result, a block error is
introduced at the RLC layer. The block error causes RLC
retransmission and affects the throughput.
The possible causes for a UE E-HICH demodulation error are as
follows:
The E-HICH power in the position where the UE is located is low.
Observation method:
See High Probability of Demodulating ACK into NACK/DTX.
Solution:
Principle description:
The exceptional bottom-layer transmission (for example, intermittent
failure of E1) causes uplink packet loss.
Observation method:
The packet loss in the uplink in this case can be observed only on the
RNC, instead of the NodeB.
Solution:
Observe whether there is any transmission alarm, solve any
transmission exception, and clear the alarm.
The uplink packet loss on the Iub interface (the uplink transmission of the Iub
interface is configured incorrectly) causes a high RLC retransmission rate.
Principle description:
The incorrect uplink transmission configuration on the Iub causes
uplink packet loss.
Observation method:
The packet loss in the uplink in this case can be observed only on the
RNC, instead of the NodeB.
Solution:
Check the configuration data of the transmission layer and ensure that
the configuration data is correct.
The uplink packet loss on the Iub interface (a transmission buffer overflow
occurs) causes a high RLC retransmission rate.
Principle description:
The untimely flow control on the Iub interface causes buffer overflows
and packet loss.
Observation method:
The packet loss in the uplink in this case can be observed through the
NodeB debugging console.
Solution:
Determine whether the flow control algorithm is exceptional.
The RLC layer fails to return an ACK in time (the RLC state report disable
timer is not set properly/the downlink BLER is not converged) so that the
RLC send window is full.
Principle description:
Currently, the maximum size of the RLC send window can be set to
2047 (the RLC receive/send window size of the terminal is 2047).
When the RLC transmission rate is very high, the RLC send window is
easily full and cannot send other data if the state report is not returned
in time.
For example, if the rate on the air interface is 1.4 Mbit/s and the RLC
PDU size is 336 bits, the RLC send window can send data for (2047 x
336)/(1.4 x 1000) = 491.28 ms. If the RNC fails to receive a state report
within 491.28 ms, the RLC send window is full.
The return time of the state report is related to the state report disable
timer and the uplink air interface quality. If the state report disable time
is set too long, or the uplink BLER is not converged, the RLC send
window may be full.
Observation method:
Currently, we have very limited means to observe whether the RLC
send window is full on the UE side. We must analyze the data on the
user plane and the control plane at the RLC layer to learn whether the
RLC window is full. Currently, the Assistant V1.4 does not support this
function. We can use only the QCAT to make analysis.
Therefore, a simple method is reverse inference. Assume that the RLC
send window is full and try the following methods to check whether the
problem is solved. If the problem is solved, the cause is that the RLC
send window is full.
Solution:
Method 1: Increase the RLC send window by changing the RLC PDU
size from 336 to 656.
Method 2: Check whether the state report disable timer is set properly
and whether it is set to the default of the baseline.
Method 3: Check the convergence of the downlink BLER to ensure the
BLER is converged.
Therefore, the factors affecting the TCP/IP data transmission rate include:
Too small a TCP receive window on the receiver side makes the send
window easily full.
Principle description:
TCP/IP adopts the sliding window protocol. The sliding window
protocol allows the sender to transmit multiple consecutive packets
before the sender stops transmission and waits for an acknowledgment.
As it is unnecessary for the sender to stop and wait for an
acknowledgment each time it transmits a packet, the sliding window
protocol increases the data transmission rate.
Theoretically, TCP receive window size should be greater than the
product of the bandwidth and the delay.
Capacity(bit)=bandwidth(b/s)*round-trip time(s)
A 66535-byte window is sufficient for the 1.6 Mbit/s service, but
insufficient for 3.6 Mbit/s service. Especially when the delay is greater
than 200 ms, the TCP window is easily full. As a result, you observe
that the buffers of the RLC and the NodeB are 0.
Observation method:
1) Query the configuration of the TCP receive window at the receiver
end.
2) Obtain the current Ping delay (test the RTT)
3) Observe the rate on the UE/DU meter is approximate to the TCP
receive window size/RTT.
Solution:
1) Change the TCP receive window size at the receiver end.
Use the following registry entries to set the receive window size to 80
KB (80*1024 = 81920).
Method 1:
Use the DRTCP tool to modify the receive window size and restart the
computer.
Method 2:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\
Services\Tcpip \Parameters\TcpWindowSize (REG_DWORD)
Restart the computer.
2) If no DRTCP tool is available, use multiple processes to perform
verification.
A 100% CPU load at the receiving end cause the TCP receive window to be
full.
Principle description:
When the CPU load at the receiving end reaches 100%, the data in the
TCP receive window cannot be submitted to the upper layer and the
TCP receive window is full.
When the TCP receive window is full, the receiver notifies the TCP
sender of it and the sender stops transmitting data. As a result, the RLC
BO is 0 and the UE transmits no data.
Observation method:
Observe the Performance tab page in the Windows Task Manager.
Solution:
1) Close the programs not related to the test at the receiving end.
2) Use high-performance computer at the receiving end.
The RTT timeout at the TCP/IP layer caused by packet loss at the CN side
triggers congestion avoidance.
Principle description:
TCP provides the reliable transport layer. One of the methods that TCP
uses is acknowledging the data received from the other peer, however,
data and acknowledgment may be lost. TCP solves the problem by
starting a timer when it starts transmitting data. If no acknowledgment
is received when the timer expires, TCP retransmits the data.
The TCP sender measures the RTT of a connection (measures the RTT
from when it transmits a byte with a special sequence number to when it
receives an acknowledgment containing this byte) to maintain an RTT
timer.
Observation method:
Start Ethereal on the portable PC attached with a data card to capture
TCP data packets, and then analyze the captured packets. Check
whether the receiver sends repeated acknowledgment packets.
Solution:
Check segment by segment to confirm that the problem lies in the RAN
or the CN.
Packet loss may happen on the Iu-PS interface, interface between the
SGSN and the GGSN, and interface between the GGSN and the
receiver.
The RTT timeout at the TCP/IP layer caused by the convergence failure of
the downlink BLER triggers congestion avoidance.
Principle description:
TCP provides the reliable transport layer. One of the methods that TCP
uses is the acknowledgment to the data received from the other peer.
However, data and acknowledgment may be lost. TCP solves the
problem by starting a timer when data transmission begins. If no
acknowledgment is received when the timer expires, TCP retransmits
the data.
The TCP sender measures the RTT of a connection (measures the RTT
from when it transmits a byte with a special sequence number to when it
receives an acknowledgment containing this byte) to maintain an RTT
timer.
If the RTT timer expires, TCP considers that a network congestion
occurs and triggers the congestion avoidance mechanism. As a result,
the data transmission rate is affected.
IP packet loss on the CN side causes the RTT timeout.
Observation method:
If the downlink bearer is a DCH,
Step 1: Check the convergence of the downlink BLER on the RNC
LMT.
Often, you are unable to observe the downlink BLER and the terminal
does not report the downlink BLER. In this case, you need to use a
terminal tool to observe the downlink BLER.
Step 2: Observe whether the downlink transmit power is limited and
confirm the causes for the downlink BLER convergence failure.
If the downlink bearer is an HSDPA,
Observe the downlink SBLER and the residual BLER through the
Probe.
Solution:
If the downlink transmit power is limited, analyze the cause (a long
distance from the NodeB) and determine a solution according to the
cause.
If the downlink transmit power is not limited but the downlink outer
loop power control does not converge, the power control performance
of the terminal is not ideal. In this case, you can use another type of
terminal to perform a test.
Too small a downlink TCP/IP reverse bandwidth causes a large RTT delay.
Principle description:
TCP provides a reliable transport layer. One of the methods that TCP
uses is acknowledging the data received from the other peer. However,
data and acknowledgment may be lost. TCP solves the problem by
starting a timer when data transmission begins. If no acknowledgment is
received when the timer expires, TCP retransmits the data.
The TCP sender measures the RTT of a connection (measures the RTT
from when it transmits a byte with a special sequence number to when it
receives an acknowledgment containing this byte) to maintain an RTT
timer.
If the RTT timer expires, TCP considers that a network congestion
occurs and triggers the congestion avoidance mechanism. As a result,
the data transmission rate is affected.
IP packet loss on the CN side causes the RTT timer expiration.
Observation method:
Step 1: Check the downlink rate of the service through the RAB
Assignment Request message.
Step 2: When the downlink channel is a DCH, check the actual
downlink bandwidth through the RB SETUP message. When the
downlink channel is an HSDPA channel, combine the available
bandwidth on the Iub interface to determine the bandwidth that is
currently available.
Step 3: Query the subscription rate in the HLR. The minimum downlink
subscription rate of the HSUPA is recommended to be no less than 128
kbit/s.
Step 4: Check whether the AT command is run on the portable test PC
to specify a downlink rate.
Solution:
If the subscription rate is too low, change the subscription rate or use
the AT command to ensure that the downlink rate matches the uplink
rate.
If the subscription rate is reasonable but the actual RB rate is low,
locate the problem from the RAN side. Usually, network resource
congestion causes an RB rate increase failure.
1.
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.
Package lose on CN side result in TCP/IP layer RTT overtime touch off
congestion avoidance
TCP apply credible transmit layer. One method is to affirm the data which receive from the other side.
But data and affirmance may lose . TCP transit set a timer in the send time to solve the problem.
When the timer overflow , it dont receive affirm message, it will retransmission data.
TCP send point will be a measure to a connect RTT. Maintain a RTT timer.
If it measure RTT overtime , TCP think net congestion , it will start-up congestion avoidance.
Consequently, it will affect data transmit rate.
IP package lose on CN side will make RTT overtime.
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.
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
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 downlayer 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.
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.
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.
3G2G handover
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.
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:
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.
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.
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.
1.
Interruption delay of
TCP displayed in
Ethereal
In 5.4.2, 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
The following table lists the contents of this chapter.
Title
Description
6.1
6.2
Cases at CN Side
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:
Add E1 bandwidth
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.
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.
1.
Convers
ational
Strea
ming
Inter
activ
e
Backg
round
8k/8k
275ms
258ms
293ms
307ms
64k/12
8k
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.
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.
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.
1.
Variation of total
throughput of one IMA
link of HSDPA codes
2. Variation of total
throughput of two IMA
links of HSDPA codes
In Figure 6-1 and Figure 6-2, 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 Figure
6-2, the measured throughput of cell is consistent with the theoretical rate, but in Figure 6-1, 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.
SG that the UE obtains, which indicates the maximum power that the NodeB
allows the UE to transmit
Percentage of the data to be transmitted to the buffer, which indicates the size
of data that the UE needs to transmit
These factors are represented by corresponding parameters in the QXDM and Probe tools accordingly.
In the Probe, the following limited rates are displayed in the HSUPA Link
Statistics window to represent these factors.
SG Limited Rate
In each TTI in the data packets recorded by the QXDM, the Payload Reason
option is recorded. This option indicates the three factors for the limited
server payload: MAX power, SG, and buffer occupancy (that is, whether data
lacks or not).
In the figure below, MP in the Reas column indicates the transmission rate of
the UE is currently subject to the maximum transmit power.
In the figure below, BO in the Reas column indicates that the UE current has
no data to send.
Low UL Rate Caused by the Limited Rate of the Buffer to Which the UE
Sends Data Through FTP
Location method: The Buffer Limit Rate observed in the HSUPA Link
Statistics window of the Probe is high, approximate to 100%. BO is all
displayed in the Reas column of all packets captured by the QXDM.
Solution: When the UE uploads data through FTP, the displayed cause for the
buffer limited rate is that the vacancy of the Buffer on the UE side is high
because the application layer sends data to the RLC layer at a low rate. After
the UE is connected to another portable PC, the uplink transmission of UE is
normal. Then, a comparison is made and it is found that the version of the UE
drive on the portable PC is old. After the drive is updated, the uplink
transmission rate is improved. The records on the Probe and the QXDM are
observed later. It is found that no buffer limit exists.
It is also found that different configurations on the portable PC and different
types of portable PCs affect the uplink throughput to different extents. For
example, the uplink throughput tested by an HP portable PC is slightly higher
than that tested by a Dell portable PC. The larger the memory in the portable
PC is, the smaller the buffer limit is.
Location method: The SG limited rate observed in the HSUPA Link Statistics
window on the Probe is very high. SG is displayed in the Reas column in
most captured packets but the current SG does not reach the maximum value.
The maximum value in HSUPA phase1 of E270 (cat3) is 23.
Symptom and cause: If the cell load is limited, you often see that the cellload
value reaches 1023 (maximum value) when you observe the cell load
information on the NodeB debugging console. In addition, you can find that
the RTWP of the cell is increased greatly to 90 dBm or so. There are many
causes for cell load increase. For example, when multiple UEs
simultaneously upload data, the RTWP is increased. It is found during the test
that the SIR of some UEs is not converged and leads to exceptional rise in the
transmit power of another UE. As a result, the cell load also increases
exceptionally and the other UEs cannot transmit data normally.
Solution: When the cell load (or RTWP) is high, first stop the uploading
service of all UEs in the cell and observe the RTWP in the cell to determine
whether the RTWP increase is caused by the UEs in the cell or other
interference. After other interference is removed, test the RTWP increase in
the cell when only one UE uploads data. If the RTWP in the cell is increased
exceptionally, the problem is caused by the UE.
2. Cases at CN Side
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.
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.
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 (2030 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
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.
1.
2.
Analysis
Figure 6-5 shows analyzing packets captured by Ethereal upon unstable PS rate.
3.
Analyzing packets
captured by Ethereal
upon unstable PS rate
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.
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.
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.
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.
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.
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.
Figure 6-6 shows the interactive interface in CuteFTP.
1.
Interactive interface in
CuteFTP
2.
Signaling of normal
downloading by FTP
3.
Signaling of abnormal
downloading by FTP
Without other better method, the method of exchanging NEs and segment is used.
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.
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.
Figure 6-9 shows the signaling of normal handover between 3G network and 2G network.
1.
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 Figure 6-10:
2.
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.
Figure 6-11 shows the signaling flow traced on 2G SGSN.
3.
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.
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
The following table lists the contents of this chapter.
Title
Description
8.1
8.2
8.3
8.4
8.5
8.6
8.7
APN Effect
8.8
PS Tools
8.9
1.
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.
1.
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.
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.
2. RLC Layer
The RLC header overhead is 16 Bits.
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.
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.
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.
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:
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.
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.
1. Tool Modification
Run the DRTCP.exe attached in the appendix 8.8.1. For the running interface, see the method for
modifying MTU.
Change the TCP Receive Window, such as 65535.
2. Regedit Modification
Detailed operations are as below:
In Windows 2000,
In
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip,
add string: "TcpWindowSize"="65535"
In
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Pa
rameters, add double type value TcpWindowSize. Set it to 65535 or ffff
(hex).
1. Tool Modification
Run the DRTCP.exe attached in the appendix 8.8.1, with the running interface as shown in .
1. Running interface of
DRTCP
Server
Modify the MTU in Adapter Settings shown in Figure 8-6 , 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.
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\Parameters\Interfaces\{.....
....}\, add a double byte value, named mtu, with the value of 1450.
1.
Detailed resolution of
Activate PDP Context
Request message
1. Traffic Classes:
The traffic classes in an Activate PDP Context Request message include the following:
Traffic class,
0 0 0 Subscribed traffic class
0 0 1 Conversational class
0 1 0 Streaming class
0 1 1 Interactive class
1 0 0 Background class
1 1 1 Reserved
Among them, Subscribed traffic class is not determined by the UE, but determined by the core
network according to the subscription information of the UE.
3. APN
The APN in the message is a character string in the ASCII format and cannot be read directly, as
shown in the figure below. You can use Ultra Edit to convert the ASCII codes into a character string.
Method of converting ASCII codes into a character string: Open the UltraEdit and create a file.
Click Edit and choose Hex Edit and enter the ASCII codes. Then you can see the character string of
the APN. In the figure below, the character string of the APN starts from the fourth bytes.
Run UltraEdit
Create a File
You can see the APN string in Figure 8-8, it start at the fourth byte.
7. APN Effect
1. Major Effect
In GPRS/WCDMA networks, APN has the following effects:
APN defines the external PDN that GGSN can connect to, such as ISP
networks, private networks, and enterprise intranets.
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.
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. PS Tools
1. TCP Receive Window and MTU
Modification Tools
Modify TCP receive window and MTU with the following tool:
For the detailed method, see the appendix 8.4 and 8.5.
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.
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).
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 HSPDSCH 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.
1.
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:
Unknown PDP address or PDP type (#28): the PDP address or PDP type
cannot be identified by SGSN.
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.
RPU failure
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.
2008-12-15
Page166 , Total166