Beruflich Dokumente
Kultur Dokumente
03
UMTS RF
Troubleshooting Guideline
U04.03
Version: 2.1
Table of Contents
2. REFERENCES ........................................................................................................................... 10
Change Record
This table details the changes done to the document since the last baseline version
2. References
[1] TS 23122 NAS Functions related to Mobile Station (MS) in idle mode
[2] TS 11.11 Specification of the SIM – ME interface
[3] TS 25304 UE Procedures in Idle Mode and Procedures for Cell Reselection
in Connected Mode”
[4] GSM 03.22 Functions related to Mobile Station in idle mode and group
receive mode
[5] TS 24008 Mobile radio interface layer 3 specification; Core Network
Protocols – Stage3
[6] TS 25331 RRC Protocol Specification
[7] TS 25433 UTRAN Iub Interface NBAP Signalling
[8] TS 24007 Mobile radio interface signalling layer 3 specification; general
aspects
[9] TS 25413 UTRAN Iu Interface RANAP Signalling
[10] TS 25423 UTRAN Iur Interface RNSAP Signalling
[11] TS 25214 Physical layer procedures (FDD)
[12] TS 25922 Radio resource management strategies
[13] TS 25201 User Equipment (UE) Radio transmission and reception (FDD)
[14] TS 25306 UE Radio Access Capabilities
[15] TS 34121 Terminal conformance specification; Radio transmission and
reception (FDD)
[16] UMTS RF Translation Application Note (TAN) for HSDPA
[17] UMTS RF Translation Application Note (TAN) for EDCH
[18] UMTS RF Translation Application Note (TAN) for Cell Selection and
Reselection
[19] UMTS RF Translation Application Note (TAN) for Access Procedures
[20] UMTS RF Translation Application Note (TAN) for Load Control
[21] UMTS RF Translation Application Note (TAN) RLC
[22] UMTS RF Translation Application Note (TAN) RF Call Trace
[23] UMTS RF Translation Application Note (TAN) Handover
[24] UMTS RF Translation Application Note (TAN) Inter-Frequency Handover
[25] UMTS RF Translation Application Note (TAN) Inter-RAT Handover
[26] UMTS RF Translation Application Note (TAN) Inter Frequency Handover
[27] UMTS RF Translation Application Note (TAN) Radio Link Control
[28] UMTS RF Translation Application Note (TAN) Power Control
[29] Actix, http://www.actix.com
3.2. Content
There are five main chapters in this document:
• Chapter “About this document” is providing an introduction and an
overview of the UMTS RF Troubleshooting Guideline.
• Chapter “Description of the optimisation process” is providing a short
overview of the UMTS optimisation process as covered by the UMTS
RF Troubleshooting Guideline.
• Chapter “Call setup” is listing all problems that might occur at the call
establishment phase.
• Chapter “Call reliability” is describing failures and problems that might
occur after call establishment; examples are dropped calls, radio link
failures or handover problems.
• Chapter “Call quality” is dealing with quality problems as perceived by
the UMTS subscriber.
5. Call setup
One main user perception of a UMTS network is the success of setting-up a
UMTS call. This section is describing all kind of failures and problems that might
occur during the call establishment phase. The different phases during the call
setup are covered step-by-step in the following subsections of this chapter.
Qrxlevmeas is cell RX level value. This is received signal, CPICH RSCP for FDD cells (dBm),
P-CCPCH RSCP for TDD cells (dBm) and RXLEV for GSM cells (dBm)
Pcompensation is the defined as Max(UE_TXPWR_MAX_RACH – P_MAX, 0) (UMTS),
Max(MS_TXPWR_MAX_CCH – P, 0) (GSM)
UE_TXPWR_MAX_RACH is the maximum allowed power for the RACH and P_MAX is the
maximum power for the given mobile power class.
The different O&M parameters of the formula above are listed in Table 1 below:
Parameter Description
Qqualmin Minimum required quality level in the cell (dB). Not applicable for TDD cells or
GSM cells, broadcasted via SIB3 and SIB4
Qrxlevmin Minimum required RX level in the cell (dBm), broadcasted via SIB3 and SIB4
Remark
The current formulas can only be used in case HCS is not deployed.
Furthermore while camping the UE shall start to perform inter-RAT
measurements if Squal <= SSearchRAT, otherwise not. SSearchRAT is a configurable
UMTS parameter broadcasted on SIB3/SIB4. However note that to avoid ping
ponging between UMTS and GSM the following condition should be fulfilled:
FDD_Qmin > Qqualmin + SsearchRAT
If the above condition is not satisfied, a UE will move from GSM to UMTS and
immediately start monitoring neighboring GSM cells again, an undesirable
condition. Furthermore frequent re-selections between UMTS and GSM can
cause mobile terminating call failure in case the PLMN pages the current
network while the UE is in the process of registering with the other network.
In a similar way the criterion for UMTS Interfrequency measurements is defined;
for this parameter Sintersearch is used and is broadcasted on SIB3/SIB4.
The UE can only reselect one of the 2G or 3G cells that are defined in the
reselection list that are broadcasted via SIB11/SIB12 on the BCCH.
For cell reselection the target cell has to fulfill the same criteria as specified for
the cell selection case. The UE ranks the cells according to the cell ranking
criteria Rs (serving cell) and Rn (neighbour cell). The UE will reselect the best
GSM or UMTS cell of the ranking list if at least Treselection (UMTS parameter)
has elapsed when camping on the cell. For UMTS network without HCS the
following formulas are used (both for GSM and UMTS cells):
Rs = Qmeas,s + Qhysts
Rn = Qmeas,n - Qoffsets,n
For UMTS Qmeas is based either on RSCP or Ec/No measurements of the
server/neighbour cell depending on the setting of the UTRAN parameter
configuring the selection and reselection quality measure. Qhysts is an hysteresis
to avoid ping-pong effects, Qoffsets,n is an offset defined on a per-neighbour
definition (for both GSM and UMTS neighbours).
The reselection process using the mentioned parameters (Qoffsets,n = 0) is
visualised in Figure 3 below:
Table 2 below is listing the main parameters configuring the cell reselection
process in case no HCS is used:
Parameter Description
cellSelAndResQualMeas Parameter defining whether CPICH or RSCP measurement shall be used for
UMTS measurements
sIB3Treselection Time hysteresis for the cell reselection
sIB3RAT.sSearchRAT UMTS parameter broadcasted via the SIB3/SIB4 defining whether or not to start
with inter-RAT measurements (setting of SSearchRAT)
sIB3SInterSearch UMTS parameter broadcasted via the SIB3/SIB4 defining whether or not to start
with UMTS interfrequency measurements (setting of Sintersearch)
Table 2: Most important parameter used for cell reselection, non HCS
measurements. Also the cell offsets for the GSM cells can be adapted to prefer
call setup on the 2G layer.
Another problem arises when different LA codes are defined for the GSM and
UMTS networks and the Inter-RAT reselection criterion is met. This is in
particular the case for subscribers inside a building where the UMTS coverage
is not as strong compared to the GSM coverage, but the preference is on the
UMTS network. As a consequence it is recommended to assign the same LA
codes to GSM and UMTS cells that are providing coverage to the same area to
avoid LAU ping-pong.
Table 3 below is listing the identification techniques of PLMN/cell (re-)selection
failures in drive test traces and scanner measurements:
After the UE has successfully decoded the paging on the PCH it sends a RACH
Preamble using the open loop power control algorithm. When the NodeB
receives the RACH Preamble it answers by sending an indication on the AICH,
the reception of the AICH is answered by the UE by sending a RRC Connection
Request/Cell Update/URA Update message using the RACH (so called RACH
Message Part). Upon successful decoding the NodeB forwards the RACH
Message Part to the RNC. RACH failures are covered in subsection 5.1.3.
The RNC sends back (on the FACH) the RRC Connection Setup/Cell Update
Confirm/URA Update Confirm message (successful case). FACH failures are
covered in subsection 5.1.6.
Table 4 below is listing the main UTRAN parameters configuring the PICH, PCH
and AICH:
Parameter Description
pICHPower UTRAN parameter defining the power settings of the PICH
pCHPower UTRAN parameter defining the power settings of the PCH
aICHPower UTRAN parameter defining the power settings of the AICH
1
CN_PCH_Timer Timeout when the CN will reinitiate the paging
tPageRep Timeout when the RNC will reinitiate the paging
CN_PCH_Max Maximum number of paging repetitions by the CN
nUtranPageRep Maximum number of paging repetitions by the RNC
Table 4: Parameter used for configuring the PICH, AICH and PCH
The paging itself is sent on the PCH that is a PHY channel on Uu. The drive test
equipment can record paging requests. However analysing drive test logs is not
a good way to investigate paging problems because paging that is not received
by the UE can only be detected via parallel Iub tracing.
A better approach for analysing call setup problems due to paging failures is to
use PM counters of the UTRAN and the CN.
If the UE is in URA_PCH or CELL_PCH mode, the RRC connection is
maintained via the common physical channels (subsection 6.6). When the UE
cannot be reached via paging the UTRAN may decide to drop the RRC
connection.
1
CN_PCH_Timer & CN_PCH_Max are dummy names for the parameters
2
“<per establishment cause>” is a placeholder for e.g. OrigConvCall, OrigStrmCall etc. A full list is
available in [42].
Failures in the RACH procedure occur if either the RACH Preamble or the
RACH Message Part cannot be decoded.
Possible reasons for these decoding problems are:
• Non optimal RACH power settings
• Non optimal RACH counter/timer settings
• RACH congestion
• Non optimal setting of physicalRACHPreambleThreshold & RACH
search Window
• Poor radio conditions in terms of low RSCP or Ec/No because of e.g.
pilot pollution (subsection 6.4.1), poor RF coverage (subsection 6.4.5),
camping on a non-optimal cell (see subsection 5.1.1) etc.
In the following only the RACH specific issues are covered, for the other
(common) RF issues see the corresponding subsections.
Table 7 below is listing the main UTRAN parameters configuring the RACH:
Parameter Description
constantVal Used by UE to calculate Initial Preamble Power
PowerRampStep Determines the power increment between two successive RACH
Preambles
maxRetranPreamble Determines the maximum number of preambles allowed within one
Power Ramping Cycle
physicalRACHPreambleThres The threshold for preamble detection. The ratio between received
hold preamble power during the preamble period and interference level
shall be above this threshold in order to be acknowledged.
SIB3MAXAllowedULTXPower, These parameters define the maximum allowed power the UE may
SIB4MAXAllowedULTXPower use when accessing the cell on PRACH in idle mode
mMax Determine the maximum number of power ramping cycles allowed
t300 UE guard timer that is supervising the RRC Connection Setup
procedure when the UE is waiting for the RRC Connection Setup
message
n300 Defines the number of times the UE is allowed to send the same
RRC Connection Request message
t302 UE guard timer that is supervising the Cell/URA Update procedure
when the UE is waiting for the Cell Update Confirm/ URA Update
Confirm message
n302 Defines the number of times the UE is allowed to send the same
Cell Update/ URA Update message
and MAC procedure of the RACH is listed in the drive test logs e.g. number of
3
RACH Preambles sent, last transmitted power etc .
Possible congestion on the RACH could be detected by supervision of PM
UTRAN counters (Table 9 below).
The RACH performance can be improved by changing of the power settings
and/or changing of the timer/counter as listed in Table 7.
Table 8 below is listing the identification possibilities for network interface
traces, Table 9 below is listing the identification possibilities using KPIs
retrieved by the UTRAN PM system.
3
Note: It might be that in the drive test logs a RRCConnectionRequest message is listed, but the
RACH message part is never transmitted via the air interface in case the RACH preamble has already
failed.
The higher layer (RRC) initiates the transmission of the RACH message. In case of a lower layer
failure ro deliver preamble it is up to the higher layer re-initiate the whole RACH procedure again
(means in the RRC decoding another RACH Message would be listed).
Parameter Description
thrCAC2UL Specifies the load threshold for UL call admission of a non-emergency RRC connection
request.
thrCAC2DL Specifies the load threshold for DL call admission of a non-emergency RRC connection
request when HSDPA is disabled.
thrCAC2DLHS Specifies the load threshold for DL call admission of a non-emergency RRC connection
DPA request when HSDPA is enabled.
It is assumed that the RACH Message Part has been successfully received, the
CAC has been granted and the RL are established. In this case the RNC sends
back either the RRC Connection Setup, Cell Update Confirm or URA Update
Confirm message on FACH (successful case).
The RNC sends the FACH message, resets counter V30001 and starts its
guard timer T30001. When the RNC receives the answer by the UE (RRC
Connection Setup Complete, UTRAN Mobility Information Confirm, Radio
Bearer Reconfiguration Complete, … ) before T30001 expires, the RNC stops
T30001. If the RNC does not receive the message before T30001 expires, the
RNC may resend the FACH message depending on the status of counter
V30001. If V30001<= N30001 (maximum number of retries), the RNC
increments V30001 by one, resets timer T30001 and sends the FACH message
again. If V30001 > N30001, the RNC will stop sending FACHs to the UE and
will release the reserved resources on NBAP and ALCAP. Note that the RNC
will not send any failure message on the Uu.
The whole procedure is visualised in Figure 9 below:
Parameter Description
fACHTrafPower UTRAN parameter defining the power settings of the FACH data part
fACHSigPower UTRAN parameter defining the power settings of the FACH control part
uERRCConnectionSetupRes UTRAN parameter defining setting of T30001
ponseTimer
maxRRCConnSetupRetries UTRAN parameter defining setting of N30001
Possible reasons for that failure message are problems in the Radio Link Setup
procedure, protocol errors or problems when sending the FACH etc. Table 18
below is listing how to identify this kind of error in Uu logs:
Parameter Description
measQty.maxNoReport Defines the maximum number of cells the UE may report on RACH
edCellsOnRACH
addThresholdSHO Defines the hysteresis used at call setup to add neighbour cells to the Active Set
4
Exception: there might be the case that due to a bad RF environment the direct transfer messages
cannot be delivered to the other entity because the RLC layer is not able to deliver the corresponding
message also after RLC retransmissions, RLC resets etc. It is up to the corresponding higher layer
(e.g. CC, GMM, MM or SM) to react accordantly of the discarded message.
GMM Authentication Uu or Iub or Iu Any occurrence of a GMM Authentication and Ciphering Failure
and Ciphering Failure message sent by the UE. The specified rejection cause will indicate
the reason for the failure e.g. a sync failure.
GMM Authentication Uu or Iub or Iu Any occurrence of a GMM Authentication and Ciphering Reject
and Ciphering Reject message sent by the CN.
GMM Routing Area Uu or Iub or Iu Any occurrence of a GMM Routing area update reject message sent
Update Reject by the CN. The specified rejection cause will indicate the reason for
the failure e.g. protocol error, wrong or incorrect IE format etc.
GMM Service Reject Uu or Iub or Iu Any occurrence of a GMM Service reject message sent by the CN
Table 22 below is listing the PM KPIs of the Mobility Management as they can
be retrieved by the PM system of the 3G-MSC and SGSN:
5
Dummy names
6
There are a huge amount of failure causes, but not all related to RAB assignment failure.
7
The requested QoS profile in the PDP Context Activation message might be ignored and only a
default one is assigned
UtranCell RAB.FailEstabPSNoQueuing Number of RAB Establishment Failures due to a given cause for PS
.<Cause> domain.
Table 30 below is listing the identification triggers for network interface traces,
Table 31 the corresponding UTRAN KPIs.
Parameter Description
t312 The UTRAN parameter is configuring timer T312
n312 The UTRAN parameter is configuring N312
8
For corresponding definitions of CS RAB Attempts and PS RAB Attempts see [42].
CN
Parameter Description
tRLFailure This parameter is defining the setting of T_RLFAILURE
noOutSyncInd This parameter is defining the setting of N_OUTSYNC_IND
noInSyncInd This parameter is defining the setting of N_INSYNC_IND
radioLinkFailureResynchronisationR Configure guard timer T_RL_RESYNC to allow time for re-
esponseTimer synchronization to occur when a loss of synchronization is
detected on the last or only radio link associated with a
UE connection.
RadioLinkFailureDeletionResponse Configure guard timer T_RL_RESYNC to allow time for the
Timer normal operation of the handover and power control
algorithm to delete a radio link affected by a loss of
synchronization or for re-synchronization to occur when the
radio link is one of several associated with a UE
connection.
t313 This parameter is defining the setting of T313
n313 This parameter is defining the setting of N313
t314 This parameter is defining the setting of T314
t315 This parameter is defining the setting of T315
n315 This parameter is defining the setting of N315
9
To be noted: the group “eventResults” containing the IE “eventID” is optional, for example when
periodic reporting is enabled.
RAB drops that are not caused within the UTRAN can be identified by the Iu
Release Command message on RANAP; the specified cause is other than
“Release due to UTRAN generated reason” and “normal-release”.
The specified cause is vendor dependent. For the root cause analysis please
check with the corresponding UTRAN vendor documentation and the
documentation of the CN vendor.
10
The case RRCConnectionRelease with cause “congestion” is covered in subsection 5.4.1.
11
The likelihood of this is not very high because the specified failure causes do not match to the cell
update causes
it is indicating that the RLC in the UE has detected a failure on one of its AM
RLC entities that has not been resolved by e.g. resetting of the RLC [36]. For
more details regarding failures on the RLC see subsection 6.14.
If there is a RRC Connection Release message with cause “congestion” the
reason might be either Dynamic Bearer Control (subsection 5.4.1) or
Congestion Control (subsection 6.5).
Ex-Lucent supports the RRC connection re-establishment for PS, CS and
simbearer services, where by on detection of the RLF, the UE sends a cell
update with cause “RLF” and consequently old radio links are deleted and the
new radio links are established by the RNC.
This procedure fails if the UE does not send the cell update, a RANAP
procedure has started or a NAS message is received to be forwarded to the UE.
The procedure will also not occur if all the radio legs are on the Drift RNC, a
RANAP procedure is in progress or UE indicates that the T314 or T315 timer
has expired.
"RRC Connection
Re-Establishment Feature.ppt"
UE Node B RNC CN
4) ALCAP Release
10) UE Measurements
UE Node B RNC CN
T_RL_RESYNCH
expires, UE is PS 1) Radio Link Failure Indication
only
RNC st ops
Tim er
5) Cell Update (Cause Radio Link Failure)
11) UE Measurements
12
This is not really a problem to be identified in a trace; it is more an indication for in general non-
optimal RF conditions.
6.4.3. Around-the-corner-effect
6.4.3.1. Concept
Around-the-corner-effect is quite often encountered in a dense urban
environment. The effect describes a moving UE where the receive level of the
cells in the active set decreases dramatically (in terms of Ec/No and RSCP)
whereas the receive level of cells in the monitored or detected set suddenly
increases. The root cause for this problem is shadowing of buildings or other
obstructions. As a consequence the quality of the call will always drop if the UE
is not fast enough to adapt (via Active Set Update) to the new RF conditions.
Figure 16 is showing the effect in a dense urban environment:
Dropping of the RRC connection is done using the RRC Connection Release
message with specified cause “congestion”.
The initiating of CongC is indicating a high noise raise of the RF environment.
The only optimisation approach in that case is to optimise the RF environment
in terms of pilot pollution, neighbour list optimisation etc.
More detailed information can be found in [20].
13
Note that when the UE is in URA_PCH mode or CELL_PCH mode the release message with cause
“congestion” is used when DBC is triggered.
URA_PCH /
CELL_PCH
Cell DCH
DCH
IDLE
According to [6] the UE has to monitor the FACH transport channels in the
downlink. The UE in CELL_FACH mode informs the UTRAN when reselecting a
new cell by sending a RRC Cell Update message on RACH; the RNC answers
by sending a Cell Update Confirm message on the FACH and the procedure
ends with the UE sending an UTRAN Mobility Information Confirm message
again on RACH.
The SRNC decides whether or not to transit the UE to another state. Figure 18
is showing the different UE states and possible transition between them. In all
cases the RNC will initiate the transition by using either the RB Reconfiguration
or the Transport Channel Reconfiguration procedure on RRC (subsection
6.17.1). It might be necessary to either delete or setup resources on the Iub via
the corresponding NBAP procedures (exception is the transition from
CELL_FACH to URA_PCH/CELL_PCH but this should occur rarely).
The algorithms are vendor dependent taking into account traffic measurements
and the RF environment. Please check in the particular UTRAN vendor
parameter description.
Figure 19 and Figure 20 below are visualising the call handling for the transition
from CELL_DCH to CELL_FACH and vice versa:
There are a lot of PM counters available counting the number of attempts and
failures for the state transitions, see [42] for details.
Figure 22: Call handling flowchart of Active Set Update event 1a (event 1c)
HO related parameters and more detailed information about the Ex-Lucent
implementation is available in [23].
14
In case of e.g. periodic reporting an update via Measurement Control message is not required
Figure 23 below shows the call flow chart across the UMTS and GSM network
for performing UMTS to GSM voice handover including the UMTS and GSM
CN:
the UE. If the UE fails to complete the requested handover then the SRNC
receives a Handover From UTRAN Command Failure message from the UE.
According to [9] the failure causes specified within this message can be
subdivided as follows:
• Physical channel failure
• Unacceptable configuration
• Protocol error
The first failure refers to the case when there is loss of synchronisation between
UE and NodeB. This is mainly caused by poor RF conditions. The other two
causes are expected to occur seldom and in general are not related to RF
issues.
The IRAT HO can be configured with the parameters as described in [25].
More information about IRAT Handover optimisation is available in [46].
6.10.4. Failure symptoms, identification and fixes for improvement (CS GSM -
>UMTS)
Some main reasons as to why the GSM to UMTS handover procedure may fail
can be as follows. For a full list please refer to [25].
• The GSM to UMTS handover feature is not enabled in UTRAN target cell
• The UE does not support the target cell frequency band
• The requested radio resources cannot be established, e.g. radio link setup
fails on Iub or the ALCAP Iu transport bearer cannot be established
• The RNC does not receive a HANDOVER TO UTRAN COMPLETE message
from the UE, because the UE has received an invalid HANDOVER TO UTRAN
COMMAND message or it does not support the configuration included in the
message. In this case the timer expires
• The MSC cancels the relocation by releasing the Iu connection
Parameter Description
t309 Defining timer T309
Table 51: Parameter used for configuring the cell change order from
UTRAN
Table 52 below is listing the identification in interface traces possibilities for the
cell change order from UTRAN procedure:
Cell Change Order from UTRAN II Uu Any occurrence of the RRC message
CellChangeOrderFromUTRAN and within x seconds there is a
cell update message with cause "Radio link failure"
Cell Change Order from UTRAN III Uu Any occurrence of the RRC message
CellChangeOrderFromUTRAN and within x seconds there is a
cell update message with cell update cause "cellReselection"
Table 52: Identification of cell change order from UTRAN failures in traces
PM KPIs related to the process is available in [25].
• The UE may not able to perform the new configuration and returns a
Physical Channel -, Transport Channel - or Radio Bearer Reconfiguration
If the timer expires after any of the above Reconfiguration message has
been sent to the UE then the SRNC releases all radio resources newly
allocated using the NBAP Radio Link Deletion Procedure. The old radio
resources are no more available and the call will drop. The RNC initiates the
RANAP Iu Release Request procedure with cause 'Failure in the Radio
Interface Procedure' towards the CN.
Some important KPIs/Counters pegged during this process are given below:
PM Counter / KPI15 KPI Name / Description
system
UtranCell (HHO.SuccOutInterFreq.<trigger> / Inter-frequency hard handover
HHO.AttOutInterFreq.<trigger>) * 100 success rate
UtranCell HHO.FailOuterInterFreq.<trigger>.<failure cause> Hard handover failure count
UtranCell VS.HHO.AttPrepOutInterFreq.<trigger> Hard handover preparation attempt
count
15
<trigger> refers to quality or load based HO initiation and <failure cause> can be physical channel
reconfig failure or protocol error or configuration not supported.
AM RLC provides the link-layer ARQ scheme that is required to hide PHY block
errors from higher layers.
The RLC provides three different types of data transfer modes:
• TM data transfer
o No protocol overhead added; transparent to the RLC
o Used for signalling SRB (e.g. broadcast SRB on BCCH, paging
SRBs on PCH), voice services and CS data
• UM data transfer
o Buffer control of RLC SDUs for smoothing data rate variations
introduced by burst-traffic sources (e.g. TCP flow control) and
lower layer variations
o Segmentation, concatenation and padding into RLC PDUs. Each
PDU is transferred as one physical layer TB.
o Reassembly of PHY data from TB into RLC PDUs and RLC SDUs
o Used for fast signalling (e.g. SRB1 on DCCH)
• AM data transfer
o
o UM data transfer features plus
o Error control feedback, retransmission of erroneous or lost PDUs
and in sequence delivery of RLC PDUs by ARQ
o Used for signalling (SRB 2-4) and PS data services
There is one pair of AM RLC entities per RB. In the following TM is not
considered any further because there is no performance impact due to RLC.
Figure 26 below is showing the UMTS protocol stack of the user plane for a
TCP/IP data application:
Figure 26: UMTS protocol stack of the userplane for a TCP/IP application
TCP has its own flow control and ARQ algorithms so the O&M parameter of
RLC has to be adapted to interwork with TCP in an optimal way. Because the
TCP settings could be different on each client PC (and the corresponding server
in the Internet or corporate business network) a reference client-server system
should be defined and used to optimise the RLC settings.
16
A RLC PDU for PS RB has a size of 42 bytes (40 byte payload and 2 byte
header), which is relatively small compared to a TCP/IP packet size of around
17
1000 byte . As a consequence retransmission on RLC results in a
retransmission of relatively small amount of data compared to that on TCP/IP
layer. Furthermore if a data PDU is not completely filled with data of one SDU,
concatenation and/or padding are applied.
For each TB set the PHY is performing a CRC check; in the UL the NodeB is
adding the CRCI to each TB set (see also subsection 7.1.2.1). Furthermore the
physical frames on Iub are protected by additional CRCs. If one of both CRC
fails lower layer discards the whole frame on Iub / the whole TB set. It is up to
the RLC of how to react on lost data and possibly initiate retransmission.
16
The size of signaling SRBs is 16 bytes plus 2 bytes header
17
The size of the TCP/IP packet is depending on the MSS negotiated for each TCP session during the
connection setup. In addition it might be that the IP packet is further segmented by one Internet server
routing the packets
SM SM
SM MM
IP PMM PMM IP
MM SM Q2150.1
PDCP RRC RRC PDCP GTP-U GTP-C GTP-U
GTP-U GTP-C
PHYRRC RRC
RANAP RANAP
Q2150.1
RLC FP UDP UDP
codec RLC RLC UDP
RLC Q2150.1
MAC MAC Iu UP
MAC MAC
Phy-up ALCAP
Phy-up ALCAP Phy-up IP SCCP SCCP IP IP
Phy-up SCCP SCCP Q2150.1 Q2150.
MAC-hs STC.2 NBAP NBAP STC.2 MTP3-b MTP3-b 1
NBAP ALCAP MTP3B MTP3B MTP3B
HS-
DCH HS- SSCF-UNI SSCF-UNI FP SSCF-N SSCF-N
SSCF SSCF DSCH DCH SSCF SSCF SSCF SSCF
FP DSCH
FP FP
PHY PHY PHY PHY FP SSCOP SSCOP SSCOP SSCOP SSCOP
SSCOP SSCOP SSCOP SSCOP
DCH HSDPA HSDPA DCH PHY
AAL2 AAL5 AAL5 AAL2 AAL5 AAL5 L2 L2
AAL5 AAL5 AAL2 AAL2 AAL5 AAL5 AAL5 AAL5 AAL5
AAL2
ATM ATM ATM L1 L1
ATM ATM
E1/ STM-1 STM-1 STM-1
E1 E1
Transmission gap Uu, TCP Cross-correlation Uu and TCP trace: during a Transport Channel
during HO in Reconfiguration / Radio Bearer Reconfiguration procedure there is a
HSDPA call transmission gap on TCP layer in the DL for x seconds
1800
1600
1200
1000
800
600
400
200
0
0 5 10 15 20 25
CQI
1800
1600
1400
App Fwd Throughput [kbps]
1200
1000
800
600
400
200
0
-20 -18 -16 -14 -12 -10 -8 -6 -4
Ec/No [dB]
6.15.4. UE limitations
HSDPA capable terminals with resulting peak data rates ranging from 1.2 Mbit/s
to 14 Mbit/s at physical layer, see also [14] and [16]. Depending on the terminal
type different maximum number of HS-DSCH codes, different maximum TBS or
modulation schemes are supported. As a consequence the maximum
achievable throughput is terminal dependent and should be taken into
consideration when analysing HSDPA UE traces.
As described in subsection 6.15.3 currently the UE is the limiting factor in case
of optimal RF conditions.
Some relavent KPIs/Counters are given that deal with the handover aspect of
HSUPA
PM Counter/KPI KPI Name / Description
system
UtranCell (VS.SuccServCellChangeEDCH / EDCH Serving Cell change Success
VS.AttServCellChangeEDCH)*100 rate
UtranCell VS.ReconfSucc.EDCH-HSDSCH_ULDCH-HSDSCH Total number of successful
reconfiguration E-DCH to DCH in UL
with HSDPA in DL
UtranCell VS.ReconfSucc.ULDCH-HSDSCH_EDCH-HSDSCH Total number of successful
reconfiguration DCH to E-DCH in UL
with HSDPA in DL
current grant. This can act as an indicator of how fairly each UE is being
scheduled.
Under bad RF conditions the UE is likely to be transmitting at high power to
reach the NodeB and hence will not have sufficient power available to send the
data resulting in loss of throughput.
6.16.4. UE Limitations
HSUPA capable terminals have peak data rates ranging from 0.7 Mbit/s to 5.7
Mbit/s at physical layer, see also [14] and [17]. Depending on the terminal type,
various options for maximum number of UL codes, minimum SF and TTI
durations are supported. As a consequence the maximum achievable
throughput is terminal dependent and should be taken into consideration when
analysing HSUPA UE traces.
Figure 32: User versus Cell throughput variation with increase in users
Parameter Description
IRATHORelocGuardTimer This parameter configuring the IRAT-HO relocation guard timer.
RelocationGuardTimer This parameter configuring the relocation guard timer.
7. Call quality
In this section those aspects are investigated that have a direct influence of the
user perceived call quality. In the first part the BLER in the DL and UL is
discussed. The second part gives a definition of the Quality of Service (QoS)
parameters for the different types of services like voice, data and VT and a
description of performance weaknesses and of how to overcome these issues.
belong to different RNCs the SRNC is doing the frame selection; the data is
provided via the Iur interface.
For each UL TB set the NodeB is performing a CRC check on PHY and adding
a CRCI to the frame. In addition the quality of the link is estimated; the QE in
each TB provides the results. The QE is vendor proprietary, different metrics
might be used to derive it. The QE ranges from 0 to 255 (small QEs are
indicating good quality).
UL inner loop PC:
The UL inner loop PC is adjusting the transmit power of the UE in order to
achieve the provided SIR target. All NodeBs involved in the particular call are
sending TPC commands with a rate of up to 1500 Hz. The TPC commands of
the particular NodeBs can differ. In this case if only one of the NodeBs is
sending a “power down” command, the UE will lower its transmit power by the
defined power-down-step. In case there is no TPC at all the transmit power of
the UE remains unchanged.
More information including parameter can be found in [28].
18
Note that according to the 3GPP specification there are four power classes defined (power class 1 to 4) with maximum
output power +33 dBm, +27 dBm, +24 dBm and +21 dBm. The most common mobiles on the market are class 3 (+24 dBm).
Table 70 below is giving the QoS parameter for voice services. For the voice
quality evaluation the Mean Opinion Score (MOS) is used. The MOS is defined
by the ITU and is ranging from 1 to 5, for details see also ITU P.800 and ITU
P.862. For further discussion on the MOS performance of various AMR codec
rates see [47]. A good voice quality can be considered when the MOS is
exceeding 3.0. Voice quality degradations like e.g. echo or voice delay are
reflected by this measure.
threshold). The RNC may or may not react on this Measurement Report by
doing a RB reconfiguration (see subsection 5.4.1 and 6.17.1). Furthermore a
smaller RB can be assigned in case of overload estimations done by the RNC
(subsection 6.5).
Another difference when describing the PS data user perceived QoS is that a
drop of the RAB and RRC connection does not (necessarily) mean that the PDP
Context is removed from the GGSN or the FTP session drops. After the new
establishment of the RRC connection and the new establishment of the RAB
the FTP session can be resumed in case the session has not timed out in
between. For the user the drop of the RRC and RAB is visible by stalling of the
FTP transfer for the particular timeframe and because of low throughput rates.
In case of real time applications like video streaming or web radio the drop will
be noticed by the user if the buffer of the application is emptied and no new
data is received. It might be that the application will re-start with codecs
requiring lower bandwidth to fill the internal buffer again.
On the PPP link of the PS data session the TCP/IP header and data can be
compressed resulting in a throughput increase. For most Microsoft platforms,
the PPP compression is an available option in the PPP settings of the dial-up
networking. .
In addition also the PDCP layer is providing header compression for e.g. TCP,
UDP, RTP and IP header [40].
Simple FTP-download tests of files with the size of 1MB in the UMTS networks
has shown that the throughput for zipped binary files is around 25% less
compared with the ASCII files.
Appendix
A. Measurement definition
A.1. Measurement definition – voice
For voice services the UMTS UE in the drive test van should call an ISDN line in
the PLMN because otherwise it is hard to distinguish if the first or the second
mobile is responsible for observed failures or also for voice quality
degradations. This will help the RF planner to analyse the failure and propose
additional network changes.
The voice test call sequence for the UMTS UE in the drive test van should be as
follows:
• Network attach
• Mobile Originating Call (MOC), duration 2 minutes, alternating speech
sample from the UE to the PLMN and vice versa.
• Network detach and pause of around 10 seconds
• Network attach
• Mobile Terminating Call (MTC), duration 2 minutes, alternating speech
sample from UE to the PLMN and vice versa.
• Network detach and pause of around 10 seconds
The used drive test equipment should be capable of do generating this
measurement sequence automatically.
In parallel the RF conditions of the UE and the neighbouring cells should be
recorded using the drive test tool and a 3G and 2G scanner in parallel.
19
The original DOS FTP client should be used instead the FTP client from cygwin (/usr/bin/ftp). This
can be achieved by defining a variable called FTP_CMD = “c:\winnt\system32\ftp.exe” in the scripts.
The TCP/IP settings can be verified using Ethereal. The settings can be set for
Windows PCs in the registry or with help of shareware tools like [39]. For UNIX
and Linux operating systems the settings can be set in the corresponding
configuration files.
In case ciphering on RLC/MAC and data compression on PPP/PDCP are not
used, special prepared ASCII files shall be used. This will ease the identification
of each single packet in Ethereal, Iub or Iu traces to detect retransmission on
TCP or RLC. Note that on Iu, Gn and Gi there is no compression and ciphering
used so using the particular tracing equipment can identify the ASCII payload.
The special ASCII files should contain only one (!) line and as an example the
following sequence:
“umts000000000umts000000001umts000000002umts000000003umts0000000
04umts000000005umts000000006 …”
In case PPP data compression is on, zipped data shall be used to avoid
irregular throughput measurements.
Finally care should be taken that no other application on the PC are generating
any unnecessary network traffic.
Figure 38 below is showing a snapshot of the Ethereal protocol analyser:
Uu
(cabled)
Stationary
voice/VT
evaluation drive 2nd mobile in
test equipment shadowing box
Uu
(cabled) Iub Iu
UMTS protocol
analyser
Local
NTP server