Professional Documents
Culture Documents
Product version
Total 166 pages
3.2
Approved by Date
Huawei Technologies Co., Ltd.
All Rights Reserved
Revision Records
Date Version Description Reviewer Author
2004-11- 1.00
Initial transmittal. Yu Yongxian
26
Abstract
The document serves the optimization of PS service problems in large networks. It describes problem
evaluation, data collection, and methods for analyzing problems.
Acronyms and
Full spelling
abbreviations
DT Driver Test
SF Spreading Factor
UE User Equipment
SBLER Scheduled Block Error Rate
NE Network Element
1. Introduction
Title Description
Chapter 1 Introduction
Chapter 6 Cases
Chapter 7 Summary
Chapter 8 Appendix
In WCDMA networks, besides traditional conversational service, data service is growing with
features. It has a significant perspective.
Access performance
It is reflected by the following indexes of data service:
Success rate of RRC setup
Success rate of RAB setup
Success rate of PDP activation
Call drop rate of PS service
Throughput
Delay
There are access delay and the service interruption delay caused by HHO.
This document addresses on problems in PS service optimization, such as access problems, data
transfer failure, low throughput of data transfer, unstable rate of data transfer, and interruption of data
transfer. It describes the method to analyze and solve DT/CQT problems. In addition, it describes the
flow for processing access failure and data transfer failure problems in optimization of PS throughput.
For access problems, call drop and handover problems, see W-KPI Monitoring and Improvement
Guide, which provides analysis in terms of signaling flow and performance statistics. This guide
supplements the possible causes and solutions to PS service access problems in terms of operations.
This guide is for RNO in commercial network, not in benchmark trial network.
The HSDPA problem analysis and description of MML command and product function are based on
the following product versions:
BSC6800V100R006C01B064
BTS3812E V100R006C02B040
When refer RRC arithmetic and product realization default is RNC V16, refer V17 it will be labeled.
The HSUPA problem analyses, description of MML command and product function are based on the
following product versions:
BSC6800V100R008C01B082
DBS3800-BBU3806V100R008C01B062
2. Evaluation of PS Throughput
Problems
1. Requirements by
DT/CQT on PS
throughput
planned load)
without call drop
problems due to
congestion.
Put FTP servers
in CN.
Download with
5 threads.
Exclude non-
RAN problems
or decline of
throughput
caused by UE.
CQI of tested
area is 10.
Single
subscriber in
unloaded
conditions and
in the edge of
cell.
not restricted.
Pilot power
33dBmRSCP
>=-70dBm;
Single
subscriber in
unloaded
conditions
Set MTU
size 1500
bytes , set PDU
size= 336 bits.
In UE QoS
profile in HLR,
MBR=2Mbps,
service type is
Background/Inte
ractive
The data
resource of FTP
must make sure
that upload can
get the faster
rate in the wire
connection
conditions.
Obtain the faster
rate, combine
UE capability,
get APP rate in
the conditions of
uplink
RTWP,IUB
bandwidth are
not restricted.
200kbps~400kbps Uplink
RTWP,IUB
(cell edge)
bandwidth
Ind Servi Referen Reference test method
ex ce ce
resource and UE
TX power are
not restricted.
Pilot power
33dBmRSCP
>=-100dBm;
Single
subscriber in
unloaded
conditions
set
MTU 1500
bytes , set PDU
= 336 bits
In UE QoS
profile in HLR,
MBR=2Mbps,
service type is
Background/Inte
ractive
The data
resource of FTP
must make sure
that upload can
get the fast rate
in the wire
connection
conditions.
Get the fast rate ,
combine UE
capability , get
APP rate in the
conditions of
uplink
RTWP,IUB
bandwidth are
not restricted.
3. Data Collection
Title Description
3.2 DT/CQT
3.3 Others
There are two major methods for evaluating PS throughput: traffic statistics and DT/CQT.
1. Traffic Statistics
For collecting traffic statistics data, see W-Equipment Room Operations Guide.
2. DT/CQT
To obtain DT/CQT data, use the software Probe, UE, scanner, and GPS are involved. Obtain the
information output by UE, such as:
Coverage
Pilot pollution
Signaling flow
Downlink BLER
TX power of UE
Based on the measurement tracing on RNC LMT, obtain the following information:
Uplink BLER
Downlink code transmission power
Downlink carrier transmission power
Signaling flow at RNC side
By the DT processing software Assistant, analyze comprehensively the data collected by Probe in
foreground DT and tracing record on RNC LMT.
1. Major
parameters to be
collected in
DT/CQT
For the detailed test and operation methods of DT and CQT, see W-Test Guide. For detailed
operations on LMT, see W-Equipment Room Operations Guide.
3. Others
After finding problems by traffic statistics, DT/CQT, and subscribers' complaints, analyze and locate
problems with DT/CQT and the following aspects:
RNC CHR
Connection performance measurement
Cell performance measurement
Alarms on NEs
States of NEs
FlashGet
DU Meter
3.3 lists the tools for collecting data.
1. Tools for
collecting data
application
layer real-time,
take statistics
of total
throughput,
average
throughput, and
peak
throughput in a
period (the
result is
recorded by
PrintScreen
shot).
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.
4. Analysis of Traffic Statistics Data
Title Description
The access, call drop, SHO, HHO, inter-RAT handover problems may affect throughput of PS
services. Therefore, before analyzing and optimizing throughput of PS services, analyze access, call
drop, SHO, HHO, inter-RAT handover problems.
To analyze access problems and traffic statistics indexes, see W-Access Problem Optimization Guide.
To analyze handover and call drop problems, and traffic statistics indexes, see W-Handover and Call
Drop Problem Optimization Guide.
1. Traffic Statistics Indexes Related to
Throughput
The following four tables are based on RNC V1.6.
4.1 lists the measured items related to PS throughput in overall performance measurement of RNC.
1. Measured items
related to PS
throughput in
overall
performance
measurement of
RNC
measurement
2. Measured items
related to PS
throughput in cell
performance
measurement
Cell Uplink
measurement/BLER average
measurement of BLER of
various services in various
cell services in
cell
The ratio of
time of
maximum
value of
BLER
Table 4-3 lists the measured items related to HSDPA throughput (cell measurement).
3. Measured items
related to
HSDPA
throughput (cell
measurement)
Table 4-4 lists the measured items related to HSDPA throughput (cell measurement).Measured items
4. related to
HSUPA
throughput (cell
measurement)
Measured item
Know the HSUPA
Cell HSUPA.CELL include
throughput and
measurement/HSDPA the PI of service setup ,
number of subscribers
service measurement release and the number of
in cell
EDCH handover
5. Other measured
items related to
throughput
In actual traffic statistics analysis, evaluate the indexes of entire network and then locate cell-level
problems.
The RNC traffic statistics indexes of current version do not include statistics of throughput of various
services, but include RNC traffic volume measurement. The traffic volume measurement is relevant to
subscribers' behaviors and traffic model.
The traffic volume is not the same every day, but is fluctuating periodically from Monday to Saturday
and Sunday. Therefore, upon analysis of RNC traffic volume, observe the fluctuation of weekly traffic
volume. For example, compare the curve chart of traffic volume for a weak with that of last weak. If
they are similar, the network is running normally according to RNC-level analysis. If they are greatly
different from each other, analyze the problem in details.
When analyzing problems, check whether the RNC-level traffic statistics indexes are normal in
synchronization, such as RB, RLC, Iu interface. Then follow the flow for analyzing cell-level traffic
statistics data.
If the PS throughput of one or two cells is abnormal, this cannot be reflected by RNC-level traffic
statistics. Therefore, analyzing cell-level traffic statistics data is necessary even if RNC-level traffic
statistics is normal.
Select a representative service in the network, or a continuous coverage service. Analyze the average
throughput of each cell for the selected service by Nastar and sort the cells by cell throughput. Select
the top N worst cells for analysis.
The cells with 0 PS RAB setup request is excluded from sorting alignment, namely, the total number
of the four indexes listed in 4.2.2 is 0. Such cells are considered as having no PS service request, so
they are excluded from sorting alignment the worst cells for PS throughput.
1. Indexes to judge
whether a cell has
PS service
request
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.
3. Analysis of cell
performance/Iub
interface
measurement
Take statistics of traffic flow, signaling flow, FACH/RACH/PCH transport channel flow, and Iub
CCH bandwidth.
If the total service throughput approaches available Iub bandwidth of TCH, the throughput may
declines due to inadequate Iub bandwidth. Solve this problem by adding transmission bandwidth.
4. Cell
Measurement/Cel
l RLC
Measurement
Analysis
The causes of high RLC retransmission rate and PDU packet dropping rate are:
To confirm weak coverage problem, perform DT/CQT and analyze CHR as below:
Title Description
1. Flow for
analyzing DT/CQT data
For access, call drop, signaling plane, and handover problems, see W-Access Problem Optimization
Guide and W-Handover and Call Drop Problem Analysis Guide. This guide supplements some
operations in PS service test.
1. Access Failure
There are two ways to use PS services:
The signaling of originating PS services by UE directly is the same as that of PC + UE. The difference
lies in the access point name (APN), and the way to set the address for service visiting.
If the UE fails to originate PS services directly, following the step below for analyzing causes:
2. UE as the Modem of PC
5.1.2 shows the flow for analyzing access problem when the UE serves as the modem of PC.
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.
In 5.1.2, Probe contains two windows: RRC Message, and NAS Messages. The signaling point
in NAS Messages window corresponds to the point of direct transfer messages in RRC Message.
The following problem may occur due to the comparison of signaling flow:
DCH bearer
5.2.1 shows the flow for analyzing RAN side problem about disconnection of service plane for DCH
bearer.
3. Connection Performance
Measurement-Downlink
Throughput and
Bandwidth window
In 5.2.1,
The bandwidth shown is the bandwidth assigned for UE by system.
The DLThroughput is the actual throughput of downlink data transfer.
Monitor the variation of access layer rate and non-access layer rate of
uplink and downlink data transfer for the current connection. This helps
analyze the functions of dynamic channel configuration and variation
features of service source rate.
If the uplink throughput is 0, the uplink may be disconnected.
If the downlink throughput is 0, the downlink may be disconnected.
When the RNC DCCC function is valid, distinguish the variation of
bandwidth caused by DCCC.
If the problem is still 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.
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:
4. HSDPA parameters in
Probe
Wherein, the HS-SCCH Success Rate (%) is the HS-SCCH scheduling
success rate of the UE. It is relevant to the following parameters:
Number of HS-SCCHs
Number of HSDPA subscribers
Scheduling algorithm parameter
If an HS-SCCH is configured to the HSDPA cell, the scheduling algorithm
is the RR algorithm, and all the connected subscribers keeps data transfer,
the HS-SCCH success rate is the reciprocal of number of subscribers.
Namely, all the subscribers share the HS-SCCH resource.
If the HS-SCCH success rate of a subscriber approaches 0, the data
transfer rate of the subscriber approaches 0, and the service plane may be
disconnected.
The HS-SCCH success rate approaches 0 due to:
The scheduling algorithm is much similar to MAX C/I algorithm, more than
one HSDPA subscribers connects to the cell, and the CQI of the subscriber is
low.
The transmit power of HS-SCCH is over low. Now in the indoor scenario, the
transmit power of HS-SCCH is fixed to 2% of total transmit power of cell. In
outdoor scenarios, the proportion is 5%. If the transmit power of HS-SCCH is
lower than the fixed power, the UE may fail to demodulate HS-SCCH data.
No data is transmitted at the application layer. Confirm this by the actual
transmitted data volume in the Connection Performance Measurement-
Uplink Throughput and Bandwidth, Downlink Throughput and
Bandwidth on RNC LMT.
The CQI reported by UE is over low, so the NodeB will not schedule the
subscriber.
SBLER being 100%
The SLBER is the slot block error rate of HS-DSCH. In 5.2.1, the right
pane of the WCDMA HSDPA Decoding Statistics window shows the
SBLER and retransmission conditions of transport blocks of different
sizes. The WCDMA HSDPA Link Statistics window shows the
following parameters:
HS-DSCH SBLER-Deta
HS-DSCH SBLER-Average
Wherein, the 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.
The available power of HS-PDSCH in static power configuration =
maximum transmit power of cell power margin R99 downlink load
(including CCH load) HS-SCCH power.
The available power of HS-PDSCH in dynamic power configuration =
power of HS-PDSCH and HS-SCCH HS-SCCH power.
Note the static power configuration. Due to power control, the R99
services can use HS-PDSCH power.
According to previous two formulas, in dynamic power configuration of
HSDPA power, if the power margin is over large, R99 downlink load is
over high, or HS-SCCH power is over high, the available power of HS-
PDSCH is over low. In static power configuration of HSDPA power, if the
HS-PDSCH and HS-SCCH power are over low, or HS-SCCH power is
over high, the available power of HS-PDSCH is over low.
SBLER is 100% seldom due to inadequate power, unless the CQI reported
by UE is over small. When the power of NodeB is inadequate, the CQI
calculated by NodeB is smaller, the scheduled TB blocks becomes smaller,
so the rate obtained by UE declines.
Solution: adjust parameter configuration. If the R99 load is over high, add
carriers.
Check the available bandwidth, occupied bandwidth, and assigned
bandwidth at Iub interface
Query Iub bandwidth by executing the command DSP AAL2PATH on
RNC LMT. Or start the task Periodic Reporting of Iub Bandwidth
Assignment Conditions of HSDPA on NodeB console.
If errors occur in data transmission, the IMA group number of
AAL2PATH (For HSDPA) on NodeB fails to match that on RNC. When
the available bandwidth of HSDPA is inadequate due to product software
problems, the data transfer is unavailable.
5.2.2 shows the flow for analyzing problems at CN side about disconnection of service plane.
1. Flow for analyzing
problems at CN side
about disconnection of
service plane
Confirm by other access network or LAN that the service software servers and service software run
normally.
LAN
Use FTP or HTTP service on a PC connected to LAN, and check whether
the service is available. In addition, verify the user name and password of
the connected user.
Other radio access network under the same CN
If different 3G access networks under the same CN sets up PS service or
sets up PS service from the GRPS network, check whether the service is
normal.
After previous checks, if the service servers work normally, focus on the problems at RAN side for
analysis. If the service servers are abnormal according to previous checks, ask the on-site engineers of
CN PS domain to solve the problem.
The IP address for visiting FTP and HTTP service servers by LAN is different from that for visiting
service servers after the UE sets up wireless connection. For details, turn to on-site engineers of CN
PS domain.
3. Poor Performance of Data Transfer
The poor performance of data transfer, in terms of throughput measurement, lies in the following
problems:
The PS services use the AM mode of RLC and support retransmission function. The FTP and HTTP
services use TCP protocol which supports retransmission. The parameters of these two protocols
(RLC/TCP) have great impact on rate.
If the parameter configuration is improper, or missing and dropping data packet may cause the data
rate to decline. When checking the quality of service (QoS), engineers make UE as the modem of a
computer running applications, so the performance of computer and servers will influence the QoS.
By and large, several factors affect the performance of data transfer of PS services, and they include:
RAN side
CN equipment
Applications and service software
The applications and service software problems are contained in the CN side problems. 5.3 shows the
flow for analyzing poor performance of data transfer.
1. Flow for analyzing poor
performance of data
transfer
1. Checking Alarms
If there is a problem, check whether there are alarms. Query the NodeB and RNC alarms at RAN side.
Query the SGSN, GGSN, LAN switch, router, and firewall at CN side. The alarms like abnormal
clock alarms, high transmission error rate, and abnormal equipment affect data transfer.
If problems cannot be located according NE alarms, refer to 5.3.2. By comparing operations and
analyzing problem, reduce the scope of problem.
1. Comparing
operations and
analyzing
problem
After the approximate scope of problem cannot be located after previous checks, analyze it as a
problem of data transfer at RAN side and CN side.
5.3.3 shows the flow for analyzing RAN side problem about poor performance of data transfer on
DCH.
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.
Data transfer affected by Uu interface
When PS services are carried by DCH, the factors affecting data transfer at
Uu interface includes:
DCH bandwidth
State transition
Block error rate (BLER) at Uu interface
5.3.3 shows the 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:
The bandwidth is the same as the request rate or subscribed rate.
Maximum assignable rate (such as 384 kbps) is met upon DCH bearer.
If the bandwidth assigned to UE is smaller than the expectation, there are
two causes:
Congestion or other causes. The RAN cannot assign UE with channels of
higher rate, which is abnormal.
DCCC algorithm of RNC. If the DCCC algorithm parameter is rational, the
decline of rate is normal.
Enable the DCCC algorithm in the existing network so that the system can
save resource by reducing assigned bandwidth upon decline or pause of
data transfer. However, the DCCC algorithm configuration may be
irrational. DCCC algorithm involves rate adjustment based on traffic and
coverage, and rate adjustment in soft handover (SHO) SHO areas.
According to the parameters configured on site and based on algorithm,
judge whether the assignment and adjustment of DCH bandwidth are
rational, whether there are abnormalities, and whether the problem is solve
by adjusting parameters.
If the assigned DCH bandwidth is small due to congestion and other
abnormalities, solve the problem by the following methods:
Trace signaling of single subscriber
Query cell downlink load, assignment of code resource, and available
bandwidth at Iub interface
Obtain CHR from BAM and check the abnormalities on RNC INSIGHT
PLUS or Nastar.
BLER at Uu interface
The BLER at uplink and downlink Uu interface directly affect data
transfer of PS services. If the average of UL BLER or DL BLER measured
in a period is equal to or better than BLER Target, the code errors at Uu
interface are normal. Otherwise, analyze this problem.
DL BLER measurement: collect DT data by Probe and UE, and then
import the DT data to Assistant for analysis.
UL BLER measurement: In Connection Performance Measurement-
Uplink Transport Channel BLER window, import the measurement file
to Assistant, and analyze together with the Probe DT data files.
The power control and coverage affects the uplink and downlink BLER in
the following aspects:
Outer loop power control switch. Check that the outer loop power control
switch of RNC is on.
Coverage. Check whether the uplink and downlink are restricted in the areas
with bad UL BLER and DL BLER. For details, see W-RF Optimization
Guide.
Performance of UE. Change a UE of other types and compare their
performance.
In Sequence Delivery
Set the sequence submission to TURE or FALSE. This affects the rate and
fluctuation of downlink. If you set the sequence submission to TURE, the
RLC keeps the transfer sequence of upper-layer PDUs. If set the sequence
submission to FALSE, the receiver RLC entity allows sending SDUs to
upper-layer in a sequence different from the sender. If you set the sequence
submission to FALSE, the uplink rate for data transfer will be low and data
transfer fluctuates much.
Setting sequence submission to TURE by executing the command MOD
GPRS on Huawei HLR is recommended.
Data Transfer Affected by Iub Interface
The transport code error at Iub interface, delay jitter, and Iub bandwidth
affect the performance of data transfer.
5.3.3 shows the flow for analyzing data transfer affected by Iub interface.
3. Flow for analyzing data
transfer affected by Iub
interface
Subscribed rate
Bandwidth at Iub interface
Maximum rate supported by RNC, NodeB, GGSN, and SGSN.
When there are multiple subscribers, besides previous factors, the scheduling algorithm used by
NodeB and number of HS-SCCH configured to cell affects the rate of data transfer.
The UE reports CQI on HS-DPCCH. The NodeB obtains the CQI of UE's
location.
The scheduling module inside NodeB evaluates different subscribers by
channel conditions, the amount of data in cache for each subscriber, the last
serving time. It then determines the HS-DSCH parameters.
The NodeB sends HS-DSCH parameters on HS-SCCH, and after two slots it
sends data on HS-DSCH.
The UE monitors HS-SCCH for information sent to it. If there is any
schedule information, it starts receiving HS-DSCH data and buffers them.
According to HS-SCCH data, the UE judges whether to combine the received
HS-DSCH data and data in soft buffer.
The UE demodulates the received HS-DSCH data, and send the ACK/NACK
message on uplink HS-DPCCH according to CRC result.
If the NodeB receives the NACK message, it resends the data until it receives
the ACK message or reaches the maximum retransmission times.
In the DT tool Probe, out of consideration for multiple subscriber scheduling and retransmission at
MAC-HS layer, there are three rates at MAC-HS layer:Scheduled RateServed RateMAC Layer
Rate.
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.
You can also check the information like reported CQI in the WCDMA HSDPA Link
Statistics window in the DT software Probe. If no information is in the window, the service must be
carried on DCH, as shown in 5.3.4.
3. Confirming in Probe
that service is set up on
HSDPA channel
If the service is not set up on HSDPA channel, it will automatically be set up on DCH. Now the
service rate is the rate of R99 service, usually equal to or smaller than 384 kbps.
If it is confirmed that the service is not set up on HSDPA channel, analyze it from the following
aspects.
Normally, there is mapping relationship (depending on mapping table of NodeB CQI in actual use)
between the schedule rate and CQI reported by UE. The NodeB will filter and adjust the CQI reported
by UE, so the scheduled rate and CQI scheduled by NodeB have mapping relationship, not completely
having mapping relationship with the CQI reported by UE.
5.3.4 lists the relationship between CQI and TB size according to the protocol 3GPP 25.306. It is only
for reference, the product realization does not completely consist with protocol.
1. Relationship
between CQI and
TB size when the
UE is in category
1112
1 137 1 QPSK 0
2 173 1 QPSK 0
3 233 1 QPSK 0
4 317 1 QPSK 0
5 377 1 QPSK 0
6 461 1 QPSK 0
7 650 2 QPSK 0
8 792 2 QPSK 0
C Trans Nu Modul Referen
Q port mbe ation ce
I Block r of power
va Size HS- adjustm
lu PDS ent
e CH
9 931 2 QPSK 0
10 1262 3 QPSK 0
11 1483 3 QPSK 0
12 1742 3 QPSK 0
13 2279 4 QPSK 0
14 2583 4 QPSK 0
15 3319 5 QPSK 0
16 3319 5 QPSK 1
17 3319 5 QPSK 2
18 3319 5 QPSK 3
19 3319 5 QPSK 4
20 3319 5 QPSK 5
21 3319 5 QPSK 6
22 3319 5 QPSK 7
23 3319 5 QPSK 8
C Trans Nu Modul Referen
Q port mbe ation ce
I Block r of power
va Size HS- adjustm
lu PDS ent
e CH
24 3319 5 QPSK 9
25 3319 5 QPSK 10
26 3319 5 QPSK 11
27 3319 5 QPSK 12
28 3319 5 QPSK 13
29 3319 5 QPSK 14
30 3319 5 QPSK 15
2. Relationship
between CQI and
TB size when the
UE is at the level
16
1 137 1 QPSK 0
C Trans Nu Modula Refere
Q port mbe tion nce
I Block r of power
va Size HS- adjust
lu PDS ment
e CH
2 173 1 QPSK 0
3 233 1 QPSK 0
4 317 1 QPSK 0
5 377 1 QPSK 0
6 461 1 QPSK 0
7 650 2 QPSK 0
8 792 2 QPSK 0
9 931 2 QPSK 0
10 1262 3 QPSK 0
11 1483 3 QPSK 0
12 1742 3 QPSK 0
13 2279 4 QPSK 0
14 2583 4 QPSK 0
15 3319 5 QPSK 0
16 3565 5 16-QAM 0
C Trans Nu Modula Refere
Q port mbe tion nce
I Block r of power
va Size HS- adjust
lu PDS ment
e CH
17 4189 5 16-QAM 0
18 4664 5 16-QAM 0
19 5287 5 16-QAM 0
20 5887 5 16-QAM 0
21 6554 5 16-QAM 0
22 7168 5 16-QAM 0
23 7168 5 16-QAM 1
24 7168 5 16-QAM 2
25 7168 5 16-QAM 3
26 7168 5 16-QAM 4
27 7168 5 16-QAM 5
28 7168 5 16-QAM 6
29 7168 5 16-QAM 7
30 7168 5 16-QAM 8
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.
In static power distribution, the R99 services may occupy the power of HSDPA cell, so the actual
power used by HSDPA cell is not the configured power.
Analyze the factors affecting available power of HSDPA cell from the
following aspects:
Query power margin by executing the command LST MACHSPARA on
NodeB. The default power margin is 10%, namely, the total downlink load of
cell can use 90% of total power of cell.
On RNC LMT, select Realtime Performance Monitoring > Cell
Performance Monitoring > Tx Carrier Power. Observe the transmit carrier
power and power used by non-HSDPA subscribers. The available power of
HSDPA = transmit carrier power - power used by non-HSDPA subscribers. If
the power used by non-HSDPA subscribers is over high, the available power
of HSDPA cell becomes low, so the scheduled rate is affected.
Available codes of HSDPA cell
If inadequate codes are assigned to HSDPA subscribers, the TB size of
NodeB scheduling will be affected..
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..
Amount of data to be transmitted being smaller than the maximum TB size
The TB size scheduled by NodeB depends on the available power and
codes of the subscriber, as well as the amount of data transferred by the
subscriber. If the amount of data sent is smaller than the maximum
scheduled TB size, the rate at physical layer is lower than the expectation.
This problem occurs when there is data in NodeB buffer but the amount of
data is inadequate for a scheduled maximum TB size.
The success rate of HS-SCCH is relevant to HS-SCCH power, number of HS-SCCHs, number of
subscribers, scheduling algorithm, and transported traffic. The following paragraphs describe them
respectively.
1. HS-SCCH power
offset
4 10.75 6.75
8 7.75 3.75
16 4.75 0.75
32 1.75 +2.25
64 +1.25 +5.25
IBLER
IBLER affects MAC-HS retransmission, so it consequently affects the
actual rate of subscribers. The IBLER here is number of incorrect
TBs/number of total new data blocks when the NodeB transmits new data.
The SBLER here is number of incorrect blocks/(number of incorrect and
correct blocks) when the NodeB transmits new data or retransmits data.
IBLER directly affects SBLER. Now the default IBELR is 10%. IBLER
directly affects the power for scheduling each subscriber. This is similar
with outer loop power control of R99.
Execute the command SET MACHSPARA to set the following items:
Scheduling algorithm
MAC-HS retransmission times
Power margin
HS-SCCH power
Initial BLER
The MML command is as below:
SET MACHSPARA: LOCELL=1, SM=PF, MXRETRAN=4,
PWRMGN=10, PWRFLG=FIXED, PWR=5, IBLER=10;
Low CQI and inadequate HSDPA power
If the CQI reported by UE is low, and the available power of HSDPA is
inadequate, SBLER will be high. The size of an MAC-d PDU is 336 bits.
The MAC PDU requires the TB size larger than 336 bits in transmission.
As a result, the CQI upon NodeB's scheduling must be larger than a value
to meet that IBLER is within 10%.
CQI reported by UE being higher than actual one
The CQI reported by UE is inaccurate, higher than the actual one. The
NodeB adjusts the CQI according to target IBLER, but it takes some time
for adjustment. During this period, the NodeB transfers data with low
power according to the CQI reported by UE. As a result, the SLBER is
high, so the performance of data transfer is affected.
Solution: by Windows HyperTerminal, connect UE to the data card.
Adjust the CQI reported by UE by executing AT commands (This solution
caters for Huawei data card only. The current version does not support
this).
Assume: before the following operations, the CQI reported by connected
UE is 25.
Enable the function of adjusting CQI, set the offset to 200, and lower CQI.
Type the following command:
AT^CQI=1,-200
The UE responds OK. The CQI is 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.
Disable the function of adjusting CQI. Type the following command:
AT^CQI=0,200
The UE responds OK. The CQI remains 2728.
If you type wrong parameters as below:
AT^CQI=1,100,1
The UE responds TOO MANY PARAMETERS.
If you query the state of CQI adjustment function, type the following
command:
AT^CQI?
When the UE responds +CME ERROR, the current NV time 4448
NV_CQI_ADJUST_I is not activated, and the adjustment function is
disabled.
When the UE responds ^CQI:0,200, the function of adjusting CQI is disabled.
When the UE responds ^CQI:1,200, the function of adjusting CQI is enabled.
Over low pilot power
On prior version of NodeBs, according to RTT test,
If the power of other channel is 10 dB higher than pilot channel, this leads to
a 10% code error for HSDPA.
If the power of other channel is 13 dB higher than pilot channel, this leads to
a 100% code error for HSDPA.
Now the NodeB can adjust power in a certain scope according to HSDPA
SBLER. If the power of other channels is 13 dB higher than the pilot
power, the impact on throughput is little. Setting PICH over low is
forbidden; otherwise, the power is inadequate after adjustment by NodeB.
This leads to over high SBLER, and consequently the throughput is
affected.
If Scheduled RateServed Rate and MAC Layer Rate is normal , it need more adjust whether RLC
Throughput is normal.
Because PDUs caput spending rate is small , watch RLC Throughput and MAC Layer Rate from
Probe, the curve superposition
In the WCDMA HSDPA Decoding Statistics window, you can see ACK-
>NACK/DTX. In , ACK->NACK/DTX is 76.01%. The right pane displays
detailed number of blocks that are correct received and retransmitted. As a
result, ACK->NACK/DTX=7808/(7808+2465)=76.01%.
In the WCDMA HSDPA Link Statistics window, the MAC Layer Rate-
Average is 67.33 kbps. In the left pane, the RLC DL Throughput is 16.19
kbps. The ratio of RLC rate and MAC rate is 16.19/67.33, equal to
24.05%. If the correct blocks that are repeated received is excluded from
calculating MAC layer rate, the MAC layer rate is 67.33 * (1- 76.01) =
16.15 kbps. The MAC layer rate is approximately equal to RLC rate.
Over low configuration of HS-DPCCH power parameters
HS-DPCCH is an uplink dedicated physical channel, transporting the
ACK/NACK, and CQI messages at physical layer. HS-DPCCH is not
under respective power control, but has a power offset with downlink
DPCCH. When HS-DPCCH carries different information, it uses
different offset values.
If the ACK/NACK power offset on HS-DPCCH is over low, the ACK-
>NACK/DTX demodulated by NodeB in uplink will be overhigh, and
consequently the subscribers' rate is affected.
For the description of HS-DPCCH power parameters, see the appendix
HS-DPCCH Power Control Parameter Configuration.
Uplink and downlink RL imbalance in handover areas
The uplink and downlink RL imbalance in handover areas are defined
as below, and shown in:
RL2_dl > RL1_dl
RL2_ul < RL1_ul
Because RL2_dl > RL1_dl, the serving cell is updated, and the HSDPA
service is set up in the cell 2. The RNC adjusts SIRtarget according to
combination result of two UL RLs due to SHO. The two cells perform
inner loop power control according to SIRtarget. The UE combines the
downlink TCP of the two cells. According to combination principles, if the
TCP of one cell is 1, lower power accordingly. When the TCP of two
cells is +1, raise power.
Because RL2_ul < RL1_ul, the RL1_ul SIR is converged to target value,
and RL2_ul SIR is lower than the target value. The power control over
HS-DPCCH is based on the associated channel of RL_ul, so the
demodulation performance of HS-DPCCH ACK/NACK/CQI cannot meet
requirement. As a result, the performance of data transfer for HSDPA
subscribers is poor.
Analysis proceeds as below:
Obtain HSDPA-HSDPA handover test data, including the data at UE side and
RNC side.
According to single subscribing signaling tracing, analyze to see whether
there is a serving cell updated due to UL RL failure. If yes, find the UE APP
throughput at the corresponding point.
With the data at RNC side, draw a chart involving uplink SIR, SIRtarget, UL
BLER, downlink throughput, PCPICH RSCP and Ec/No. Obtain the SIR
information on HSDPA uplink associated channel.
Based on the results from Step 2 and 3 above, obtain the information about
RL imbalance.
Analyze RL imbalance and provide solutions.
Over high RLC retransmission rate due to over high residual BLER at MAC
layer
If the retransfer at MAC layer reaches the maximum times, the TBs
incorrectly received will be dropped. If the receiver detects dropping data
packets, it requires the sender to resend data packets by state report.
Retransfer lowers the sending efficiency of RLC, so it affects the valid
throughput of RLC. When residual BLER at MAC layer is over high, the
SBLER at MAC layer is probably over high. For detailed analysis, see the
analysis of over high SLBER in previous sections.
Normal the residual BLER at MAC layer is smaller than 1%.
shows the residual BLER at MAC layer in WCDMA HSDPA Decoding
Statistics window.
The RTT delay at the RLC layer is exceptional (the RLC state report disable
timer is not set properly/the uplink BLER is not converged) so that the RLC
send window is full.
Currently, the maximum size of the RLC send window can be set to 2047
(the RLC receive/send window size of the terminal is 2047). When the
RLC transmission rate is very high, the RLC send window is easily full
and cannot send other data if the state report is not returned in time.
For example, the rate on the air interface is 3 Mbit/s and the MAC-D PDU
size is 336 bits, the RLC send window can send data for (2047 x 336)/(3 x
1024) = 224 ms. If the RNC fails to receive a state report within 224 ms,
the RLC send window is full.
The return time of the state report is related to the state report disable timer
and the uplink air interface quality. If the state report disable time is set too
long, or the uplink BLER is not converged, the RLC send window may be
full.
Solution:
Check whether the state report disable timer is set properly and whether it
is set to the default of the baseline. Currently, the default timer length is
120 ms (service-oriented configuration) in the RNC V16 and 80 ms for the
3.6 Mbit/s services (service-oriented configuration) in the RNC V17.
Check the convergence of the uplink BLER to ensure the BLER is
converged.
Compare the throughputs at the application layer (APP) and the RLC layer.
TCP/IP adopts the inclusive acknowledgment strategy for reliable data
transmission and the sliding window protocol for flow control, and
performs congestion control when detecting a network congestion.
Flow control (sliding window)
Flow control is used to prevent buffer overflows and saturation of the
receiving machine. Flow control generates a window value for the
sender to transmit the specified number of bytes in the window. After
that, the window is closed and the sender must stop data transmission.
The window is not opened until the sender receives an ACK from the
receiver.
Inclusive acknowledgment strategy
All to-be-transmitted bytes before the confirmed byte number are
acknowledged. Suppose that 10 data fragments are to be transmitted.
These data fragments cannot reach the destination in sequence. TCP
must acknowledge the highest byte number of consecutive bytes
without any error. The highest byte number is not allowed to be
acknowledged before all the middle bytes reach the destination. If the
acknowledgment to the middle bytes is not sent to the sender, the sender
TCP entity finally times out and retransmits the unacknowledged data.
Congestion control (timeout and retransmission)
The 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:
Configured TCP receive/send window
Although the receive window size is dynamic (if packets out of
sequence are received or packets cannot be submitted to the upper layer
in time, the available window size becomes small), the configured
window size determines the maximum available size of the receive
window.
According to the formula Capacity (bit)=bandwidth (b/s)*round-trip
time (s), if the receive/send window is too small, the transmission rate is
affected.
Congestion caused by RTT fluctuation
The throughput at APP and RLC layer is obtainable by DT/CQT. For
the theoretical relationship of rate at each layer, see the appendix 8.2.
If the rate of APP throughput and RLC throughout is lower than the
normal range according to theoretical analysis, the retransmission cost
of TCP/IP is over large. Check and modify the TCP receiver window
and MTU configuration. For the method, see the appendix 8.4 and 8.5.
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.
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)
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.
MAC-e PDU Available Rate = Sum of TB sizes when COMB_HICH is ACK
or ACK_NS in the case of non-DTX/(NUM_SAMPLES*TTI)
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.
Relationship between these three throughputs:
MAC-e PDU Served Rate = MAC-e PDU Non-DTX Rate * Non-DTX
Probability
MAC-e PDU Available Rate MAC-e PDU Served Rate *(1-SBLER)
Where,
Non-DTX Probability = Number of non-DTXs/NUM_SAMPLES *
100%
SBLER = (Number of non-DTXs Number of ACK or
ACK_NS)/Number of non-DTXs * 100%
UL RLC PDU Throughput = Sum of bits of all RLC PDUs sent by the RLC
layer within the measurement period/Measurement period duration
Sum of bits of all RLC PDUs sent by the RLC layer within the measurement period: The first
transmitted data and the retransmitted data are included. In addition, the data is transferred by MAC-d
and contains the header overhead (16 bits) of the RLC PDU.
Measurement period duration: The time when data is transmitted and the time when no data is
transmitted are both included.
Relationship with MAC-e PDU Available Rate:
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
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:
RLC SDU Throughput UL RLC PDU Throughput UL*(1-RLC PDU
Retransmission Rate UL)*header overhead ratio of the RLC PDU
The figure below shows the optimization flow of a low throughput of the HSUPA UE.
2. Optimization flow of a
low throughput of the
HSUPA UE
Service Setup on an E-DCH
Check whether the serving E-DCH RL indicator in the RB SETUP message of the RNC is True, as
shown in the figure below. If yes, the service is borne on the HSUPA.
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.
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 HSUPA cell is available and activated.
The access of the HSUPA UE fails.
Check whether the type of the HSUPA AAL2PATH is configured correctly
and whether a type of HSUPA AAL2PATH is configured.
Abnormal MAC-e PDU Non-DTX Rate
The UE compares its current MAC-e PDU Non-DTX Rate with the maximum allowable ETFC
according to the corresponding ETFC of the SG that the UE currently maintains. Make analysis in
combination with the Happy/Unhappy information reported by the UE.
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:
1. Categories of UE
HSUPA
capability levels
2 ms TTI
2 ms TTI
2 ms TTI
When 4 codes are transmitted in parallel, two codes shall be transmitted with SF2 and two with SF4
Observation method:
Observe the UE capability
Generally, the terminals supporting the HSUPA function all support the
HSDPA function. That is, the HSPA bears the services of users as a
whole. The following describes how to observe the HSPA function that
the UE supports and the specific HS-DSCH/E-DCH capability level in
combination with actual RRC messages.
First, the RRC_CONN_REQUEST message reported by the UE
indicates whether the HSDPA and the HSUPA functions are supported.
In the figure below, the capability reported by the UE indicates that the
UE supports HS-DSCH and E-DCH.
5. RRC CONNECTION
REQUEST message
When the DCCC algorithm of the HSUPA is disabled, the RNC configures the maximum capability
according to the MBR of the UE. When the DCCC algorithm of the HSUPA is enabled, the
maximum capability is affected by the initial access rate of the DCCC.
Solution:
Improve the capability of the RAN side or use a terminal with a higher
capability level.
The transmit power of the terminal is limited.
Principle description
The UE calculates the transmit TB size according to the currently available
transmit power. Then, the UE selects the smaller between the TB size
supported by the transmit power and the TB size supported by the SG as
the actual transmit TB size.
The available transmit power of the UE is the same, but the transmit TB
size may be not the same. The factors that influence the TB size are as
follows:
The UE is at the edge of a cell and the uplink path loss is large.
The uplink load of the cell is high (the UE is not at the edge of a cell).
The UE performs combined services. The DCH service consumes much
power and insufficient power is available to the E-DCH service.
Observation method:
Method of observing whether the transmit power of the UE limited:
Observe the power limited rate reported by the UE through the Assistant. If
the power limited rate is greater than 0%, the transmit power of the UE within
the corresponding measurement period of the measurement value is limited.
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.
The traffic of the terminal is limited.
Principle description:
If the data in the UE RLC Buffer is insufficient, the actual MAC-e PDU
Non-DTX Rate is low.
Observation method:
Method of observing whether the traffic of the UE is limited
Observe the buffer limited rate reported by the UE through the
Assistant. If the buffer limited rate greater than 0%, the traffic of the UE
within the corresponding measurement period of the measurement value
is limited.
9. Display of the Assistant
HSUPA related
information (limited
traffic)
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.
Cause 2: The IUB bandwidth is limited.
Principle description:
1) According to basic function 1 of the HSUPA scheduling, when the
available bandwidth of the Iub HSUPA is limited on the RAN side, the
target load is the adjusted target value after flow control (principle of
the Iub flow control: adjust the target load according to the buffer
change trend on the transmission path). If the actual cell load exceeds
the target load value, the data transmission delay is prolonged or even
packet loss occurs on the Iub interface so that the data transmission
performance is affected. Therefore, the actual cell load needs to be
controlled.
2) When the ATM is adopted on the Iub interface, the HSUPA Iub
bandwidth utilization = TCP layer rate/ATM bandwidth
11. ATM transmission
efficiency
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
12. P bandwidth utilization
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.
Cause 3: The NodeB CEs are limited.
Principle description:
When the NodeB CE resources on the RAN side are limited, the
dynamic CE adjustment algorithm (not implemented in NodeB V18 but
implemented in later versions) reduces the MBR of the UEs or the
minimum available SF.
Observation method:
Make observations on the NodeB debugging console.
Solution:
Add CEs.
The service MBR (NodeB MBR) is limited.
Principle description:
See the description of basic function 2 of the HSUPA scheduling.
Concepts of CN assigned MBR, RNC MBR, and NodeB MBR
CN assigned MBR:
The CN notifies the RNC of the assigned MBR in a RAB Assignment
Request message.
UE MBR:
15. RB SETUP message
(containing the
maximum number of
available channel codes)
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.
Step 3: Compare the rates obtained in the previous two steps.
If the rate on the DU meter is approximate to the RNC MBR and the
corresponding UE MAC-e PDU Served Rate is approximate to the
NodeB MBR, the NodeB MBR is limited.
Solution:
To improve the throughput of a UE, modify the subscription information
and configure a higher MBR.
The UE demodulates incorrectly.
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.
Observation method:
For cause 1:
Step 1: Confirm the current power control mode by using an MML
query command.
COMMAND: LST MACEPARA (NodeB LMT)
Step 2: If the power control mode is fixed transmit power relative to the
PCPICH (default algorithm in V18), check whether the parameters used
by the system are baseline parameters.
If not, change the parameters to the baseline parameters and observe
whether the problem is solved. If the problem is not solved, confirm the
pilot signal quality (PCPICH RSCP and Ec/Io) in the position where the
UE is located. The baseline parameters are set on the assumption that a
signal Ec/Io is given at the edge of the cell. If the actual signal Ec/Io at
the edge of the cell is less than the assumed value, increase the power
offset (PO) on the basis of the baseline parameters.
1. PO for the E-
AGCH when the
Ec/Io at the edge
of cells is 12 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).
2. PO for the E-
RGCH when the
Ec/Io at the edge
of cells is 12 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.
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.
Relationship between the MAC-e PDU Served Rate and the MAC-e PDU Non-DTX Rate:
Served Rate = MAC-e PDU Non-DTX Rate * Non-DTX Probability
Locating an served rate exception is the process of locating a non-DTX probability exception.
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.
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".
Relationship between the MAC-e PDU Available Rate and the MAC-e PDU Served Rate:
Locating a MAC-e PDU available rate exception is the process of locating an SBLER exception.
You can set the target number of the MAC-es PDU retransmissions (usually 0.1 on average) on the
RNC LMT.
If the measured SBLER deviates greatly from the target number of MAC-es PDU retransmissions, it is
considered as an SBLER exception.
3. PO for the E-
HICH when the
Ec/Io at the edge
of cells is 12 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.
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.
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:
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 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.
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.
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.
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.
If MAC-e PDU Non-DTX Rate, MAC-e PDU Served Rate, and MAC-e PDU Served Rate are all
normal, the traffic of the UE is limited, but the data to be sent is sufficient, it can determined that the
TCP/IP layer rate is exceptional.
Too small a TCP receive window on the receiver side makes the send
window easily full.
Principle description:
TCP/IP adopts the sliding window protocol. The sliding window
protocol allows the sender to transmit multiple consecutive packets
before the sender stops transmission and waits for an acknowledgment.
As it is unnecessary for the sender to stop and wait for an
acknowledgment each time it transmits a packet, the sliding window
protocol increases the data transmission rate.
Theoretically, TCP receive window size should be greater than the
product of the bandwidth and the delay.
Capacity(bit)=bandwidth(b/s)*round-trip time(s)
A 66535-byte window is sufficient for the 1.6 Mbit/s service, but
insufficient for 3.6 Mbit/s service. Especially when the delay is greater
than 200 ms, the TCP window is easily full. As a result, you observe
that the buffers of the RLC and the NodeB are 0.
Observation method:
1) Query the configuration of the TCP receive window at the receiver
end.
2) Obtain the current Ping delay (test the RTT)
3) Observe the rate on the UE/DU meter is approximate to the TCP
receive window size/RTT.
Solution:
1) Change the TCP receive window size at the receiver end.
Use the following registry entries to set the receive window size to 80
KB (80*1024 = 81920).
Method 1:
Use the DRTCP tool to modify the receive window size and restart the
computer.
Method 2:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\
Services\Tcpip \Parameters\TcpWindowSize (REG_DWORD)
Restart the computer.
2) If no DRTCP tool is available, use multiple processes to perform
verification.
A 100% CPU load at the receiving end cause the TCP receive window to be
full.
Principle description:
When the CPU load at the receiving end reaches 100%, the data in the
TCP receive window cannot be submitted to the upper layer and the
TCP receive window is full.
When the TCP receive window is full, the receiver notifies the TCP
sender of it and the sender stops transmitting data. As a result, the RLC
BO is 0 and the UE transmits no data.
Observation method:
Observe the Performance tab page in the Windows Task Manager.
17. Receiver's CPU
performance observation
window
Solution:
1) Close the programs not related to the test at the receiving end.
2) Use high-performance computer at the receiving end.
The RTT timeout at the TCP/IP layer caused by packet loss at the CN side
triggers congestion avoidance.
Principle description:
TCP provides the reliable transport layer. One of the methods that TCP
uses is acknowledging the data received from the other peer, however,
data and acknowledgment may be lost. TCP solves the problem by
starting a timer when it starts transmitting data. If no acknowledgment
is received when the timer expires, TCP retransmits the data.
The TCP sender measures the RTT of a connection (measures the RTT
from when it transmits a byte with a special sequence number to when it
receives an acknowledgment containing this byte) to maintain an RTT
timer.
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.
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.
NE Alarms
At CN side, analyze the alarms on SGSN, GGSN, LAN switch, router, and firewall (collecting SGSN
and GGSN alarms as key task). Clock alarms and transport code error alarms may lead to fluctuation
of PS data.
Package lose on CN side result in TCP/IP layer RTT overtime touch off
congestion avoidance
TCP apply credible transmit layer. One method is to affirm the data which receive from the other side.
But data and affirmance may lose . TCP transit set a timer in the send time to solve the problem.
When the timer overflow , it dont receive affirm message, it will retransmission data.
TCP send point will be a measure to a connect RTT. Maintain a RTT timer.
If it measure RTT overtime , TCP think net congestion , it will start-up congestion avoidance.
Consequently, it will affect data transmit rate.
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.
Changing MTU includes changing the MTU of server and changing the MTU of test laptop. After PS
service connection setup, the service negotiates with the client. The MTU in use takes the smaller of
the two MTUs.
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 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.
4. Interruption of Data Transfer
1. Analzying DCH Interruption of Data
Transfer
Description: data transfer is interrupted for a period.
Alarms
Query the alarms on CN and RAN. Know the abnormalities in the operation of current system. Guide
to analyze and exclude problems. Some problem, such as interruption of data transfer, clock
asynchronization in some cells, and NE congestion, can be known from alarms.
Signaling Flow
Analyze signaling in details to locate interruption of data transfer. Check whether call drops, whether
the UE hands over from 3G networks to 2G networks, and whether state transits.
Collect signaling in several ways. Collect the signaling at UE side by using Probe and UE. Collect the
signaling at RNC side on RNC LMT. By comparison of two signaling flow, check whether messages
are lost at air interface. Based on analysis and CHR, engineers can locate the problem or obtain the
rough direction.
Call Drop
For call drop problems, see W-Handover and Call Drop Problem
Optimization Guide.
Channel State Transit
When the cell state transits to CCH, it cannot restore to CELL_DCH.
Check the abnormal information in CHR. If the downlink load is over
large by confirmation, or the bandwidth at Iub interface is congested, add
carriers or transport resources.
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.
The SHO associated HSDPA serving cell update includes two aspects:
During the handover between HSDPA and GPRS, data transfer will also be interrupted.
Alarms
Query the alarms on CN and RAN. Know the abnormalities in the
operation of current system. Guide analyzing and identifying problems.
Some problem, such as interruption of data transfer, clock
asynchronization in some cells, and NE congestion, can be known from
alarms.
Whether downloading is complete
Data transfer is interrupted for a long time, so restoring it is impossible.
Check whether downloading the file by FTP is complete.
Signaling Flow
According to detailed analysis of RNC and UE signaling, judge whether
call drops upon interruption of data transfer, whether the H-H serving cell
is updated, and whether H2D or D2H handover occurs. If the interruption
of data transfer is caused by call drop, analyze the cause of call drop. For
details, see W-Handover and Call Drop Problem Optimization Guide.
Use Qualcomm QXDM and QCAT tool. The interval between dropping
packet at receiver and receiving current data is the interruption time of data
transfer.
Capture TCP/IP packets directly by using the software Ethereal. Analyze the
interval between TCP/IP.
1. Interruption delay of
TCP displayed in
Ethereal
In 5.4.2, the data transfer is interrupted for two times, and the interruption delays are respectively
300ms and 300ms. Compare the TCP rate in Ethereal and the rate at application layer in Assistant, and
they must match. Therefore, obtain the update point of serving cell in Assistant.
6. Cases
Title Description
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.
Analysis
According to statistics of rate at RNC RLC layer, the maximum rate exceeds 64 kbps, and it fluctuates
sharply. As a result, the average rate at application layer displayed by the software FTP is low.
According to signaling tracing and statistics of uplink BLER, the uplink BLER is about 10%. As a
result, the rate at application layer fluctuates and the throughput declines.
Solution
Change the target uplink BLER to 6% or 1%. Change related power control parameter.
Setting different target BLER helps balance the performance of single UE and more UEs. According
to the information from other networks, different target BLER are set for different networks, but they
are small.
Note that setting target BLER is according to index of service type. The uplink and downlink
bandwidth are usually different, namely, the index of service type is different. Set target BLER after
confirming the index of service type.
Analysis
In formal tests, the ping delay of conversational service is 230ms and that of streaming service is
109ms. The conversational service uses 8k/8k, and the streaming service uses 64k/128k. Their
bandwidth is different, so their delay is different.
According to R5 TS23.107 requirement, the delay of conversational must be smaller than 100ms. The
unidirectional delay from UE to Gi interface (UMTS bearer) is 100ms. The delay at RAN is 80ms.
The 80ms shall contain the delay at access layer of UE and exclude that of USB and PC. According to
test, the end-to-end delay is 115ms (230ms/2), so it does not meet the requirement.
It is almost certain that engineers cannot test with 8k/8k bandwidth whether the delay meets the
requirement, because the bandwidth is too small. The RNC of current version support PS
conversational service of 8k only. Now which service uses the type of PS conversational service is
unknown.
Test twice with Sony-Ericsson Z1010, because other UEs fail to support conversational service. After
the UE is activated, execute the command ping over firewall on GGSN through a laptop.
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.
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.
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.
Lower the pilot power and HSDPA power in the following tests, such as by using attenuator.
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.
Select a good test point (CPICH RSCP is about 70 dB, Ec/Io is above 6 dB, and the fluctuation is
stable). Connect 6 HSDPA UEs one by one to the network. The PS service is activated on UE. The
RAN bears PS service on HS-DSCH. Download with FTP, and record the peak throughput of cell.
Disconnect the E1 link of IMA group one by one manually while connect 6 subscribers one by one to
the network. Record the total peak throughput of cell after one subscriber accesses the network.
Draw a curve chart with the recorded peak throughput of cell at every point, as shown in Figure 6-1
and Figure 6-2.
1. Variation of total
throughput of one IMA
link of HSDPA codes
2. Variation of total
throughput of two IMA
links of HSDPA codes
In Figure 6-1 and Figure 6-2, the throughput of one E1 is lower than the throughput of two E1's.
Analysis
The cell uses 5 HSDPA codes, and class-12 UE. The maximum throughput at MAC layer of cell is
1.72 Mbps. The SBLER is 10%, so the throughput at MAC layer of cell is about 1.55 Mbps. In Figure
6-2, the measured throughput of cell is consistent with the theoretical rate, but in Figure 6-1, the
throughput of cell declines.
Check the Iub bandwidth. The AAL2PATH bandwidth is 10 Mbps, but the physical bandwidth is
about 1.9 Mbps with one E1, and 2.8 Mbps with 2 E1's. Obviously, the NodeB flow control does not
consider the variation of physical bandwidth, but allocates bandwidth according to configured
AAL2PATH bandwidth.
The throughput of cell with 2 E1's is not affected by physical bandwidth. This must be analyzed in
terms of flow control at NodeB Iub interface. The Node flow control allocates bandwidth for each
subscriber according to the data amount in NodeB buffer, the data amount of RNC RLC buffer, and
the rate at the air interface.
The Iub flow control allocates bandwidth for subscribers that the maximum allocated bandwidth is
twice of the rate at the air interface. According to previous analysis, the twice of the rate at the air
interface is 3.4 Mbps at most, not exceeding the physical bandwidth of 2 E1's. As a result, the rate of
air interface is not affected when there are 2 E1's. When there is 1 E1, the twice of the rate at the air
interface exceeds the physical bandwidth of 1 E1. As a result, data packets are missing at Iub
interface, and the rate of subscribers is affected.
Solution
Change the AAL2PATH of HSDPA to 1.9 Mbps when there is one E1. Test again, and the rate of
subscribers is about 1.5 Mbps.
In actual networks, guarantee that the AAL2PATH allocated bandwidth to HSDPA is smaller than the
physical bandwidth at Iub interface. This will affect throughput of cell. Meanwhile, check NodeB
alarms whether there are E1 fault alarms.
In the Probe, the following limited rates are displayed in the HSUPA Link
Statistics window to represent these factors.
Power Limited Rate
SG Limited Rate
Buffer 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).
In the figure below, MP in the Reas column indicates the transmission rate of
the UE is currently subject to the maximum transmit power.
In the figure below, BO in the Reas column indicates that the UE current has
no data to send.
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.
Low UL Rate Caused by the Limited Rate of the Buffer to Which the UE
Sends Data Through FTP
Location method: The Buffer Limit Rate observed in the HSUPA Link
Statistics window of the Probe is high, approximate to 100%. BO is all
displayed in the Reas column of all packets captured by the QXDM.
Solution: When the UE uploads data through FTP, the displayed cause for the
buffer limited rate is that the vacancy of the Buffer on the UE side is high
because the application layer sends data to the RLC layer at a low rate. After
the UE is connected to another portable PC, the uplink transmission of UE is
normal. Then, a comparison is made and it is found that the version of the UE
drive on the portable PC is old. After the drive is updated, the uplink
transmission rate is improved. The records on the Probe and the QXDM are
observed later. It is found that no buffer limit exists.
It is also found that different configurations on the portable PC and different
types of portable PCs affect the uplink throughput to different extents. For
example, the uplink throughput tested by an HP portable PC is slightly higher
than that tested by a Dell portable PC. The larger the memory in the portable
PC is, the smaller the buffer limit is.
Low Uplink Transmission Rate Owing to Limited UE SG Caused by
Limited Cell Load
Location method: The SG limited rate observed in the HSUPA Link Statistics
window on the Probe is very high. SG is displayed in the Reas column in
most captured packets but the current SG does not reach the maximum value.
The maximum value in HSUPA phase1 of E270 (cat3) is 23.
Symptom and cause: If the cell load is limited, you often see that the cellload
value reaches 1023 (maximum value) when you observe the cell load
information on the NodeB debugging console. In addition, you can find that
the RTWP of the cell is increased greatly to 90 dBm or so. There are many
causes for cell load increase. For example, when multiple UEs
simultaneously upload data, the RTWP is increased. It is found during the test
that the SIR of some UEs is not converged and leads to exceptional rise in the
transmit power of another UE. As a result, the cell load also increases
exceptionally and the other UEs cannot transmit data normally.
Solution: When the cell load (or RTWP) is high, first stop the uploading
service of all UEs in the cell and observe the RTWP in the cell to determine
whether the RTWP increase is caused by the UEs in the cell or other
interference. After other interference is removed, test the RTWP increase in
the cell when only one UE uploads data. If the RTWP in the cell is increased
exceptionally, the problem is caused by the UE.
2. Cases at CN Side
1. Low FTP Downloading Rate due to Over
Small TCP Window on Server TCP
Description
Activate uplink 64 kbps and downlink 384 kbps services on UE and laptop. Download data from the
servers of operator with CUTEFTP. The average downloading rate of UE is 33 kbps, much lower than
384 kbps. The average rate at FTP application layer is about 28 kbps.
Analysis
Activate uplink 64 kbps and downlink 128 kbps services, and download data. Engineers obtain the
required rate. However, after activating 384 kbps, the maximum rate cannot be reached. Try to
connect the UE to Huawei web server (the GGSN Gi interface <-> Lanswitch <-> NE08 <-> Internet
<-> Server of operator. The <-> used here means connection between two network elements (NEs).
Huawei web servers connect to Lanswitch by Gi interface. The address of web server and the address
of GGSN Gi interface share the same network segment).
The downloading rate reaches 47 kbps. After engineers connect UE to the server of operator, the
downloading rate is 30 kbps, far from the required rate. After engineers activate PS service from
Huawei SGSN to the GGSN of other vendors (such as N), the rate is about 30 kbps after visiting the
server of operator by N's GGSN. Therefore, the problem must not be due to system. Probably the
operator restricts the rate on the server, so the downlink 384 kbps is unavailable.
Capture packets on Gn and Gi interface, and UE by Sniffer. According to analysis of packet capture,
the TCP at the FTP server of operator restricts the sending window (the TCP window of the operator's
host server is 63136, but probably the software at application layer restricts the sending window.
According to the analysis below, the sending window size of FTP on operator's server is about 8 kbps,
much smaller than 64 kbps).
FTP server to client: After sending 6 TCP packets (4 * 1500 + 2 *1190), the
server stops sending, and 6 packets must be confirmed.
The FTP server receives an ACK message. After the FTP server and client
confirm two TCP packets, the server stops sending. There are 4 packets to
be confirmed.
The FTP server receives an ACK message again. After the FTP server and
client confirm two TCP packets, the server sends three continuous TCP
packets (2 * 1500 + 1190). There are 5 packets to be confirmed.
The FTP server receives an ACK message again. After the FTP server and
client confirm two TCP packets. The server sends 3 continuous TCP
packets (2 * 1500 + 1190). There are 6 packets to be confirmed.
It goes back to the first step. A cycle forms.
The FTP server sends at most 8.4 kbyte (4 *1500 + 2 * 1190) packets to be confirmed. According to
the second step above, the sender needs to send 4 kbyte data continuously. Therefore, the FTP server
sets the TCP sending window to be smaller than 10 kbyte, and the TCP is optimized to send large
block data (over 4 kbytes). The actual TCP window is 7 kbytes on average for FTP server. Assume
that the round-trip delay is t mm, so the maximum available rate is (7 kbytes/t) * 8 kbps.
According to previous analysis, after activating PS service, do not transfer data. Execute ping to server
on UE, and check the delay at the air interface. In Huawei system, the average delay for ping packets
is 250ms. According to analysis, 7 kbps/0.25 = 28 kbps. Namely, the theoretical average rate at
application layer is 28 kbps. This theoretical value is the same as the actual value. Therefore, the
operator must have restricted the TCP window at application layer on the server, so the rate keeps
low.
Solution
To increase rate, engineers must reduce the round-trip delay. When the delay
is smaller than 150ms, the rate can reach 384 kbps (7 kbps/0.15 = 46.7 kbps).
Actually reducing the delay at air interface is difficult. The Huawei delay at
air interface is about 250ms. Therefore, the rate cannot reach 284 kbps.
Download data with multiple threads tool, such as FlashGet and NetAnt.
Multiple TCP connects to the server, so the rate can increase. According to
test result, download data with more than two threads by using FlashGet or
NetAnt, the rate can reach 47 kbps.
Remove the restriction on sending window size of server, and set the sending
window size of server to 65535.
Analysis
Uploading and downloading simultaneously affect the ACK delay of TCP. This leads to prolonged
delay upon confirmation, and the TCP window size is inadequate. Execute the ping command upon
for confirming delay upon simultaneous uploading and downloading. Obtain the maximum supported
rate with the TCP window size/delay.
According to the analysis of the second problem, the TCP window size of operator's server is about
8.4 kbyte (the operator may use the FTP software Serv-U. Its default sending and receiving buffer is
8293 bytes). Upon simultaneous uploading and downloading, check the ping packet delay by
executing the command ping to the server. The ping packet delay is about 1500ms, 8.4/1.4 = 6 kbyte.
The previous two paragraphs describe the case of single thread. Start 3 threads and the theoretical rate
should be 18 KB/s (6 * 3 = 18). According to actual test, download data with 3 threads by using
FlashGet from the operator's server, and upload data with CuteFTP simultaneously. The average
sending and receiving rate of UE is 17.9 KB/s in downlink and 7.2 KB/s in uplink. The downlink rate
is approximately equal to theoretical value.
Namely, when the UE sends data in uplink, the delay increases sharply, so is the uplink response delay
to the ACK message. As a result, the TCP judges it as congestion, so the rate declines. This explains
that uploading and downloading respectively are available but simultaneous uploading and
downloading lead to decline of downlink rate.
Solution
According to previous analysis, increasing TCP window size of server leads to increasing downlink
theoretical rate. Actually, when using Huawei servers for test, set the TCP window size to 65535,
download with three threads by using FlashGet. Simultaneously upload data with CuteFTP. The
average sending and receiving rate is 46.5 KB/s in downlink and 6 KB/s in uplink.
Download data with multiple threads. According to test, download data with 10 threads from
operator's server when the TCP window size is 8192. The average sending and receiving rate is 42
KB/s in downlink and 6 KB/s in uplink. The data transfer is unstable with jitters.
Send the ACK message in downlink data packets, and sends uplink data packets at a fixed rate.
Restrict the uplink rate so that the uplink data packets will not be blocked at the air interface and the
delay at the air interface will not increase, and there is no jitter. Obviously, the decline of downlink
rate upon uplink and downlink data transfer is not due to Huawei system, and this problem cannot be
mitigated by this solution. This is a defect of TCP/IP protocol used in radio transmission. It is good to
combine the UE and the driver of wireless Modem to carry out the solution.
Analysis
Download data on one UE by FTP from operator's server, and the rate is as normal as above 47 KB/s.
Download data on two UEs, and then on three. The downloading rate keeps at about 47 KB/s with 4
UEs connected at most. When the fifth UE connects to the server, the rate declines. Try on site as
below:
Download data with four UEs from the operator's server, and with two UEs
from Huawei servers. Check whether the rate is faulty.
As a result, the downloading rate of 6 UEs reaches 47 KB/s.
Probably, the operator's server does not well cooperate with Huawei
networks.
Download data with six UEs from Huawei servers. Check whether the rate is
faulty.
Huawei servers cooperate well with Huawei networks. Probably the
operator's server does not well cooperate with Huawei networks.
The difference between the operator's server and Huawei server lies in the
router and firewall over the operator's server. Try to avoid the impact from
firewall and router, and check whether the rate increases.
Connect the Gi interface of GGSN to NE08 directly, and download data
with UE from the operator's server. Check whether the rate increases. The
result proves that the rate remains the same.
Therefore, the firewall has no impact on the rate.
Download data with six UEs from Huawei servers, and there is no problem.
Connect Huawei server to NE08 port to replace the operator's server for
test, and check whether the rate is faulty.
As a result, the downloading rate of six UEs reaches above 47 KB/s.
Therefore, the router is normal.
Connect a laptop to Gi interface. Download data with 4 UEs and with a laptop
simultaneously, and check whether their downloadings affect each other.
Tests prove that they seldom affect each other. The rate of some UEs
declines a little, and that of some UEs are seldom affected. The rate of
downloading data directly by laptop is 388 KB/s (single thread) or 1000
KB/s (three threads).
The export bandwidth to the operator's server is enough, so decline of rate
must not be due to bandwidth used for downloading data by multiple UEs
simultaneously.
After previous verifications, the peripheral equipment problems are excluded,
so probably the problem lies in the cooperation between the operator's
server and Huawei network. The major differences between Huawei server
and the operator server lie in two aspects: MTU and TcpWindowSize. Still
on Huawei Server, modify the two parameters for verification:
The configuration in the regedit on server is MTU 1450, and
TcpWindowSize is 65535. Activate six UEs simultaneously, and the rate is
as stable as above 47 KB/s.
Keep the MTU of web server at 1450. Modify the TcpWindowSize in
regedit to 10 KB (10240). After restart, the rate of simultaneous rate by six
UEs keeps above 47 KB/s.
Delete the MTU from the regedit of web server (use the default value
1500). Keep TcpWindowSize at 65535. After restart, the rate of six UEs
declines sharply (2030 KB/s). The downloading rate of three UEs keeps
at 47 KB/s until the fourth UE joins.
Therefore, when the MTU is the default value 1500, the rate of
simultaneous downloading by multiple UEs declines. According to the
packets captured by Sniffer, the MTU on the operator's server is the
default value 1500.
According to analysis, when the MTU is 1500, due to the TCP header
encapsulated along the path, the data packet is over long when the
downlink data packet reaches SGSN. Before sending data packet to RNC,
the SGSN must fragment and reassemble the packet. The current SGSN
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.
Analysis
Figure 6-5 shows analyzing packets captured by Ethereal upon unstable PS rate.
3. Analyzing packets
captured by Ethereal
upon unstable PS rate
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.
8. Low PS Service Rate in Presentation
Occasion
Description
The rate of PS downlink 384k service is low in presentation.
Analysis
After numerous tests and analysis, the problem must be at RAN. After engineers analyze to detailed
subscriber signaling, data statistics at subscriber plane, the quality of signals at the air interface, and
loss of packets at Iub interface, the problem is still present. It is difficult. RNP engineers check the
signals on site, and the signals are qualified. After using the laptop of an RNP engineer, the data
transfer of PS service is normal. According to further analysis, the problem lies in the driver of public
laptop used in presentation. After engineers change the laptop, the problem is solved.
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.
Activate UL64k/DL 32k service, and download data with Qualcomm 6250, and capture packets on
RNC and SGSN.
Download a 3.5 Mb file with the operator's FTP, and it takes 12 minutes. The problem is still present.
Download a 3.5 Mb file with the Windows FTP command, and it takes 30 minutes. After
downloading is complete, quit the FTP by typing bye. The problem is still present. Maybe the Outlook
is transferring data in daemon during data transfer, so there may be impact. After the transfer is
complete, the transfer is abnormally disconnected after a long time.
Download a 0.4 Mb file with the Windows FTP command, and it takes 2 minutes. Quit the FTP by
typing bye. The problem is not present.
Download a 0.4 Mb file with the operator's FTP, and it takes 2 minutes. The problem is not present.
Perform the same operations as the second step. Disconnect the downloading by Outlook in daemon.
The result is the same as the second step. See the following print.
----End
According to previous operations, the downloading is relevant to time, not the file size. Based on
analysis of massive data, the data transfer by FTP is normal, the downloaded content is correct and
available, but the signaling is abnormally closed.
Without other better method, the method of exchanging NEs and segment is used.
Search for the configuration of FTP server, and no relevant configuration is found.
Conclusion: the problem is present with multiple UEs, operators, and Huawei FTP server, so the
problem is irrelevant to UEs and FTP server, but relevant to Huawei network.
Compare the tests in the 3G network, the 2G network, and the tests of
handover to the 2G network after access in the 3G network.
According to tests, the problem must be between GGSN and FTP server. This reduces the scope of
problem.
According to other tests, the problem does not occur when no firewall is over Huawei server. This
shows the cause. The problem does not reoccur due to no firewall.
According to data analysis, the data transfer at the FTP port is normal, but the signaling port is
disconnected after 10 minutes. This must be due to firewall. It is the firewall that can disconnect a port
without data transfer after 10 minutes, so the problem is due to firewall.
Processing the problem goes smoothly after focusing on the firewall. The expert on firewall explains
as below:
The FTP session includes two session tables on firewall. One is for FTP control channel, and the
default aging time is 10 minutes. The other is FTP data channel, and the default aging time is 4
minutes. The no detect ftp command is configured between domains, the data channel will not update
the aging time of control channel upon data transfer. As a result, the control channel is aging and
deleted after 10 minutes with the following phenomenon.
If the detect ftp command is configured, the data channel will update the aging time of control
channel. As a result, the problem does not occur.
The problem, in whole process, is irrelevant to RAN. However, the process and result of locating
problem is considerable.
The difficulty of problem may exceed engineers' consideration. It needs wide-range knowledge.
However, after the problem is solved, it seams easy.
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.
1. Signaling of normal
handover between 3G
network and 2G network
Check the 3G signaling LMT. During the handover from the 3G network to the 2G network, the
handover signaling is normal at 3G network side. After the UE sends the routing area update request
message to the 2G SGSN, the SGSN context and response flow between the 2G SGSN and 3G SGSN
is normal. Till now, the handover of 3G SGSN is complete. The next step is the signaling interaction
between the UE and the 2G SGSN, as shown in Figure 6-10:
2. Normal signaling flow
between UE and 2G
SGSN.
Trace the signaling on the partner's 2G SGSN. It is found that the signaling interaction flow from 2G
SGSN to GGSN and that of HLR are complete. After the 2G SGSN sends UE the routing area update
request message, the UE must sends 2G SGSN the routing area update complete message according to
standard flow, which is not found in traced signaling. As a result, the 2G SGSN judges that the UE has
not completed the routing area update, so the UE cannot transfer data after handover to the 2G
network. However, the UE keeps being in connected mode after handover to 2G network, so the UE
judges that it has completed routing area update. This indicates that the problem lie between the UE
and SGSN.
Check the encryption state of 3G SGSN. The SGSN uses UEA1 as the encryption method, but the
serving 2G network uses no encryption method. When the UE hands over from the encryption in 3G
network to the non-encryption in 2G network, the 2G network fails to send the encryption and
authentication message, indicating UE to disable encryption state, and the encryption state of UE has
not synchronized with network side. As a result, the UE encrypted its messages upon sending RAU,
but the RAN side does not encrypt messages. Therefore, the RAN side fails to receive RAU result.
Solution
This problem concerns the partner's equipment at RAN side. It cannot be solved at UE side due to
restriction from protocols. Therefore, the solution is to set the encryption item to non-encryption so
that the messages sent by UE are not encrypted. As a result, the problem is mitigated.
Suggestion and Summary
The problem concerns the partner's equipment at RAN side. Not every type of UE meets the problem,
because the problem is just incidental. Therefore locate the problem based on signaling and analyze
the problem to obtain the correct result.
7. Summary
This document describe the access, disconnection of data transfer, low rate of data transfer, unstable
rate of data transfer, and interruption of data transfer. It provides the methods for analyzing and
processing these problems in terms of traffic statistics and DT/CQT. The experience from analyzing
problems in terms of traffic statistics is little, and will be supplemented.
In addition, the document details the flow for optimizing DCH bearer of data service and the flow for
optimizing HSDPA bearer of data service.
The used cases include abundant cases at CN side. Actually, analyzing problems or modifying
parameters at CN side must be processed by engineers at CN side. These CN cases just serve as
reference for analyzing problems.
8. Appendix
Title Description
8.8 PS Tools
1. Transport channel of PS
data
Wherein, the Gi interface connects to the application server, on which the FTP Server software is
running. Download data from the application server to UE (MS) through five interfaces: Gi, Gn, IuPS,
Iub, and Uu. The PS services use the AM mode of RLC, which supports retransmission. The services
like FTP and HTTP use TCP protocol, which also supports retransmission.
The parameters of these two protocols (RLC/TCP) have great impact on rate. If the parameters are
improper, or packet error or loss of packets occurs during transmission, the rate will decline. Evaluate
QoS based on that a computer with UE as its modem runs applications. This concerns the performance
of computers and servers.
2. Theoretical Rates at Each Layer
8.2 shows the packet service data flow.
Observe different protocol layers, and there are different definitions of throughput, such as the
application layer throughput, RLC layer throughput, and MAC layer throughput.
Due to data packet header at each protocol layer, there is overhead. Except the physical layer, the
TCP/IP and RLC layer have high overhead. The typical PDU size and overhead at each layer are listed
as below.
1. TCP/IP Layer
Assume that the MTU is 1500 Bytes.
The TCP/UDP PDU size, namely, the payload at application layer, is 1460 Bytes, but the whole IP
packet size is 1500 Bytes.
2. RLC Layer
The RLC header overhead is 16 Bits.
The RLC PDU size is 336 Bits.
Assume that the rate at the application layer is 1 Bytes/s. if retransmission at each layer is not
considered, the corresponding rate at RLC layer is 1500/1460, namely, 1.027. The rate at MAC-d
layer is 1500/1460 * 336/320, namely, 1.079.
3. Retransmission Overhead
If the TCP layer retransmission (assume that the retransmission rate is r1) and RLC layer
retransmission are considered, the corresponding rate at RLC layer is 1500 * (1 + r1)/1460. The rate at
MAC-d layer is 1500 * (1 + r1)/1460 * (1 + r2) * 336/320.
4. MAC-HS Layer
If there is only one subscriber, without retransmission at MAC-HS layer, the rate at MAC-HS is
(scheduling transport block size TBs)/2ms, and the rate at MAC-d layer is 336 * (TBs/336s)/2ms.
In the DT tool Probe, with consideration of multiple subscriber scheduling and retransmission at
MAC-HS, there are three rate involved at MAC-HS layer: scheduled rate, served rate, and MAC layer
rate.
Wherein, the HS-SCCH Success Rate is the success rate for receiving HS-SCCH data by a subscriber,
and SLBER is incorrect TB received at MAC-HS layer/total TBs received.
3. Bearer Methods of PS Services
In Rel 4 and R99 protocol versions, data service is carried on DCH. If the data services are low in
traffic, it can also be carried on FACH.
When HSDPA is used in Rel 5, the data service can be carried on DCH or HSDPA. If the traffic is
low, the data service can be carried by FACH through state transition.
The following three paragraphs describe the method for RNC to judge whether a PS service is carried
by DCH or HSDPA in a cell supporting HSDPA.
Two parameters are relevant to the SET FRC command on RNC LMT: downlink streaming service
HSDPA threshold and downlink BE service HSDPA threshold.
Downlink streaming service HSDPA threshold indicates the rate judgment threshold of PS streaming
service carried on HS-DSCH. When the downlink maximum rate of PS streaming service is equal to
or larger than the threshold, the service can be carried on HS-DSCH. Otherwise, it is carried on DCH.
The service is carried by from DCH or HSDPA to FACH through state transition.
1. DCH
The DCH bandwidth depends on the current power resource, code resource, and Iub bandwidth
resource. Typical rates include 8 kbps, 32 kbps, 64 kbps, 128 kbps, 144 kbps, and 384 kbps. The DCH
bandwidth is adjustable by algorithms like DCCC according to the current traffic and coverage
conditions, but the adjustment is limited to previous rates. In addition, the interval to trigger
adjustment is long. As a result, the adjustment is not frequent.
2. HSDPA
The network does not allocate fixed bandwidth or resources for the PS services carried by HSDPA,
but perform fast schedule every 2ms. Therefore, the throughput that a subscriber can reach depends on
abundant factors, such as:
FACH uses code resource of different SFs, so it support variable channel rate. This depends on the
need by broadcasting services like CMB.
4. Method for Modifying TCP Receive
Window
For the services (such as VOD and FTP) using TCP protocol, the TCP window size of test laptop
(client) and server have great impact on performance of service. To obtain better performance, set the
window size as large as possible, and set the window size of client and server to the same, such as
64K (65535).
1. Tool Modification
Run the DRTCP.exe attached in the appendix 8.8.1. For the running interface, see the method for
modifying MTU.
2. Regedit Modification
Detailed operations are as below:
In Windows 2000,
In
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip,
add string: "TcpWindowSize"="65535"
In
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Pa
rameters, add double type value TcpWindowSize. Set it to 65535 or ffff
(hex).
5. Method for Modifying MTU
The MTU here is IP packet size. As shown in Figure 5-27, GGSN has two layer IP. The maximum IP
packet size is 1500 bytes. If a data packet at IP layer is to be transmitted, and the packet is larger than
MTU at IP layer after encapsulation, IP packet fragment is necessary. After fragment, each fragment
is smaller than the MTU at IP layer.
In terms of PS CN efficiency, avoid IP fragment and reassembly, and meanwhile use the MTU as
large as possible. The MTU is usually smaller than or equal to 1450 bytes. The data transmission rate
of PS CN is usually higher than the rate at air interface, so the MTU has little impact on the rate at air
interface. The default MTU in computers is 1500 bytes.
Modifying MTU includes modifying the MTU of server and modifying the MTU of test laptop. The
server and client will negotiate, so the actual MTU is the smaller one.
Modify MTU by using DRTCP tool or modifying Windows Register. The following sections detail
the operations.
1. Tool Modification
Run the DRTCP.exe attached in the appendix 8.8.1, with the running interface as shown in .
1. Running interface of
DRTCP
Server
Modify the MTU in Adapter Settings shown in Figure 8-6 , namely, the MTU at the network port.
Test Laptop
For test laptops, the UE is connected to it by data line and dial-up connection is set up. Data packets
are sent through USB port. As a result, modifying MTU of USB port is necessary, namely, the Dial
Up(RAS) MTU as shown in .
2. Regedit Modification
Modifying MTU of server
Modify the MTU of network port on server.
In Windows 2000, in
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{.....
....}\, add a double byte value, named mtu, with the value of 1450.
In Windows 2000, in
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NdisWan\Parameters\Protocols\0
\, modify the ProtocolMTU to 1450.
1. Detailed resolution of
Activate PDP Context
Request message
1. Traffic Classes:
The traffic classes in an Activate PDP Context Request message include the following:
Traffic class,
0 0 1 Conversational class
0 1 0 Streaming class
0 1 1 Interactive class
1 0 0 Background class
1 1 1 Reserved
Among them, Subscribed traffic class is not determined by the UE, but determined by the core
network according to the subscription information of the UE.
max bit rate down: Maximum downlink rate. In the preceding figure, the value of this field is 104,
which corresponds to 384 kbit/s.
guar bit rate up: Guaranteed uplink bit rate. In the preceding figure, the value of this field is 0, which
means that there is no requirement for the guaranteed uplink bit rate.
guar bit rate down: Guaranteed downlink bit rate. In the preceding figure, the value of this field is 0,
which means that there is no requirement for the guaranteed downlink bit rate.
If 128>x>=64, the actual rate is 64 + (x 64) * 8 kbit/s. In the preceding figure, the value of the max
bit rate down field is 104 and the maximum downlink bit rate is 384 kbit/s calculated according to the
conversion formula 64 + (104 64) *8.
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.
1. Converting ASCII codes
into a character string by
using the UltraEdit
Run UltraEdit
Create a File
Select Edit > Hex Edit
Type the ASCII code of APN in the messages
You can see the APN string in Figure 8-8, it start at the fourth byte.
7. APN Effect
1. Major Effect
In GPRS/WCDMA networks, APN has the following effects:
Subscribers select GGSN by different APNs. Namely, subscribers can activate multiple PDP context,
and each PDP context is related to an APN. Subscribers select different APNs to connect to different
external networks through different GGSNs.
3. APN Configuration
Before configuring APN on GGSN9811, the PDN that can be visited by subscribers must be clearly
known. Set different APNs to different PDNs. For example, the GGSN9811 allows a subscriber to
visit Internet through an ISP and an enterprise intranet simultaneously, and two APNs must be set up
on GGSN9811: one for visiting Internet, and the other for visiting the enterprise intranet.
8. PS Tools
1. TCP Receive Window and MTU
Modification Tools
Modify TCP receive window and MTU with the following tool:
For the detailed method, see the appendix 8.4 and 8.5.
2. Sniffer
Sniffer can capture, construct, and send packets. It constructs transfer data at a fixed rate, and then
obtains the rate at other NEs. This eliminates the external impact. Sniffer can send packets at UE side
or on server. It can construct data transfer at fixed rate in uplink and downlink simultaneously, or just
construct data transfer in uplink or downlink.
4. HSDPA Test UE
In terms of test methods, the PS service test carried by HSDPA is the same as that carried by DCH.
Select the test UEs that support HSDPA.
Now the UEs available in HSDPA PS service test include Huawei E620 data card, Qualcomm
TM6275, and UB TM500.
Huawei E620 data card is a category 12 UE. It supports 5 HS-PDSCH codes at most. It supports
QPSK, but not 16QAM. The maximum throughput at physical layer is 1.8 Mbps. The actual
throughput at application rate is 1.4 Mbps. Huawei E620 data card supports combination of PS and
AMR services, but not VP service.
UB TM500 is an emulation test UE. It can emulate the UEs of multiple categories. It supports 15 HS-
PDSCH codes at most. It supports QPSK and 16QAM. It supports the combination of PS and CS
services, namely, after a subscriber starts PS service, it then start CS service.
Huawei E620 data card and Qualcomm TM6275 are for DT. TM500 is large, unfit for DT, but it can
emulate multiple UE categories. In laboratory, HSDPA performance test requires UE to support 10 or
15 codes, but no UE or data card support 10 or 15 codes. As a result, using TM500 for test is
necessary.
9. Analysis of PDP Activation
The GRPS subscribed data can include the subscribed information of multiple packet data protocol
(PDP) address. In MS, SGSN, and GGSN, one or more PDP contexts describe each PDP address.
Each PDP context is in the following two states: inactive or active state.
In active state, PDP context is activated in MS, SGSN, and GGSN. It contains the routing and
mapping information to process PDP PDU between MS and GGSN. The PDP context activation
process contains the activation process originated by MS, the activation process originated by
network, and the second activation process. The activation process originated by MS is used upon PS
service connection.
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.