Professional Documents
Culture Documents
Ps-Service Problem Optimization
Ps-Service Problem Optimization
Revision Records
Table of Contents
1 Introduction.........................................................................................................................12
2 Evaluation of PS Throughput Problems...........................................................................14
3 Data Collection..................................................................................................................18
3.1 Traffic Statistics...................................................................................................................................19
3.2 DT/CQT...............................................................................................................................................19
3.3 Others..................................................................................................................................................21
6 Cases..................................................................................................................................101
6.1 Cases at RAN Side............................................................................................................................102
6.1.1 Call Drop due to Subscriber Congestion (Iub Resource Restriction)......................................102
6.1.2 Uplink PS64k Service Rate Failing to Meet Acceptance Requirements in a Test (Air Interface
Problem)............................................................................................................................................102
6.1.3 Statistics and Analysis of Ping Packet Delay in Services of Different Types..........................103
6.1.4 Low Rate of HSDPA Data Transfer due to Over Low Pilot Power.........................................105
6.1.5 Unstable HSDPA Rate due to Overhigh Receiving Power of Data Card.................................106
6.1.6 Impossible Maximum HSDPA Rate due to Over large Radius of Cell....................................107
6.1.7 Decline of Total Throughput in Cell due to AAL2PATH Bandwidth larger than Actual Physical
Bandwidth.........................................................................................................................................109
7 Summary...........................................................................................................................129
8 Appendix..........................................................................................................................130
8.1 Transport Channel of PS Data...........................................................................................................131
8.2 Theoretical Rates at Each Layer........................................................................................................131
8.2.2 TCP/IP Layer............................................................................................................................132
8.2.3 RLC Layer................................................................................................................................132
8.2.4 Retransmission Overhead.........................................................................................................133
8.2.5 MAC-HS Layer........................................................................................................................133
8.3 Bearer Methods of PS Services.........................................................................................................133
8.3.1 DCH.........................................................................................................................................134
8.3.2 HSDPA.....................................................................................................................................134
8.3.3 CCH..........................................................................................................................................135
8.4 Description of HSDPA Algorithms and Parameters..........................................................................135
8.4.1 Code Resource Configuration..................................................................................................135
8.4.2 HS-PDSCH MPO Instant.........................................................................................................141
8.4.3 HSDPA UE Category...............................................................................................................142
8.4.4 HS-DPCCH Power Control......................................................................................................143
8.5 Method for Modifying TCP Receive Window..................................................................................148
8.5.1 Tool Modification.....................................................................................................................148
8.5.2 Regedit Modification...............................................................................................................148
8.6 Method for Modifying MTU.............................................................................................................148
8.6.1 Tool Modification.....................................................................................................................149
8.6.2 Regedit Modification...............................................................................................................150
8.7 Confirming APN and Rate in Activate PDP Context Request Message...........................................150
8.7.2 Traffic Class.............................................................................................................................151
8.7.3 Maximum Rate and Guaranteed Rate......................................................................................152
8.7.4 APN..........................................................................................................................................152
8.8 APN Effect.........................................................................................................................................153
8.8.1 Major Effect.............................................................................................................................153
8.8.2 Method for Naming APN.........................................................................................................154
List of Tables
Table 2-1 Requirements by DT/CQT on PS throughput...........................................................................15
Table 4-1 Measured items related to PS throughput in overall performance measurement of RNC........24
Table 5-2 Relationship between CQI and TB size when the UE is at the level 11–12..............................73
Table 5-3 Relationship between CQI and TB size when the UE is at the level 1–6.................................74
Table 8-4 Relationship between the CQI reported by UE and pilot Ec/Io..............................................142
List of Figures
Figure 4-1 Flow for analyzing RNC-level traffic statistics data...............................................................29
Figure 5-2 Flow for analyzing access failure problems when originating PS services by UE directly. . .40
Figure 5-3 Flow for analyzing access problem when the UE serves as the modem of PC......................42
Figure 5-7 Flow for analyzing RAN side problem about disconnection of service plane for DCH bearer
...................................................................................................................................................................49
Figure 5-10 Flow for analyzing problems at CN side about disconnection of service plane...................56
Figure 5-12 Flow for analyzing RAN side problem about poor performance of data transfer................61
Figure 5-14 Flow for analyzing data transfer affected by Iub interface...................................................65
Figure 5-15 Flow for analyzing poor performance of data transfer at RAN side.....................................69
Figure 5-16 Confirming in the RNC message that PS service is set up on HSDPA channel...................70
Figure 5-20 Residual BLER at MAC layer in WCDMA HSDPA Decoding Statistics window............89
Figure 5-21 Flow for analyzing poor performance of data transfer at CN side.......................................90
Figure 5-24 Normal and abnormal interruption of data transfer upon update of H-H serving cell..........98
Figure 5-25 Interruption of data transfer due to H-D and D-H handover................................................99
Figure 6-2 Variation of total throughput of one IMA link of HSDPA codes..........................................109
Figure 6-3 Variation of total throughput of two IMA links of HSDPA codes........................................110
Abstract: The document serves the optimization of PS service problems in large networks. It describes
problem evaluation, data collection, and methods for analyzing problems.
DT Driver Test
SF Spreading Factor
UE User Equipment
NE Network Element
1 Introduction
Title Description
Chapter 1 Introduction
Chapter 2 Evaluation of PS Throughput Problems
Chapter 7 Summary
Chapter 8 Appendix
The PS throughput in RAN traffic statistics is obtainable from cell throughput of different
services. HSDPA throughput of RAN traffic statistics is obtainable from average throughput of
MAC-D flow in HSDPA service measurement (cell).
3 Data Collection
There are two major methods for evaluating PS throughput: traffic statistics and
DT/CQT.
3.2 DT/CQT
To obtain DT/CQT data, use the software Probe. UE, scanner, and GPS are involved.
Obtain the information output by UE, such as:
Coverage
Pilot pollution
Signaling flow
Downlink BLER
Transmit power of UE
Based on the measurement tracing on RNC LMT, obtain the following information:
Downlink BLER
Downlink code transmit power
Downlink carrier transmit power
Signaling flow at RNC side
By the DT processing software Assistant, analyze comprehensively the data collected
by Probe in foreground DT and tracing record on RNC LMT.
lists the major parameters to be collected in DT/CQT.
In PS service test, to reduce the impact from TCP receiver window of application
layer, using multi-thread downloading tools like FlashGet is recommended. Set the
number of threads to 5. For uplink data transfer, start several FTP processes.
For the detailed test and operation methods of DT and CQT, see W-Test Guide. For
detailed operations on LMT, see W-Equipment Room Operation Guide.
3.3 Others
After finding problems by traffic statistics, DT/CQT, and subscribers' complaints,
analyze and locate problems with DT/CQT and the following aspects:
RNC CHR
Connection performance measurement
Cell performance measurement
Alarms on NEs
States of NEs
FlashGet
DU Meter
lists the tools for collecting data.
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.
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.
Overall performance RLC cache size, average Check whether the RLC
measurement of utilization of cache; cache is inadequate; check
RNC/RLC statistics number of data packets the probability of
measurement sent and received by RLC dropping data packets by
in TM/AM/UM mode; RLC or whether the
number of data packets downlink retransmission
dropped by RLC, number rate is overhigh.
of retransmitted data
packets
Overall performance Number of UEs in Serve as reference for
measurement of RNC/UE CELL_DCH, knowing traffic model of
state measurement CELL_FACH, subscribers
CELL_PCH, and
URA_PCH state
Overall performance Number of conversational Analyze the number of
measurement of RNC/RB service, streaming service, subscribers using different
measurement interactive service, and services at different rate;
background service in analyze the call drop
various uplink and problems of various rate
downlink rates in PS
domain under RNC; Times
of abnormal call drops for
previous services in
various rate in PS domain
Overall performance Uplink and downlink
measurement of traffic (RLC layer excludes
RNC/RNC traffic traffic of RLC header) of
measurement all services in PS domain
under RNC
In cell performance measurement, HSDPA part is added, and other indexes are the
same as that of R99. Some traffic statistics indexes corresponding to HSDPA services
are not added to RNC traffic statistics.
lists the measured items related to HSDPA throughput (cell measurement).
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.
For the worst cell, check that they are not with access, call drop, and handover
problems. Then analyze the cell performance from cell measurement/traffic
measurement, cell measurement/cell algorithm measurement, and cell
measurement/cell RLC measurement.
describes the cell measurement/cell algorithm measurement analysis.
The causes of high RLC retransmission rate and PDU packet dropping rate are:
Bad BLER of radio link (including weak coverage)
High transmission error rate
Clock abnormality
To confirm weak coverage problem, perform DT/CQT and analyze CHR as below:
Perform DT/CQT to know the overall coverage conditions
Analyze CHR to know the RSCP and Ec/Io of subscribers in the environment
Sort the subscribers by RSCP in CHR analysis
Record the worst N subscribers and visit the location
Perform DT/CQT accordingly in these locations
----End
WCDMA PS service data transfer problems include the following three types in terms
of phenomena:
Access failure (or dial-up connection failure)
Successful access but unavailable data transfer
Available data transfer but low speed or great fluctuation
For the problem with different phenomena, follow different flows for processing them.
For access, call drop, signaling plane, and handover problems, see W-Access Problem
Optimization Guide and W-Handover and Call Drop Problem Analysis Guide. This
guide supplements some operations in PS service test.
Access Failure
There are two ways to use PS services:
Originating PS services directly on UE, browsing web pages, and watching video
streaming directly on UE
Combining personal computer (PC) and UE. Namely, UE serves as the modem of
PC, and the service is originated through PC
In optimization test, the combination of PC and UE is most widely used. In DT/CQT,
the PC is usually a laptop with the DT software Probe installed on it. This is called
Probe + UE. When the UE fails to directly originate PS services, it can obtain more
information by using Probe + UE. Therefore, the following analysis is mainly based on
Probe + UE.
Flow for analyzing access failure problems when originating PS services by UE directly
Flow for analyzing access problem when the UE serves as the modem of PC
Reinstall the driver. This problem usually occurs upon the first connection of PC
and UE.
Trace the NAS and RRC signaling in Probe or trace the signaling of single subscriber
on RNC LMT. Analyze the problem by comparing it to the signaling flow for standard
data service. For the signaling flow for standard data service, see the senior training
slides of RNP: W-RNP Senior Training-Signaling Flow.
shows the signaling flow of successful setup of a PS service in Probe.
In , Probe contains two windows: RRC Message, and NAS Messages. The signaling
point in NAS Messages window corresponds to the point of direct transfer messages
in RRC Message.
The following problem may occur due to the comparison of signaling flow:
RRC connection setup failure
Description: in , it is abnormal from the RRC Connection Request message to the
RRC Connection Setup Complete message.
Analysis: the UE fails to send the RRC Connection Request message according to
the RRC Messages window in Probe, probably due to:
− Modem port is not selected in the Hardware Config widow in Probe.
− TestPlan is not configured in Probe or improperly configured.
− The port of UE is abnormal. See the Failure in Opening Port in 5.1.2 for
solution.
If the APN at UE side and restricted rate are properly configured, the problem
is probably due to CN problem. If some interfaces of CN are unavailable,
locate the problem with engineers on PS domain of CN.
If the PS service is the initial commissioning, the APN for defining a
subscriber by HLR is inconsistent with that of gateway GPRS support node
(GGSN). Confirm this with engineers on PS domain of CN.
For the analysis of causes of PDP activation rejection, see 8.10.
RB setup failure
Description: after Activate PDP Context Request, the system fails to receive
Radio Bearer Setup message, but receives the release message.
Analysis: for details, see the section Analyzing RAB or RB Setup Problems in W-
Access Problem Optimization Guide.
Others
See 5.3.1. Shrink the scope of the problem by changing each device.
DCH bearer
shows the flow for analyzing RAN side problem about disconnection of service plane
for DCH bearer.
Flow for analyzing RAN side problem about disconnection of service plane for DCH
bearer
In ,
The bandwidth shown is the bandwidth assigned for UE by system.
The DlThroughput is the actual throughput of downlink data transfer.
Monitor the variation of access layer rate and non-access layer rate of uplink and
downlink data transfer for the current connection. This helps analyze the functions of
dynamic channel configuration and variation features of service source rate.
If the uplink throughput is 0, the uplink may be disconnected.
If the downlink throughput is 0, the downlink may be disconnected.
When the RNC DCCC function is valid, distinguish the variation of bandwidth caused
by DCCC.
If the problem is still unlocated after previous operations, collect the data packets
received and sent at RNC L2 and by GTPU by using the tracing tool RNC CDT. This
helps judge whether the disconnection of subscriber plane is in uplink or downlink, at
CN side or RAN side.
Others
Check problems at the CN side according to analysis of problems at CN side in
5.2.2.
Refer to Comparing Operations and Analyzing Problem. Change each part and
compare the operations. This helps reduce the scope of the problem. Feed back
the problem.
HSDPA Bearer
The HSDPA feature of cell is activated, The UE supports HSDPA. The rate requested
by UE or the subscribed rate is higher than HSDPA threshold for downlink BE service
(for BE service) or HSDPA threshold for downlink streaming service (for streaming
service). When the PS services are carried by HSDPA, follow the steps below:
Alarms in RNCs and CHR
Check the alarms and CHR for the point of problem occurrence whether there are
abnormalities. Provide diagnosis.
Deactivate HSDPA features so that PS services are set up on DCH
Deactivate HSDPA features by executing the command DEA CELLHSDPA. Connect
UE to the network by dial-up so that PS services are set up on DCH.
If the data transfer is unavailable on DCH, see the troubleshooting in previous block
DCH Bearer.
If the data transfer is available on DCH, the problem must be about HSDPA. Follow
the steps below.
Check the CQI, HS-SCCH success rate, and SBLER
Check the CQI, HS-SCCH success rate, and SBLER by Probe + UE as below:
CQI
The UE estimates and reports CQI based on PCPICH Ec/Nt. For the calculation,
see 8.4.2.
If the CQI reported by UE is 0, the NodeB will not send UE any data.
In the current version, if the CQI calculated by NodeB based on current available
power is smaller than 2, the NodeB will not schedule the UE and send it any data.
If the common parameters like pilot Ec/Io, CellMaxPower, PcpichPower, and
MPO are normal, but the CQI is bad, change a PC. The PCs of different types
have different thermal noises, so they have different impact on reported CQI.
HS-SCCH success rate
The HS-SCCH success rate is obtainable in the WCDMA HSDPA Decoding
Statistics window and WCDMA HSDPA Link Statistics window, as shown in .
Wherein, the HS-SCCH Success Rate (%) is the HS-SCCH scheduling success
rate of the UE. It is relevant to the following parameters:
− Number of HS-SCCHs
− Number of HSDPA subscribers
− Scheduling algorithm parameter
If an HS-SCCH is configured to the HSDPA cell, the scheduling algorithm is the
RR algorithm, and all the connected subscribers keeps data transfer, the HS-
SCCH success rate is the reciprocal of number of subscribers. Namely, all the
subscribers share the HS-SCCH resource.
If the HS-SCCH success rate of a subscriber approaches 0, the data transfer rate
of the subscriber approaches 0, and the service plane may be disconnected.
The HS-SCCH success rate approaches 0 due to:
− The scheduling algorithm is much similar to MAX C/I algorithm, more than
one HSDPA subscribers connects to the cell, and the CQI of the subscriber is
low.
− The transmit power of HS-SCCH is over low. Now in the indoor scenario, the
transmit power of HS-SCCH is fixed to 2% of total transmit power of cell. In
outdoor scenarios, the proportion is 5%. If the transmit power of HS-SCCH is
lower than the fixed power, the UE may fail to demodulate HS-SCCH data.
− No data is transmitted at the application layer. Confirm this by the actual
transmitted data volume in the Connection Performance Measurement-
Uplink Throughput and Bandwidth, Downlink Throughput and
Bandwidth on RNC LMT.
− The CQI reported by UE is over low, so the NodeB will not schedule the
subscriber.
SBLER being 100%
The SLBER is the slot block error rate of HS-DSCH. In , the right pane of the
WCDMA HSDPA Decoding Statistics window shows the SBLER and
retransmission conditions of transport blocks of different sizes. The WCDMA
HSDPA Link Statistics window shows the following parameters:
− HS-DSCH SBLER-Deta
− HS-DSCH SBLER-Average
Wherein, the Deta is the instantaneous value. The Average is the average value.
When the HS-PDSCH Ec/Nt is over low, the SBLER will be 100%. This is
actually caused by inadequate HSDPA power. Check the HSDPA power
configuration by executing the command LST CELLHSDPA. Wherein, the HS-
PDSCH and HS-SCCH power are the HSDPA power configuration.
There are two methods for HSDPA power configuration: static power
configuration and dynamic power configuration.
− If the power of the parameter configuration is higher than or equal to the
maximum transmit power of cell, use dynamic power configuration.
− If the power of the parameter configuration is lower than the maximum
transmit power of cell, use static power configuration.
The available power of HS-PDSCH in static power configuration = maximum
transmit power of cell – power margin – R99 downlink load (including CCH
load) – HS-SCCH power.
The available power of HS-PDSCH in dynamic power configuration = power of
HS-PDSCH and HS-SCCH – HS-SCCH power.
Note the static power configuration. Due to power control, the R99 services can
use HS-PDSCH power.
According to previous two formulas, in dynamic power configuration of HSDPA
power, if the power margin is over large, R99 downlink load is overhigh, or HS-
SCCH power is overhigh, the available power of HS-PDSCH is over low. In
static power configuration of HSDPA power, if the HS-PDSCH and HS-SCCH
power are over low, or HS-SCCH power is overhigh, the available power of HS-
PDSCH is over low.
SBLER is 100% seldom due to inadequate power, unless the CQI reported by UE
is over small. When the power of NodeB is inadequate, the CQI calculated by
NodeB is smaller, the scheduled TB blocks becomes smaller, so the rate obtained
by UE declines.
Solution: adjust parameter configuration. If the R99 load is overhigh, add
carriers.
Check the available bandwidth, occupied bandwidth, and assigned bandwidth at Iub
interface
Query lub bandwidth by executing the command DSP AAL2PATH on RNC LMT. Or
start the task Periodic Reporting of Iub Bandwidth Assignment Conditions of HSDPA
on NodeB console.
If errors occur in data transmission, the IMA group number of AAL2PATH (For
HSDPA) on NodeB fails to match that on RNC. When the available bandwidth of
HSDPA is inadequate due to product software problems, the data transfer is
unavailable.
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.
Checking Alarms
If there is a problem, check whether there are alarms. Query the NodeB and RNC
alarms at RAN side. Query the SGSN, GGSN, LAN switch, router, and firewall at CN
side. The alarms like abnormal clock alarms, high transmission error rate, and
abnormal equipment affect data transfer.
If problems cannot be located according NE alarms, refer to 5.3.1. By comparing
operations and analyzing problem, reduce the scope of problem.
If the problem is at RAN side, refer to 5.3.2.
If the problem is at CN side, refer to 5.3.4.
If the problem concerns both the RAN and CN side, analyze it from both sides.
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.
Flow for analyzing RAN side problem about poor performance of data transfer on DCH
NE Alarms
If the performance of data transfer for PS services is poor, analyze NodeB and RNC
alarms. The clock alarms, alarms on transmission error rate, and transmission
interruption may cause fluctuation of PS data. For querying NodeB and RNC alarms,
see W-Equipment Room Operation Guide.
Data transfer affected by Uu interface
When PS services are carried by DCH, the factors affecting data transfer at Uu
interface includes:
− DCH bandwidth
− State transition
− Block error rate (BLER) at Uu interface
shows the flow for analyzing data transfer affected by Uu interface.
1) DCH bandwidth
When PS services are carried by DCH, the RNC assigns bandwidth for each
connected UE. The bandwidth depends on spreading factor and coding
method.
On RNC LMT, in the Connection Performance Measurement-Uplink
Throughput and Bandwidth, Downlink Throughput and Bandwidth
window, check the uplink and downlink assigned bandwidth and throughput.
The bandwidth is the channel bandwidth assigned to UE by RAN. The
DlThroughput is the actual downlink rate of data transfer. Assigning
bandwidth (namely, code resource, power resource, and Iub resource are
normal) is normal if one of the following conditions is met:
− The bandwidth is the same as the request rate or subscribed rate.
− Maximum assignable rate (such as 384 kbps) is met upon DCH bearer.
If the bandwidth assigned to UE is smaller than the expectation, there are
two causes:
− Congestion or other causes. The RAN cannot assign UE with channels
of higher rate, which is abnormal.
The UE monitors HS-SCCH for information sent to it. If there is any schedule
information, it starts receiving HS-DSCH data and buffers them.
According to HS-SCCH data, the UE judges whether to combine the received HS-DSCH
data and data in soft buffer.
The UE demodulates the received HS-DSCH data, and send the ACK/NACK message
on uplink HS-DPCCH according to CRC result.
If the NodeB receives the NACK message, it resends the data until it receives the ACK
message or reaches the maximum retransmission times.
In the DT tool Probe, out of consideration for multiple subscriber scheduling and
retransmission at MAC-HS layer, there are three rates at MAC-HS layer:
Scheduled rate
Schedule rate = total bits of all TBs received in statistics period/total time with
TB scheduled in statistics period
The total time with TB scheduled in statistics period includes the time with data
received and excludes the time without data received.
Served rate
Served Rate = Scheduled Rate * HS-SCCH Success Rate
Served rate = total bits of all TBs received in statistics period/statistics period
The total bits of all TBs received in statistics period include the bits of received
correct and wrong TBs.
The statistics period includes the time with and without data received.
MAC layer rate
MAC Layer Rate = Served Rate * (1- SBLER)
MAC Layer Rate = total bits of correct TBs received in statistics period/statistics
period
The total bits of correct TBs received in statistics period include the bits of
corrects TBs and excludes bits of wrong TBs.
The statistics period includes the time with and without data received.
HS-SCCH success rate is the success rate for receiving HS-SCCH data by UE
SLBER = wrong TBs received at MAC-HS layer/(received correct and wrong TBs)
ACK->NACK/DTX is the ratio that NodeB judges the ACK message as NACK/DTX
message.
shows the flow for analyzing poor performance of data transfer on HSDPA at RAN
side.
Flow for analyzing poor performance of data transfer on HSDPA at RAN side
NE Alarms
When the performance of data transfer for PS services is poor, analyze the NodeB and
RNC alarms. The clock alarms, alarms on transport code error, and transmission
interruption may lead to fluctuation of PS data. For querying NodeB and RNC alarms,
see W-Equipment Room Operation Guide.
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 .
If the service is not set up on HSDPA channel, it will automatically be set up on DCH.
Now the service rate is the rate of R99 service, usually equal to or smaller than 384
kbps.
If it is confirmed that the service is not set up on HSDPA channel, analyze it from the
following aspects.
HSDPA cell is not set up
Check at RNC side whether the HSDPA cell is activated by executing the
command LST CELLHSDPA.
Check at NodeB side whether the local cell supports HSDPA. Check by executing
the command LST LOCELL whether the value of the local cell is TRUE or
FALSE.
If the HSDPA cell at RNC side is not activated, activate it by executing the
command MOD LOCELL: LOCELL=0, HSDPA=TRUE.
In addition, during modifying the HSDPA cell configuration on RNC, if HSDPA
codes are statically assigned, and if there are excessive R99 subscribers
connected to the cell so the code assigned to HSDPA is inadequate, the RNC still
displays that the modifying HSDPA cell configuration succeeds. However,
actually the HSDPA cell is not successfully set up. Check whether the codes
assigned to HSDPA cell are successful by selecting Realtime Performance
Monitoring > Cell Performance Monitoring > Code Tree Tracing on RNC.
Incorrect type of HSDPA AAL2PATH or No Configuration
Set the type of HSPDA AAL2PATH to HSDPA_RT or HSDPA_NRT. Otherwise
the cell can support R99 services only, but not HSDPA services. It is
recommended that one HSDPA AAL2PATH is configured to one NodeB. If
multiple HSDPA AAL2PATHs are configured, the data packets are easily dropped
in the current version. Query it at RNC or NodeB side by executing the command
LST AAL2PATH.
If the HSDPA AAL2PATH is set to RT or NRT, the downlink subscription rate of
UE is 2 Mbps. When the UE accesses the network, setting subscriber plane for
HSDPA service fails, and the RNC will automatically set up the subscriber plane
of PS 384kbps service. According to signaling of the RB Setup message, the
service is set up on R99, and SF is 8.
HSDPA subscriber's admission failure
The HSDPA subscriber's admission failure leads to that the RNC reconfigures
HSDPA service to be carried by PS384K channel of R99 service. If the service
cannot be set up, the UE continues to access the network after lowering the rate
of R99 service. If the rate of connected HSDPA subscriber is as low as 384 kbps,
128 kbps, or 64 kbps of R99 services according to test, confirm whether the
service is set up on HSDPA channel and whether the admission fails.
Check whether the following aspects are rational:
− Uplink and downlink load of R99 services
− Downlink code resource
− Iub transmission resource
− Number of HSDPA subscribers
− Threshold of HSDPA cell rate
− Guaranteed rate threshold of streaming service
− Guaranteed power threshold
Overhigh HSDPA threshold for downlink BE service
The HSDPA threshold for downlink BE service defines the rate judgment
threshold for background or interactive services carried on HS-DSCH in PS
domain. If the request rate is great than or equal to the threshold, the PS service is
carried on HS-DSCH; otherwise, the PS service is carried on DCH.
Set HSDPA threshold for downlink BE service by executing the command SET
FRC: DlBeTraffThsOnHsdpa=D384 on RNC.
1 137 1 QPSK 0
2 173 1 QPSK 0
3 233 1 QPSK 0
4 317 1 QPSK 0
5 377 1 QPSK 0
6 461 1 QPSK 0
7 650 2 QPSK 0
8 792 2 QPSK 0
9 931 2 QPSK 0
10 1262 3 QPSK 0
11 1483 3 QPSK 0
12 1742 3 QPSK 0
13 2279 4 QPSK 0
14 2583 4 QPSK 0
15 3319 5 QPSK 0
16 3319 5 QPSK –1
17 3319 5 QPSK –2
18 3319 5 QPSK –3
19 3319 5 QPSK –4
20 3319 5 QPSK –5
21 3319 5 QPSK –6
22 3319 5 QPSK –7
23 3319 5 QPSK –8
24 3319 5 QPSK –9
25 3319 5 QPSK –10
26 3319 5 QPSK –11
27 3319 5 QPSK –12
28 3319 5 QPSK –13
29 3319 5 QPSK –14
30 3319 5 QPSK –15
Relationship between CQI and TB size when the UE is at the level 1–6
CQI Transport Number of Modulation Reference
value Block Size HS-PDSCH power
adjustment
1 137 1 QPSK 0
2 173 1 QPSK 0
3 233 1 QPSK 0
4 317 1 QPSK 0
5 377 1 QPSK 0
6 461 1 QPSK 0
7 650 2 QPSK 0
8 792 2 QPSK 0
9 931 2 QPSK 0
10 1262 3 QPSK 0
11 1483 3 QPSK 0
12 1742 3 QPSK 0
13 2279 4 QPSK 0
14 2583 4 QPSK 0
15 3319 5 QPSK 0
16 3565 5 16-QAM 0
17 4189 5 16-QAM 0
18 4664 5 16-QAM 0
19 5287 5 16-QAM 0
20 5887 5 16-QAM 0
21 6554 5 16-QAM 0
22 7168 5 16-QAM 0
23 7168 5 16-QAM –1
24 7168 5 16-QAM –2
25 7168 5 16-QAM –3
26 7168 5 16-QAM –4
27 7168 5 16-QAM –5
28 7168 5 16-QAM –6
29 7168 5 16-QAM –7
30 7168 5 16-QAM –8
If the available power of HSDPA cell is over low, the TB size of NodeB
scheduling will be affected.
HSDPA power configuration includes dynamic and static configuration.
The RNC MML is MOD CELLHSDPA: HSDPAPOWER=430. The unit of
HSDPA power is 0.1 dB. The total power of all HS-PDSCHs and HS-SCCHs
must not exceed the HSDPAPOWER.
When HSDPAPOWER in previous formula is higher than or equal to total power
of cell, the HSDPA power configuration is dynamic configuration. The available
power of HSDPA cell = total power of cell * (1 – power margin) – power used by
R99 TCH and CCH.
When HSDPAPOWER in previous formula is lower than total power of cell, the
HSDPA power configuration is static configuration. Namely, the available power
of HSDPA cell is the HSDPAPOWER. However, the maximum available power =
total power of cell * (1 – power margin) – CCH power.
In static power distribution, the R99 services may occupy the power of HSDPA cell, so the
actual power used by HSDPA cell is not the configured power.
Analyze the factors affecting available power of HSDPA cell from the following
aspects:
− Query power margin by executing the command LST MACHSPARA on
NodeB. The default power margin is 10%, namely, the total downlink load of
cell can use 90% of total power of cell.
− On RNC LMT, select Realtime Performance Monitoring > Cell
Performance Monitoring > Tx Carrier Power. Observe the transmit carrier
power and power used by non-HSDPA subscribers. The available power of
HSDPA = transmit carrier power - power used by non-HSDPA subscribers. If
the power used by non-HSDPA subscribers is overhigh, the available power of
HSDPA cell becomes low, so the scheduled rate is affected.
Available codes of HSDPA cell
If inadequate codes are assigned to HSDPA subscribers, the TB size of NodeB
scheduling will be affected. For the method of assigning HSDPA channel codes,
see the appendix 8.4.1.
HSDPA UE CATEGORY
The 3GPP protocol 25.306 defines 12 types of UE category. In a TTI, the UE of a
type obtains different maximum TB size, so the maximum scheduled rate
obtained by UE is different.
The UE reports its capability in the IE hsdsch physical layer category of the
RRC Connection Setup Complete message.
For the HSDPA UE category, see 8.4.3.
Amount of data to be transmitted being smaller than the maximum TB size
The TB size scheduled by NodeB depends on the available power and codes of
the subscriber, as well as the amount of data transferred by the subscriber. If the
amount of data sent is smaller than the maximum scheduled TB size, the rate at
physical layer is lower than the expectation.
This problem occurs when there is data in NodeB buffer but the amount of data is
inadequate for a scheduled maximum TB size.
4 –10.75 –6.75
8 –7.75 –3.75
16 –4.75 –0.75
32 –1.75 +2.25
64 +1.25 +5.25
128 +4.25 +8.25
256 +7.25 +11.25
− If there is only one HSDPA subscriber in a cell, the traffic is not restricted and
HS-SCCH power is adequate, the success rate of HS-SCCH for the subscriber
approaches 100%.
− If there are multiple HSDPA subscribers in the cell, the success rate of HS-
SCCH for each subscriber is relevant to scheduling algorithm and number of
HS-SCCHs.
Usually set the HS-SCCH according to available power of HS-PDSCH, code
resource, and traffic of service source. For example, if UEs used in the cell are all
category 12 UE, set number of HS-PDSCH codes and number of HS-SCCHs as
below:
− If you set 5 codes to HS-PDSCH, it is recommended to set 2 HS-SCCHs.
− If you set 10 codes to HS-PDSCH, it is recommended to set 3 HS-SCCHs.
− If you set 14 codes to HS-PDSCH, it is recommended to set 4 HS-SCCHs.
Scheduling algorithm
Using different scheduling algorithm for multiple subscribers enables each
subscriber to be scheduled at different probability. For example, after MaxC/I
scheduling algorithm is used, the subscribers far from the cell center will hardly
or even never be scheduled due to low CQI.
The scheduling algorithm is one function of new function entity of HSDPA, the
MAC-hs function entity. Four factors are involved as below:
− CQI
CQI is the quality of signals received by UE at the location.
− Wait_Inter_TTI
It indicates the length of time that the UE must wait for service.
− Queue priority
− Queue length
The following scheduling algorithms are typical:
− MaxC/I (only considering CQI value)
− RR (only considering wait_Inter_TTI)
− Classic PF (proportional fair, considering previous factors)
Parameters are not configured for current scheduling algorithm. Select one of
previous three algorithms by executing the command below:
SET MACHSPARA: LOCELL=10131, SM=PF;//The previous algorithm
corresponds to the PF scheduling algorithm.
The following aspects must be considered in a typical PF scheduling algorithm:
− Allocate resources according to the weighting factor of scheduling equal to
R/r. Wherein, the R is the requested rate; the r is the actual average scheduling
rate for the subscriber, and it is the output after а filter. The average length is
equivalent to 1.6s. The retransmitted data is not involved in the calculation of
R and r. Therefore, the actual rate obtained by the subscriber at the
application layer and the rate requested by CQI are approximately
proportional.
− Upon overall scheduling, the NodeB allocates resources to the UE with
highest weighting factor of scheduling. If there are resources left, the NodeB
allocates them to the UE with the second highest weighting factor of
scheduling.
When an RRU is used, the remote deployment distance of it is within the cell radius.
Set the cell radius and set the cell to support HSDPA by executing the command
below:
ADD LOCELL: LOCELL=1, RADIUS=5000, HSDPA=TRUE;
Traffic
After previous configuration and checks, there is no problem and CQI reported by
UE is high, but the rate of subscribers fluctuates. Check downlink traffic in
Connection Performance Monitoring window on RNC LMT, and see whether
there is enough traffic for scheduling. Or check downlink traffic in HSDPA User
Flow Control Performance Periodic Report window on NodeB LMT.
The cause of this problem is unstable source rate, single thread used upon
downloading, and small TCP window.
In the HSDPA User Flow Control Performance Periodic Report window, there
are following selections:
− Queue Priority
− Queue Buffer Used Ratio
− RLC User Buffer Size
− Input Data Size
− Output Data Size
Select Queue Buffer Used Ratio to draw picture on LMT, and check the
occupation of NodeB queue.
Select RLC User Buffer Size to check RLC cache.
Select Input Data Size and Output Data Size to check the sending and receiving
queue data. The data involved in Output Data Size is the data with ACK
indicator received.
Restricted Rate at UE side
The request service type, uplink and downlink maximum rate are sent to UE by
AT commands. The UE sends the information to CN in the following Active PDP
context request message. When the subscribed rate is higher than or equal to the
requested maximum rate, the CN sends the RAN Assignment request message at
the requested maximum rate. If the resource is not restricted at RNC side, the
final output rate is the request maximum rate. If the downlink maximum rate in
the RAB Assignment request message is much lower than scheduled rate, and the
traffic in buffer is inadequate upon NodeB's scheduling, the success rate of HS-
SCCH must be low.
Execute AT commands as below:
Right click My Computer
Select Property > Hardware > Device Manager > Modem > Property > Senior
Type AT command into the Initialization Command text box. Set APN by AT
command. If you want to set APN to cmnet, the rate is restricted to 64 kbps in uplink
and 384 kbps in downlink, execute the following command:
AT+cgdcont=1,"ip","cmnet"; +cgeqreq=1,3,64,384
When you remove the restriction on rate, execute AT command to set the rate to 0. The
value 0 means that no specified rate is requested, so the system assigns the subscribed
rate as possible. Execute the following command:
AT+cgdcont=1,"ip","cmnet"; +cgeqreq=1,3,0,0
----End
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.
----End
TCP and RLC uses AM mode, so sending the ACK message is necessary on
uplink DCH.
TCP provides reliable transport layer, the receiver responds the ACK message.
Any the data and the ACK message may be lost during transmission, so TCP sets
a timer upon sending for solving this problem. If the sender does not receive the
ACK message till expiration of the timer, it resends the data. As a result, the rate
for data transfer is affected. If the uplink DCH power control is not converged,
and BLER is overhigh, the sender TCP will fail to receive the ACK message and
resend the data. As a result, the rate of data transfer is affected.
RLC uses AM mode. If the uplink BLER is not converged, the RLC will receive a
late ACK response or no response. After expiration, the RLC resend the data, so
the rate for data transfer is affected. If the RLC fails to receive the ACK message
after multiple times, RLC reset occurs. The RLC sending window can configure
the maximum value to 2047 at most. When the rate for sending by RLC is high,
and the response to RLC is late, the RLC sending window will be full and no new
data can be sent.
Check the uplink BLER in Uplink BLER of RNC Connection Performance
Monitoring window. The baseline requires target uplink BLER as 1%. Find the
causes of non convergence of uplink power control from the following two
aspects:
− Check whether the RTWP fluctuates abnormally, and whether there is uplink
interference. Check RTWP in RNC cell performance monitoring.
− Check whether the configuration of outer loop power control parameters for
the current services is proper. Focus on SIRTarget and BLERTarget. Follow
the steps below:
Query the index value for current services by executing the command LST TYPRAB.
For example, the index value for the 384 kbps services is 22.
Query SIRTarget and BLERTarget by executing the command LST TYPRAB:
RABINDEX=22, TRCHTYPE=TRCH_HSDSCH,
IUBTRANSBEARTYPE=IUB_GROUND_TRANS;
Modify SIRTarget and BLERTarget for current service by executing the command MOD
TYPRABOLPC: RABINDEX=22, SUBFLOWINDEX=0,
TRCHTYPE=TRCH_HSDSCH, IUBTRANSBEARTYPE=IUB_GROUND_TRANS,
BLERQUALITY=-20;
----End
The NodeB deducts the bandwidth corresponding to R99 call from the total
bandwidth of PATH according to receiving rate, and then obtains the residual
bandwidth of all PATH. The RCR is reported to DSP, and the DSP construct
frame informs RNC of residual bandwidth. The residual bandwidth is for HSDPA
subscribers, so the flow is controlled.
If the receiving bandwidth RCR of NodeB AAL2 PATH is larger than PCR of
RNC AAL2 PATH, the data packets at Iub interface will be dropped.
In addition, if the configured bandwidth of AAL2PATH is larger than the physical
actual bandwidth, the data packets at Iub interface will be dropped. As a result,
the total throughput of cell declines.
Overhigh RLC retransmission rate due to overhigh residual BLER at MAC layer
If the retransfer at MAC layer reaches the maximum times, the TBs incorrectly
received will be dropped. If the receiver detects dropping data packets, it requires
the sender to resend data packets by state report. Retransfer lowers the sending
efficiency of RLC, so it affects the valid throughput of RLC. When residual
BLER at MAC layer is overhigh, the SBLER at MAC layer is probably overhigh.
For detailed analysis, see the analysis of overhigh SLBER in previous sections.
Normal the residual BLER at MAC layer is smaller than 1%.
shows the residual BLER at MAC layer in WCDMA HSDPA Decoding
Statistics window.
NE Alarms
At CN side, analyze the alarms on SGSN, GGSN, LAN switch, router, and firewall
(collecting SGSN and GGSN alarms as key task). Clock alarms and transport code
error alarms may lead to fluctuation of PS data.
Environment Problems
The rate is relevant to PC, OS, and applications. The internal algorithm of software at
different application layer and TCP parameters of OS have great impact on
performance. If other conditions are the same, the rate of data transfer on Windows
2000 computer is superior to that on Windows 98 computer. Therefore, it is
recommended to use Windows 2000 Professional and Windows 2000 server as the OS
of PCs and servers.
Now the laptops are installed with Windows XP, so there is no problem concerning
perform due to OS. Anyhow, the servers must be installed with Windows 2000 server,
because Windows XP will affect the performance of data transfer.
The PC (laptop) for being daemon of UE must be of good performance. Tests prove
that IBM laptops have good performance in playing VODs. Now Huawei RNP
engineers use the new laptops of D Corporation, which have worst performance in data
transfer of HSDPA test than the new ones of H Corporation.
If the utilization CPU being daemon of UE is 100%, the TCP/IP receiver window is
full. As a result, the performance of data transfer is affected.
The performance of servers may affect service effect, which must be considered.
Service-related Problems
FTP
Use the commercial FTP software, because the FTP software embedded in
Windows OS is of average performance. Download data with FTP in binary. The
multi-thread downloading software like FlashGet is recommended.
VOD
The software RealPlayer sets the maximum play rate to larger than 384 kbps. The
buffer time must not be over long, and 3s is proper. Some computers are installed
with qualified video adapter, so the monitor jumps some frames. Change the
resolution to 800x600. If the problem is still present, change the video adapter.
Net TV
When the rate of down-layer declines, the Net TV is difficult to restore. Note this.
Video conference
Set the output rate of convergence TV smaller than the rate of down-layer;
otherwise, data packets will be dropped. Huawei conference video sets 64 kbps as
step from 128 kbps. The recommended configuration is 320 kbps. If the rate is
over low, utilization rate of down-layer rate will be over low. Otherwise, using
the rate higher than 320 kbps, such as equal to or larger than 384 kbps, leads to
dropping data packets because the rate of down-layer cannot meet the
requirements by application layer. As a result, the performance of video
conference declines. If a lightning sign appears on the right upper corner of
conference TV, there must be code error or packet dropping during transmission.
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.
During the handover between HSDPA and GPRS, data transfer will also be
interrupted.
The interruption of data transfer includes two aspects:
The interruption of data transfer without update of serving cell or handover
Over long interruption of data transfer with update of serving cell or handover
Interruption of data transfer without update of serving cell or handover
The causes of interruption of data transfer without update of serving cell or
handover includes:
− Call drop or TRB reset occurs during data transfer
− Other abnormalities, such as interruption of transport resource like Iub or
completing downloading data files.
Locate the problem by checking alarms, whether downloading is complete, and
signaling flow.
− Alarms
Query the alarms on CN and RAN. Know the abnormalities in the operation
of current system. Guide analyzing and identifying problems. Some problem,
such as interruption of data transfer, clock asynchronization in some cells, and
NE congestion, can be known from alarms.
− Whether downloading is complete
Data transfer is interrupted for a long time, so restoring it is impossible. Check
whether downloading the file by FTP is complete.
− Signaling Flow
According to detailed analysis of RNC and UE signaling, judge whether call
drops upon interruption of data transfer, whether the H-H serving cell is
updated, and whether H2D or D2H handover occurs. If the interruption of data
transfer is caused by call drop, analyze the cause of call drop. For details, see
W-Handover and Call Drop Problem Optimization Guide.
Over long interruption of data transfer with update of serving cell or handover
lists the interruption delay of data transfer in HSDPA.
The previous table provides value only for reference. The actual KPI depends on the issue of
WCDMA&GSM Network Performance Research Department. Different product algorithms
lead to different references.
The causes to over long interruption of data transfer upon update of serving cell
or handover include:
− The serving cell is frequently updated in ping-pong handover areas, and the
CQI reported by UE is low.
− Impact from product processing algorithm
− Bugs of UEs and other products
shows the normal and abnormal interruption of data transfer upon update of H-H
serving cell.
Normal and abnormal interruption of data transfer upon update of H-H serving cell
In ,
The point A indicates over long interruption of data transfer due to ping-pong
handover
− The point B indicates over long interruption of data transfer duo to H-H intra-
NodeB serving cell update
− The point C over long interruption of data transfer duo to H-H inter-NodeB
serving cell update.
− The point D indicates over long interruption of data transfer due to faulty UE
− The point E indicates over long interruption of data transfer due to improper
RNC product processing algorithm.
shows the interruption of data transfer due to H-D and D-H handover.
In ,
− The point A indicates the interruption of data transfer upon H-D handover
− The point B indicates the interruption of data transfer upon D-H handover
In the ping-pong handover areas, perform RF optimization by:
In , the data transfer is interrupted for two times, and the interruption delays are
respectively 300ms and 300ms. Compare the TCP rate in Ethereal and the rate at
application layer in Assistant, and they must match. Therefore, obtain the update
point of serving cell in Assistant.
6 Cases
Title Description
Description
In a project, there are abundant 3G UEs or data cards. The subscribers are test
subscribers, so they need not to pay. As a result, the traffic model in the area is
special. The busy hour of traffic is around 23:00, when PS call drops.
Analysis
According to traffic statistics, the traffic in the cell is heavy. The bandwidth at
Iub interface is 1 Mbps, always fully used. If a UE keeps transferring data on
line, the transferring is stable. If the subscriber browses web pages without
data transfer, the UE transits to idle mode to save resource according to
DCCC algorithm. When the UE needs to transfer data again, it must apply for
resource again. However, the resource may be used by other UEs, so no
resource is assigned to it. As a result, the connection fails. The subscriber feels
that he/she is off line. It is difficult to reconnect to the network. When other
subscribers use less resource, the subscriber can succeed in dial to connect to
the network.
The essence of the problem lies in that excessive subscribers use the
resources, so the resource is congested.
To solve this problem, use the methods below:
Reduce test subscribers
Add E1 bandwidth
Description
For PS64k service, the acceptance contract prescribes that the actual average
rate must be larger than 51 kbps, but the uplink rate is about 50 kbps in test.
Analysis
According to statistics of rate at RNC RLC layer, the maximum rate exceeds
64 kbps, and it fluctuates sharply. As a result, the average rate at application
layer displayed by the software FTP is low. According to signaling tracing and
statistics of uplink BLER, the uplink BLER is about 10%. As a result, the rate
at application layer fluctuates and the throughput declines.
Solution
Change the target uplink BLER to 6% or 1%. Change related power control
parameter.
Setting different target BLER helps balance the performance of single UE and
more UEs. According to the information from other networks, different target
BLER are set for different networks, but they are small.
Note that setting target BLER is according to index of service type. The
uplink and downlink bandwidth are usually different, namely, the index of
service type is different. Set target BLER after confirming the index of service
type.
6.1.3 Statistics and Analysis of Ping Time Delay in Different Service Types
Description
On SNSN, test the transfer delay of streaming and conversational service. CN
test engineers feed back that the transfer delay of conversational service
cannot meet the protocol requirement. The test result is that: the ping delay of
conversational service is 230ms and that of streaming service is 109ms.
According to R5 TS23.107 requirement, the delay of conversational must be
smaller than 100ms. The delay in the test is 115ms (230ms/2), so it does not
meet the requirement.
Analysis
In formal tests, the ping delay of conversational service is 230ms and that of
streaming service is 109ms. The conversational service uses 8k/8k, and the
streaming service uses 64k/128k. Their bandwidth is different, so their delay
is different.
According to R5 TS23.107 requirement, the delay of conversational must be
smaller than 100ms. The unidirectional delay from UE to Gi interface (UMTS
bearer) is 100ms. The delay at RAN is 80ms. The 80ms shall contain the
delay at access layer of UE and exclude that of USB and PC. According to
test, the end-to-end delay is 115ms (230ms/2), so it does not meet the
requirement.
It is almost certain that engineers cannot test with 8k/8k bandwidth whether
the delay meets the requirement, because the bandwidth is too small. The
RNC of current version support PS conversational service of 8k only. Now
which service uses the type of PS conversational service is unknown.
Test twice with Sony-Ericsson Z1010, because other UEs fail to support
conversational service. After the UE is activated, execute the command ping
over firewall on GGSN through a laptop.
Activate the four 8k/8k services: background, interactive, streaming, and
conversational. Test the delay, and trace SGSN and RNC CDR.
Activate the three 64k/128k services: background, interactive, and
streaming. Test the delay, and trace SNSN and RNC CDR.
lists the delay test result of ping packet.
In 8k/8k, the delay of each service is larger than 220ms. In 64k/128k, the
delay is smaller. Therefore the delay and bandwidth are relevant.
Execute the command ping by 32 bytes, and analyze as below:
In 8k/8k, execute the command ping by 32 bytes. It is 60 bytes including the
IP head. The TTI of 8k is 40ms. Each TTI has a block. The TB size is 336
bits. As a result, executing the command ping by 32 bytes occurs on two
TTIs, namely, 80ms. The downlink is similar.
The uplink and downlink must stagger a TTI. Assume that the processing at
nodes and interface goes infinitely fast. To the air interface and from the air
interface take 200ms (5*40 ms).
In addition, a PC always sends data about MSN, HTTP protocols. If the PC
sends other packet during sending ping data, the ping command has to wait.
Therefore, 8k bandwidth is over small.
In 64k/128k, execute the command ping by 32 bytes. It is 60 bytes including
the IP head. The TTI of 128k is 20ms. Each TTI has 8 blocks. The TB size is
336 bits. As a result, executing the command ping by 32 bytes occurs on a
TTI, namely, 20ms. The downlink is similar.
The uplink and downlink must stagger a TTI. Assume that the processing at
nodes and interface goes infinitely fast. To the air interface and from the air
interface take 60ms (3*20 ms). Adding this to CN cost and laptop cost makes
more than 100ms.
Execute the command ping by 8 bytes on conversational service. After on-site
verification, the test is consistent with prediction.
Analyze the parts of total delay from laptop, to UE, to NodeB, to RNC, to CN,
and to server. Analyze the factors that affect delay in each part. This helps
locate delay problems.
Compared with 8k/8k streaming service, the typical parameters of 8k/8k
conversational service must be optimized.
6.1.4 Low Rate of HSDPA Data Transfer due to Over Low Pilot Power
Description
In an HSDPA live demonstration, when the commissioning is complete, the
rate of HSDPA service is as low as half of standard rate, and the
retransmission rate is high.
Analysis
On-site NodeB engineers have demonstrated the service in laboratory, and the
rate is normal, 1400 kbps. They use big antenna and lower the power on site
to cover the sites of the operator. After this, the Ec is –50 dBm, and Ec/Io is –
3 dB. Namely, the coverage is qualified. In the on-site test, after starting
downloading data, the Ec/Io deteriorates sharply. According to QXDM
tracing, the transmission rate is 100% (engineers doubt that the problem is
caused by interference and improper installation of antenna, but the cause is
not them according to frequency sweep and SITEMASTER test). As a result,
2019-1-19 华为机密,未经许可不得扩散 第 85 页, 共 133 页
文档名称 文档密级
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.
6.1.5 Unstable HSDPA Rate due to Overhigh Receiving Power of Data Card
Description
On HBBU, activate HSDPA service, and the retransmission rate is high. The
BLER of data sent at the first time is about 60%, the residual BLER is 5%.
The downloading rate is low, and the rate fluctuates sharply.
Analysis
Once the on-site engineers download data, the CQI fluctuates sharply and
frequently between 15 and 26. The rate fluctuates between 100 kbps and 600
kbps.
The load of HSDPA fluctuates sharply between 3% and 24%. This must be
relevant to downloading rate.
No FP packet is missing. No packet is missing because the queue is full. In the
scheduling period, abundant DTXs exist according to NodeB, with few
NACK messages.
According to check, the receiving power of data card is as high as –45 dBm,
exceeding the normal range (–55 dBm to –85 dBm). The signals are strong,
and the attenuation is inadequate, so the measured CQI is inaccurate.
Solution
Add an attenuator at the antenna port, and keep the receiving power at about –
70 dBm. After this, the problem of frequently fluctuation, as well as the
BLER problem, is solved.
6.1.6 Impossible Maximum HSDPA Rate due to Over large Radius of Cell
Description
A subscriber uses Huawei E620 data card. The HSDPA rate fails to reach
above 1.5 Mbps, but remains at about 1.2 Mbps. Check through QXDM, there
is no code error in downlink DSCH. Anyhow, the HSSCCH scheduling cannot
reach 100%, but remains at 80%.
shows the UE HSDPA statistics data in QXDM.
Analysis
To locate the problem, proceed as below:
Check the transmit power of cell carriers. It is lower than 60%, so the power is
not restricted.
Check the UE HSDPA statistics in QXDM. There is no code error on HS-
DSCH, but its scheduling is only 80%.
Check the AAL2 Path bandwidth. The HSDPA AAL2 Path bandwidth is 2
Mbps, so there is no bottleneck.
Disable downlink DSP flow control, so the impact from flow control is avoided.
Still, the HSDPA rate is 1.25 Mbps.
Check the downlink throughput and traffic of single subscriber on the
corresponding RNC. The rate at RLC layer on RNC fails to reach the required
flow rate. According to CDR, the HS-DSCH flow control information sent by
NodeB is consistent. The decline of RLC rate is irrelevant to RNC, but
relevant to the bottleneck of overall process.
Query the scheduling information of downlink DSP on NodeB LMT. According
to the scheduling information, the scheduling times in 1s is 428 at most, so it
is impossible to reach 100% scheduling of 500 times.
The coding DSP experts calculate the scheduling times, 500*6/7 = 428. They
check the cell radius. The cell radius is 10 km. After engineers change the
radius to 2 km, the rate increases to about 1.5 Mbps.
According to timing relationship of HSDPA, it takes 15.5 timeslots from
HSSCCH's scheduling the subscriber to receiving the response to the
scheduling. HSSCCH schedules single subscriber with multiple threads, so it
can schedule other threads while waiting for the response of a scheduling. As
a result, scheduling is more efficient. Now at most 6 threads are used, and
each TTI needs 3 timeslots, so a cycle contains 18 timeslots. Compared with
the single thread RTT of 15.5 timeslots, the NodeB can schedule subscribers
in 2.5 timeslots with the following aspects:
Demodulating HS-DPCCH data
Coding HSSCCH data
Internal processing delay
In NodeB design, the single thread RTT is relevant to the distance between
NodeB and the subscriber. When the distance is long, the RTT will be large.
As a result, the processing time for NodeB is short, so the NodeB has
inadequate time to process HS-DPCCH feedback, coding HS-SCCH and
scheduling subscribers.
Actually, the downlink DSP does not know the distance of UE, so it uses the
cell radius. If the cell radius is larger than 5 km, the downlink DSP uses 7
TTIs to schedule 6 threads to guarantee enough processing time. The
downlink DSP can schedule 6 threads in 7 TTIs, so the total scheduling time
at most is 6/7, namely, 85.7%. In 1s, the downlink DSP can schedule 500 *
6/7 times, namely, 428 times.
Solution
After engineers adjust the cell radius less than 5 km, the rate exceeds 1.4
Mbps, and the scheduling time reach about 95%.
6.1.7 Decline of Total Throughput in Cell due to AAL2PATH Bandwidth larger than
Actual Physical Bandwidth
The WCDMA network runs normally. The admission of the cell to be
measured is disabled. The cell is unloaded. The neighbor cells are disabled.
The HSDPA cell is successfully set up. The power is dynamically distributed.
HSDPA uses 5 codes. The MAC-HS scheduling algorithm uses PF. There is
one HS-SCCH. The cell uses 8 E1's. One of them uses UNI method, and the
rest 7 E1's use the IMA group method. The IMA group bears HSDPAAAL2
PATH. The UNI bears the NCP/CCP/ALCAP/R99 AAL2 PATH at other Iub
interfaces.
Select a good test point (CPICH RSCP is about –70 dB, Ec/Io is above –6 dB,
and the fluctuation is stable). Connect 6 HSDPA UEs one by one to the
network. The PS service is activated on UE. The RAN bears PS service on
HS-DSCH. Download with FTP, and record the peak throughput of cell.
Disconnect the E1 link of IMA group one by one manually while connect 6
subscribers one by one to the network. Record the total peak throughput of
cell after one subscriber accesses the network.
Draw a curve chart with the recorded peak throughput of cell at every point,
as shown in and .
In and , the throughput of one E1 is lower than the throughput of two E1's.
Analysis
The cell uses 5 HSDPA codes, and class-12 UE. The maximum throughput at
MAC layer of cell is 1.72 Mbps. The SBLER is 10%, so the throughput at
MAC layer of cell is about 1.55 Mbps. In , the measured throughput of cell is
consistent with the theoretical rate, but in , the throughput of cell declines.
Check the Iub bandwidth. The AAL2PATH bandwidth is 10 Mbps, but the
physical bandwidth is about 1.9 Mbps with one E1, and 2.8 Mbps with 2 E1's.
Obviously, the NodeB flow control does not consider the variation of physical
bandwidth, but allocates bandwidth according to configured AAL2PATH
bandwidth.
The throughput of cell with 2 E1's is not affected by physical bandwidth. This
must be analyzed in terms of flow control at NodeB Iub interface. The Node
flow control allocates bandwidth for each subscriber according to the data
amount in NodeB buffer, the data amount of RNC RLC buffer, and the rate at
the air interface.
The Iub flow control allocates bandwidth for subscribers that the maximum
allocated bandwidth is twice of the rate at the air interface. According to
previous analysis, the twice of the rate at the air interface is 3.4 Mbps at most,
not exceeding the physical bandwidth of 2 E1's. As a result, the rate of air
interface is not affected when there are 2 E1's. When there is 1 E1, the twice
of the rate at the air interface exceeds the physical bandwidth of 1 E1. As a
result, data packets are missing at Iub interface, and the rate of subscribers is
affected.
Solution
Change the AAL2PATH of HSDPA to 1.9 Mbps when there is one E1. Test
again, and the rate of subscribers is about 1.5 Mbps.
In actual networks, guarantee that the AAL2PATH allocated bandwidth to
HSDPA is smaller than the physical bandwidth at Iub interface. This will
affect throughput of cell. Meanwhile, check NodeB alarms whether there are
E1 fault alarms.
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 <->
2019-1-19 华为机密,未经许可不得扩散 第 90 页, 共 133 页
文档名称 文档密级
Server of operator. The <-> used here means connection between two network
elements (NEs). Huawei web servers connect to Lanswitch by Gi interface.
The address of web server and the address of GGSN Gi interface share the
same network segment).
The downloading rate reaches 47 kbps. After engineers connect UE to the
server of operator, the downloading rate is 30 kbps, far from the required rate.
After engineers activate PS service from Huawei SGSN to the GGSN of other
vendors (such as N), the rate is about 30 kbps after visiting the server of
operator by N's GGSN. Therefore, the problem must not be due to system.
Probably the operator restricts the rate on the server, so the downlink 384 kbps
is unavailable.
Capture packets on Gn and Gi interface, and UE by Sniffer. According to
analysis of packet capture, the TCP at the FTP server of operator restricts the
sending window (the TCP window of the operator's host server is 63136, but
probably the software at application layer restricts the sending window.
According to the analysis below, the sending window size of FTP on
operator's server is about 8 kbps, much smaller than 64 kbps).
According to the basic regulations of data packet at Gi interface,
FTP server to client: After sending 6 TCP packets (4 * 1500 + 2 *1190), the
server stops sending, and 6 packets must be confirmed.
The FTP server receives an ACK message. After the FTP server and client
confirm two TCP packets, the server stops sending. There are 4 packets
to be confirmed.
The FTP server receives an ACK message again. After the FTP server and
client confirm two TCP packets, the server sends three continuous TCP
packets (2 * 1500 + 1190). There are 5 packets to be confirmed.
The FTP server receives an ACK message again. After the FTP server and
client confirm two TCP packets. The server sends 3 continuous TCP
packets (2 * 1500 + 1190). There are 6 packets to be confirmed.
It goes back to the first step. A cycle forms.
The FTP server sends at most 8.4 kbyte (4 *1500 + 2 * 1190) packets to be
confirmed. According to the second step above, the sender needs to send 4
kbyte data continuously. Therefore, the FTP server sets the TCP sending
window to be smaller than 10 kbyte, and the TCP is optimized to send large
block data (over 4 kbytes). The actual TCP window is 7 kbytes on average for
FTP server. Assume that the round-trip delay is t mm, so the maximum
available rate is (7 kbytes/t) * 8 kbps.
According to previous analysis, after activating PS service, do not transfer
data. Execute ping to server on UE, and check the delay at the air interface. In
Huawei system, the average delay for ping packets is 250ms. According to
analysis, 7 kbps/0.25 = 28 kbps. Namely, the theoretical average rate at
application layer is 28 kbps. This theoretical value is the same as the actual
value. Therefore, the operator must have restricted the TCP window at
application layer on the server, so the rate keeps low.
Solution
To increase rate, engineers must reduce the round-trip delay. When the
delay is smaller than 150ms, the rate can reach 384 kbps (7 kbps/0.15 =
46.7 kbps). Actually reducing the delay at air interface is difficult. The
Huawei delay at air interface is about 250ms. Therefore, the rate cannot
reach 284 kbps.
Download data with multiple threads tool, such as FlashGet and NetAnt.
Multiple TCP connects to the server, so the rate can increase. According
to test result, download data with more than two threads by using
FlashGet or NetAnt, the rate can reach 47 kbps.
Remove the restriction on sending window size of server, and set the
sending window size of server to 65535.
Description
Activate uplink 64 kbps and downlink 384 kbps services on UE and laptop.
Connect UE to the server of operator, and upload and download data with FTP
simultaneous. Wherein, the downloading rate is greatly affected, and
fluctuates sharply. The average downloading rate declines from 47 kbyte to 20
kbyte. However, downloading and uploading respectively are available.
Analysis
Uploading and downloading simultaneously affect the ACK delay of TCP.
This leads to prolonged delay upon confirmation, and the TCP window size is
inadequate. Execute the ping command upon for confirming delay upon
simultaneous uploading and downloading. Obtain the maximum supported
rate with the TCP window size/delay.
According to the analysis of the second problem, the TCP window size of
operator's server is about 8.4 kbyte (the operator may use the FTP software
Serv-U. Its default sending and receiving buffer is 8293 bytes). Upon
simultaneous uploading and downloading, check the ping packet delay by
executing the command ping to the server. The ping packet delay is about
1500ms, 8.4/1.4 = 6 kbyte.
The previous two paragraphs describe the case of single thread. Start 3 threads
and the theoretical rate should be 18 KB/s (6 * 3 = 18). According to actual
test, download data with 3 threads by using FlashGet from the operator's
server, and upload data with CuteFTP simultaneously. The average sending
and receiving rate of UE is 17.9 KB/s in downlink and 7.2 KB/s in uplink.
The downlink rate is approximately equal to theoretical value.
Namely, when the UE sends data in uplink, the delay increases sharply, so is
the uplink response delay to the ACK message. As a result, the TCP judges it
as congestion, so the rate declines. This explains that uploading and
downloading respectively are available but simultaneous uploading and
downloading lead to decline of downlink rate.
Solution
According to previous analysis, increasing TCP window size of server leads to
increasing downlink theoretical rate. Actually, when using Huawei
servers for test, set the TCP window size to 65535, download with three
threads by using FlashGet. Simultaneously upload data with CuteFTP.
The average sending and receiving rate is 46.5 KB/s in downlink and 6
KB/s in uplink.
Download data with multiple threads. According to test, download data with
10 threads from operator's server when the TCP window size is 8192.
The average sending and receiving rate is 42 KB/s in downlink and 6
KB/s in uplink. The data transfer is unstable with jitters.
Send the ACK message in downlink data packets, and sends uplink data
packets at a fixed rate. Restrict the uplink rate so that the uplink data
packets will not be blocked at the air interface and the delay at the air
interface will not increase, and there is no jitter. Obviously, the decline of
downlink rate upon uplink and downlink data transfer is not due to
Huawei system, and this problem cannot be mitigated by this solution.
This is a defect of TCP/IP protocol used in radio transmission. It is good
to combine the UE and the driver of wireless Modem to carry out the
solution.
Description
Activate 6 UEs with downlink 384k service, and connect them to the
operator's server simultaneously. Download data with FTP, and the rate
declines to 30 KB/s.
Analysis
Download data on one UE by FTP from operator's server, and the rate is as
normal as above 47 KB/s. Download data on two UEs, and then on three. The
downloading rate keeps at about 47 KB/s with 4 UEs connected at most.
When the fifth UE connects to the server, the rate declines. Try on site as
below:
Download data with four UEs from the operator's server, and with two UEs
from Huawei servers. Check whether the rate is faulty.
As a result, the downloading rate of 6 UEs reaches 47 KB/s.
Probably, the operator's server does not well cooperate with Huawei
networks.
Download data with six UEs from Huawei servers. Check whether the rate is
faulty.
Huawei servers cooperate well with Huawei networks. Probably the
operator's server does not well cooperate with Huawei networks.
The difference between the operator's server and Huawei server lies in the
router and firewall over the operator's server. Try to avoid the impact
from firewall and router, and check whether the rate increases.
Connect the Gi interface of GGSN to NE08 directly, and download data
with UE from the operator's server. Check whether the rate increases.
The result proves that the rate remains the same.
Therefore, the firewall has no impact on the rate.
Download data with six UEs from Huawei servers, and there is no problem.
Connect Huawei server to NE08 port to replace the operator's server for
test, and check whether the rate is faulty.
As a result, the downloading rate of six UEs reaches above 47 KB/s.
Therefore, the router is normal.
Connect a laptop to Gi interface. Download data with 4 UEs and with a laptop
simultaneously, and check whether their downloadings affect each other.
Tests prove that they seldom affect each other. The rate of some UEs
2019-1-19 华为机密,未经许可不得扩散 第 93 页, 共 133 页
文档名称 文档密级
declines a little, and that of some UEs are seldom affected. The rate of
downloading data directly by laptop is 388 KB/s (single thread) or 1000
KB/s (three threads).
The export bandwidth to the operator's server is enough, so decline of
rate must not be due to bandwidth used for downloading data by multiple
UEs simultaneously.
After previous verifications, the peripheral equipment problems are excluded,
so probably the problem lies in the cooperation between the operator's
server and Huawei network. The major differences between Huawei
server and the operator server lie in two aspects: MTU and
TcpWindowSize. Still on Huawei Server, modify the two parameters for
verification:
The configuration in the regedit on server is MTU 1450, and
TcpWindowSize is 65535. Activate six UEs simultaneously, and the rate
is as stable as above 47 KB/s.
Keep the MTU of web server at 1450. Modify the TcpWindowSize in
regedit to 10 KB (10240). After restart, the rate of simultaneous rate by
six UEs keeps above 47 KB/s.
Delete the MTU from the regedit of web server (use the default value
1500). Keep TcpWindowSize at 65535. After restart, the rate of six UEs
declines sharply (20–30 KB/s). The downloading rate of three UEs keeps
at 47 KB/s until the fourth UE joins.
Therefore, when the MTU is the default value 1500, the rate of
simultaneous downloading by multiple UEs declines. According to the
packets captured by Sniffer, the MTU on the operator's server is the
default value 1500.
According to analysis, when the MTU is 1500, due to the TCP header
encapsulated along the path, the data packet is over long when the
downlink data packet reaches SGSN. Before sending data packet to
RNC, the SGSN must fragment and reassemble the packet. The current
SGSN transfers data by using software, so it starts flow control to protect
main controller. As a result, the downlink rate declines upon fragment
and reassembly.
Solution:
− Set the MTU of the operator's server to 1450 (if fragment is
unnecessary, MTU should be as large as possible. According to test,
1450 is improper).
− Set the MTU of laptops connected to UE to 1450 (you must change
the MTU at USB port of laptops) so that the SGSN will not start
fragment and reassembly.
Since it is impossible to modify MTU of the operator's server, solve the
problem by using the second method. For how to TCP parameters in
Windows, see the appendix.
Description
On-site engineers feed back that the data transfer fluctuates at the beginning
every morning. Facts prove this right upon downloading. and show unstable
PS rate.
Analysis
shows analyzing packets captured by Ethereal upon unstable PS rate.
Description
After the commercial network is launched, the rate of 384 kbps service is
unstable. It cannot reach the required rate, and even keeps at several dozen
kbps.
Analysis
Probably the problem is caused by loss of data packets and delay. After
capturing packets by segment, the cause proves on the firewall.
After repeated tests, the Up/Down and CRC Error occur frequently at the
firewall 2 interface 2/2. After another 3 hours' test, the cable between the
firewall 2 interface 2/2 and LS12 must not be physically broken, and CRC
error must be due to improper installation of fiber.
A faulty firewall leads to loss of packets at the application layer, which has
great impact on rate.
When the firewall is normal, the PS rate increases greatly. However, the rate is
still unstable. According to further analysis, the BLER at the air interface is
10%, so it is normal for PS rate to fluctuate at the air interface. After
engineers modify the BLER to 1%, the problem is solved. However, the cost
is more consumption of power at the air interface and impact on capacity.
Description
A subscriber cannot use streaming service in a deployment.
Analysis
The subscriber can browse the portal websites, but cannot use streaming
service. Meanwhile other subscribers can use streaming service. Therefore,
the PS service bearer is normal, and the cause cannot be on RAN, SGSN, and
GGSN. Probably the UE, USIM card, and server are faulty. According to
further analysis, the problem must be on the USIM card, and the subscriber
did not pay for using streaming service. The subscriber can browse the free
portal websites.
Description
A subscriber cannot use PS services with Nokia 7600 connected to his laptop.
Analysis
The subscriber feed back that other subscribers can use PS services with his
card. He could use PS service until one day recently. Therefore, the problem is
about the laptop. The problem does not occur after he changes the laptop.
According to check, the subscriber has installed a firewall on his laptop
recently. After uninstalling the firewall, he can use PS services again.
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.
Description
An operator's engineer feed back that the downloading cannot be ended
normally when it lasts for over 10 minutes with Huawei 3G network. The
downloading is normal with other operators' networks or 2G networks.
Analysis
According to analysis of FTP messages captured by Ethereal, the data session
of FTP is over, but it misses the last interactive completion process, and no
messages like 221-Goodbye is found. The downloaded files can be opened.
After the files are downloaded, they can be opened according to check.
shows the interactive interface in CuteFTP.
normal, the downloaded content is correct and available, but the signaling is
abnormally closed.
Without other better method, the method of exchanging NEs and segment is
used.
Check whether the problem is about UE and server.
The problem is still present with verification by three UEs: Nokia 6630,
Qualcomm 6250, and Moto 835. The problem is still present with verification
by two servers: Eurotel FTP server and Huawei FTP server. The problem is
still present with verification by Huawei FTP server in UNIX operating
system and in Windows 2000 Professional FTP server.
Search for the configuration of FTP server, and no relevant configuration is
found.
Conclusion: the problem is present with multiple UEs, operators, and Huawei
FTP server, so the problem is irrelevant to UEs and FTP server, but relevant to
Huawei network.
Compare the tests in the 3G network, the 2G network, and the tests of handover
to the 2G network after access in the 3G network.
According to tests, the problem must be between GGSN and FTP server. This
reduces the scope of problem.
According to other tests, the problem does not occur when no firewall is over
Huawei server. This shows the cause. The problem does not reoccur due to no
firewall.
According to data analysis, the data transfer at the FTP port is normal, but the
signaling port is disconnected after 10 minutes. This must be due to firewall.
It is the firewall that can disconnect a port without data transfer after 10
minutes, so the problem is due to firewall.
Processing the problem goes smoothly after focusing on the firewall. The
expert on firewall explains as below:
The FTP session includes two session tables on firewall. One is for FTP
control channel, and the default aging time is 10 minutes. The other is FTP
data channel, and the default aging time is 4 minutes. The no detect ftp
command is configured between domains, the data channel will not update the
aging time of control channel upon data transfer. As a result, the control
channel is aging and deleted after 10 minutes with the following phenomenon.
If the detect ftp command is configured, the data channel will update the
aging time of control channel. As a result, the problem does not occur.
The problem, in whole process, is irrelevant to RAN. However, the process
and result of locating problem is considerable.
Changing NEs in test is significantly useful.
The difficulty of problem may exceed engineers' consideration. It needs wide-
range knowledge. However, after the problem is solved, it seams easy.
Description
A test of handover between Huawei 3G network of trial deployment and the
2G network of a partner is going in a deployment. The test UE is Huawei
U626. When the UE hands over from the 3G network to the 2G network in
connection mode, it keeps being in PS connection, but it cannot transfer data
normally. When the UE hands over from the 2G network to the 3G network, it
can transfer data normally.
Analysis
The UE hands over between the 3G network and 2G network. The UE camps
on 3G network, and has activated PDP, in PMM Connected state. When the
UE moves at the edge of 3G network coverage areas, it starts handing over to
2G network. When the handover is complete, the PS user plane is restores and
can perform data transfer. However, the problem lies in that the UE cannot
continue data transfer.
Analyze traced signaling.
shows the signaling of normal handover between 3G network and 2G
network.
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 :
Trace the signaling on the partner's 2G SGSN. It is found that the signaling
interaction flow from 2G SGSN to GGSN and that of HLR are complete.
After the 2G SGSN sends UE the routing area update request message, the UE
must sends 2G SGSN the routing area update complete message according
to standard flow, which is not found in traced signaling. As a result, the 2G
SGSN judges that the UE has not completed the routing area update, so the
UE cannot transfer data after handover to the 2G network. However, the UE
keeps being in connected mode after handover to 2G network, so the UE
judges that it has completed routing area update. This indicates that the
problem lie between the UE and SGSN.
shows the signaling flow traced on 2G SGSN.
Check the encryption state of 3G SGSN. The SGSN uses UEA1 as the
encryption method, but the serving 2G network uses no encryption method.
When the UE hands over from the encryption in 3G network to the non-
encryption in 2G network, the 2G network fails to send the encryption and
authentication message, indicating UE to disable encryption state, and the
encryption state of UE has not synchronized with network side. As a result,
the UE encrypted its messages upon sending RAU, but the RAN side does not
encrypt messages. Therefore, the RAN side fails to receive RAU result.
Solution
This problem concerns the partner's equipment at RAN side. It cannot be
solved at UE side due to restriction from protocols. Therefore, the solution is
to set the encryption item to non-encryption so that the messages sent by UE
are not encrypted. As a result, the problem is mitigated.
7 Summary
This document describe the access, disconnection of data transfer, low rate of
data transfer, unstable rate of data transfer, and interruption of data transfer. It
provides the methods for analyzing and processing these problems in terms of
traffic statistics and DT/CQT. The experience from analyzing problems in
terms of traffic statistics is little, and will be supplemented.
In addition, the document details the flow for optimizing DCH bearer of data
service and the flow for optimizing HSDPA bearer of data service.
The used cases include abundant cases at CN side. Actually, analyzing
problems or modifying parameters at CN side must be processed by engineers
at CN side. These CN cases just serve as reference for analyzing problems.
8 Appendix
Title Description
8.1Transport Channel of PS
Data
8.2Theoretical Rates at Each
Layer
8.3Bearer Methods of PS
Services
8.4Description of HSDPA
Algorithms and Parameters
8.5Method for Modifying TCP
Receive Window
8.6Method for Modifying
MTU
8.7Confirming APN and Rate
in Activate PDP Context
Request Message
8.8APN Effect
8.9PS Tools
8.10Analysis of PDP
Activation
Wherein, the Gi interface connects to the application server, on which the FTP
Server software is running. Download data from the application server to UE
(MS) through five interfaces: Gi, Gn, IuPS, Iub, and Uu. The PS services use
the AM mode of RLC, which supports retransmission. The services like FTP
and HTTP use TCP protocol, which also supports retransmission.
The parameters of these two protocols (RLC/TCP) have great impact on rate.
If the parameters are improper, or packet error or loss of packets occurs during
transmission, the rate will decline. Evaluate QoS based on that a computer
with UE as its modem runs applications. This concerns the performance of
computers and servers.
8.3.1 DCH
The DCH bandwidth depends on the current power resource, code resource,
and Iub bandwidth resource. Typical rates include 8 kbps, 32 kbps, 64 kbps,
128 kbps, 144 kbps, and 384 kbps. The DCH bandwidth is adjustable by
algorithms like DCCC according to the current traffic and coverage
conditions, but the adjustment is limited to previous rates. In addition, the
interval to trigger adjustment is long. As a result, the adjustment is not
frequent.
8.3.2 HSDPA
The network does not allocate fixed bandwidth or resources for the PS
services carried by HSDPA, but perform fast schedule every 2ms. Therefore,
the throughput that a subscriber can reach depends on abundant factors, such
as:
UE category (capacity level)
Available code resource of HSDPA
Available power resource of HSDPA
Number of HSDPA subscribers
Scheduling algorithm
Radio environment
Therefore, the throughput of single PS service carried by HSDPA fluctuates
more sharply than that carried by DCH. However, HSDPA uses new
technologies, such as fast schedule, HARQ, and 16QAM, so the utilization
rate of resources is higher, and throughput of whole cell is higher.
8.3.3 CCH
FACH can carried PS services of low traffic, it can also bear broadcasting
services like CMB.
FACH uses code resource of different SFs, so it support variable channel rate.
This depends on the need by broadcasting services like CMB.
In , the pink massy dot is assigned to CCH. Each channel code is indicated by
C (m, n). Wherein, the m is SF (spreading factor), and n is channel code
number, 0 ≤ n ≤ m – 1. The m is 2 to the power x. The x is an integer.
The HSDPA cells, like R99 cells, must be configured with CCH. Codes must
be assigned to CCH. The codes of PCPICH and PCCPCH are fixed to C (256,
0), C (256, 1). Number of SCCPCHs and SF change. The SF ranges from 256
to 4. It is set on RNC LMT.
lists the CCH SFs.
CCH SFs
Channel SF
PCPICH 256
PSCH None
SSCH None
BCH Carried by P-CCPCH. SF: 256
PCH Carried by S-CCPCH. SF is variable. The
default SF is 64.
FACH
AICH 256
PICH 256
0 30 15 256 300 20 20 0 0
1 30 15 256 300 20 12 8 0
2 30 15 256 300 20 18 0 2
3 30 15 256 300 20 10 8 2
4 60 30 128 600 40 40 0 0
5 60 30 128 600 40 32 8 0
6 60 30 128 600 40 38 0 2
7 60 30 128 600 40 30 8 2
8 120 60 64 1200 80 72 0 8*
9 120 60 64 1200 80 64 8 8*
10 240 120 32 2400 160 152 0 8*
11 240 120 32 2400 160 144 8 8*
12 480 240 16 4800 320 312 0 8*
13 480 240 16 4800 320 296 16 8*
14 960 480 8 9600 640 632 0 8*
15 960 480 8 9600 640 616 16 8*
16 1920 960 4 19200 1280 1272 0 8*
17 1920 960 4 19200 1280 1256 16 8*
The number of SCCPCHs and SF depends on the capacity of PCH and FACH bearer.
Engineers must be cautious on actual modification. Only when engineers perform cell
throughput test or maximum subscriber number of single cell, can them change SF
larger, such as from 64 to 128.
HSDPA SFs
Channel SF
HS-SCCH 128
HS-PDSCH 16
Only when the HSDPA feature is deactivated, can engineers modify code
resource. After modification, activate HSDPA feature. Modify HSDPA
by executing the command below:
DEA CELLHSDPA; //Deactivate HSDPA feature of cell
MOD CELLHSDPA: CELLID=10201, AllocCodeMode=Manual,
HSPDSCHCODENUM=10, HSSCCHCODENUM=2;
ACT CELLHSDPA; // Activate HSDPA feature of cell
RNC automatic code allocation algorithm
In automatic code allocation, the RNC LMT sets the maximum and
minimum number of available codes for HS-PDSCH.
Minimum number of HSDPA codes: assume that the value is N1, and
then the codes with the number from 16 to 16 – N1 + 1 are allocated to
HS-DSCH.
Maximum number of HSDPA codes: assume that the value is N2, and
then the codes with 16 as SF and with the number from 16 – N1 + 1 to
16 – N2 + 1 are totally allocated to HS-DSCH if R99 DPCH does not
need the codes.
The codes with 16 as SF and with code number from 16 – N1 + 1 to 16 –
N2 + 1 are shared codes. Namely, they can be used by R99 DPCH and
HSDPA. Most of the services carried on R99 DPCH are CS services,
with high priority. As a result, when the R99 DPCH code resource is
inadequate, the R99 DPCH will use shared code by priority.
DEA CELLHSDPA; // Deactivate HSDPA feature of cell
MOD CELLHSDPA: CELLID=10201, AllocCodeMode=Automatic,
HsPdschMaxCodeNum=10, HsPdschMinCodeNum=5,
RevSFThd=SF32;
ACT CELLHSDPA; // Activate HSDPA feature of cell
In ,
CCH: PCIPCH uses C(256,0), PCCPCH uses C(256,1), AICH uses
C(256,2), PICH uses C(256,3), and SCCPCH(64,1).
HS-SCCH: C(128,4)–C(128,7). Four HS-SCCHs are configured.
HS-PDSCH: C(162,2)–C(16,15). 14 HS-PDSCHs are configured.
Associated DCH: C(256,16)–C(256,19). There are four HSDPA
subscribers. After each subscriber sets up HSDPA services, the network
allocates a DCH with 256 as SF.
and the power. In current version, when the CQI modified by NodeB is
smaller than 2, the NodeB will not transfer data to the UE.
Calculate the CQI reported by UE according to Ec/Nt as below:
CQI reported by UE = (Ec/Nt)CPICH + 10 * lg(16) + MPO + 4.5
Wherein,
10 * lg(16) is the spreading factor (SF = 16) for calculating HS-PDSCH.
MPO is the acronym of Measure Power Offset. Calculate MPO with the
MPO constant as below:
MPO = Min(13,CellMaxPower - PcpichPower – MPO constant)
4.5 is a fixed constant, obtained from simulation result.
The CellMaxPower is 43 dBm. The PcpichPower is 33 dBm. The default
MPO constant is 2.5 dB. The orthogonal factor is 0.6. The average
interference factor of neighbor cell is 0.65. Therefore, the relationship
between pilot Ec/Io and pilot Ec/Nt is N t (1 f ) * I oc N 0 and
I o (1 f ) * I oc N 0 . Wherein, Ioc is the signals of the cell. Neglecting the
impact from thermal noise, the relationship between the CQI reported by UE
and pilot Ec/Io is as listed in .
–14 12
–13 13
–12 14
–11 15
–10 16
–9 17
–8 18
–7 19
–6 20
–5 21
The CQI reported by UE is relevant to factors like multipath conditions, and thermal
noise of laptops.
Sometime the impact from thermal noise No cannot be neglected, especially with
laptop and data card.
power control, but keeps a power offset with uplink DPCCH. When HS-
DPCCH carries different information, it uses different power offsets.
Basic Process
Upon modulation, the information 0, 1, and DTX of HS-DPCCH are
respectively mapped as +1, –1, and 0. After spreading, they are multiplied
with a gain factor hs . The hs depends on the power offsets ACK ,
NACK , and CQI . lists the quantized amplitude ratio of power offsets
ACK , NACK , and CQI .
HS DPCCH CQI
For the timeslot to bear CQI, , so for uncompressed
HS DPCCH
frames,
HS c 10 20
.
At the header and tail of compressed frames, the ratio of DPCCH power and
HS-DPCCH power keeps fixed. Between the frame header and tail,
HS DPCCH
N pilot ,C
HS c 10 20
N pilot , N
vary with the difference between initial target SIR of the service and the
reference target SIR.
In
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpi
p\Parameters, add double type value TcpWindowSize. Set it to 65535 or
ffff (hex).
Server
Modify the MTU in Adapter Settings shown in , namely, the MTU at the
network port.
Test Laptop
For test laptops, the UE is connected to it by data line and dial-up connection
is set up. Data packets are sent through USB port. As a result, modifying
MTU of USB port is necessary, namely, the Dial Up(RAS) MTU as shown in .
After modification, restart the Windows operating system.
8.7 Confirming APN and Rate in Activate PDP Context Request Message
When the UE originates data services, the QoS is sent to the system in
Activate PDP Context Request message. The message result is as shown in .
guar bit rate up: uplink guaranteed rate, 0 in the following figure,
namely, no requirement is on uplink guaranteed rate.
guar bit rate down: downlink guaranteed rate, 0 in the following figure,
namely, no requirement is on downlink guaranteed rate.
3GPP protocol 24.008 prescribes the method for calculating rate as below:
Assume x is the initial value required by a rate.
If 0 < x < 64, the actual rate is x kbps.
If 64 ≤ x < 128, the actual rate is 64 + (x – 64) * 8 kbps. In the following
figure, the downlink maximum rate is 104 kbps. The calculation formula: 64 +
(104 – 64) * 8 = 384 kbps.
If 128 ≤ x < 255, the actual rate is 576 + (x – 128) * 64 kbps.
If x = 255, the actual rate is 0 kbps.
8.7.3 APN
The APN in messages are ASCII code of characters, so engineers cannot see
the string directly.
shows converting ASCII code to string in UltraEdit.
You can see the APN string in , it start at the fourth byte.
8.9 PS Tools
8.9.1 TCP Receive Window and MTU Modification Tools
Modify TCP receive window and MTU with the following tool:
Drtcp.rar
For the detailed method, see the appendix 8.5 and 8.6.
8.9.2 Sniffer
Sniffer can capture, construct, and send packets. It constructs transfer data at a
fixed rate, and then obtains the rate at other NEs. This eliminates the external
impact. Sniffer can send packets at UE side or on server. It can construct data
transfer at fixed rate in uplink and downlink simultaneously, or just construct
data transfer in uplink or downlink.
ping packets of the same number are received. This checks whether packets
are lost during transmission.
C1
3. Radio Access Bearer Setup
4. Invoke Trace
5. Create PDP Context Request
C2
7. Activate PDP Context Accept
The MS sends SGSN the Activate PDP Context Request (NSAPI, TI, PDP
Type, PDP Address, Access Point Name, QoS Requested). The PDP Address
indicates the dynamic address or the static address. If the PDP Address is
dynamic address, set it to null.
The following aspects lead to unsuccessful PDP activation process:
Activation rejected, unspecified (#31): Huawei SGSN defines GTPU
interaction failure, expiration, operation SDB failure, activation failure
due to other abnormalities to this kind of failure.
Activation rejected by GGSN (#30): GGSN rejects or fails to decode the
corresponding activation request.
Missing or unknown APN (#27): APN is not contained in the activation
request message or cannot be extracted. Huawei SGSN takes DNS
resolution failure, DHCP or MIP GGSN address acquisition failure, APN
error specified by activation at network side, other APN error as
activation failure. These are internal causes.
Unknown PDP address or PDP type (#28): the PDP address or PDP type
cannot be identified by SGSN.
User Authentication failed (#29): user authentication fails.
Service option not supported (#32): the requested serving PLMN does
not support this. Huawei SGSN takes wildcard (*) activation rejection,
service non-supportive, IPV6 non-supportive as this type.
Requested service option not subscribed (#33): requested service is not
subscribed. Huawei SGSN takes mismatch subscribed information,
VPLMN access inhibit, and charging restricted callingVPLMN as this
type.
Insufficient resources (#26): activation fails due to inadequate resource.
Huawei SGSN takes the following causes as inadequate resource.
− UGBI PDP resource congestion
− UGBI board congestion
− RPU failure
− Inadequate SDB or SM CB resource
− Activation failure due to internal charging restricted calling
Operator Determined Barring (#8): operators bar PDP activation process.
Service option temporarily out of order (#34): this is a cause value which
MSC use to indicate that function are inadequate to support
corresponding requests. Huawei SGSN is seldom used, so neglect it.
NSAPI already used (#35): the requested NSAPI is already used by PDP
activated by the subscriber, but the cause value will not be sent.
Protocol error, unspecified (#111): Huawei SGSN in abnormal SDB or
SM state may confront this type of activation rejection.
Reference
[1] W-Equipment Room Operation Guide