Professional Documents
Culture Documents
Product name
WCDMA RNP
Product version
3.2
Confidentiality level
For internal use only
Total 165 pages
Prepared by
Reviewed by
Reviewed by
Approved by
Yu Yongxian
Xie Zhibin, Chen Qi, Xu Zili, Xu
Dengyu, Jiao Anqiang, Hu Wensu, Ji
Yinyu, Qin Yan, Wan Liang, and Ai
Hua
Qin Yan and Wang Chungui
Date
Date
2006-03-22
2006-03-22
Date
Date
2006-03-30
2015-10-21
Page1 , Total165
Revision Records
Date
2004-11-26
Version Description
1.00
Initial transmittal.
1.01
Reviewer
Author
Yu Yongxian
Yu Yongxian
2006-03-16
1.02
Yu Yongxian
3.00
Yu Yongxian
3.10
case.
Supplementing HSDPA KPIs; adding flow
Wang Dekai
transfer
for
HSDPA
service;
2015-10-21
Page2 , Total165
Date
2006-10-24
Version Description
Reviewer
3.11
1 Adding analysis of throughput about lub
Author
Wang Dekai
3.2
2008-04-17
3.21
TCP/IPs content.
Adding some content about HSUPA
Adding checklist of HSPA throughputs
2008-10-24
3.22
3.23
2008-12-18
2015-10-21
Gao Bo
Hua Yunlong
Zheng Kaisi
He fengming
Page3 , Total165
Contents
1 Introduction................................................................................ 12
2 Evaluation of PS Throughput Problems.........................................14
3 Data Collection...........................................................................18
3.1 Traffic Statistics...............................................................................................................................................19
3.2 DT/CQT...........................................................................................................................................................20
3.3 Others...............................................................................................................................................................22
6 Cases.......................................................................................123
6.1 Cases at RAN Side.........................................................................................................................................124
2015-10-21
Page4 , Total165
7 Summary..................................................................................147
8 Appendix..................................................................................148
8.1 Transport Channel of PS Data.......................................................................................................................149
8.2 Theoretical Rates at Each Layer....................................................................................................................150
8.2.1 TCP/IP Layer........................................................................................................................................150
8.2.2 RLC Layer............................................................................................................................................150
8.2.3 Retransmission Overhead.....................................................................................................................151
8.2.4 MAC-HS Layer....................................................................................................................................151
8.3 Bearer Methods of PS Services.....................................................................................................................152
8.3.1 DCH......................................................................................................................................................152
8.3.2 HSDPA.................................................................................................................................................152
8.3.3 CCH......................................................................................................................................................152
8.4 Method for Modifying TCP Receive Window...............................................................................................154
8.4.1 Tool Modification.................................................................................................................................154
8.4.2 Regedit Modification............................................................................................................................154
8.5 Method for Modifying MTU.........................................................................................................................155
8.5.1 Tool Modification.................................................................................................................................155
8.5.2 Regedit Modification............................................................................................................................156
8.6 Confirming APN and Rate in Activate PDP Context Request Message........................................................157
8.6.1 Traffic Classes:.....................................................................................................................................157
8.6.2 Maximum Bit Rates and Guaranteed Bit Rates....................................................................................158
2015-10-21
Page5 , Total165
8.6.3 APN......................................................................................................................................................158
8.7 APN Effect.....................................................................................................................................................160
8.7.1 Major Effect..........................................................................................................................................160
8.7.2 Method for Naming APN.....................................................................................................................160
8.7.3 APN Configuration...............................................................................................................................160
8.8 PS Tools.........................................................................................................................................................161
8.8.1 TCP Receive Window and MTU Modification Tools..........................................................................161
8.8.2 Sniffer...................................................................................................................................................161
8.8.3 Common Tool to Capture Packet: Ethereal..........................................................................................162
8.8.4 HSDPA Test UE....................................................................................................................................162
8.9 Analysis of PDP Activation............................................................................................................................163
2015-10-21
Page6 , Total165
Figures
Figure 4-1 Flow for analyzing RNC-level traffic statistics data...........................................................................30
Figure 4-2 Flow for analyzing cell-level traffic statistics data.............................................................................32
Figure 5-1 Flow for analyzing DT/CQT data.......................................................................................................38
Figure 5-2 Flow for analyzing access failure problems when originating PS services by UE directly................39
Figure 5-3 Flow for analyzing access problem when the UE serves as the modem of PC...................................40
Figure 5-4 Flow for processing problem of failure in opening port.....................................................................41
Figure 5-5 Flow for analyzing access failure problems........................................................................................42
Figure 5-6 Signaling flow of successful setup of a PS service in Probe...............................................................43
Figure 5-7 Flow for analyzing disconnection of service plane.............................................................................46
Figure 5-8 Flow for analyzing RAN side problem about disconnection of service plane for DCH bearer..........47
Figure 5-9 Connection Performance Measurement-Downlink Throughput and Bandwidth window..................48
Figure 5-10 HSDPA parameters in Probe.............................................................................................................50
Figure 5-11 Flow for analyzing problems at CN side about disconnection of service plane...............................52
Figure 5-12 Flow for analyzing poor performance of data transfer......................................................................55
Figure 5-13 Flow for analyzing RAN side problem about poor performance of data transfer on DCH..............58
Figure 5-14 Flow for analyzing data transfer affected by Uu interface................................................................59
Figure 5-15 Flow for analyzing data transfer affected by Iub interface...............................................................61
Figure 5-16 Flow for analyzing poor performance of data transfer on HSDPA at RAN side..............................64
Figure 5-17 Confirming in the RNC message that PS service is set up on HSDPA channel................................65
Figure 5-18 Confirming in Probe that service is set up on HSDPA channel........................................................65
Figure 5-19 High code error of ACK->NACK/DTX in Probe.............................................................................76
Figure 5-20 Uplink and downlink RL imbalance in handover areas....................................................................77
Figure 5-21 Residual BLER at MAC layer in WCDMA HSDPA Decoding Statistics window...........................80
Figure 5-22 Working process of an HSUPA UE...................................................................................................82
Figure 5-23 Optimization flow of a low throughput of the HSUPA UE...............................................................85
Figure 5-24 Confirming the service is set up on the HSUPA according to a signaling message of the RNC......86
2015-10-21
Page7 , Total165
2015-10-21
Page8 , Total165
2015-10-21
Page9 , Total165
Tables
Table 2-1 Requirements by DT/CQT on PS throughput.......................................................................................15
Table 3-1 Major parameters to be collected in DT/CQT.......................................................................................20
Table 3-2 Tools for collecting data........................................................................................................................22
Table 4-1 Measured items related to PS throughput in overall performance measurement of RNC....................25
Table 4-2 Measured items related to PS throughput in cell performance measurement.......................................26
Table 4-3 Measured items related to HSDPA throughput (cell measurement).....................................................27
Table 4-4 related to HSUPA throughput (cell measurement)................................................................................27
Table 4-5 Other measured items related to throughput.........................................................................................28
Table 4-6 Indexes to judge whether a cell has PS service request........................................................................33
Table 4-7 Cell measurement/cell algorithm measurement analysis......................................................................33
Table 4-8 Analysis of cell performance/Iub interface measurement.....................................................................34
Table 4-9 Cell Measurement/Cell RLC Measurement Analysis...........................................................................35
Table 5-1 Comparing operations and analyzing problem.....................................................................................56
Table 5-2 Relationship between CQI and TB size when the UE is in category 1112.........................................67
Table 5-3 Relationship between CQI and TB size when the UE is at the level 16.............................................68
Table 5-4 HS-SCCH power offset.........................................................................................................................71
Table 5-5 Categories of UE HSUPA capability levels..........................................................................................89
Table 5-6 PO for the E-AGCH when the Ec/Io at the edge of cells is 12 dB...................................................103
Table 5-7 PO for the E-RGCH when the Ec/Io at the edge of cells is 12 dB....................................................104
Table 5-8 PO for the E-HICH when the Ec/Io at the edge of cells is 12 dB.....................................................107
Table 6-1 Delay test result of ping packet...........................................................................................................125
2015-10-21
Page10 , Total165
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
2015-10-21
Page11 , Total165
Introduction
Description
Chapter 1
Introduction
Chapter 2
Chapter 3
Data Collection
Chapter 4
Chapter 5
Chapter 6
Cases
Chapter 7
Summary
Chapter 8
Appendix
2015-10-21
Page12 , Total165
In WCDMA networks, besides traditional conversational service, data service is growing with
features. It has a significant perspective.
The indexes to indicate the performance of WCDMA data service includes:
Access performance
It is reflected by the following indexes of data service:
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
2015-10-21
Page13 , Total165
Evaluation of PS Throughput
Problems
2015-10-21
Page14 , Total165
Service
Reference
Average
downlink
throughput of
R99
PS
UL64k/DL
64k
4856 kbps
PS
UL64k/DL
128k
96106 kbps
Average
uplink
throughput of
R99
Downlink
average
throughput
for HSDPA
single
subscriber
2015-10-21
PS
UL64k/DL
384k
300350 kbps
PS
UL64k/DL
64k
4856 kbps
CAT12
1.52Mbps
(SBLER =
10%)
Page15 , Total165
Index
Throughput
of HSDPA
cell
Service
CAT12
Reference
760 kbps
It is restricted by HS-PDSCH
code. The carrier power and
Iub bandwidth are not
restricted.
It is restricted by carrier
power. The HS-PDSCH code
and Iub bandwidth are not
restricted.
Pilot power
33dBmRSCP>=-70dBm;
3.25 Mbps
800 kbps
HSUPA
Single
subscriber
throughput
2015-10-21
CAT3
800kbps~1.1M
bps
(cell center)
Page16 , Total165
Index
Service
Reference
200kbps~400k
bps
Pilot power
33dBmRSCP>=-100dBm;
(cell edge)
2015-10-21
Page17 , Total165
Data Collection
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.
2015-10-21
Page18 , Total165
2015-10-21
Page19 , Total165
3.2 DT/CQT
To obtain DT/CQT data, use the software Probe, UE, scanner, and GPS are involved. Obtain the
information output by UE, such as:
Coverage
Pilot pollution
Signaling flow
Downlink BLER
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.
Table 1.1 lists the major parameters to be collected in DT/CQT.
Table 1.1 Major parameters to be collected in DT/CQT
Parameter
Tool
Effect
Probe + GPS
Record trace
Probe + UE
Analyze problems
UE TX Power
Probe + UE
Downlink BLER
Probe + UE
Uplink/Downlink
application layer, RLC
layer throughput
Probe + UE
Probe + UE
Analyze problems
Probe + UE
Uplink BLER
RNC LMT
2015-10-21
Page20 , Total165
Parameter
Tool
Effect
Downlink transmission
code power
RNC LMT
RNC LMT
Analyze problems
Iub bandwidth
RNC/NodeB LMT
Analyze problems
Downlink carrier
transmission power and
non-HSDPA carrier
transmission power
RNC LMT
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.
2015-10-21
Page21 , Total165
3.3 Others
After finding problems by traffic statistics, DT/CQT, and subscribers' complaints, analyze and locate
problems with DT/CQT and the following aspects:
RNC CHR
Alarms on NEs
States of NEs
FlashGet
DU Meter
Tools for
collecting
data
Tools
for
viewing
/
analyzi
ng data
Effect
Remark
Traffic
statistics data
M2000
Nastar
DT/CQT data
Probe + UE
Assistant
Connection
performance
measurement,
cell
performance
measurement,
signaling
tracing by RNC
RNC LMT
Assistant
or RNC
LMT
Analyze calls in
terms of flow and
coverage based on
DT/CQT data and
traced data on RNC
Alarm
M2000 or
RNC LMT
M2000 or
RNC LMT
2015-10-21
Check alarms
whether there are
abnormal NEs
Page22 , Total165
Data
Tools for
collecting
data
Tools
for
viewing
/
analyzi
ng data
Effect
Remark
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 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
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.
2015-10-21
Page23 , Total165
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.
2015-10-21
Page24 , Total165
Major indexes
Overall performance
measurement of RNC/RLC
statistics measurement
Average utilization of
buffer
Number of retransmitted
data packets
Overall performance
measurement of RNC/UE
state measurement
Number of UEs in
CELL_DCH, CELL_FACH,
CELL_PCH, and URA_PCH
state
Overall performance
measurement of RNC/RB
measurement
Overall performance
measurement of RNC/RNC
traffic measurement
2015-10-21
Number of conversational
service, streaming service,
interactive service, and
background service in
various uplink and
downlink rates in PS
domain under RNC
Effect
Page25 , Total165
Measured item
Major indexes
Overall performance
measurement of RNC/PS
inter-RAT handover
measurement
Times of successful/failure
PS inter-RAT handovers
Effect
Frequent inter-RAT and the
call drop due to it will
directly affects PS service
subscribers' experiences.
Guarantee high handover
success rate by analyzing
and optimizing the measured
item while avoid ping-pong
handover. Reduce the impact
from inter-RAT handover on
PS throughput.
Table 1.2 lists the measured items related to PS throughput in cell performance measurement.
Table 1.2 Measured items related to PS throughput in cell performance measurement
Measured item
Major indexes
Effect
Cell measurement/traffic
measurement
Cell measurement/cell
algorithm measurement
Cell measurement/cell
RLC measurement
Number of signaling
PDUs
Cell measurement/cell
throughput of various
services, throughput t
measurement
2015-10-21
Number of retransmitted
PDUs
Number of discarded
PDUs
Page26 , Total165
Cell measurement/BLER
measurement of various
services in cell
Cell measurement/Iub
interface measurement
Number of requested
RLs at Iub interface
Number of successful
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).
Table 1.3 Measured items related to HSDPA throughput (cell measurement)
Measured item
Major indexes
Cell
measurement/HSDPA
service measurement
Statistics of HSDPA
service setup and
deletion
Number of HSDPA
subscribers in cell
Intra-frequency HHO
Inter-frequency HHO
MAC-D flow
throughput
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
Table 1.4 related to HSUPA throughput (cell measurement)
Measured item
Major indexes
Effect
Cell
measurement/HSDPA
service measurement
Measured
item
HSUPA.CELL include the PI
of service setup , release and the
number of EDCH handover
Know
the
HSUPA
throughput and number of
subscribers in cell
2015-10-21
Page27 , Total165
Major indexes
Effect
Performance measurement
at Iu interface
Analyze whether
interface is normal
GTP-U measurement
IMA
GROUP
measurement
2015-10-21
link
lu-PS
Page28 , Total165
Cell measurement
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.
2015-10-21
Page29 , Total165
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
2015-10-21
Page30 , Total165
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.
2015-10-21
Page31 , Total165
2015-10-21
Page32 , Total165
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 Table 1.1 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.
Table 1.1 Indexes to judge whether a cell has PS service request
Measured item
Type
Index
Cell measurement
Number of successful
RABs with RAB
assignment setup in
PS domain in cell
VS.RAB.AttEstabPS.Conv
VS.RAB.AttEstabPS.Str
VS.RAB.AttEstabPS.Inter
VS.RAB.AttEstabPS.Bkg
Cell
measurement/HSDPA
service measurement
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.
1Table 1.2 describes the cell measurement/cell algorithm measurement analysis.
Table 1.2 Cell measurement/cell algorithm measurement analysis
Index
Meaning
Analysis
Solution
VS.LCC.BasicCongNumUL
Times of uplink
and downlink
basic
congestion in
cell
If one of them
is large than 0,
the cell is with
basic
congestion
problem
Times of cell
congestion due
to uplink and
downlink
overload
If one of them
is large than 0,
the cell must
be
badly
congested
VS.LCC.BasicCongNumDL
VS.LCC.OverCongNumUL
VS.LCC.OverCongNumDL
2015-10-21
Page33 , Total165
VS.DCCC.D2D.SuccRateDo
wn.UE
VS.DCCC.D2D.SuccRateUp.
UE
VS.Cell.UnavailTime.OM
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.
Length
unavailable
time of cell
If it is large
than 0, the cell
must
have
been
unavailable.
of
Meaning
Analysis
VS.IUB.AttRLSetup
Number of requested
RLs set up at lub
interface in cell.
If SuccRLSetup <
AttRLSetup, the RL
setup must have
failed
at
lub
interface.
Analyze
the problem for
detailed causes.
VS.IUB.SuccRLSetup
Number of successful
RLs set up at lub
interface in cell.
VS.IUB.FailRLSetup.Cf
gUnsup
VS.IUB.FailRLSetup.Co
ng
VS.IUB.FailRLSetup.O
M
VS.DL.RL.Timing.Adjus
t.Fail
VS.IUB.FailRLSetup.H
W
VS.DL.RL.Timing.Adjus
t.Succ
Solution
Number of downlink
RLs of successful and
failed RLs of timing
adjustment in cell
Page34 , Total165
Meaning
Analysis
Solution
VS.RLC.AM.TrfPDU.Trans
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.
Check
the
power control
parameters like
target value of
service BLER,
transmission
error rate, and
clock
abnormality.
Check
coverage.
VS.RLC.AM.TrfPDU.Retrans
VS.AM.RLC.DISCARD.TRF.PDU
Number of service
PDUs dropped by
RLC in downlink in
AM mode of cell
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.PDU
Number of signaling
PDUs dropped by
RLC in downlink in
AM mode of cell
Check
the
power control
parameters like
target value of
service BLER,
transmission
error rate, and
clock
abnormality.
Check
coverage.
The causes of high RLC retransmission rate and PDU packet dropping rate are:
Clock abnormality
2015-10-21
Page35 , Total165
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
2015-10-21
Page36 , Total165
Description
5.1
Access Failure
5.2
5.3
5.4
2015-10-21
Page37 , Total165
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.
Figure 1.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.
2015-10-21
Page38 , Total165
Originating PS services directly on UE, browsing web pages, and watching video
streaming directly on UE
Combining personal computer (PC) and UE. Namely, UE serves as the modem of PC,
and the service is originated through PC
In optimization test, the combination of PC and UE is most widely used. In DT/CQT, the PC is
usually a laptop with the DT software Probe installed on it. This is called Probe + UE. When the UE
fails to directly originate PS services, it can obtain more information by using Probe + UE.
Therefore, the following analysis is mainly based on Probe + UE.
2015-10-21
Page39 , Total165
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:
2015-10-21
Page40 , Total165
2015-10-21
Page41 , Total165
Trace the NAS and RRC signaling in Probe or trace the signaling of single subscriber on RNC LMT.
Analyze the problem by comparing it to the signaling flow for standard data service. For the
signaling flow for standard data service, see the senior training slides of RNP: W-RNP Senior
Training-Signaling Flow.
2015-10-21
Page42 , Total165
Figure 1.4 shows the signaling flow of successful setup of a PS service in Probe.
Figure 1.4 Signaling flow of successful setup of a PS service in Probe
In Figure 1.4, 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:
The port of UE is abnormal. See the Failure in Opening Port in 5.1.2for solution.
After the UE sends the RRC Connection Request message, it receives no response or
receives RRC Connection Reject message due to the admission rejection caused by weak
coverage and uplink and downlink overload. For details, see the section Analyzing RRC
Connection Setup Problems in W-KPI Monitoring and Improvement Guide.
The UE may have not registered in PS domain. According to signaling flow, after the
UE sends the Attach Request message, the network side responds the Attach Reject
message. The engineers at CN side need to check whether the USIM supports PS
services.
2015-10-21
Page43 , Total165
Analysis: there are two types of problems, the improper configuration of APN and rate at
UE side, or CN problems.
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.
2015-10-21
Page44 , Total165
2015-10-21
Page45 , Total165
DCH bearer
Figure 1.2 shows the flow for analyzing RAN side problem about disconnection of service plane for
DCH bearer.
Figure 1.2 Flow for analyzing RAN side problem about disconnection of service plane for DCH bearer
2015-10-21
Page46 , Total165
In Figure 1.3,
Monitor the variation of access layer rate and non-access layer rate of uplink and
downlink data transfer for the current connection. This helps analyze the functions of
dynamic channel configuration and variation features of service source rate.
When the RNC DCCC function is valid, distinguish the variation of bandwidth caused
by DCCC.
If the problem is still not located after previous operations, collect the data packets
received and sent at RNC L2 and by GTPU by using the tracing tool RNC CDT. This
helps judge whether the disconnection of subscriber plane is in uplink or downlink, at
CN side or RAN side.
Further
Check problems at the CN side according to analysis of problems at CN side in 5.2.2.
2015-10-21
Page47 , Total165
Refer to Comparing Operations and Analyzing Problem. Change each part and compare
the operations. This helps reduce the scope of the problem. Feed back the problem.
HSDPA Bearer
The HSDPA feature of cell is activated, The UE supports HSDPA. The rate requested by UE or the
subscribed rate is higher than HSDPA threshold for downlink BE service (for BE service) or HSDPA
threshold for downlink streaming service (for streaming service). When the PS services are carried
by HSDPA, follow the steps below:
Alarms in RNCs and CHR
Check the alarms and CHR for the point of problem occurrence whether there are
abnormalities. Provide diagnosis.
Deactivate HSDPA features so that PS services are set up on DCH
Deactivate HSDPA features by executing the command DEA CELLHSDPA. Connect UE
to the network by dial-up so that PS services are set up on DCH.
If the data transfer is unavailable on DCH, see the troubleshooting in previous block
DCH Bearer.
If the data transfer is available on DCH, the problem must be about HSDPA. Follow the
steps below.
Check the CQI, HS-SCCH success rate, and SBLER
Check the CQI, HS-SCCH success rate, and SBLER by Probe + UE as below:
CQI
The UE estimates and reports CQI based on PCPICH Ec/Nt.
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.
2015-10-21
Page48 , Total165
Wherein, the HS-SCCH Success Rate (%) is the HS-SCCH scheduling success rate of
the UE. It is relevant to the following parameters:
Number of HS-SCCHs
2015-10-21
The scheduling algorithm is much similar to MAX C/I algorithm, more than one
HSDPA subscribers connects to the cell, and the CQI of the subscriber is low.
The transmit power of HS-SCCH is over low. Now in the indoor scenario, the
transmit power of HS-SCCH is fixed to 2% of total transmit power of cell. In outdoor
scenarios, the proportion is 5%. If the transmit power of HS-SCCH is lower than the
fixed power, the UE may fail to demodulate HS-SCCH data.
No data is transmitted at the application layer. Confirm this by the actual transmitted
data volume in the Connection Performance Measurement-Uplink Throughput
and Bandwidth, Downlink Throughput and Bandwidth on RNC LMT.
All rights reserved
Page49 , Total165
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.
If the power of the parameter configuration is higher than or equal to the maximum
transmit power of cell, use dynamic power configuration.
If the power of the parameter configuration is lower than the maximum transmit
power of cell, use static power configuration.
2015-10-21
Page50 , Total165
Confirm by other access network or LAN that the service software servers and service software run
normally.
2015-10-21
Page51 , Total165
LAN
Use FTP or HTTP service on a PC connected to LAN, and check whether the service is
available. In addition, verify the user name and password of the connected user.
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.
2015-10-21
Page52 , Total165
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. Figure 1.1
shows the flow for analyzing poor performance of data transfer.
2015-10-21
Page53 , Total165
If the problem concerns both the RAN and CN side, analyze it from both sides.
2015-10-21
Page54 , Total165
Operation
Result
Analysis
Related to drivers,
APN, restricted rate,
and firewall.
The problem at CN
side, related to service
software
The problem at CN
side, related to
performance of server,
TCP/IP parameters, or
service software
2015-10-21
Change PC
Page55 , Total165
Ord
er
Operation
Result
Analysis
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.
2015-10-21
Page56 , Total165
Figure 1.1 Flow for analyzing RAN side problem about poor performance of data transfer on DCH
NE Alarms
Alarm check
If the performance of data transfer for PS services is poor, analyze NodeB and RNC
alarms. The clock alarms, alarms on transmission error rate, and transmission
interruption may cause fluctuation of PS data. For querying NodeB and RNC alarms, see
W-Equipment Room Operations Guide.
2015-10-21
Page57 , Total165
DCH bandwidth
State transition
Figure 1.2 shows the flow for analyzing data transfer affected by Uu interface.
Figure 1.2 Flow for analyzing data transfer affected by Uu interface
DCH bandwidth
When PS services are carried by DCH, the RNC assigns bandwidth for each connected
UE. The bandwidth depends on spreading factor and coding method.
On RNC LMT, in the Connection Performance Measurement-Uplink Throughput and
Bandwidth, Downlink Throughput and Bandwidth window, check the uplink and
downlink assigned bandwidth and throughput.
The bandwidth is the channel bandwidth assigned to UE by RAN. The DlThroughput is
the actual downlink rate of data transfer. Assigning bandwidth (namely, code resource,
power resource, and Iub resource are normal) is normal if one of the following
conditions is met:
Maximum assignable rate (such as 384 kbps) is met upon DCH bearer.
If the bandwidth assigned to UE is smaller than the expectation, there are two causes:
2015-10-21
Page58 , Total165
Congestion or other causes. The RAN cannot assign UE with channels of higher rate,
which is abnormal.
DCCC algorithm of RNC. If the DCCC algorithm parameter is rational, the decline of
rate is normal.
Enable the DCCC algorithm in the existing network so that the system can save resource
by reducing assigned bandwidth upon decline or pause of data transfer. However, the
DCCC algorithm configuration may be irrational. DCCC algorithm involves rate
adjustment based on traffic and coverage, and rate adjustment in soft handover (SHO)
SHO areas. According to the parameters configured on site and based on algorithm,
judge whether the assignment and adjustment of DCH bandwidth are rational, whether
there are abnormalities, and whether the problem is solve by adjusting parameters.
If the assigned DCH bandwidth is small due to congestion and other abnormalities, solve
the problem by the following methods:
Query cell downlink load, assignment of code resource, and available bandwidth at
Iub interface
Obtain CHR from BAM and check the abnormalities on RNC INSIGHT PLUS or
Nastar.
BLER at Uu interface
The BLER at uplink and downlink Uu interface directly affect data transfer of PS
services. If the average of UL BLER or DL BLER measured in a period is equal to or
better than BLER Target, the code errors at Uu interface are normal. Otherwise, analyze
this problem.
DL BLER measurement: collect DT data by Probe and UE, and then import the DT data
to Assistant for analysis.
UL BLER measurement: In Connection Performance Measurement-Uplink
Transport Channel BLER window, import the measurement file to Assistant, and
analyze together with the Probe DT data files.
The power control and coverage affects the uplink and downlink BLER in the following
aspects:
Outer loop power control switch. Check that the outer loop power control switch of
RNC is on.
Coverage. Check whether the uplink and downlink are restricted in the areas with bad
UL BLER and DL BLER. For details, see W-RF Optimization Guide.
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.
Page59 , Total165
Figure 1.3 shows the flow for analyzing data transfer affected by Iub interface.
Figure 1.3 Flow for analyzing data transfer affected by Iub interface
2015-10-21
Querying the bandwidth at Iub interface on RNC LMT and NodeB LMT.
Referring to the section Flow for Analyzing Cell-level Traffic Statistics Data.
Page60 , Total165
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.
Number of HS-PDSCH codes in cell (when there is only one subscriber, a HS-SCCH is
necessary)
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.
2015-10-21
Page61 , Total165
The UE monitors HS-SCCH for information sent to it. If there is any schedule
information, it starts receiving HS-DSCH data and buffers them.
According to HS-SCCH data, the UE judges whether to combine the received HS-DSCH
data and data in soft buffer.
The UE demodulates the received HS-DSCH data, and send the ACK/NACK message
on uplink HS-DPCCH according to CRC result.
If the NodeB receives the NACK message, it resends the data until it receives the ACK
message or reaches the maximum retransmission times.
In the DT tool Probe, out of consideration for multiple subscriber scheduling and retransmission at
MAC-HS layer, there are three rates at MAC-HS layer:Scheduled RateServed RateMAC Layer
Rate.
Served Rate = Scheduled Rate * HS-SCCH Success Rate
MAC Layer Rate = Served Rate * (1- SBLER)
Scheduled rate
Schedule rate = total bits of all TBs received in statistics period/total time with TB
scheduled in statistics period
The total bits of all TBs received in statistics period include all the bits of received
correct and wrong TBs.
The total time with TB scheduled in statistics period includes the time with data
received and excludes the time without data received.
Served rate
Served rate = 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.
HS-SCCH success rate is the success rate for receiving HS-SCCH data by UE
SLBER = wrong TBs received at MAC-HS layer/(received correct and wrong TBs)
ACK->NACK/DTX is the ratio that NodeB judges the ACK message as NACK/DTX
message.
Figure 1.1 shows the flow for analyzing poor performance of data transfer on HSDPA at RAN side.
2015-10-21
Page62 , Total165
Figure 1.1 Flow for analyzing poor performance of data transfer on HSDPA at RAN side
NE Alarms
When the performance of data transfer for PS services is poor, analyze the NodeB and RNC alarms.
The clock alarms, alarms on transport code error, and transmission interruption may lead to
fluctuation of PS data. For querying NodeB and RNC alarms, see W-Equipment Room Operations
Guide.
2015-10-21
Page63 , Total165
Figure 1.2 Confirming in the RNC message that PS service is set up on HSDPA channel
You can also check the information like reported CQI in the WCDMA HSDPA Link Statistics
window in the DT software Probe. If no information is in the window, the service must be carried on
DCH, as shown in Figure 1.3.
Figure 1.3 Confirming in Probe that service is set up on HSDPA channel
2015-10-21
Page64 , Total165
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.
2015-10-21
Page65 , Total165
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.
Transport
Block Size
Number of
HS-PDSCH
Modulati
on
Reference
power
adjustment
N/A
Out of range
137
QPSK
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
3319
QPSK
2015-10-21
Page66 , Total165
CQI
value
Transport
Block Size
Number of
HS-PDSCH
Modulati
on
17
3319
QPSK
Reference
power
adjustment
2
18
3319
QPSK
19
3319
QPSK
20
3319
QPSK
21
3319
QPSK
22
3319
QPSK
23
3319
QPSK
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
Table 3.2 Relationship between CQI and TB size when the UE is at the level 16
CQI
value
Transport
Block Size
Number of
HS-PDSCH
Modulatio
n
Reference
power
adjustment
N/A
Out of range
137
QPSK
173
QPSK
233
QPSK
317
QPSK
377
QPSK
461
QPSK
650
QPSK
792
QPSK
931
QPSK
10
1262
QPSK
2015-10-21
Page67 , Total165
CQI
value
Transport
Block Size
Number of
HS-PDSCH
Modulatio
n
Reference
power
adjustment
11
1483
QPSK
12
1742
QPSK
13
2279
QPSK
14
2583
QPSK
15
3319
QPSK
16
3565
16-QAM
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:
The interference is strong, and there is pilot pollution, and the CQI reported by UE is
low.
When the HSDPA serving cell is frequently updated, the HSDPA subscribers cannot
change accordingly due to punishment, so the CQI reported by UE is low.
Page68 , Total165
If the interference is strong, adjust the azimuth and down tilt in RF optimization. This
forms a primary cell.
If the HSDPA serving cell is frequently updated, avoid frequent handover by adjusting
antenna azimuth and down tilt or constructing sites in RF optimization.
Analyze the factors affecting available power of HSDPA cell from the following aspects:
Query power margin by executing the command LST MACHSPARA on NodeB. The
default power margin is 10%, namely, the total downlink load of cell can use 90% of
total power of cell.
HSDPA UE CATEGORY
The 3GPP protocol 25.306 defines 12 types of UE category. In a TTI, the UE of a type
obtains different maximum TB size, so the maximum scheduled rate obtained by UE is
different.
The UE reports its capability in the IE hsdsch physical layer category of the RRC
Connection Setup Complete message..
2015-10-21
Page69 , Total165
This problem occurs when there is data in NodeB buffer but the amount of data is
inadequate for a scheduled maximum TB size.
Set the HS-SCCH power on NodeB LMT by executing the command below:
SET MACHSPARA: PWRFLG=FIXED, PWR=5;
HS-SCCH power can be configured as dynamic power control, which is achieved by
setting a power offset to the pilot bit of DL-ADPCH. The power offset is relevant to
spreading factor of downlink DPCH and whether the UE is in SHO state. When this
method is used, the HS-SCCH power offset is listed as in Table 3.3.
The MML command is as below:
SET MACHSPARA: PWRFLG=DYNAMIC;
Table 3.3 HS-SCCH power offset
Spreading
factor of
downlink DPCH
HS-SCCH power
offset in nonSHO period
HS-SCCH power
offset in SHO
period
10.75
6.75
7.75
3.75
16
4.75
0.75
32
1.75
+2.25
2015-10-21
Page70 , Total165
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 inner-loop power
control.
At last , according to the ACK/NACK/DTX information from HS-DPCCHs feedback
,adjust HS-SCCH power , like DCH outer-loop power control.
The parameter of the power control which base on CQIs HS-SCCH : HS-SCCHs initial
power , Default is 28(-3 dBm), relative to pilot power ; HS-SCCH power controls aim
FER , Default is 10%(1%)
If there is only one HSDPA subscriber in a cell, the traffic is not restricted and HSSCCH power is adequate, the success rate of HS-SCCH for the subscriber approaches
100%.
If there are multiple HSDPA subscribers in the cell, the success rate of HS-SCCH for
each subscriber is relevant to scheduling algorithm and number of HS-SCCHs.
Usually set the HS-SCCH according to available power of HS-PDSCH, code resource,
and traffic of service source. For example, if UEs used in the cell are all category 12 UE,
set number of HS-PDSCH codes and number of HS-SCCHs as below:
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
2015-10-21
Page71 , Total165
Parameters are not configured for current scheduling algorithm. Select one of previous
three algorithms by executing the command below:
SET MACHSPARA: LOCELL=10131, SM=PF;//The previous algorithm corresponds to
the PF scheduling algorithm.
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 Queue Buffer Used Ratio to draw picture on LMT, and check the occupation of
NodeB queue.
Select RLC User Buffer Size to check RLC buffer.
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.
Select Property > Hardware > Device Manager > Modem > Property > Senior
Type AT command into the Initialization Command text box. Set APN by AT
command. If you want to set APN to cmnet, the rate is restricted to 64 kbps in
uplink and 384 kbps in downlink, execute the following command:
AT+cgdcont=1,"ip","cmnet"; +cgeqreq=1,3,64,384
When you remove the restriction on rate, execute AT command to set the rate to 0.
The value 0 means that no specified rate is requested, so the system assigns the
subscribed rate as possible. Execute the following command:
AT+cgdcont=1,"ip","cmnet"; +cgeqreq=1,3,0,0
2015-10-21
Page72 , Total165
If the physical bandwidth at Iub interface is restricted, the HSDPA service obtains
inadequate AAL2PATH bandwidth. As a result, the traffic in NodeB buffer is inadequate,
so the success rate of HS-SCCH is low.
In addition, the R99 AAL2PATH and HSDPA AAL2PATH are respectively configured,
but they share the physical bandwidth. If multiple R99 subscribers are using the
bandwidth at Iub interface in the cell, the HSDPA service obtains inadequate
AAL2PATH bandwidth. As a result, the success rate of HS-SCCH is low.
After the UE demodulates HS-PDSCH data, the UE sends an HARQ ACK or NACK
message based on cyclic redundancy check (CRC) of MAC-hs, and it repeats sending the
ACK/NACK message in the continuous N_acknack_transmit HS-DPCCH subframes. If
the N_acknack_transmit is larger than 1, the UE will not try to receive or demodulate
transport blocks between the HS-DSCH n+1 and n + N_acknack_transmit 1 subframes.
The n is the sub frame number of last HS-DSCH in the received transport blocks. Now
the rate obtained by UE is as below:
Rate of UE when the ACK/NACK is not repeatedly sent * (1/ N_acknack_transmit)
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
Power margin
HS-SCCH power
Initial BLER
2015-10-21
Page73 , Total165
If the CQI reported by UE is low, and the available power of HSDPA is inadequate,
SBLER will be high. The size of an MAC-d PDU is 336 bits. The MAC PDU requires
the TB size larger than 336 bits in transmission. As a result, the CQI upon NodeB's
scheduling must be larger than a value to meet that IBLER is within 10%.
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 10 dB higher than pilot channel, this leads to a 10%
code error for HSDPA.
If the power of other channel is 13 dB higher than pilot channel, this leads to a 100%
code error for HSDPA.
Now the NodeB can adjust power in a certain scope according to HSDPA SBLER. If the
power of other channels is 13 dB higher than the pilot power, the impact on throughput is
little. Setting PICH over low is forbidden; otherwise, the power is inadequate after
adjustment by NodeB. This leads to over high SBLER, and consequently the throughput
is affected.
2015-10-21
Page74 , Total165
In the WCDMA HSDPA Decoding Statistics window, you can see ACK->NACK/DTX.
In Figure 1.4 , ACK->NACK/DTX is 76.01%. The right pane displays detailed number
of blocks that are correct received and retransmitted. As a result, ACK>NACK/DTX=7808/(7808+2465)=76.01%.
2015-10-21
Page75 , Total165
In the WCDMA HSDPA Link Statistics window, the MAC Layer Rate-Average is
67.33 kbps. In the left pane, the RLC DL Throughput is 16.19 kbps. The ratio of RLC
rate and MAC rate is 16.19/67.33, equal to 24.05%. If the correct blocks that are
repeated received is excluded from calculating MAC layer rate, the MAC layer rate is
67.33 * (1- 76.01) = 16.15 kbps. The MAC layer rate is approximately equal to RLC
rate.
Because RL2_dl > RL1_dl, the serving cell is updated, and the HSDPA service is set up
in the cell 2. The RNC adjusts SIRtarget according to combination result of two UL RLs
due to SHO. The two cells perform inner loop power control according to SIRtarget. The
UE combines the downlink TCP of the two cells. According to combination principles, if
the TCP of one cell is 1, lower power accordingly. When the TCP of two cells is +1,
raise power.
Because RL2_ul < RL1_ul, the RL1_ul SIR is converged to target value, and RL2_ul
SIR is lower than the target value. The power control over HS-DPCCH is based on the
associated channel of RL_ul, so the demodulation performance of HS-DPCCH
ACK/NACK/CQI cannot meet requirement. As a result, the performance of data transfer
for HSDPA subscribers is poor.
Analysis proceeds as below:
2015-10-21
Page76 , Total165
Obtain HSDPA-HSDPA handover test data, including the data at UE side and RNC
side.
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 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;
2015-10-21
Page77 , Total165
Modify SIRTarget and BLERTarget for current service by executing the command
MOD TYPRABOLPC: RABINDEX=22, SUBFLOWINDEX=0,
TRCHTYPE=TRCH_HSDSCH,
IUBTRANSBEARTYPE=IUB_GROUND_TRANS, BLERQUALITY=-20;
----End
In addition, in remote deployment test of single HSDPA subscriber in a single HSDPA
cell, at the cell edge, the CQI reported by UE is good, but subscriber's rate is low, even as
low as 0. The major cause is that the uplink power of UE is restricted, that uplink power
control is not converged, and that uplink BLER is high, even as high as 100%.
Wrong configuration of AAL2 PATH (NodeB RCR > RNC PCR, or configured
bandwidth > physical bandwidth)
The RCR parameter is added to AAL2 PATH at NodeB side to fulfill flow control. It is
the receiving rate of NodeB. For ATM driver, the receiving rate cannot be restricted, so
the RCR parameter is logical only. The receiving rate is not necessarily equal to the
configured RCR parameter, but depends on the sending rate of RNC, namely, the PCR
and SCR upon configuration of AAL2PATH by RNC.
The NodeB deducts the bandwidth corresponding to R99 call from the total bandwidth of
PATH according to receiving rate, and then obtains the residual bandwidth of all PATH.
The RCR is reported to DSP, and the DSP construct frame informs RNC of residual
bandwidth. The residual bandwidth is for HSDPA subscribers, so the flow is controlled.
If the receiving bandwidth RCR of NodeB AAL2 PATH is larger than PCR of RNC
AAL2 PATH, the data packets at Iub interface will be dropped.
In addition, if the configured bandwidth of AAL2PATH is larger than the physical actual
bandwidth, the data packets at Iub interface will be dropped. As a result, the total
throughput of cell declines.
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%.
Figure 1.6 shows the residual BLER at MAC layer in WCDMA HSDPA Decoding
Statistics window.
2015-10-21
Page78 , Total165
Figure 1.6 Residual BLER at MAC layer in WCDMA 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.
2015-10-21
Compare the throughputs at the application layer (APP) and the RLC layer.
Page79 , Total165
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:
2015-10-21
Page80 , Total165
From the angle of throughput measurement, poor data transmission performance reflects a low
unsteady rate with a wide fluctuation range. From the angle of the QoS, poor data transmission
performance reflects unclear streaming images, buffering, and slow response to web browsing.
The working process of an HSUPA UE is as follows:
The NodeB determines the granted level (the E-AGCH sends T/P and the E-RGCH sends
an adjust command to tune (+1, 0 -1)) according to the UE request (SI), monitored RoT,
and the satisfaction (Happy bit indication carried on the E-DPCCH) from the UE.
The UE sends corresponding data according to the granted level. Meanwhile, the UE
attaches the next frame request (SI) on the E-DPDCH and feeds back the satisfaction
(Happy bit) at the allocated granted level on the E-DPCCH.
After receiving and demodulating the data, the NodeB returns an AcK/Nack on the EHICH.
During the optimization of the HSUPA throughput, you should combine the drive test data of the
Probe tool for analysis. The following describes HSUPA-related rates in the Probe tool:
MAC-e PDU Non-DTX Rate = Sum of all TB sizes in the case of non-DTX/(number of
non-DTXs * TTI)
This rate is the actual rate of the MAC-e (excluding DTX, but including the rate of
retransmission blocks)
2015-10-21
Page81 , Total165
Sum of all TB sizes in the case of non-DTX: Not only the block transmitted first but also the
retransmitted blocks are included.
Number of non-DTXs * TTI: Only the time when data is transmitted is counted and the time when
no data is transmitted is excluded. For example, if only 50 sub-frames send data within the
measurement period of 100 sub-frames (200 ms), the denominator is 100 ms.
MAC-e PDU Served Rate = Sum of all TB sizes in the case of non-DTX/
(NUM_SAMPLES * TTI)
This rate is the served rate of the MAC-e (including DTX and the rate of retransmission
blocks)
Sum of all TB sizes in the case of non-DTX: Not only the block transmitted first but also the
retransmitted blocks are included.
NUM_SAMPLES * TTI: The time when data is transmitted and the time when no data is transmitted
are both included. For example, if only 50 sub-frames send data within the measurement period of
100 sub-frames (200 ms), the denominator is 200 ms.
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.
MAC-e PDU Served Rate = MAC-e PDU Non-DTX Rate * Non-DTX Probability
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 MACd 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.
2015-10-21
RLC PDU Throughput UL = MAC-e PDU Available Rate * (1-header overhead ratio
of MAC-e PDU)
A precise relationship should exclude the header overhead and the padding bits when the TB size
does not match N RLC PDU bits
UL RLC SDU Throughput = Sum of bits of all RLC SDUs sent by the RLC layer within
the measurement period/Measurement period duration
Page82 , Total165
Sum of bits of all RLC SDUs sent by the RLC layer within the measurement period: Compared with
the sum of RLC PDU bits, the retransmitted data and header overhead (16 bits) of the RLC PDU are
excluded.
Measurement period duration: The time when data is transmitted and the time when no data is
transmitted are both included.
Relationship between RLC SDU Throughput UL and RLC PDU Throughput UL:
The figure below shows the optimization flow of a low throughput of the HSUPA UE.
2015-10-21
Page83 , Total165
Page84 , Total165
Figure 1.3 Confirming the service is set up on the HSUPA according to a signaling message of the RNC
You can also observe whether an SG is reported in the HSUPA Link Statistics window provided by a
drive test tool, for example, Probe. If no information is displayed in the window, the service is borne
on a DCH, as shown in the figure below.
2015-10-21
Page85 , Total165
Figure 1.4 How to confirm the service is set up on the HSUPA through the drive test tool Probe
If the service is not borne on the HSUPA, the service is automatically set up on a DCH. In this case,
the service rate is the rate of the R99 service, usually 384 Kpbs or below.
If the service is not set up on the HSUPA, you can make analysis in terms of the following aspects:
Check whether the capabilities reported by the UE include the HSUPA. The
RRC_CONN_REQUEST message reported by the UE indicates whether the HSDPA and
HSUPA are supported. The specific E-DCH capability level is reported in an
RRC_CONN_SETUP_CMP message.
Check whether the MBR in the subscription information in the previous line is normal
and whether the rate threshold over an E-DCH is set too high. If the MBR assigned by
the CN does not exceed the rate threshold over an E-DCH, the service is set up on a
DCH.
Check whether the type of the HSUPA AAL2PATH is configured correctly and whether a
type of HSUPA AAL2PATH is configured.
2015-10-21
Page86 , Total165
If the UE reports HAPPY, the user may not feel happy. Make specific analysis according to the happy
reasons.
If the MAC-e PDU Non-DTX Rate is abnormal, use the drive test tool Probe to determine whether
the UE reports HAPPY or UNHAPPY.
If the UE reports HAPPY and the UE rate cannot reach the MBR, the possible causes are as follows:
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.
Cause 3: The NodeB CEs are 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.
The terminal capability or the RAN capability is limited.
Principle description
Currently, the capability of Qualcomm HSUPA and Huawei E270 HSUPA is CAT5 (the
corresponding MAC-e rate is 2 Mbit/s). The maximum capability supported by Huawei
RAN6.0 (RNCV1.8 and NodeBV1.8) is 2 x SF4 (the corresponding MAC-e rate is
1.4484 Mbit/s). Currently, the maximum rate that a single UE can obtain is limited to the
capability of the RAN6.0.
The RAN6.0 supports 2 x SF4, the maximum TB size is 14484), and the MAC-e PDU
Non-DTX Rate is 14484/10 = 1.4484 Mbit/s
The CAT5 terminal supports 2 x SF2, the maximum TB size is 20000, and the MAC-e
PDU Non-DTX Rate is 20000/10 = 2 Mbit/s.
2015-10-21
Page87 , Total165
Maximum
Number of
E-DCH
Codes
Transmitt
ed
Minimu
m
Spreadi
ng
Factor
Suppor
t for
10 and
2 ms
TTI
EDCH
Maximum
Number of Bits
of an E-DCH
Transport
Block
Transmitted
Within a 10 ms
E-DCH TTI
Maximum Number
of Bits of an E-DCH
Transport Block
Transmitted Within
a 2 ms E-DCH TTI
Category 1
SF4
10 ms
TTI only
7110
Category 2
SF4
10 ms
and
14484
2798
2 ms TTI
Category 3
SF4
10 ms
TTI only
14484
Category 4
SF2
10 ms
and
20000
5772
2 ms TTI
Category 5
SF2
10 ms
TTI only
20000
Category 6
SF2
10 ms
and
20000
11484
2 ms TTI
NOTE: When 4 codes are transmitted in parallel, two codes shall be transmitted with SF2 and two with SF4
Observation method:
2015-10-21
Page88 , Total165
2015-10-21
Page89 , Total165
2015-10-21
Page90 , Total165
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:
2015-10-21
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.
Page91 , Total165
Observation method:
Method of observing whether the transmit power of the UE limited:
Observe the power limited rate reported by the UE through the Assistant. If the power
limited rate is greater than 0%, the transmit power of the UE within the
corresponding measurement period of the measurement value is limited.
Figure 1.8 Display of the Assistant HSUPA related information (limited transmit power of the UE)
When the UE uses the maximum block (14480), Qualcomm chips of early versions also display the
limited transmit power, but in fact, the transmit power is not limited. This problem can be ruled out by
combining the current MAC-e PDU Non-DTX Rate with the actual transmit power of the UE.
After confirming that the transmit power of the UE is limited, analyze the limitation
causes.
a.View the PCPICH RSCP of the cell where the UE is located and check whether the
UE is at the edge of the cell.
b.View the RTWP of the cell where the UE is located before the access and check
whether the uplink load of the cell is high.
c.View the uplink SIR of the UE to check whether the SIR is exceptionally high.
d.View the service that the UE sets up and check whether the service is a combined
service.
Solution:
If the UE is at the edge of the cell, move the UE to the center of the cell.
If the uplink load of the cell is high and the cell load is adjustable, reduce the cell
load.
If the service that the UE sets up is a combined service, deactivate the R99 service
and observe the rate of the HSUPA service.
2015-10-21
Principle description:
Page92 , Total165
If the data in the UE RLC Buffer is insufficient, the actual MAC-e PDU Non-DTX Rate
is low.
Observation method:
Figure 1.9 Display of the Assistant HSUPA related information (limited traffic)
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.
2015-10-21
Page93 , Total165
When the actual value of the MAC-e rate (including retransmitted blocks) is greater
than the MBR, an RG Down is sent to the UE to reduce the SG of the UE. As a result,
the transmission rate of the UE is reduced and is kept approximate to the MBR.
The UE maintains the SG according to the AG (AG is used only to increase the rate in
the RAN6.0) and the RG (Up, Hold, and Down) sent by the NodeB. The UE determines
the actual transmission rate by reference to the SG. The actual transmission rate is less
than or equal to the corresponding transmission rate of the SG.
The resources (air interface load, IUB bandwidth, and CEs) on the RAN side are limited.
If the resources on the RAN side are limited, the SG that the NodeB actually allocates to
the UE is small. As a result, the UE reports that the SG is limited.
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.
2015-10-21
Page94 , Total165
The disagreement of the background set on the RNC LMT with the cell background
affects the throughput of the cell. If the setting value of the background noise is much
larger than the actual background noise value, the system stability may be reduced.
When the setting value of the background noise is greater than the actual background
noise value, the actual cell throughput is greater than the throughput that the target
ROT corresponds to.
When the setting value of the background noise is less than the actual background
noise value, the actual cell throughput is less than the throughput that the target ROT
corresponds to.
Observation method:
Observe the cell uplink RTWP measurement recorded and displayed on the RNC
LMT to check whether it is close to the configured target RTWP. If the measured
value is close to the target RTWP, the air interface load is limited and reaches the
target value.
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.
2015-10-21
Principle description:
Page95 , Total165
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
2015-10-21
Page96 , Total165
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.
If the sum of the rates of all UEs is approximate to the available bandwidth of the
HSUPA times the bandwidth utilization, the Iub bandwidth is limited. In addition,
observe the measured RTWPs of all cells. They should all be less than the target
value configured on the RNC.
Solution:
Improve the available Iub bandwidth of the HSUPA.
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:
Make observations on the NodeB debugging console.
Solution:
Add CEs.
2015-10-21
Principle description:
Page97 , Total165
2015-10-21
Page98 , Total165
UE MBR:
2015-10-21
Page99 , Total165
Figure 1.15 RB SETUP message (containing the maximum number of available channel codes)
2015-10-21
Page100 , Total165
HsupaMaxRateUpScale
Requested
rate up scale
for the
HSUPA
service
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 E-HICH).
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.
2015-10-21
Page101 , Total165
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.
Table 15.1 PO for the E-AGCH when the Ec/Io at the edge of cells is 12 dB
Control channel
Scenario
Power Offset
(dB)
E-AGCH
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.
For cause 2, remove the bugs from the terminal.
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)
2015-10-21
Page102 , Total165
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.
Table 15.2 PO for the E-RGCH when the Ec/Io at the edge of cells is 12 dB
Control Channel
Scenario
Power Offset
(dB)
E-RGCH
22
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 E-RGCH 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 E-RGCH. 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.
Page103 , Total165
When a single HSUPA UE uploads a large-sized file, normally, the non-DTX probability should be
100%.A non-DTX probability less than 100% is considered an exception and the cause needs to be
analyzed.
Factors affecting a non-DTX probability:
The RLC layer is exceptional so that RLC data is not sent in time.
See "RLC SDU Throughput UL Exception Location".
The TCP/IP layer is exceptional so that TCP data is not sent in time.
See "TCP/IP Layer Rate Exception Location".
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.
The maximum SIRtarget value is related to other outer loop power control parameters
(including reference ETFCI, reference PO, and target number of retransmissions).
Observation method:
Query the maximum SIRtarget that the system currently uses.
MML command: LST TYPRAB
2015-10-21
Solution:
Page104 , Total165
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 E-HICH. 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 non-serving 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
2015-10-21
Page105 , Total165
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.
Table 15.3 PO for the E-HICH when the Ec/Io at the edge of cells is 12 dB
Control Channel
Scenario
Power Offset
(dB)
E-HICH
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 E-HICH 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.
Before the RLC receives an acknowledgment packet, the maximum number of PDUs
that the RLC can send is the RLC Send Window. The sooner the sender receives an
2015-10-21
Page106 , Total165
acknowledgment, the faster the window slides and the higher the allowed RLC
transmission rate is. Otherwise, the RLC transmission rate is lower. Even call drops
occur because the RLC is reset.
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.
Sequential submission is recommended for the RLC and the non-sequential submission
for the core network.
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:
RLC PDU Throughput UL = MAC-e PDU Available Rate * (1-header overhead ratio of
MAC-e PDU)
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 MAC-e layer
retransmissions reaches the maximum. This is packet loss for the RLC layer.
2015-10-21
Page107 , Total165
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.
4) The uplink transmission quality on the air interface is controlled by the uplink
outer loop power control. If packet loss occurs in the uplink of the air interface, the
uplink outer loop power control is generally exceptional.
Observation method:
Method 1: Observe the RLC PDU retransmission rate UL on the Probe.
Method 2: Observe the residual BLER (Res. BLER) of the MAC-e layer on the
Probe. Normally, the Res. BLER is less than 1%.
Block
Number of frames failing to be transmitted at the MAC-e layer. That is, if the
transmission of a frame still fails after the MAC-e layer retransmits it for multiple
times, the RLC layer originates a retransmission. In this case, the value is increased
by 1.
Block +
Number of frames transmitted successfully at the MAC-e layer, equal to SB +
Res. BLER
Residual block error rate at the MAC-e layer, namely, the number of frames failing to
be transmitted at the RLC layer/total number of transmissions at the RLC layer:
(Block -) / ((Block -) + (Block +)) * 100%
Solution:
The uplink transmission quality on the air interface is controlled by the uplink outer
loop power control. If packet loss occurs in the uplink of the air interface, the uplink
outer loop power control is usually exceptional.
You need to check whether
a) Target values for power control are configured correctly.
b) The uplink SIRtarget is normal.
c) The actual SIR is converged within the target value.
The downlink packet loss on the air interface (the probability of demodulating NACK
into ACK is high) causes a high RLC retransmission rate.
2015-10-21
Principle description:
All rights reserved
Page108 , Total165
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:
See High Probability of Demodulating ACK into NACK/DTX.
The uplink packet loss on the Iub interface (the bottom-layer transmission is exceptional)
causes a high RLC retransmission rate.
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.
2015-10-21
Principle description:
Page109 , Total165
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.
2015-10-21
Page110 , Total165
TCP determines a network congestion by measuring the round-trip time (RTT) delay
timeout or receiving a repeated acknowledgment. When a network congestion is
detected, the congestion avoidance algorithm (downspeeding and retransmission) is
enabled.
Therefore, the factors affecting the TCP/IP data transmission rate include:
RTT fluctuation triggers the congestion avoidance mechanism (packet loss on the CN
side, downlink BLER convergence failure, and too small a reverse bandwidth of TCP/IP)
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:
2015-10-21
Page111 , Total165
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.
2015-10-21
The RTT timeout at the TCP/IP layer caused by packet loss at the CN side triggers
congestion avoidance.
All rights reserved
Page112 , Total165
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.
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:
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.
2015-10-21
Page113 , Total165
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.
2015-10-21
Page114 , Total165
Figure 1.1 Flow for analyzing poor performance of data transfer at CN side
NE Alarms
At CN side, analyze the alarms on SGSN, GGSN, LAN switch, router, and firewall (collecting
SGSN and GGSN alarms as key task). Clock alarms and transport code error alarms may lead to
fluctuation of PS data.
2015-10-21
Page115 , Total165
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 binary. The multi-thread
downloading software like FlashGet is recommended.
If update rate is low , it can consider process multi-FTP transmission at the same time, or
use tools send fixed rate package to make sure whether the bottom has a problem.
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
2015-10-21
Page116 , Total165
video adapter, so the monitor jumps some frames. Change the resolution to 800x600. If
the problem is still present, change the video adapter.
Net TV
When the rate of down-layer declines, the Net TV is difficult to restore. Note this.
Video conference
Set the output rate of convergence TV smaller than the rate of down-layer; otherwise,
data packets will be dropped. Huawei conference video sets 64 kbps as step from 128
kbps. The recommended configuration is 320 kbps. If the rate is over low, utilization rate
of down-layer rate will be over low. Otherwise, using the rate higher than 320 kbps, such
as equal to or larger than 384 kbps, leads to dropping data packets because the rate of
down-layer cannot meet the requirements by application layer. As a result, the
performance of video conference declines. If a lightning sign appears on the right upper
corner of conference TV, there must be code error or packet dropping during
transmission.
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.
2015-10-21
Page117 , Total165
After the UE hands over 3G networks to 2G networks, it cannot perform data transfer.
A state transition occurs. After the UE transits from CELL_DCH to CELL_FACH and
CELL_PCH, when restoring data transfer is necessary and the resource for restoring data
transfer is inadequate, the UE cannot restore to CELL_DCH state. Therefore data
transfer is affected.
2015-10-21
Page118 , Total165
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.
2015-10-21
Page119 , Total165
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.
Intra-NodeB. In the same DSP of a NodeB, interruption of data transfer does not occur
because no data needs transiting from one MAC-hs buffer to another MAC-hs buffer.
Inter-NodeB. When MAC-HS is reset, the NodeB drops original data in buffer and
restores the dropped data by RNC RLC retransmission. The interruption of data transfer
lasts for about 300ms.
During the inter-frequency and intra-frequency HHO associated HSDPA serving cell update, the
MAC-HS is reset, the NodeB drops original data in buffer and restores the dropped data by RNC
RLC retransmission. The interruption of data transfer also occurs.
During H2D SHO, intra-frequency HHO, inter-frequency HHO, D2H SHO, intra-frequency HHO,
and inter-frequency HHO, the interruption of data transfer also will occur.
During the handover between HSDPA and GPRS, data transfer will also be interrupted.
The interruption of data transfer includes two aspects:
Over long interruption of data transfer with update of serving cell or handover
2015-10-21
Page120 , Total165
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.
In Figure 1.1, 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.
2015-10-21
Page121 , Total165
Cases
Description
6.1
6.2
Cases at CN Side
2015-10-21
Page122 , Total165
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.
2015-10-21
Page123 , Total165
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.
Activate the four 8k/8k services: background, interactive, streaming, and conversational.
Test the delay, and trace SGSN and RNC CDR.
Activate the three 64k/128k services: background, interactive, and streaming. Test the
delay, and trace SNSN and RNC CDR.
8k/8k
2015-10-21
Conversational
Streaming
Interactive
Background
275ms
258ms
293ms
307ms
Page124 , Total165
64k/128k
121ms
134ms
131ms
In 8k/8k, the delay of each service is larger than 220ms. In 64k/128k, the delay is smaller. Therefore
the delay and bandwidth are relevant.
Execute the command ping by 32 bytes, and analyze as below:
In 8k/8k, execute the command ping by 32 bytes. It is 60 bytes including the IP head. The TTI of 8k
is 40ms. Each TTI has a block. The TB size is 336 bits. As a result, executing the command ping by
32 bytes occurs on two TTIs, namely, 80ms. The downlink is similar.
The uplink and downlink must stagger a TTI. Assume that the processing at nodes and interface goes
infinitely fast. To the air interface and from the air interface take 200ms (5*40 ms).
In addition, a PC always sends data about MSN, HTTP protocols. If the PC sends other packet
during sending ping data, the ping command has to wait. Therefore, 8k bandwidth is over small.
In 64k/128k, execute the command ping by 32 bytes. It is 60 bytes including the IP head. The TTI of
128k is 20ms. Each TTI has 8 blocks. The TB size is 336 bits. As a result, executing the command
ping by 32 bytes occurs on a TTI, namely, 20ms. The downlink is similar.
The uplink and downlink must stagger a TTI. Assume that the processing at nodes and interface goes
infinitely fast. To the air interface and from the air interface take 60ms (3*20 ms). Adding this to CN
cost and laptop cost makes more than 100ms.
Execute the command ping by 8 bytes on conversational service. After on-site verification, the test is
consistent with prediction.
Analyze the parts of total delay from laptop, to UE, to NodeB, to RNC, to CN, and to server.
Analyze the factors that affect delay in each part. This helps locate delay problems.
Compared with 8k/8k streaming service, the typical parameters of 8k/8k conversational service must
be optimized.
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.
2015-10-21
Page125 , Total165
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.
2015-10-21
Page126 , Total165
2015-10-21
Page127 , Total165
Figure 1.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.
2015-10-21
Page128 , Total165
Maximum transmit power provided by the UE for uplink packet access (UPA)
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
The highest limited rate indicates that it is the major factor affecting the uplink
transmission rate of the UE. The measurement period of the Probe is long. These three
limited rates are measured within a measurement period of 200 ms.
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).
2015-10-21
In the figure below, MP in the Reas column indicates the transmission rate of the UE
is currently subject to the maximum transmit power.
Page129 , Total165
2015-10-21
In the figure below, BO in the Reas column indicates that the UE current has no data
to send.
Page130 , Total165
During tests, if the throughput of the UE is abnormal (for example, low or fluctuates
greatly), you can query the previous parameters to determine the cause.
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.
2015-10-21
Page131 , Total165
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
2015-10-21
Page132 , Total165
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.
2015-10-21
Page133 , Total165
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
2015-10-21
Page134 , Total165
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 transfers data by using software, so it starts flow control to protect
main controller. As a result, the downlink rate declines upon fragment and reassembly.
Solution:
Set the MTU of the operator's server to 1450 (if fragment is unnecessary, MTU
should be as large as possible. According to test, 1450 is improper).
Set the MTU of laptops connected to UE to 1450 (you must change the MTU at USB
port of laptops) so that the SGSN will not start fragment and reassembly.
Since it is impossible to modify MTU of the operator's server, solve the problem by
using the second method. For how to TCP parameters in Windows, see the appendix.
2015-10-21
Page135 , Total165
Analysis
Figure 6-5 shows analyzing packets captured by Ethereal upon unstable PS rate.
2015-10-21
Page136 , Total165
500: ACK
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.
2015-10-21
Page137 , Total165
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.
2015-10-21
Page138 , Total165
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.
2015-10-21
Page139 , Total165
2015-10-21
Page140 , Total165
2015-10-21
Page141 , Total165
2015-10-21
Page142 , Total165
2015-10-21
Page143 , Total165
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.
Figure 1.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:
2015-10-21
Page144 , Total165
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.
2015-10-21
Page145 , Total165
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.
2015-10-21
Page146 , Total165
2015-10-21
Page147 , Total165
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.
2015-10-21
Page148 , Total165
Appendix
Description
8.1
8.2
8.3
8.4
8.5
8.6
8.7
APN Effect
8.8
PS Tools
8.9
2015-10-21
Page149 , Total165
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.
2015-10-21
Page150 , Total165
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.
2015-10-21
Page151 , Total165
Assume that the rate at the application layer is 1 Bytes/s. if retransmission at each layer is not
considered, the corresponding rate at RLC layer is 1500/1460, namely, 1.027. The rate at MAC-d
layer is 1500/1460 * 336/320, namely, 1.079.
2015-10-21
Page152 , Total165
8.3.1 DCH
The DCH bandwidth depends on the current power resource, code resource, and Iub bandwidth
resource. Typical rates include 8 kbps, 32 kbps, 64 kbps, 128 kbps, 144 kbps, and 384 kbps. The
DCH bandwidth is adjustable by algorithms like DCCC according to the current traffic and coverage
conditions, but the adjustment is limited to previous rates. In addition, the interval to trigger
adjustment is long. As a result, the adjustment is not frequent.
8.3.2 HSDPA
The network does not allocate fixed bandwidth or resources for the PS services carried by HSDPA,
but perform fast schedule every 2ms. Therefore, the throughput that a subscriber can reach depends
on abundant factors, such as:
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.
2015-10-21
Page153 , Total165
8.3.3 CCH
FACH can carried PS services of low traffic, it can also bear broadcasting services like CMB.
FACH uses code resource of different SFs, so it support variable channel rate. This depends on the
need by broadcasting services like CMB.
2015-10-21
Page154 , Total165
In
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters,
add double type value TcpWindowSize. Set it to 65535 or ffff (hex).
2015-10-21
Page155 , Total165
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.
2015-10-21
Page156 , Total165
2015-10-21
Page157 , Total165
001
Conversational class
2015-10-21
Page158 , Total165
010
Streaming class
011
Interactive class
100
Background class
111
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.
8.6.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.
2015-10-21
Page159 , Total165
Figure 1.1 Converting ASCII codes into a character string by using the UltraEdit
Run UltraEdit
Create a File
You can see the APN string in Figure 8-8, it start at the fourth byte.
2015-10-21
Page160 , Total165
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.
2015-10-21
Page161 , Total165
8.8 PS Tools
8.8.1 TCP Receive Window and MTU Modification
Tools
Modify TCP receive window and MTU with the following tool:
Drtcp.rar
For the detailed method, see the appendix 8.4 and 8.5.
8.8.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.
2015-10-21
Page162 , Total165
2015-10-21
Page163 , Total165
UTRAN
3G-SGSN
3G-GGSN
The MS sends SGSN the Activate PDP Context Request (NSAPI, TI, PDP Type, PDP Address,
Access Point Name, QoS Requested). The PDP Address indicates the dynamic address or the static
address. If the PDP Address is dynamic address, set it to null.
The following aspects lead to unsuccessful PDP activation process:
Activation rejected, unspecified (#31): Huawei SGSN defines GTPU interaction failure,
expiration, operation SDB failure, activation failure due to other abnormalities to this
kind of failure.
Activation rejected by GGSN (#30): GGSN rejects or fails to decode the corresponding
activation request.
Missing or unknown APN (#27): APN is not contained in the activation request message
or cannot be extracted. Huawei SGSN takes DNS resolution failure, DHCP or MIP
GGSN address acquisition failure, APN error specified by activation at network side,
other APN error as activation failure. These are internal causes.
Unknown PDP address or PDP type (#28): the PDP address or PDP type cannot be
identified by SGSN.
Service option not supported (#32): the requested serving PLMN does not support this.
Huawei SGSN takes wildcard (*) activation rejection, service non-supportive, IPV6 nonsupportive as this type.
2015-10-21
Page164 , Total165
Requested service option not subscribed (#33): requested service is not subscribed.
Huawei SGSN takes mismatch subscribed information, VPLMN access inhibit, and
charging restricted callingVPLMN as this type.
Insufficient resources (#26): activation fails due to inadequate resource. Huawei SGSN
takes the following causes as inadequate resource.
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.
Protocol error, unspecified (#111): Huawei SGSN in abnormal SDB or SM state may
confront this type of activation rejection.
2015-10-21
Page165 , Total165